Snort and blocking IPs

[mdima]

Hi,
    I am wondering I didn't realize it before, but it happens that the Snort package is blocking only and always the SRC IP, in all cases, no matter what.

For example, there are some rules that intercept the answer of an attack, in this case the DST should be blocked, not the SRC.

A concrete example is (from alert log):
1:3273:6 - SQL sa brute force failed login unicode attempt - SRC: (wan ip address), DST: XXX.XXX.XXX.XXX
I expect that the DST IP is blocked, not the SRC (that of course is in white-list, so it's not gonna be blocked anyway).

In the rule definition, there is:

alert tcp $SQL_SERVERS 1433 -> $EXTERNAL_NET any (msg:"SQL sa brute force failed login unicode attempt"; flow:from_server,established; content:"L|00|o|00|g|00|i|00|n|00| |00|f|00|a|00|i|00|l|00|e|00|d|00| |00|f|00|o|00|r|00| |00|u|00|s|00|e|00|r|00| |00|'|00|s|00|a|00|'|00|"; detection_filter:track by_src, count 5, seconds 2; reference:bugtraq,4797; reference:cve,2000-1209; reference:nessus,10673; classtype:unsuccessful-user; sid:3273; rev:6;)

I think that in this case, the "flow:from_server" would mean that the attacker is on the other end of the communication, means that the offender is the destination, not the source.

What do you think about it? Is there any way that the procedure that defines the blocks consider this parameter and in this case blocks the destination IP, not the source?

Thanks,
Michele

[marcelloc]

Fill server info(web, dns, smtp,etc) at snort gui.
This should prevent snort from blocking servers ip.

If not, put your servers ip on whitelist.

[mdima]

@marcelloc:

Fill server info(web, dns, smtp,etc) at snort gui.
This should prevent snort from blocking servers ip.
If not, put your servers ip on whitelist.

Marcello, the problem is not about snort blocking my own ip addresses (as I wrote, they are already in white-list), the problem is snort not blocking an offender ip!

[Jonb]

I would presume you have but to check you have switched on the block offenders in the interface.

[mdima]

@Jonb:

I would presume you have but to check you have switched on the block offenders in the interface.

of course…

I think it is a limit of "snort2c" (the plug-in used to block offending IPs). Looking at the source code of snort2c, it looks it only blocks the source IP, while in some rules (flow: from_server) it should block the destination IP.

Unfortunately in the snort2c code I see that the rule generating the alert is not "parsed" in any way to understand which is the IP to block, it just goes straight to block the source ip.

Maybe it would have sense to change the snort2c code in order to block the source and the destination IP at the same time, because anyway the local addresses are in whitelist by default. In this case it should be easy to add just 3-4 lines of code in the snort2c source.

What do you think about it?

Thanks,
Michele

[mdima]

I was investigating a little more. The plugin used by the Snort package is spoink.
In the file spo_pf.c, function AlertPf, it would be easy to duplicate the same algorithm used for the source IP also for the destination IP.
This algorithm:

1. Tries to get the source IP
2. See if the IP is not in white list
3. If not, blocks the IP

if this would be applied to both source and destination IP (5 lines of code) it would solve the problem. I think, but better to ask it should not have side effects.

What you all think about that?

[marcelloc]

An easier way is to fill src and dst on rule.

Last century ;) I wrote a perl script that 'tails -f snort logs' and block offenders based on categories and ip.

If whe are looking to change alert_pf whe may include a feature to block hard attacks and not all alerts/logs

[mdima]

@marcelloc:

An easier way is to fill src and dst on rule.

Last century ;) I wrote a perl script that 'tails -f snort logs' and block offenders based on categories and ip.

If whe are looking to change alert_pf whe may include a feature to block hard attacks and not all alerts/logs

hehe! Yes, me too… when I had a different firewall I was saving the Snort alerts on a SQLServer, then I made a program that was parsing the alerts and insert the "ban list" for the firewall. But this is a complex system and actually I don't know how to do that on FreeBSD.

I try to post a task in redmine, I see what the guys tell me!

[digdug3]

I too have the same problem.

Isn't it possible to allways block the destination ip on one interface? So I can block destination ip-s on my LAN and source ip-s on the WAN interface…