Re: SMTP Backscatter

[Dave Corsello <snort-users () wintertreemedia com>]

Wow, thanks for this.

For starters, I limited the functions to just:
- open my alert.fast log file and position at eof
- loop
-- sleep
-- parse new records for alerts that contain "BLOCKED DESTINATION"
-- grab the destination IP from the next record
-- insert an iptables rule that blocks all incoming traffic from that
address
- end loop

I have just one "BLOCKED DESTINATION" rule for outgoing SMTP 450 errors,
so what I've coded so far is good enough for now.  It's quick and dirty,
but it works.  If I have a chance to work on this more, I'll add the
other functions that you suggested.  But until then, I'll probably just
reload my default iptables rules from time to time to clear our the
blocked addresses.

The fast alert log never rolls over, right?  I have code to handle a
roll-over if it occurs, because I originally thought I'd be parsing the
unified2 log.  But I don't think I'll need it.

I have one question:  I'm getting multiples of the same iptables rule in
a row.  Maybe this is due to a sleep time that's too long?  It's
currently set to 1 sec.  I installed hires, but haven't implemented it
yet in the script.  Before I do, I wanted to ask you how many
milliseconds do you sleep, and what made you choose that amount of time?

Thanks again for your help.

On 2/17/2014 3:29 PM, waldo kitty wrote:
> On 2/17/2014 10:13 AM, Dave Corsello wrote:
> > On 2/16/2014 10:25 AM, waldo kitty wrote:
> > > On 2/16/2014 9:54 AM, Dave Corsello wrote:
> > > > and in response, 2) block all incoming SMTP traffic from the sender
> > > > IP for a
> > > > period of time?
> > > i'm not aware of this ever having been done... *I* do it in my
> > > active response
> > > system but it requires that the system have a way of knowing to
> > > reverse the IPs
> > > and then for it to reverse them during its processing where in the
> > > end it issues
> > > iptables rules to block the remote site... a feature is that at some
> > > point in
> > > the future, the block expires and is removed from iptables...
> > >
> > > my response system is a perl 'app' that monitors the default snort
> > > ALERT file...
> > > one can easily code up something similar and create the necessary
> > > custom rule(s)
> > > for snort to use... if you are interested in more details and doing
> > > some coding,
> > > you may contact me offlist if you like...
> >
> > I'm interested.  Thanks!
>
> the first thing is to be able to monitor and parse the default snort
> alert file as new alerts are posted to it... once that is done, then
> one can decide how they want to respond to the alerts... either ignore
> it because it doesn't fit some pattern or issue some sort of response
> to it...
>
> the alert file format is pretty simple... each alert block may or may
> not have all 7 standard lines and there may be one or more following
> lines containing reference entries from the rules (web sites with
> information on the attack, violation or rule)... for our purposes, we
> only need the GID:SID (to check for white listings and to report in
> the logs and GUI Pages), the MSG (for the GUI page, tracker files, and
> to indicate that we need to reverse the IPs before the block), the
> SOURCE and DESTINATION IPs (so we know what to block as well as
> logging to the GUI pages)... everything else is icing on the cake...
>
> on the aspect of indicating that the IPs need to be reversed in the
> processing, i use the string "BLOCKED DESTINATION" in the snort rule
> msg...
>
> eg: LOCAL.RULES SMTP rejected for spam -- BLOCKED DESTINATION
> eg: LOCAL.RULES SMTP Mail set NOT to be delivered -- BLOCKED DESTINATION
> eg: LOCAL.RULES SMTP Authentication failed -- BLOCKED DESTINATION
>
> pretty much anything where i'm using an outbound internal server
> message to detect a violation of our rules by an external entity...
>
> when the script decides to do something with an alert and it detects
> the above string in the msg, it simply swaps the IPs in the variables
> that contain them and processes on as usual...
>
> in effect, we do something like this...
>
> on start-up of the script, position to the end of the alert file...
> then enter the processing loop...
>
>   start of never-ending loop
>     hires sleep for certain millisecond period
>     if we are no longer at the bottom of the alert file,
>       start alert parsing loop
>         parse each line of the alert block to extract the needed data
>           store 1st line between the [**] markers to $type
>             store rule GID:SID:REV to $id from $type
>           store priority to $pri from the 2nd line (if priority field
> exists)
>           store the $src_ip and $dst_ip from the 5th line
>         jump to checking routine passing these 5 vars
>       until we reach the bottom of the alert file
>     check for expired IP hashes and handle them
>     check for changed config files and handle them
>     check if WAN IP has changed (for dynamic or DHCP) and handle it
>   )
>
> we terminate the loop and thus the app on SIGTERM and similar because
> we set up routines to catch those signals before we got to the
> processing loop... these routines cause the app to write memory
> resident data to files for reloading on next start-up of the app so we
> can return to a known state and retain all our blocked IPs... yes, we
> also remove our automated IP block rules when we shut down the app so
> that means as long as the app is down, IPs that were blocked
> automatically are not blocked any more... we can specifically convert
> them to a manual entry in our GUI but for the most part, this is only
> desired once in a blue moon... now on to the rest of the pseudo-code ;)
>
> in the checking routine...
>
>   break out the GID and SID of $id (revision is unneeded)
>   if index($type,"BLOCKED DESTINATION") > -1
>     reverse $src_ip and $dst_ip
>   check various whitelistings of GID, SID, GID:SID, IPs
>     abort if the entry is in a whitelist
>   check priority if you are servicing only certain priorities
>     abort if the priority is not in the valid range
>   we made it this far so now
>     if packet was sent to/by our WAN, network or gateway address
>       call block_it($source,$dest)
>
>
> the last part, block_it, is where we generate our iptables rules to
> block and possibly log future hits by the same IP... this routine is
> also where we add the offender to a hash list along with the datetime
> information for later removal of the blocking and possible logging
> rules... we also record "tracker" files that contain every violation
> the IP has committed... these are, of course, named by IP number... in
> the above pseudo-code, we're only passing the $source and $dest but in
> our app, we pass the additional vars we sent to the checking routine
> because all of the info is logged and written to GUI pages for human
> interaction...
>
> the app maintains a hash list of blocked IPs so that we don't create a
> new iptables block or log rule every time... we only need one block
> and log rule for each offender... but every time they violate another
> rule, their ban time is extended by a selected random amount... since
> our snort watches our WAN IP, it sees the traffic before iptables
> does... this allows us to keep extending the ban time for every
> violation... when the remote IP stops triggering alerts then at some
> point their ban time limit is reached so we remove the block and log
> rules as well as the IP from the hash file... keeping or not the
> tracker file with the list of violations is something else...
> currently we do not keep it when the ban is dropped...
>
> one thing that one needs to also keep in mind is if the blocked list
> is going to be maintained across reboots... after a reboot, the main
> processing loop will cycle and check for expires which will then
> remove those entries' blocks that expired while the system was down or
> the script was not running...
>
> something else is that in case of a system shutdown, one has to save
> their data... on a *nix system, shutdowns are pretty brutal and can
> result in data not being saved because there's no way to tell the
> shutdown to wait until the apps are finished writing their data...
> i've not found a way, any way... if you know of a method, i would be
> glad to hear of it... right now, one has to specifically alter the
> system so that when shutdown is called, a script runs that allows the
> app to finish its job and then the script calls the normal shutdown
> methods... this isn't really a good thing but it does work...
>
> so now, after all the above, i hope this helps give you some ideas...


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!