Team FYI Below are several techniques that may give you some idea on how to do it...
1. Use SNMP to poll all of your switches and look for OUI codes in the CAM tables of well known router product vendors. 2. Using differences in time stamps in the TCP headers and IP ID's. 3. Using inline reverse TCP connections tracerouting to endhosts. 4. Examining the TTL of packets returned in a traceroute map of your network. 5) Query the local DHCP server on the local network 6) Using a script to dump ipconfig /all of local network machines to see where default gw, default DNS, etc. is pointed 7) Run whois queries with your company name 8) Talk with purchasing dept and give them 'keywords' that they can use to look through purchases. 9) Dumping arp cache to have knowledge of machines. 10) If all internet traffic is supposed to pass through an internet firewall or proxy, look for "lack of traffic" from IP blocks on your WAN. Even a regular windows machine sitting at rest is sending out queries to windows update, NTP, DNS, etc. 11) DNS servers, who is sending queries to your recursive server and more 12.) Get the MAC address of each node on the network. The first half of each MAC address is vendor specific. These could give you clues. If you see a Cisco NIC, for example, where you know that your organization uses 3Com NICs in your systems, that might be a good place to look. If you can connect to each of your organization's switches, these will readily available, and reliable. If it's not in your switch's MAC table, it's probably not getting any frames. Perhaps a quick shell script to loop through an IP address range and ARP each would give you what you need. Keep in mind that you'll need to launch the arp command from a node on the target subnet. If not, everything will point to your next hop router. If you're in a windows environment, try nbtstat. 13) nmap has some features that could help. The standard "nmap -sS -v -O 172.16.0.0/16" CL will give you lots of info to weed out the majority of PCs, servers and printers. Maybe use -PO to scan for IP addresses that have certain protocols enabled that most hosts do not ( http://nmap.org/svn/nmap-protocols). Check out other capabilities thatcould point out differences between hosts. 14) Remember that almost any host on a network could have routing capability, so don't eliminate them as possible offenders too early. The connection that you seek may be on the other side of a windows or *nix machine. It may prove beneficial to retrieve the routing table from each host. (eg: "ROUTE PRINT" at a windows CL will show the interfaces and routes for that host) 15) If these pathways are being established covertly, they may be more difficult to detect as they may not be physical devices or connections. It is pretty easy to set up an encrypted tunnel through a proxy server and firewall and use a virtual interface that routes through this tunnel. You could retrieve processes from each host and examine/scan each list. It might be easier to generate a packet that will be routed to an internet IP (send spoofed packets to every internal host that will be responded to via the internet). I hope these are good to start with and find all that is required for this subject. Regards Sandeep Thakur On Wed, May 19, 2010 at 6:49 AM, N41K <[email protected]> wrote: > Even I was thinking of trying a workaround for such illegal sources. > After doing some groundwork I found that these needs to have good > understanding of L2 and L3 also the L7 (Layers of OSI). Because these > protocols reveal much information of the devices. Hope if Some one has > answer for the questions it would be of great help. > > General Observations: > 1. An rogue Access Point, Open for everyone to access may have > keylogger.... > 2. An rogue DHCP Server invoked in a network... > 3. Etc.. > > On May 18, 6:15 pm, Sandeep Thakur <[email protected]> wrote: > > hi all, one of my colleagues question for your study/answer: > > > --------------------------------------------------------------------------------------- > > I have a somewhat difficult problem to crack - there is a large corporate > > network which covers several Nordic countries, and unfortunately there > have > > been cases in the past where a device with routing capability has been > > plugged into the network (for creating a "faster" connection to the > internet > > for a branch office). Because this violates corporate policies and > creates > > "invisible" entry points to the internal network, I have been given a > task > > to find a suitable software for finding such kind of illegal routers. > > > > Are there any good products for detecting illegally installed boxes with > a > > routing capability? One of my fellow consultants suggested IP Sonar (by > > Lumeta) for this purpose which (as he claims) has been successfully used > by > > BT in the past. From the product description I've got an impression that > IP > > Sonar cleverly uses traceroute for detecting routers that illegally > exchange > > information between internal networks and the internet (so called > "network > > leaks"). > > > > I understand that router detection is a complex issue, and in order to > > address this problem fully, one needs to analyze traffic that flows > through > > all key routers and switches in the whole corporate network. > Unfortunately, > > since the deployment of such monitoring system takes a lot of time, I'd > like > > to begin with a relatively simple solution which attempts to locate > network > > leaks by polling the network from few points only (like IP Sonar does, > using > > traceroute for that purpose). > > > > Can anyone recommend any such commercial or open source tools? (open > source > > utilities are my preference :) > > > > Thanks in advance! > > > > -- > > You received this message because you are subscribed to the Google Groups > "nforceit" group. > > To post to this group, send an email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<nforceit%[email protected]> > . > > For more options, visit this group athttp:// > groups.google.com/group/nforceit?hl=en-GB. > > -- > You received this message because you are subscribed to the Google Groups > "nforceit" group. > To post to this group, send an email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nforceit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nforceit?hl=en-GB. > > -- You received this message because you are subscribed to the Google Groups "nforceit" group. To post to this group, send an email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
