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

Firewall log - Source and destination seem reversed

Jeff x

I am getting firewall log entries of dropped packets involving two IP's associated with the Yandex spider. What's confusing me is why my public IP, port 443 and the MAC of the Sophos external interface are listed as the source instead of the destination. It seems host and source are reversed in the firewall log. Please refer to the log entries below:

Firewall log:
/var/log/packetfilter/2019/04/packetfilter-2019-04-22.log.gz:2019:04:22-22:56:01 gateway ulogd[11303]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="xx:xx:xx:xx:xx:xx" srcip="xx.xx.xx.xx" dstip="77.88.47.2" proto="6" length="83" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="40529" tcpflags="ACK PSH FIN"

WAF Log:
/var/log/reverseproxy/2019/04/reverseproxy-2019-04-22.log.gz:2019:04:22-22:54:08 gateway httpd: id="0299" srcip="77.88.47.2" localip="xx.xx.xx.xx" size="0" user="-" host="77.88.47.2" method="GET" statuscode="301" reason="-" extra="-" exceptions="-" time="197667" url="/" server="www.mysite.com" port="443" query="" referer="-" cookie="-" set-cookie="-" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" uid="XL5@UDLwWoEAAHdqKoQAAAAm"
/var/log/reverseproxy/2019/04/reverseproxy-2019-04-22.log.gz:2019:04:22-22:54:16 gateway httpd: id="0299" srcip="77.88.47.2" localip="xx.xx.xx.xx" size="234" user="-" host="77.88.47.2" method="GET" statuscode="301" reason="-" extra="-" exceptions="-" time="325" url="/" server="REF_RevFroWwwservu80_redirect_ssl" port="80" query="" referer="-" cookie="-" set-cookie="-" websocket_scheme="-" websocket_protocol="-" websocket_key="-" websocket_version="-" uid="XL5@WDLwWoEAAHdqKoUAAAAE"

How do I go about troubleshooting this? I have Country Blocking turned on and I am using the WAF for that IP. I do not have any NAT's associated with the IP. These drops started being logged 4/2 of this month. I can't think of any changes that I have made that would have caused this. I'm guessing the traffic is actually being dropped because Country Blocking is turned on even though the log entries show FW rule 60003.



This thread was automatically locked due to age.
  • 0

    Firewall log:

    fwrule="60003" - the drop is out of the OUTPUT chain.

    outitf="eth1" - packet wants to leave from the External interface.

    srcport="443" - this is a response to an HTTP request.

    tcpflags="ACK PSH FIN" - probably an expired connection - why would your web server take so long to respond?

    Do you see anything unusual in the Intrusion Prevention log?  If you're not having any issues, you probably can ignore these entries.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks, BAlfson.

    Nothing unusual in the Intrusion Prevention log. Very few entries and 77.88.47.2 is not in the IPS log.

    It seems the Yandex spider does obey the robot.txt file. Since adding a Disallow rule specifically for the Yandex spider, I no longer see those log entries or any traffic from their IP's.

    I'm not sure about the web server response time. All websites load fast and I don't see any errors in the logs.

    --------------------------------------------------------------------
    Sophos UTM 9.719-3 - Home User
    Virtual machine on Dell Optiplex 3070
    i3-9100 @ 3.60 GHz, 16 GB RAM
    --------------------------------------------------------------------

  • 0 in reply to Jeff x

    To elaborate on Bob's answer:    The connection tracker drops a connection as soon as a FIN or RST is received in one direction.   Then the confirmation reply is dropped because there is no connection being tracked.    So your firewall drops are noise that I have learned to ignore.   The timing difference between the two log files is harder to explain.

Unfiltered HTML