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

IPS alerts from blocked address

JonEtkins
Over the last couple of days, I've seen a sudden burst of IPS alerts from two particular IP addresses.  While I have confidence in the IPS, I also see no reason to allow these sites continued access to anything I host, so I've placed them in my "Known Offenders" group which is rejected by Rule #1 on my firewall.  However, I'm still getting IPS alerts from these jerks.  

Am I correct in assuming that incoming traffic goes through the IPS before it hits the firewall?  That seems backwards to me, but perhaps someone can suggest why it would be that way.


This thread was automatically locked due to age.
Parents
  • 0
    This is something I just learned late last year about the iptables system in Astaro.  Here's Alan Toews' explanation of why I had the problem:

    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 to 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 hope you're right now, Bruce!

    Chhers - Bob
  • 0 in reply to BAlfson
    Portscan detection, for instance, still triggers when packet filters are configured, even as specified above; that function gets the traffic before the packet filters do, so portscan detection will continue to trigger alerts even though the source IP has no prayer of getting through the Packet Filter rule that's been created.
Reply
  • 0 in reply to BAlfson
    Portscan detection, for instance, still triggers when packet filters are configured, even as specified above; that function gets the traffic before the packet filters do, so portscan detection will continue to trigger alerts even though the source IP has no prayer of getting through the Packet Filter rule that's been created.
Children
No Data