Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 4895 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Single Host Source Of 80% Of The Network Dropped Packets

NashBrydges
Hi All,

First time poster and newbie to Sophos.

I've installed Sophos Home edition a little over a week ago and I've noticed a pattern that I can't figure out. One of my hosts (teenage son's PC) is the source of >80% of packets dropped. Granted this is a gamer kid so I've had to implement a few exceptions to get his rig setup however I can't figure out why there are over 68k packets.

I'm attaching what the packet filter violations graph look like for yesterday as an example. That whole period is that one host dropping packets.

Looking at the log for yesterday, I can see there are over 68k packets being dropped all with srcport=49622. The strange thing is that often these paclets are destined for dstip of an internal IP range. I'm on a 192.168.1.X and these are dstip range of 192.168.2.X or 10.X.X.X range. Some are destined for public IPs but a large number seem to target a private IP range.

All of the other 38+ hosts are behaving but this one PC is causing all of this activity.

Is this something I should be concerned about? I ran an AV scan with AVG CloudCare and Sophos as well as Malwarebytes and all came back clean. Not sure if this normal or not. Appreciate any insight you might have.


This thread was automatically locked due to age.
  • 0
    Hi, 

    Can you post a matching entry from the full (not live) firewall log?

    Is he running BitTorrent or any other P2P apps?

    Barry
  • 0 in reply to BarryG
    Here is an interesting find. I ran an arp /a command and noticed that the dstmac (I've obfuscated it in the attachment to yy:yy:yy:yy:yy:yy) belongs to the UTM at IP 192.168.1.1. Why would the log show the dstip=192.168.2.2 for that mac address?

    Anyway, this is but an extract of the entire log obviously. The full log is 32MB in size. I've zipped this file down for ease of upload. 

    This file only contains the log entries for the one host (192.168.1.3) and the dstip=192.168.2.2 which doesn't exist on my network.
    192.168.2.2_extract_packetfilter-2015-03-23.log.zip
  • 0
    A single line in your post would be sufficient.  Are the two MACs different (xx & yy), or are they the same? Where is 192.168.2.2 and why is 192.168.1.3 sending something to that IP?

    2015:03:23-17:42:10 sophosutm ulogd[29694]: id='2001' severity='info' sys='SecureNet' sub='packetfilter' name='Packet dropped' action='drop' fwrule='60002' initf='eth1' outitf='ppp0' srcmac='xx:xx:xx:xx:xx:xx' dstmac='yy:yy:yy:yy:yy:yy' srcip='192.168.1.3' dstip='192.168.2.2' proto='17' length='56' tos='0x00' prec='0x00' ttl='127' srcport='49622' dstport='22046'


    Cheers - Bob
  • 0
    Sorry Bob. Wasn't sure how much would be needed.

    They are different. I can confirm that the srcmac belongs to the host with 192.168.1.3 IP and the dstmac belongs to the UTM where the IP should be 192.168.1.1 but shows as 192.168.2.2 in the log.
  • 0
    The DSTMAC will be the UTM (gateway) if the IP is not in your network... that's normal.

    The question becomes what is that computer trying to do; you're going to have to see what's running on the computer (including checking for malware).

    It could potentially just be a misconfigured printer driver or something else innocuous.

    Barry
  • 0
    By the way, a belated welcome to the User BB!

    Don't worry about it - newbies are welcome here. [;)]

    OK, so that is a default drop out of the FORWARD chain (60002) where the packet is being routed through the UTM and there's no firewall rule to allow it to pass.  I'm not surprised to see the MAC of the Internal interface here as that's the last place that packet will ever go.  192.168.1.3's NIC sent that Ethernet message to 192.168.1.1's MAC because that's the default gateway for devices in 192.168.1.0/24.

    Cheers - Bob
  • 0
    Thanks Barry and Bob. 

    That's the weird part is that the log indicates the correct mac for the UTM but not the correct IP (192.168.2.2 vs the correct 192.168.1.1). He's running Windows 7 and has no torrents or p2p sharing going on. The closest thing he has to p2p is streaming his gaming to TwitchTV. He also uses Skype to chat while gaming.

    He says everything seems to be working and hasn't complained about any performance issues. I've also completed numerous AV and MBAM scans so I'm confident there's no machine infection. Clearly something different with his PC since it is the only one causing so many dropped packets. I suppose the only side effect to this is that I have an inflated log file. Unless you suggest I investigate further I am inclined to leave it alone. Not really wanting to do a full reinstall on that PC just to deal with this.

    Have to admit that the lessons in the Rulz post that I read yesterday should begin with #1) Make sure your spouse/kids/significant others are not home when you try to tweak any firewall or filtering settings...you'll save yourself a huge headache if something interrupts Facebook/Twitter/Instagram/Netflix...etc.
  • 0 in reply to NashBrydges
    That's the weird part is that the log indicates the correct mac for the UTM but not the correct IP (192.168.2.2 vs the correct 192.168.1.1).


    It is shown correctly.

    At the IP layer, the packet is headed to an IP on another network (192.168.2.0/24, presumably).
    As that is not within the local network, it goes through the default route/gateway which is the UTM.

    At the Ethernet layer, the UTM's internal interface is the correct path for the ethernet frames.

    So, the DST MAC will be the UTM, for ANY packet leaving the network.

    If you don't want this filling up your logs, you can create a DROP rule with Logging turned off.

    If it were me, I would still try to figure out what's going on... since they're UDP packets (and not simply TCP SYNs), running WireShark may give you more info.

    Barry
  • 0 in reply to BarryG
    Thanks Barry. I'll poke around some more. See if I can get him to use a single service at a time and see where these come from. I had the PC turned on for hours with no usage yesterday and no sky-high dropped packets so it must be from something he is running.