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?
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...
What is the current setting of the IPS attack response?
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?
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: 126.96.36.199 srcport: 12200
dstip: xxx.xxx.xxx.xxx dstport: 2479 protocol: 6 srcburb: external
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.
Message was edited by: firedupbng (CLI results indented, monospaced) on 12/09/11 13:50:04 CDT
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').
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.
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?
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
blackhole add 188.8.131.52 2 500