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

Packet Filter Logging Question

scottj_01
All-

I need some advice regarding packet filter logging. It seems that when content is delivered from Akami Technologies their servers leave a large number of logs usually ending with tcpflag RST. Please see example enclosed. My question is how do I prevent this needless logging? Mods I may have placed my post in an incorrecty under network security in place of management, logging.... Please relocate if necessary.

Thanks,
Jim

2011:05:05-12:44:14 OASIS ulogd[5189]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:90:1a:a1:41:27" dstmac="0:24:7e:x:y:z" srcip="69.31.28.242" dstip="173.A.B.76" proto="6" length="40" tos="0x00" prec="0x00" ttl="253" srcport="443" dstport="3097" tcpflags="RST" 
2011:05:05-12:44:14 OASIS ulogd[5189]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:90:1a:a1:41:27" dstmac="0:24:7e:x:y:z" srcip="69.31.28.232" dstip="173.A.B.76" proto="6" length="40" tos="0x00" prec="0x00" ttl="253" srcport="443" dstport="3119" tcpflags="RST" 
[:S]


This thread was automatically locked due to age.
  • 0
    Hi, we've had some discussions here about this happening with incoming traffic to servers, one option for that is to put a DROP Rule for HTTP with logging disabled AFTER your allow rule.

    See https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39325
    for some discussion.

    However, you're talking about traffic FROM servers to your internal clients.
    Therefore, dropping incoming traffic from HTTP & HTTPS without logging should work (after any related allow rules, if applicable).

    It does seem odd to me that webservers would be sending RSTs to browsers though. Some googling shows that some web servers will close idle sessions with RST though.

    Barry
  • 0
    Barry,

    Thanks, I'll try it and post the results.

    Regards,
    Jim
  • 0
    Barry,

    I added a rule to drop HTTP with no logging. However there continues to be a large number of log entries from content delivery such as Akami. The logs are many times noting ACK, SYN, RST. Hopefully there is another solution.

    Thanks,
    Jim
  • 0
    Keep in mind that there are quite a few default hidden PF rules.  It just may not be possible to override the settings for these as they are processed before any visible rules.
  • 0
    Jim, I wonder if you didn't have an error in your trial of Barry's suggestion.  The log lines in Post #1 show that this is a default drop out of the INPUT chain (fwrule="60001").  I'm not that knowledgable about iptables, but I don't think it's possible that that can happen before your manual packet filter rules get a shot at the packets (like I said, this is an educated guess, so I'd welcome a correction).

    Cheers - Bob
  • 0
    Guys,

    Thanks for your help. You my be correct that the rule is not correctly configured. Currently it is configured as Source Any> Service Web Surfing> Destination> External Wan Address > Drop.  Possibly I should configure it as Source Any> Service Web Surfing> Network Group containing CIDR's OF Akami Servers> Drop? Is it possible to use create a DNS group in place of the network group using http://*.deploy.akamaitechnologies.com?

    Regards,
    Jim
  • 0
    Jim, the packets you show being dropped are "uninvited" responses that the connection tracker isn't recognizing.  Billybob (I think it was) pointed out last year, in a discussion about QoS, that you need a different service definition.  Try something like "Uninvited" = 443 -> 1:65535.  Then put that in the place of "Web Surfing" in your PF rule.  I don't think that will bother real responses since conntrac should accept valid ones before the manual PF rules are consulted.

    Did that work?

    Cheers - Bob
  • 0
    Bob,

    Thank-you for you help. I see how you arrived at that answer, the ports defined in the log. I'll try it out!

    Thanks,
    Jim
  • 0
    Bob,

    Your recomendation worked reasonabliy well. The log file has been seriously reduced. I expaneded on you approach and created a group for the individual port blocking rules and placed it in the packet filter. The reduction in wasted logging is about 75%. I do understand however that using this technique my cause me to miss items that may be important. Either way I am a happy camper. Thanks for you help, it was a very good idea!

    Regards,
    Jim