Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 5514 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.
  • 0
    It is as you have determined; for instance, I can add a bad host to a blacklist (Rule 1) in the packet filter, even define a "blackhole" DNAT for a bad host, and the portscanner detection will still trigger.  It is annoying, to be sure, I think there's a feature request for at least a notification blacklist so we don't see these old portscanners, etc. over and over again after we've added blocking rules.
  • 0
    Thanks for confirming, Bruce.  Indeed, it's it's not just annoying to keep getting these alerts, it's downright bad practice because it leads one to simply delete the alerts without giving them proper consideration, i.e. you can't see he wood for the trees.  Guess I'll surf over to the request site and add my vote.

    Cheers,
      Jon.
  • 0
    I couldn't find an existing feature request, so I created a new one: IPS alert filter
  • 0
    I think the workaround for this is to create an exception in IPS.  That way, the packets can pass silently to a blackhole DNAT or to a PF rule that drops the traffic.  Note that, in order to capture this traffic, like the DNAT, the PF rule must have the "External (Address)" object as the target instead of a host definition with the same IP.  Is that what you're trying to accomplish?

    Cheers - Bob
  • 0
    Good idea, Bob.  I've created an IPS exception using the same "Known Offenders" group I use in my "Known Offenders" --> Any --> Any --> "Reject and Log" PF rule #1 - now to sit back and see if it does the trick.

    I'd still like to see selective alert filtering so I would get alerted if these miscreants subsequently start trying other attacks, but this will do for now.

    Thanks.
  • 0
    It's been true for a long time, but maybe it's been changed: the traffic selector in the PF rule must be 'Known Offenders -> Any -> External (Address)' instead of 'Known Offenders -> Any -> Any', otherwise, packets to 443, 25, 4444 and others will be accepted by the Astaro, and the others will be default dropped instead of being dropped by your PF rule.

    If the Any->Any rule worked, please confirm.

    Cheers - Bob
  • 0
    Thanks for the clarification, Bob.  I've left my my 'Known Offenders -> Any -> Any' as rule #1 and added 'Known Offenders -> Any -> External(Address)' as rule #2.  I'll be interested to see if #2 catches anything, though your explanation makes perfect sense.
  • 0 in reply to BAlfson
    It's been true for a long time, but maybe it's been changed: the traffic selector in the PF rule must be 'Known Offenders -> Any -> External (Address)' instead of 'Known Offenders -> Any -> Any', otherwise, packets to 443, 25, 4444 and others will be accepted by the Astaro, and the others will be default dropped instead of being dropped by your PF rule.

    If the Any->Any rule worked, please confirm.

    Cheers - Bob


    In my experience, this does not make any difference.
  • 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.