Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 4134 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

Network Protection: Dropped Packets

DaMaN841
I noticed a slew of dropped packets from a couple sources and I'd like to confirm that my understanding about why they were dropped is on the right track. My goal is to eliminate any unnecessary packet dropping for my hosts given they are legitimate. 

Note - I removed src and dst Mac's and IP's.

Boxee Box (Local) - Based on my digging around Google, I believe this was dropped because Boxee didn't supply any tcpflags? NETBIOS-NS Port 137 UDP is allowed on my Internal Network, which led me to this conclusion. 
2013:07:31-00:04:35 Tornado ulogd[4823]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="" dstmac="" srcip="x.x.x.118" dstip="Internal Gateway IP" proto="17" length="78" tos="0x00" prec="0x00" ttl="64" srcport="44252" dstport="137"


P2P Leecher - Based on my digging around Google, I believe this was dropped because of the reset flag within tcpflags. Perhaps this is due to their ISP sending RST Packets?
2013:07:31-12:56:52 Tornado ulogd[4823]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="" dstmac="" srcip="x.x.x.x" dstip="External IP" proto="6" length="40" tos="0x00" prec="0x00" ttl="45" srcport="8890" dstport="64713" tcpflags="RST"


I'm really not sure why this one was dropped:
2013:07:31-00:53:41 Tornado ulogd[4823]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="" dstmac="" srcip="x.x.x.x" dstip="External IP" proto="6" length="64" tos="0x00" prec="0x00" ttl="48" srcport="34990" dstport="60399" tcpflags="SYN"


I appreciate the assistance. Thank you!


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

    Boxee - port 137; boxee is probably trying to do some sort of network discovery; I don't know why it would hit the firewall's IP, but it can be ignored. 
    You should not create any new rules here, unless you want to prevent it from being logged at all.

    P2P - hard to say for sure, it could be from a session that the firewall 'expired', in which case it should be ignored.

    Last - you probably don't have any rules allowing those ports

    Barry
  • 0 in reply to BarryG
    Thanks Barry!

    What I don't understand is why it would drop the packet if the Internal Network is allowing NETBIOS-NS Port 137 UDP?

    For the P2P, I looked into it under Network Usage and found this:
    1. Bittorrent, File Transfer, 1.9 MB 99.68%, 3.2 MB, 99.79%, 5.1 MB, 99.75%, 5056 Connections, 99.06%
    2. Unclassified, Unclassified, 6.1 kB, 0.32%, 6.8 kB, 0.21%, 12.9 kB, 0.25%, 48 Connections, 0.94%

    Under Network Protection, however, I found this:
    Of those connections, 3337 Packets Blocked using 3051 different ports, all of which seem to be RST, so I'm assuming it's their end.

    As for that last one, I'm still wondering what someone is looking for on port 60399. That definitely doesn't explicitly route anywhere on my Network as far as NAT is concerned. If it is in fact P2P, only one port is DNAT'd to that Server, and 60399 is not the right one. Simply makes me curious.
  • 0
    There are built-in rules for the firewall's interfaces; those interfaces are treated very differently than the protected networks. Since the firewall doesn't 'speak' netbios, there's no reason it should accept the packets, so it drops (and logs) them.
    If there are too many entries in the logs, you can create a new rule to drop them without logging.

    RST packets could be coming from something like SandVine from your ISP or the remote P2P peer's ISP. There's not really anything you can do about it.
    They could also be expired sessions, as I mentioned earlier.

    If you don't recognize the traffic in the last log entry, then the firewall did its job; it dropped the unauthorized traffic. It could be from a port scan, a bot, etc.

    Barry
  • 0
    BTW, it was really hard to tell which traffic was from your internal network and which was from the internet since you removed all the IPs.

    You could at least leave it as 192.168.x.x for internal IPs, and at least the first octet for external ones.

    Barry
  • 0 in reply to BarryG
    That all makes sense, thank you. It's important to me to be able to filter what is expected from the Firewall and what is essentially a lack of rules on my part. It does, however, make sense that the Firewall would block Boxee's NETBIOS scan, and at the same time, is curious why Boxee would even scan the Gateway to begin with.

    My mistake on the difficultly for reading my logs. The Boxee was Internal IP to Internal Gateway IP, so 192.168.x.118 and 192.168.x.1 for example. The other two were External IP's hitting the External Gateway IP.
  • 0 in reply to DaMaN841
    I also noticed in my Network Protection --> Firewall --> Top Services, a line item for (IPV6). 273 Packets for that, however, when I click on it, just like any other Service, it will switch to Top Source Hosts by Service, filling the Search Query with (IPV6). Unfortunately, no results are returned. Perhaps a bug?