7

I am using college network to access internet. Many other users are using the same network. Recently I have been experiencing sluggish net connection. So when I did some investigation, I found that many other computers on the network have been sending ICMP packets to me. I used Wireshark to analyse the incoming packets . Here is an screenshot of my my analysis:

ICMP packet

(My IP was 192.168.38.58)

The packet capture was filled with these ICMP request. When I searched the web about it then I found that there is an attack named smurf attack in which attacker force other system in the network to send ICMP request to victim system.

Is this an example of smurf attack? If so then how to prevent my computer from being Attacked.

Please provide solution for both linux and windows Operating system.

EDIT No. 1:------

When I changed the MAC address of my PC, everything got back to normal. No such malicious packets were observed.

EDIT No. 2:------

I had used Advanced Port Scanner to scan my active port.

The port which was sending UDP packet(53411) is closed

Snake Eyes
  • 501
  • 4
  • 11
  • The answer to what happened is not in the screenshot. It may be in the capture file, so if you would share the full capture file, we might be able to find it. The interesting packets are earlier in the flow than what your screenshot shows. – kasperd Jun 17 '15 at 16:01
  • 1
    Be careful using Wireshark and/or port scanners on a University network. As stupid as it is many Universities have rules against this. – Spaceman Spiff Jun 17 '15 at 17:45
  • 1
    The reason when you changed your MAC address things went back to "normal" is because other computers were still using the old ARP entry. I'd suspect eventually once the ARP caches are cleared you'll see similar traffic again. The traffic you are seeing is normal for a university network and not indicative of an attack. – Herringbone Cat Jun 17 '15 at 19:29
  • @SpacemanSpiff If you are running it on your own computer, then it is probably outside their jurisdiction anyways. After all Wireshark does not send any network traffic at all. It is simply a tool to display which traffic the network is already sending to that host. – kasperd Jun 17 '15 at 20:04
  • 1
    @kasperd One would think, and I was completely surprised when I found out my University banned it, but here is an example (just ctrl-f wireshark) from a random University. Policies like this aren't uncommon at all. – Spaceman Spiff Jun 17 '15 at 20:13
  • @SpacemanSpiff That FAQ is misleading. The FAQ mentions Wireshark, but there is a link to the actual policy supposedly banning Wireshark, and it doesn't mention Wireshark at all. What it says is: "intercepting, monitoring, or retrieving any network communication without authorization." The words intercepting and retrieving do not apply here because the traffic is sent to his computer regardless of whether it is running Wireshark or not. That leaves only monitoring as the possible violation of the policy. – kasperd Jun 17 '15 at 20:39
  • @SpacemanSpiff Is the policy really supposed to prevent users from monitoring what the network send to their computers? If so, that would mean the users are not allowed to protect their own computer using IDS or a firewall. They would still be allowed to use Wireshark, because what you do with Wireshark is not monitoring. Monitoring is something that is in general left running all the time and responds to certain patterns by alerting somebody. Wireshark is a tool used to understand the network traffic, so it is a debugging tool rather than a monitoring tool. – kasperd Jun 17 '15 at 20:43
  • @kasperd The FAQ clearly responds to the question Can I use Wireshark on the school network? with No. The part you quoted was merely an extension of that policy. I am not a school administrator so I can't really speak to the intent of such policies, but I do know they are common, and schools will take action. That being said school administrators aren't known for being very tech savvy, or reasonable when it comes to rule violations. In most cases it is advisable to get permission if you plan to use Wireshark on a University network. – Spaceman Spiff Jun 17 '15 at 21:27
  • @SpacemanSpiff That's not how the question is worded in that FAQ. And I am pretty sure if the FAQ and the policy disagree, then it is the policy which applies not the FAQ. And I still stand by my original statement. What is happening on a student's computer is almost certainly outside of the jurisdiction of the university. The policy covers usage of the network, but what Wireshark does isn't usage of the network, it is simply observing what other software on the computer is communicating with the network about. – kasperd Jun 17 '15 at 22:09
  • @SpacemanSpiff I would never ask for permission to use Wireshark on my own computer. If I am allowed to use the network then I am also allowed to receive network packets from the network. And what happens to the packets once they are on my computer, that's my business. As long as the packets you send to the network are not in violation with the policy, then you are not to blame for anything the network sends back to you. If you start doing any form of spoofing you are likely in violation with any reasonable policy. But as long as you stay passive you will only see your own traffic. – kasperd Jun 17 '15 at 22:16
  • @kasperd Here is another one for the University of Hawaii that says Users may not “sniff” networks or undertake comparable measures to obtain access to passwords or other information not made publicly available by the owner. I personally don't think that any University should have jurisdiction over what programs run on your computer, I am just warning anyone who may try this that I know there are Universities that do and are willing to enforce rules based on that. I'm not defending these Unis – Spaceman Spiff Jun 17 '15 at 22:20
  • @SpacemanSpiff Inspecting traffic send to your own computer isn't sniffing. And if somebody decides to send data to my computer, then I didn't undertake any measures to obtain access to it. So, there is no way that wording would forbid me from looking at network traffic send to me. – kasperd Jun 17 '15 at 23:35

