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

packets slipping past explicit PF rule?

BAlfson 
07:29:56 Default DROP TCP 222.93.240.134 : 4118 → [Our Public IP] : 80 [SYN] len=48 ttl=116 tos=0x00 srcmac=00:00:00:00:00:00 dstmac=00:08:02:a4:99:5f


I have a group "Chinese Hackers" that includes 222.93.240.0/22 and a PF rule 'Chinese Hackers → Any → Any : Drop'.

99% of such packets are indeed dropped by my rule.  Any thoughts about how the packet above could have slithered past my PF rule before being default dropped?

Cheers - Bob


This thread was automatically locked due to age.
  • 0
    I submitted this to Astaro Support and got a response from Alan Toews himself!
    The log provided, shows everything working as intended. The packet was dropped 
    by fwrule 60001, which is the default drop rule for the INPUT chain. 

    It may seem odd that your pf rule didn't match, and instead, hit the default 
    drop rule. The explanation is relatively simple. Packets being sent TO the 
    Astaro are matched against several iptables INPUT chains. packets being sent 
    THROUGH the Astaro, are matched against several iptables FORWARD chains. All 
    rules created in the packet filter are created in the USR_FORWARD chain, so 
    only applied ot packets being forwarded through the Astaro. The packet logged 
    above was trying to reach port 80, which you probably don't have a DNAT rule 
    for. Since Astaro isn't forwarding the packet, it only hits the INPUT chains, 
    and thus doesn't match your rule. This doesn't change the behavior in any way, 
    since the packet is still dropped. If you want to drop these packets also, 
    creating the same pf rule, but with the external address as the destination 
    will put the rule in the USR_INPUT chain, and the packet will match that rule 
    explicitly, instead of the default drop rule.


    I have a network definition that represents the subnet of public IPs we have: MediaSoft 68.15.104.32/29
     
    I created a new PF rule: 'Any -> CIFS -> MediaSoft : Drop' with logging.  That had no effect.  I then bound that network definition to the External interface.  Still no effect.
     
    Success!
    I created a Network Group: "External Address Group" that included all External and Additional Addresses.  I then created a rule that successfully blocked:

    'Any -> CIFS -> External Address Group : Drop'


    I deleted the original rule 'Any -> CIFS -> Any : Drop'

    Likewise, I replaced 'Chinese Hackers -> Any -> Any : Drop' with:

    'Chinese Hackers -> Any -> External Address Group : Drop'


    Cheers - Bob
  • 0 in reply to BAlfson
    I used to have to add the external Broadcast (e.g. .255 on a /24) and Network (e.g. .0) to get full coverage, but I did notice that 7.5 has some extra settings to drop broadcasts without logging, so maybe it's no longer necessary.

    Barry