Click to See Complete Forum and Search --> : Militant network watchdog?


scoobydope
04-13-2001, 08:47 PM
Ok, to be honest, i couldn't figure out which area to post this in. Its sorta software related.... it could definately fit into security related, and also the networking area would have an interest/solution in the topic. Not to mention the programming folk.

So I am posting it in "General" for lack of a better place to put it.

Basically this is the situation: I have around 600 hosts on a network. Recently it became clear that I have to maintain an absolute sentinel on the IP addresses that are connected to the network. Its fairly easy for a computer to anonymously connect to the network without me seeing it right away. (this is a residential complex with all these apartments connected) The system HAS to run DHCP off an NT server for several reasons.... This, however, leaves open the possibility of anybody connecting their PC to the network and successfully obtaining an IP address. There are live RJ45 jacks located in every suite. (all 550 of them in both 38 story highrises)

Of course, Windows NT has no way to stop assigning DHCP IP addresses. It just gleefully keeps giving them out (192.168.0.0/16). That's like sixtyfive thousand some odd addresses. Sure, i have blocked most of them from being assigned, but there are still many possibilities for getting an IP.
The other crazy thing about NT is that even if you are running DHCP and NEVER assigning static IP addresses, there is nothing stopping someone from assigning themselves their own IP as long as they knew the gateway, subnet and DNS settings. (which they can copy from any legitimately connected system on the network).
The worst part about that is that the only way I, as the administrator, have any idea what is going on with the IP assignments, is through NT's DHCP log that is generated on the fly every day. It gives me the time, IP and mac address of the system connecting. Great, but anybody on the network can set up their system with a static IP and get a solid connection to the network WITHOUT making any entries in the DHCP log or any other log for that matter.

The only way i have found to keep an eye on ALL the systems connected to the network was by running 'superscan' for win98 and sweeping the entire subnet. This worked of course, but i had to run it manually and try to mentally keep track of the differences.

Enter Linux.

I built a new box to connect to the network. I blocked all the ports and servers on it (identd, wu-ftp etc) and set it up running ethereal, portsentry and arpwatch.
the little snoop doggy dogg on the network.

This successfully logs every change of IP address, every new system and every time a MAC address gets a new IP on the whole network.

This also alerts me to people popping onto the network with statically assigned IP addresses.

The only problem is that they have to remain connected to the network in order for me to catch them. Kinda like the old movies where the police have to keep the kidnapper on the phone for as long as possible to complete the trace.
That is me running from hubcloset to hubcloset with my laptop, pinging the new IP and systematically unplugging each hub feed off the switch, then isolating the mother hub, and finally in that closet, ping the new IP and watch the led's on the hubs for a twin flash, connecting me to the final port that the computer is connected to. Then i trace that port to the punchdown panel and read the suite number.
faaaaarhhhgg.

unfortunately, most of these people are connecting at like 9:00am on a sunday morning, and disconnecting at noon the same day. I see that in the log files, but its too late for me to find out where they were coming from.

So what i am looking for, is something that will keep a watchful eye on the /var/log/messages file, and look for things like "flip flop, swapped IP address:"
and as soon as it sees an entry like that generated in the logfile
(cat /var/log/messages | grep flip) and as soon as it picks up the flag i set, ...
it triggers a script which emails my pager with a textline to alert me to the fact that two minutes ago, i got a new visitor on the network.

anyone? anyone?

FoBoT
04-13-2001, 09:13 PM
isn't that why big company networks use firewall/proxy combo's??

or do you have to provide total open access for all ports to all drops??

or am i missing something??

scoobydope
04-14-2001, 10:26 AM
unfortunately, we have to provide totally open ports.

milanuk
04-14-2001, 07:00 PM
I know nothing about WinNT DHCP, but isn't there some way of limiting the 'range' of addresses available? i.e. if there is 550 apartments, can't you limit the pool to say, 600, and have short renewal times to force them to periodically renew their dhcp lease's (not sure if that would help, just tossing out ideas)? Definitely makes for an interesting scenario. Hope it works out for the best.

Monte