2 Answers2

20

The ICMP packets coming back were in response to your host sending out UDP packets to other hosts who don't have port 2054 open. It was not a smurf of any sort, unless someone remotely compelled your PC to send out those packets. Regardless, it would take a lot more than a few dozen small packets on the local subnet to noticeably slow your connectivity. The culprit to your speed issue lies elsewhere. Also, try to find out why your PC is sending UDP packets to port 2054 on a large number of hosts.

Jeff Meden
  • 3,976
  • 14
  • 16
  • How is my PC compelled to send UDP packets to other hosts? – Snake Eyes Jun 17 '15 at 13:16
  • 5
    Bittorrent would be my guess ¯\(ツ)/¯ – Jeff Meden Jun 17 '15 at 13:17
  • I am not using it. Any other guess? – Snake Eyes Jun 17 '15 at 13:19
  • 4
    Sorry for the snark. Your PC is running something looking for open UDP port 2054 on other PCs on your subnet. If you arent intentionally running some sort of peer-to-peer software like Bittorrent then it is probably malicious and could be symptomatic of (but not the cause of) your speed issues. I would suggest taking a careful look at running processes, and other traffic. – Jeff Meden Jun 17 '15 at 13:25
  • 4
    Try using netstat -o to find out which process is sending UDP 2054, then investigate that process – GdD Jun 17 '15 at 13:48
  • netstat -o shows ownership of active connections, and since UDP is not session based it will probably not show anything regarding the offending traffic. This makes attribution difficult for UDP. Looking for an open 2054 locally might be a good place to start, in the event that the program is looking for other programs like it (and it picked 2054 to look for). Sysinternals process explorer is a good tool to derive additional network info from. Here is a good tip on how to use wireshark + netstat for tracing UDP: https://ask.wireshark.org/questions/26459/which-application-is-sending-udp-packets – Jeff Meden Jun 17 '15 at 14:25
  • I just found my own machine's McAfee LiveSafe installation sending traffic to every host on the network on port 2054: https://superuser.com/questions/987494/mcafee-sending-traffic-on-udp-port-2054-is-this-expected-behaviour – Flup Oct 16 '15 at 09:48
4

Based on the screenshot and data you present, you are not on the receiving end of a smurf attack. This exploit is nostalgic for me -- back in the day, I used to hang out on IRC with TFreak and was playing with the smurf exploit when it was first created.

The smurf exploit simply would issue ICMP to a broadcast IP. Now, back in these days CIDR didn't really exist, so most networks were Class C (e.g. 8.8.8.x) or Class B (e.g. 8.8.x.x). In this exploit, pinging the broadcast IP of the network would send the ICMP packet to all the hosts in the subnet -- either up to 254 for the Class C, or up to 65535 in a Class B. The smurf exploit would spoof the ICMP packet so the ping would seem to come from the victim IP. Then, replies would flood in from all the active machines that received the spoofed packet via their broadcast IP. In such a way, one ping would be amplified up to 65,000x in replies, flooding the downstream of the victim IP.

This was the late-90s. These days, pretty much all networks are patched against this kind of exploit and there are few vulnerable broadcasts. A more modern incarnation is the DNS amplification attack, which recently was used for a large DDoS.

Also the IPs in the middle of your screenshot are all RFC1918 local IPs, so that traffic is within your LAN. Chances are there is not a smurf attack going on inside your network.

Herringbone Cat
  • 4,332
  • 16
  • 20