How can I connect a system to a network and sniff for virus/spyware related traffic? I'd like to plug in a network cable, fire up an appropriate tool sand have it scan the data for any signs of problems. I don't expect this to find everything, and this is not to prevent initial infection but to help determine if there is anything trying to actively infect other system/causing network problems.
Running a regular network sniffer and manually looking through the results is no good unless the traffic is really obvious,but I havn't been able to find any tool to scan a network data stream automatically.
I highly recommend running Snort on a machine somewhere near the core of your network, and span (mirror) one (or more) ports from somewhere along your core network path to the machine in question.
Snort has the ability to scan network traffic it sees, and automatically notify you via various methods if it sees something suspicious. This could even be taken further, if desired, to automatically disconnect devices, et cetera, if it finds something.
Use snort: An open source network intrusion prevention and detection system.
Wireshark, formerly ethereal is a great tool, but will not notify you or scan for viruses. Wireshark is a free packet sniffer and protocol analyzer.
Use the netstat -b command to see which processes have which ports open.
Use CPorts to see a list of ports and the associated programs, and have the ability to close those ports.
Download a free anti-virus program such as free AVG.
Setup your firewall more tightly.
Setup a gateway computer to let all network traffic go through. Take the above recommendataions to the gateway computer instead. You will be checking your whole network instead of just your one computer.
You can make Snort scan traffic for viruses. I think this will be the best solution for you.
For watching local network traffic your best bet (with a decent switch) is to set your switch to route all packets out a specific interface (as well as whatever interface it would normally send). This lets you monitor the entire network by dumping traffic down a specific port.
On a 100 megabit network, however, you'll want a gigabit port on your switch to plug it into, or to filter on protocol (e.g. trim out HTTP, FTP, printing, traffic from the fileserver, etc.), or your switch's buffers are going to fill up pretty much instantly and it'll start dropping whatever packets it needs to (and your network performance will die).
The problem with that approach is that most networks today are on switches, not hubs. So, if you plug a machine with a packet sniffer into the switch, it will only be able to see traffic to and from the sniffing machine; and network broadcasts.
As a followup to Ferruccio's comment you will need to find some method of getting around your switches.
A number of network switches have the option of setting up port mirrors, so that all traffic (regardless of the destination) will be copied, or "mirrored", to a nominated port. If you could configure your switch to do this then you would be able to attach your network sniffer here.
Network Magic, if you don't mind something that's not open source.
You can use an IDS, hardware or software
http://en.wikipedia.org/wiki/Intrusion-detection_system
Related
I ask myself that for some days now, and couldn't find a clear answer.
Imagine a network with several rooms, each room with it's own (Layer 2) Switch.
Those are then connected in star topology to another switch which is then connected to the router.
All Clients get IPs from the same range, all clients are in the same subnet and in the same VLAN.
Do you know a way how to determine, which client is connected to which switch, without involving the switch. E.g only with technologies and mechanisms taking place on the client.
The goal would be to be able to draw automated maps of the client distribution in the network, but, as I said, without involving the switch (for example access it's API or somethign like that).
Regards
Me
I am afraid that you are right: In general, in a "normal" Network (which means: In a Network with just Standard Switches and Routers), there is no way to do so.
Only if the Switches were managed, you could write a script which polls the arp-tables from the Switches, but of course this doesn't work with unmanaged Switches.
I realised that there is no way to do this.
The problem is, that a normal network switch, which works on Layer 2 of the OSI model, is not "visible" for tools like traceroute or such.
If you want to traceroute to, lets say: google.com, your traceroute application sends a packet with a TTL of 1 to your default gateway. Your default gateway then decreases the TTL and discards the package, because it has reached a TTL of 0.
Because of that, it answers to your computer and your computer can record, from where it received the first answer.
It then sends again a package to google.com, but this time with a TTL of 2, and the process begins from start.
Now you can't do with switches what you can do with routers, because (normal layer 2) switches do not know about IP...
Cisco offers a layer2 traceroute utility, but this is limited to the cisco ecosystem and only works with cisco hardware.
So, I fear the answer is, that it is not possible in general.
I have a small home network that I would like to analyze and capture the traffic on. What are my options for doing this? Ultimately, I would like to use a packet capture library, such as libpcap, to sniff the network in real-time as my router receives packets. I'm mainly interested in HTTP traffic. Thus far, when I run my program, I only seem to be able to see packets sourced or destined to my machine. Is there a way that I may inspect any traffic that travels through my wireless modem/router?
From the research I've done, it seems that the only way this is possible is through ARP poisoning or using a CISCO router that features Embedded Packet Capture.
Has anyone tried either of these and how successful were you? Are these my only options or is there something I may have overlooked?
Hi :) I think ARP poisoning and so on is not so easy to drop in.. ;) but you could start by trying one of the most famous network packets analyzer: Wireshark. Networking is very far to be easy.. :P but Wireshark will help you a lot and, btw, supports also libcap. Hope that helps :)
I have created a bandwidth meter application to measure total Internet traffic. I need to test the application with relatively high data transfer rates, such as 4 Mbps. I have a slow Internet connection, so I need a simulator to test my application to see the behavior with high throughput rates.
As an option, you can run some HTTP server in one virtual machine with NAT'ed network adapter and test your bandwidth meter against it from the host system or a similar VM.
There are commercial packet generators that do this, and also a few freely available ones like PackETH and Bit-Twist.
There are also other creative solutions. For example, do the packets need to be IP packets for your purpose? If not, you could always get a "dumb" switch or hub (no spanning-tree or other loop protection) and plug a crossover cable into it. (or a straight-through Ethernet cable would work if the switch supports Auto-MDIX) The idea would be that with a loop in your network, the hub/switch will flood the network to 100% for you since it will continually re-forward the same packets.
If you try this, be sure yours is the only computer on the network, since this technique will effectively render it useless. ;-)
You could always send some IP broadcast packets to "seed" the loop. Otherwise, the first thing I think you'd likely see is broadcast ARP packets, which won't help if you're measuring layer 3 traffic only.
Lastly, (and especially if this sounds like too much trouble) I recommend you read up on dependency injection and refactor your code so you can test it without the need for a high-speed interface. Of course, you'll still need to test your code in a real high-speed environment, but doing this will give you much more confidence in your code.
I'm working on a Wake on LAN service that will run from a web site and should interact with many different platforms - therefore, no Windows-only solutions. When a user registers their system with the web site, I need to get the MAC address to use in constructing the "magic" packet. I have a Java Applet that is able to do this for me and am aware of an ActiveX control that will work, but I'm wondering if there is a way to do this server-side by querying routers/switches. Since the system may be on any of a number of different physical subnets, using ARP won't work -- unless there's a way to configure the router(s) to perform the ARP on my behalf.
Anyone know of any network APIs, proprietary or otherwise, that can be used to look up MAC addresses given an IP address? I think we're using Cisco routers, but it's a complicated network and there may be multiple vendors involved at various levels. I'd like to get some background information on possible solutions before I go to make a sacrifice to the network gods. No point in abasing myself if it's not technically possible. :-)
EDIT: We do have the network infrastructure set up to allow directed broadcast, though figuring out the exact broadcast address since netmasks are not always /24 is another conundrum that I need to solve.
If you are on a local network that uses DHCP you might be able to look in the servers database to get the MAC of the last user with that address. In the future you could watch the network for ARP requests and cache the responses in some sort of table. You might also look at using RMON or SNMP to try and query the Address Tables on the switches and routers.
It should be noted that to use WoL across routers you either need to enable Directed Broadcasts or you need to have a relay server in the local segment.
Been a while since I played routers and swtiches but this might be a starting point for what to query using SNMP http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00801c9199.shtml
Use the following:
getmac /s destIp
To get the remote session Mac address.
I don't know if these might be helpful but take a look:
http://www.webdeveloper.com/forum/showthread.php?t=134120
http://www.qualitycodes.com/tutorial.php?articleid=19
You've said everything I can think of...
The source MAC address changes as a packet hops from device to device so unless the client is on the same subnet, the server won't be able to get the MAC address. (You would do it via ARP)
A signed java applet or activex control would be the easiest solution. It would be able to (almost passively) get all the networking info you need (IE doesn't even prompt to run a signed applet)
If you are fully aware of the network that is using the service then you could probably query a gateway's client-list via SNMP or CDP. You would be able to map out IP-Addresses to MAC addresses... but this is really vendor dependent (but common) and wouldn't be much better (imo) than having an applet.
Currently the application is using a Java 6 applet that allows me to extract both the hostname and the MAC address from the remote system. I don't like having this dependency on Java 6, but Snow Leopard and Windows both support it, so I can probably live with it.
On a related-front our networking folks approached me for some help with converting some existing code to ASP.NET. During the conversation I asked if they had live MAC address information (since they do port shutoffs based on suspicious network activity -- viruses/worms). Turns out they do and we may be able to leverage this project to get access to the information from the network database.
I don't think there is any way to accomplish this. When the IP packet goes via the first router the host's MAC information is lost (as you know MAC is only used in ethernet layer). If the router most close to your PC was capable of telling the remote MAC code to you, again it would only see the MAC of the next router between your PC and the "other end".
Start sacrificing.
There's no general way to do this in terms of the network unless you have no routers involved. With a router involved, you will never see the MAC address of the originating system.
This assumes that the originating system only ever has a single network interface, so has only a single MAC address.
In fact, are you even sure that your "magic packet" (whatever that is) will reach the system you want it to reach, through the routers? That sounds like a function the routers or other network infrastructure should be performing.
Mac address is only used on network segments, and is lost at each hop. Only IP is preserved for end-to-end - and even then the from ip address is rewritten when Natted. I guess my answer is, not possible unless everything is on the same network segment, or your routers are set up for proxy arp (which is not really realistic).
You can only get MAC entries in the ARP table for machines on the same network. If you connect to a machine via a router then you will only see the routers MAC address in the ARP table. So there is no way of knowing the foreign host’s MAC address unless it's a host on the same network (no routers involved).
And by the way there are many similar question already on SO.
if it's a windows system you can use NBTSTAT -A
this will return the netbios info and the IP is there
any Management system like SMS or Altiris will have this info
The DHCP server is a good idea
If it's local you can ping it and then quickly run ARP -a
look for the IP and the MAC will be there.
you might need to write a small batch file.
if you have access to the PC you can use WMI to access the info for the Nic with DHCP.
As said above we can get mac address from a known IP address if that host is in the same subnet. First ping that ip; then look at arp -a | grep and parse the string on nix* to get mac address.
We can issue system command from all programming languages standard API's and can parse the output to get mac address.Java api can ping an IP but I am not sure if we parse the ping output(some library can do it).
It would be better to avoid issuing system command and find an alternative solution as it is not really Platform Independent way of doing it.
Courtesy: Professor Saleem Bhatti
I'm trying to confirm a user a unplugged my embedded device from a network before performing some maintenance. I'm considering "ping"ing all IP address on my sub-net, but that sounds crude. Is there a broadcast/ARP method that might work better?
You can try a broadcast ping (this is from linux):
ping -b 255.255.255.255
Another option is to download Nmap and do a ping-scan.
You could use nmap. It's still crude, but at least it's using a tool designed to do it so you don't have to spend time on it.
If you can't get reliable link state information from your Ethernet device (which most chipsets should support these days, BTW...), sending an ARP request for each IP on your local subnet is a decent substitute. The overhead is minimal, and as soon as you get a single response, you can be sure you're still connected to a network.
The only possible problem I see here, is that if your device is on a /8 subnet, it can take quite a while to loop through all 4294967296 possible IPs. So, you may want to consider some optimization, such as only sending ARP requests for your default gateway, as well as all IPs currently in your ARP table.
If there's a peer you know you were connected to recently you could try pinging or arping that first. That could cut down on the traffic you're generating.
you could also run tcpdump -n to see what's active on the network too.
Not receiving any responses to ICMP pings or ARP requests is not a 100% guarantee that there's no network connection. For instances, there might be devices on the network that are firewalled off.
EDIT: May be you could access some lower-level information on your embedded device to check whether the network interface has its link up without actually sending any data.
Is there any chance that your device supports UPnP or Bonjour? Beside of the low-level protocols your should also have a look at these protocols which support some kind of plug-&-Play functionality. A UPnP device for example sends a message on the LAN before it is switched off (though, this doesn't help if it is just removed by unplugging it...).