Router Prevention

[usafbran]

Ok - I'll just give you my literal real-world scenario that i'll be undertaking in about two weeks, and this is the last of my problems that I need to fix.

I own a satellite dish through bentley walker with whom which I subscribe with for internet service. I'll soon be heading back from R&R when which I will be returning with about $3500 of server and networking hardware to sell internet to approximately 40 users. I will be using a simple linksys router with tomato firmware as this will more than cover all the QOS features I require. The 48 port switch I will be using is a DGS 1248T, which in itself is overly sufficient for my needs.

Now, as we all know, MAC Spoofing is a reality. I can assign static IPs and MACs to each port on the switch. Here's the thing though, Internet in Iraq is a high comodity - it's realistic that someone would hook their own router into my switch port without me knowing and route off my connection or something else malicious of that nature. HOW CAN I PREVENT A ROUTER FROM WORKING AFTER BEING PLUGGED INTO MY SWITCH. Even if i use VPN etc... any router will setup a connection in that manner...what can I do?

 

[jdabbs]

I think it'd be easy to identify routers by monitoring TTLs (port mirroring+Wireshark) or OS fingerprinting (nmap), but blocking them outright is more difficult.

 

[usafbran]

I could live with identifying the problem as opposed to not knowing at all - I can easily remove the culprit if i know who they are - and the fact that I can advertise to the customer I can see when they do it will prevent 99% of them from even trying, unless they're the kind that always think they're smarter.

 

[jdabbs]

When I get back from lab tonight I'll do a few test runs with a recent version of nmap, and pass the commands and observations along.

 

[usafbran]

Thanks - also, I'm not getting into a matter of ethics here am I - I wont be capturing like naked pictures of peoples wives or their bank account information, correct?

 

[jdabbs]

Thanks - also, I'm not getting into a matter of ethics here am I - I wont be capturing like naked pictures of peoples wives or their bank account information, correct?

To inspect TTLs, you need to be able to observe the traffic in your network. Setting up port mirroring and sniffing enables you to do this, as well as snagging passwords sent cleartext (FTP, POP3, many non-eCommerce sites) and rebuild any unencrypted pages and data (emails, images). But it would take a deliberate effort on your part to do these things.

I set up a Wireshark filter to catch packets with a decremented TTL for a 192.168.1.0/24 network:
ip.src_host contains "192.168.1" && !ip.dst_host contains "192.168.1" && ip.ttl <= 127 && !eth.ig == 1
In plain English, that's packets from your hosts that aren't being sent to your hosts that have a TTL of 127 or lower and are not multicast. Adding the multicast qualifier filters out a lot of garbage, but there may be some stuff that slips through--a quick Google search will help identify this traffic.

OS fingerprinting is just port scanning a computer, and using the response to profile it. As an example, if you wanted to scan the hosts on the Class C subnet 192.168.1.0, the nmap command would be nmap -O 192.168.1.0/24. During testing, I found that client-side firewalls have made this method much less of a slam dunk than it used to be, but nmap was still able to identify my Vista laptop (w/ Windows firewall) as a Windows system. It couldn't identify the router I added, but the fact that the device could not be identified is still useful information. In your case, I'd do a scan of the devices on your work, then do periodic scans later to check for changes. Being no longer able to identify a Windows system may warrant additional scrutiny (though it may be them adding a third-party firewall, which I haven't tested). The Zenmap GUI allows you to save scans, so it shouldn't be too difficult to track changes. The -O parameter is very basic; I haven't kept up with nmap so you may get more precise results with additional parameters. If you go the port scanning route, I recommend asking around to see what other people recommend.

 

[usafbran]

Well, the wireshark method is a little over my head as i've never used the program before - i did however get it set up with the filter string you provided. Given what it's shooting back at me - I'm not really sure what i'd be looking for to identify the usage of a router other than my own. My own IPs are 192.168.1.x so im not sure how i'd see the IPs from another router - or is this even what i'm looking for?

 

[jdabbs]

A hidden router on your network would use the same IP to pass traffic as the client it is masquerading as. This is NAT. TTLs (see simulation) exist to keep packets from bouncing around the network forever. The filter is based on the assumption that traffic from your hosts default to a TTL of 128 (with exceptions); since packets traveling through a router (a hop) decrement the TTL, you'd be able to identify router usage through lower TTLs. The destination filter was added to drop client-to-client traffic.

You wouldn't be able to test unless you are on a hub or have port mirroring enabled; switches are efficient in that they try to send packets (frames, really) to the proper destination port instead of all ports. Good for traffic, bad for sniffing.

 

[usafbran]

Ok - let me regurgitate this how my brain translated it. I'm plugged into the switch mirroring a suspected port - all traffic from a legitimate client will have a TTL of 128 as it's the first hop and will be filtered out. Traffic from a client behind a router plugged into the port i'm mirroring will have a TTL of 127 or lower because it hits their router first then hits my switch - is this the jist of it?

 

[usafbran]

Oh and here's an idea - tell me if this is legitimate. Can I change the TTL of incoming packets to 1 when they hit the switch - so they time out at the next hop, making a router plugged into my switch useless?

 

[jdabbs]

Ok - let me regurgitate this how my brain translated it. I'm plugged into the switch mirroring a suspected port - all traffic from a legitimate client will have a TTL of 128 as it's the first hop and will be filtered out. Traffic from a client behind a router plugged into the port i'm mirroring will have a TTL of 127 or lower because it hits their router first then hits my switch - is this the jist of it?

Some traffic will not have a TTL of 128--some local traffic will have 64 and multicast will have 1. Whatever legitimate traffic that does get caught by the filter should be discernible from web traffic behind a router.

As for setting Internet>LAN traffic to TTL 1, I think that'sa feasible solution, but the difficulty is in setting up a device to do it. Googling shows several references to modifying TTL, but usually in conjunction with attempts to work around ISP restrictions.

 

[usafbran]

Well, I have a computer that will be used solely as a server (not server software-vista 64 ultimate) Maybe i can put it in the routing chain. Between the router and switch perhaps?

 

[jdabbs]

I don't know if you have a utility in mind using Vista, but it looks like iptables for Linux may be able to do the job.

 

[usafbran]

I'm scared of linux - i have 20 years experience with windows and none with linux. Maybe i'll install both and give linux a go.

 

[YeOldeStonecat]

As an ISP you'd want a NAC (network access control). You have ultimate authority as to who/what connects to your network.

 

[usafbran]

Would this require me to implement a domain (i'd assume not) or use server software(I have vista ultimate 64 bit)?

 

[YeOldeStonecat]

No they're generally hardware appliances.