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

Lots of [RST] packets in Firewall log

despich
We get items like this in our firewall log very often. (1000's per day)

2015:07:01-09:47:25 Astaro-1 ulogd[17496]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="0" initf="eth1" srcmac="b8:9b:c9[:D]4:b0:86" dstmac="00:1a:8c:f0:0d:c1" srcip="209.85.160.173" dstip="50.195.173.17" proto="6" length="40" tos="0x00" prec="0x20" ttl="41" srcport="36552" dstport="25" tcpflags="RST" 

Now as far as I can tell this should not be getting dropped as 50.195.173.17 has a DNAT rule pointing to our internal Mail Server with a any source - destination port SMTP rule. Since this is how our incoming email comes in obviously the rule must be working.  I have seen others in the log like this where it appears that it should not be dropped based on the source - destination and port and they also have the [RST] flag.

So why are these in the log? What does the [RST] signify?


This thread was automatically locked due to age.
  • 0
    OK, so you are NOT using the SMTP proxy then?

    "TCP RST packet is the remote side telling you that the connection on which the previous TCP packet is sent is not recognized, maybe the connection has closed, maybe the port is not open, and something like these. Here is my opinion, since the connection is not valid any more, there is no need to reply an ACK"

    It could be that the mails are addressed to a domain different than that configured on your mail server (spam monkeys), so the connection is being severed.

    https://en.wikipedia.org/wiki/TCP_reset_attack
  • 0
    No we are not using the SMTP proxy.  We also see a lot of these with incoming RDP packets (3389), I assume those would be from systems trying to guess users remote desktop passwords.
  • 0
    Another possibility, check the IPS to make certain that false positives aren't being triggered.