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

scottj_01
All-

I am seeing in the firewall log since the upgrade to version 9.101-12 an enormous number of dropped entries for firewall rule 6003, tcpflags="ACK PSH FIN". They appear from an number of sources. One of the source sites is this one. I created a firewall rule any>WebGroup>drop and placed it right after websurfing. WebGroup contains http>source 1:65535> destination 80, and the same for https substuing port 80 with port 443. The log traffic box is unchecked. Can the fwrule 6003 be edited to turn off logging? My hair is now in a pile on the floor....Thanks, Jim

2013:06:08-09:52:47 Oasis ulogd[4425]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1b:21:59:59:3d" srcip="209.123.109.176" dstip="192.168.1.2" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="1632" tcpflags="ACK PSH FIN" 
2013:06:08-09:52:48 Oasis ulogd[4425]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1b:21:59:59:3d" srcip="209.123.109.177" dstip="192.168.1.2" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="1638" tcpflags="ACK PSH FIN" 
2013:06:08-09:52:48 Oasis ulogd[4425]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1b:21:59:59:3d" srcip="209.123.109.177" dstip="192.168.1.2" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="1639" tcpflags="ACK PSH FIN" 
2013:06:08-09:53:06 Oasis ulogd[4425]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1b:21:59:59:3d" srcip="85.115.22.9" dstip="192.168.1.2" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="1671" tcpflags="ACK PSH FIN" 
2013:06:08-09:53:59 Oasis ulogd[4425]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" srcmac="0:1b:21:59:59:3d" srcip="85.115.22.9" dstip="192.168.1.2" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="1671" tcpflags="ACK PSH FIN"


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

    "60003" is the default drop rule for for the (iptables) OUTPUT chain, so I'm pretty sure it can't be stopped from logging.  At no risk of disrupting "normal" connections, you could make an "HTTP-Response" service and 'Drop : Internet -> {80->1:65535} -> Internal (Network)' to get rid of the log entries, but it might be fun to figure out what's causing this.

    I don't have any certs in TCP/IP, so everyone please correct me if I'm wrong.  What's interesting about this is that conntrack accepted the packet from the responding web server, but believes that the connection with the requestor (192.168.1.2) is expired.  That could be a timeout, but my guess is that there's a glitch in the handoff from conntrack to httpproxy, and that httpproxy should have sent the packet to the requestor.

    What do you see in the Web Filtering log at the same time for one of the srcips above?

    Cheers - Bob
Reply
  • 0
    Hi, Jim,

    "60003" is the default drop rule for for the (iptables) OUTPUT chain, so I'm pretty sure it can't be stopped from logging.  At no risk of disrupting "normal" connections, you could make an "HTTP-Response" service and 'Drop : Internet -> {80->1:65535} -> Internal (Network)' to get rid of the log entries, but it might be fun to figure out what's causing this.

    I don't have any certs in TCP/IP, so everyone please correct me if I'm wrong.  What's interesting about this is that conntrack accepted the packet from the responding web server, but believes that the connection with the requestor (192.168.1.2) is expired.  That could be a timeout, but my guess is that there's a glitch in the handoff from conntrack to httpproxy, and that httpproxy should have sent the packet to the requestor.

    What do you see in the Web Filtering log at the same time for one of the srcips above?

    Cheers - Bob
Children
No Data