9 Replies Latest reply on Oct 3, 2013 2:52 PM by mtuma

    Attacks not getting blackholed

      I am trying to set up rules to blackhole repetitive attacks, including against Remote Desktop Protocol (port 3389) and netprobes.

       

      I've set them up as Attack filters, and in the Attack Response I tell it to blackhole attackers for 300 seconds if they've initiated 10 RDP connections in 10 seconds. I also get alarm emails if this triggers.

       

      But, even as I monitor an attack, the attacking IP does NOT get added to the "Blackholed IPs" list on the dashboard. The attacks continue, and I get a flood of alert emails even though they're spaced 2 minutes apart.

       

      I can blackhole the IP manually, and this stops the attack showing up in the audit report, and I stop getting the emails. So why aren't the IPs getting blackholed automatically, when every other the attack response setting seems to work?

       

      This is a Sidewinder running firmware v70100.

       

      Thanks

        • 1. Re: Attacks not getting blackholed
          sliedl

          Try this:

          Go to IPS Attack Responses and click the 'Response Settings' button in the bottom-right corner.

          Check the box next to 'Blackhole source IP if attack IP cannot be confirmed' and Save this change.


          Does the blackhole now work?

          • 2. Re: Attacks not getting blackholed

            Hi sliedl,

             

            Thanks for the suggestion, but the blackhole still doesn't seem to trigger properly.

             

            After turning on that option, in the audit log I see a string of  RDP attempts overnight that should have triggered the blackhole. But there are hundreds of RDP attempts over 10+ minutes, obviously trying user/password combinations.

             

            I also ran a portscan on the server, which again should have triggered a blackhole response but did not. This was confirmed both by seeing hundreds of netprobe audit entries appearing in about a minute, and the dashboard's "Blackholed IPs" remained at 0.

             

            Are attempts to connect while blackholed, supposed to appears as audit events? Obviously we can't be monitoring for blackholed IPs in realtime all day...

             

            Thanks

            • 3. Re: Attacks not getting blackholed

              What is the current setting of the IPS attack response?

              • 4. Re: Attacks not getting blackholed
                sliedl

                Can you post your audit filters and some example audit events which should trigger these audit filters?

                 

                You can see the audit filters with 'cf audit q'.  There are two components to each IPS Attack Response: the filter and the auditbot which looks for that filter in the audit.  If we look at the 'ACL Deny' attack response we can see the two components:

                 

                $> cf audit q filter name='ACL Deny'

                audit add filter name='ACL Deny' \
                    comments='Detects when a connection is denied by a rule in the active policy.' \
                    filter_type=attack number=4 sacap_filter='event AUDIT_R_ACLDENY'

                 

                $> cf audit q auditbot name='ACL Deny'

                audit add auditbot name='ACL Deny' filter='ACL Deny' enabled=off blackhole=0 \
                    email=Attack_Default interval=300 period=30 reset=yes sb_percentage=0 \
                    secure_alert=yes snmp_trap=no threshold=5

                 

                If you run 'cf audit q name='ACL Deny' (with no filter or auditbot flag) you will receive both entries back.

                 

                I am curious as to whether your audit filter matches the audit events that you'd like to blackhole.  Each auditbot entry watches the audit stream for the audit filter it has configured and then takes the response(s) it has configured if it sees those audits events in the audit.


                Can you paste your filters and auditbot entries and also an example or two of the audit events you would like to blackhole please?

                • 5. Re: Attacks not getting blackholed

                  Had a bit of trouble; the commands you provided, e.g. cf audit q filter name='ACL Deny' did not produce any feedback when entered. Running cf audit q filter (with no name specified) did return all filters, so I had to search through the results for the filters.

                   

                  Here is the filter for "network probe":

                   

                   

                  audit add filter name='network probe' \

                      comments='Detects network probe attacks, which occur any time a user attempts to connect or send a message to a TCP or UDP port which has no service.  Note: The appliance does not blackhole netprobe attacks, as they are likely to be Denial of Service attacks from spoofed source addresses.' \

                      filter_type=attack number=6 sacap_filter=AUDIT_X_NETPROBE

                   

                  And here is the auditbot:

                   

                  audit add auditbot name='network probe' filter='network probe' blackhole=180 \

                      email=Attack_Default enabled=on interval=300 period=5 reset=yes \

                      sb_percentage=0 secure_alert=yes snmp_trap=no threshold=25

                   

                  And here's one of the 100+ netprobes that came from the same IP, in the span of 2 seconds (our destination IP is X'ed out), which should have resulted in the IP being temporarily blackholed after 25 attempts.:

                   

                  Sep 12 03:40:34 2011 EDT  f_kernel a_nil_area t_netprobe p_minor

                  pid: 0 ruid: 0 euid: 0 pgid: 0 logid: 0 cmd: 'kernel'

                  domain: (null) edomain: (null) hostname: firewall.xxxxx.com

                  event: TCP netprobe srcip: 221.192.199.49 srcport: 12200

                  dstip: xxx.xxx.xxx.xxx dstport: 2479 protocol: 6 srcburb: external

                  interface: em0

                  reason: The Sidewinder received a TCP connection attempt destined for a service that the current policy does not support.

                   

                  These were in place when I tried using a simple portscanning service.

                   

                  Thanks

                   

                  Message was edited by: firedupbng (CLI results indented, monospaced) on 12/09/11 13:50:04 CDT

                   

                  on 12/09/11 13:50:24 CDT
                  • 6. Re: Attacks not getting blackholed

                    Hello,

                     

                    Please understand that this alert will only get triggered very 5 minutes (interval=300). If another device has triggered this alert previously, that might explain why this device was not blackholed.

                     

                    Also make sure that Sam's original suggestion is turned on still ('Blackhole source IP if attack IP cannot be confirmed').

                     

                    -Matt

                    • 7. Re: Attacks not getting blackholed

                      Hi again,

                       

                      The "Blackhole source IP if attack IP cannot be confirmed" is still turned on, yes.

                       

                      The alert interval: doesn't this only affect email and SNMP alerts? I set this with that understanding, e.g. on the off-chance we're under constant attack I don't want an alert every time the blackhole is triggered.

                       

                      But, in the GUI's Attack Frequency tab, the attack response should trigger if there's 25 matches (threshold) within 5 seconds (period), and the attack count is then reset to zero, regardless of what the alert interval is.

                       

                      This seems to be backed up by the fact if I turn off both email and SNMP alerts, the "Time to wait between alerts" is then greyed out, implying the blackhole response isn't affected by it.

                       

                      Thanks

                      • 8. Re: Attacks not getting blackholed
                        squidikus

                        I know this is an old unansered post but does anyone know of a way to restart the IPS service if it seems to not be working? or whatever service that controls the blackholing of IP's?

                        • 9. Re: Attacks not getting blackholed

                          Hello,

                           

                          Technically it is the auditbotd process that monitors the audit and then triggers alerts (which can also trigger blackhole).

                           

                          cf daemond restart agent=auditbotd

                           

                          You can try to manually blackhole using the blackhole command:

                           

                          blackhole add IPaddress zone_index timeout

                          for example:

                           

                          blackhole add  1.1.1.1 2 500

                           

                          -Matt