scoobydope
04-15-2001, 11:28 AM
yeah, you can totally wipe out entire ranges of IP addresses that are going to be assigned. with 255.255.0.0 as the subnet, you could say that
192.168.0.2 - 192.168.255.1
are wiped out, meaning you will only have available a couple hundred addresses out of 65,635 possible ones.

BUT! the @#$@ing stupid thing is that ANYONE can just change their network settings and instead of "automatically getting" the IP, they can just manually assign any IP they want (EVEN THE ONES BLOCKED OFF DHCP!!) and it will work with no problems.
they want 192.168.20.20? no problem. etc etc

milanuk
04-15-2001, 01:09 PM
Originally posted by scoobydope:
<STRONG>BUT! the @#$@ing stupid thing is that ANYONE can just change their network settings and instead of "automatically getting" the IP, they can just manually assign any IP they want (EVEN THE ONES BLOCKED OFF DHCP!!) and it will work with no problems.
they want 192.168.20.20? no problem. etc etc</STRONG>

Umm... I'm just going out on a limb here, since I am no guru, and pussed out and use FreeSCO rather than roll my own firewall rules here, much less NT, but is it possible to have some sort of firewall or something where it _rejects_ connections on the internal interface that are _not_ in the IP range of the DHCP pool? It'd seem that that would slow down a lot of the BS, or at least make them use IP's w/i the given range. But that might cause problems w/ other hosts that may already have the same IP address, or use up IP addresses for legitimate folks. FSCK!! This doesn't make sense. It would seem to me that there has to be some way of 'controlling' this better when using DHCP. Have you tried on comp.os.linux.networking or comp.os.linux.security or something similar yet? Just an idea.

Monte

Strike
04-15-2001, 01:17 PM
If you have access to which computers are allowed to DHCP, then what you can do (in Linux, I'm assuming there's something similar in WinNT) is just limit the pool of IPs to people with a certain MAC address. You can even assign an IP based on MAC address.

milanuk
04-15-2001, 01:35 PM
Originally posted by Strike:
<STRONG>If you have access to which computers are allowed to DHCP, then what you can do (in Linux, I'm assuming there's something similar in WinNT) is just limit the pool of IPs to people with a certain MAC address. You can even assign an IP based on MAC address.</STRONG>

I think the problem w/ that is that he might not be able to get the MAC addresses of every machine; after all it's an apartment complex IIRC, and I doubt they'd go that far?? (unfortunate, I agree)

As far as a possible solution, I don't know what kind of DHCP server WinNT has, but this looks somewhat promising, from the ISC website:

Version 2 of the ISC DHCP Distribution, which was released in June of 1999, adds a DHCP Client and a DHCP/BOOTP Relay Agent to the DHCP Server that was offered in Version 1. Version 2 contains many changes that improve its correctness, as well as new features that enhance configurability. Some of the new capabilities include:

IP addresses are now tested before they are assigned to clients. This allows the DHCP server to detect rogue machines that may have hijacked IP addresses before an IP address conflict can occur.

The server may be configured so that some DHCP clients can be excluded from booting.

Improved NAKing behaviour, so that clients that are using addresses other than the one the server knows they should be using are disciplined quickly.
We recommend that most sites run version 2.0 at this point.


Version 3 (beta) sounds even better, but is not recommended for production sites as of yet.

Dunno, but this could be a heck of a good reason to recommend having a small Linux box just as a DHCP server (at least initially ;p ) and to put some teeth in the request to management. It might change their tune if they realize the dollars and cents that they lose by not using a quality DHCP server.

Monte

scoobydope
04-15-2001, 10:47 PM
Originally posted by Strike:
<STRONG>If you have access to which computers are allowed to DHCP, then what you can do (in Linux, I'm assuming there's something similar in WinNT) is just limit the pool of IPs to people with a certain MAC address. You can even assign an IP based on MAC address.</STRONG>

Yup, that works. As a matter of fact it's only by MAC that I assign the IPs to the whole network. I have been running arpwatch on the network for about 8 months now, so i am fairly confident that i have scooped EVERY single MAC address in the building (this comes in very handy when trying to isolate the few rogue computers)

So of all the IP's i am assigning, they are all legitimate. None of this stops the illegal connections tho.
What i need to be able to do is LIMIT the connections ONLY to DHCP. Anyone that tries to connect without obtaining the IP that i have given them will not get a connection.

That is my main problem. NT can't stop this

Which got me to thinking. There are two main switches in the towers. One taking a fiberoptic feed from the west tower, and a switch taking the 100mbs feed from the east tower.
If i were to stick a linux box between the gateway and the switch, then make up some sort of firewall thing that only allows through the IP address that I specify in the range i have given out... that would stop anybody from being able to assign their own IP

what a haywire solution tho. And network performance may be somewhat hindered as EVERYTHING is filtered again.

Damn you microsoft.

MkIII_Supra
04-16-2001, 12:18 AM
If you have all the required MAC addresses, why not modify an iptable or ipchain rule that allows only those MAC's to be given an IP. Thereby all other MAC address's are refused an IP.

I would write an example but I am really good at concepts, not so good at implementing them yet....

ashed
04-16-2001, 05:35 AM
While I'm not sure if this can be applied to your specific problem, it might give you some ideas...

About a month ago I had to lock down a wan connection from NYC to our central campus, catalog which boxes used the link and setup some sort of enforcement system so that if a user on either side joined the network (WinNT) without permission I could shut off the connection at the network level.

Step 1: The network.
Replaced all the switches with Nortel 450's and 350's, linked them together with some MM fiber. Each switch is assigned a IP and lets you telnet to it, making it a snap to not only trace back connections, but disable the port on the fly, no need to reset the switch and affect other users.

Step 2: Controlling IP's
Rebuild a SparcStation 5 with OpenBSD, made a transparent bridge which let me filter out IP addresses not assigned to known hosts. It also let me log alot of other interesting information about the overall network.

Step 3: Bringing it all together
Once the network had been changed over, and the filtering box had been dropped into place, it was easy to check in, from time to time to see what was going on. The Filter has 3 interfaces, 1 has a IP from the same range as the rest of the networking equipment making it easy to pull SNMP info from the switches, the other 2 are in bridge filtering out whatever I need them to. Once a IP is flagged and dropped by the IPF rules, a script emails me the IP, which I SSH to the Filtering box, then telnet to the switch and disable the port of the offending user.

... all from 1200 miles away.

Hope this helps, or at least gives you some ideas.

scoobydope
04-16-2001, 11:19 AM
saweeeet!

oh yeah, one more thing i forgot to mention. I have to come up with a solution that doesn't cost any money. :eek:

It sounds like your snmp mibs can actually trace an IP back to a specific port on the switch? That's great!
I wish our hubs could do that. If i had that option, it would be SO easy. I could just log in, see a new IP and go "oh hello, and where are you coming from?"

I am using Nortel's Optivity workgroup network management software, so i have a graphical representation of each hub and the bandwidth on a port by port basis, but unfortunately the hubs don't record the MAC or IP that is actually connected to the port.

If i suspect the rogue machine is connected to the east tower 34th floor hubcloset, I can ssh from my home office to the linux box in the 'dungeon' (east tower sub-basement) then from there telnet to the hub. With one console window i can ping the offender, and in the other console window i systematically turn off the ports on the hub one by one until the ping times out.
Unfortunately, these muddafudda's have a nasty habit of logging on at 2:00am, and logging off at like 7:00am. Leaving me clueless as to their origin.

On a completely different note, there has been one particularly nasty connection that was throwing all sorts of havoc into the network that i have been trying to catch since early March. Yesterday, (easter sunday) i checked the network from home, saw that that system was connected...
Jumped in my car with laptop in hand and raced to the building. and i got the muddafudda! :cool: FINALLY.

but thanks for the example of your solution. I think short of spending 10's of thousands on new network equipment, installing a couple new linux boxes to run the same sort of firewalling script between the switch and the gateway is the solution.

there are 620 valid MAC addresses in the building, so this is going to be some pretty hefty ipchains/tables scripting. ugh.