Im my case, although I haven't looked at it in a week or so, the spam "Waves" would come in 5 or so e-mails, to non-existant e-mail accounts at one of my domains, each message from the same IP. Then, I'd get the same message, different "To" address, different IP, 5 or so of them. This would continue, and we're talking several dozen a second like this, for hours on end. Then, suddenly, they'd stop for a while, then gradually build back up. It's kind of funny to watch. The SMTP concurrency rarely changes, since most are blocked because the sources are on various RBL's. Those that don't, get greylisted and that usually ends that.
Prior to running SpamDyke, this stuff was killing my server...At least now I have some degree of controlling the connections to the server... I would like to set up a honey-pot type system that can take some of the greylisted entries that don't exist, and parses their source IP's into a blacklist_IP file... I think this would be better than the SMTP Valid Rcpt to, since it won't validate existing e-mail addresses, but could quickly build a very relevant RBL that is specific to a particular organizations mail server... If I'm getting attacked by a specific spammer, my RBL needs might be different than someone elses, and it would allow the "Local" RBL to be updated much more quickly than the other more commonly used RBL's... Any ideas on this? I mean, adding to either the blacklisted_IP file should be easy, but I think adding to a local RBLDNS would be cleaner and less taxing on the system. (And be usable by multiple servers in a cluster). The trick would be, I guess, writing a script that would go through the Greylisted e-mail accounts, check if they exist, if they don't, parse the source e-mail that created them for the IP, add it to the RBLDNS, then, since we're there, delete the greylist entry...Might as well tidy up a bit... Michael J. Colvin NorCal Internet Services www.norcalisp.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, May 08, 2008 5:35 PM > To: spamdyke users > Subject: Re: [spamdyke-users] OT: Spambot attack > > I've had this happen a couple of times, but nothing on this > scale. Each time, I've just blacklisted the sender/recipient > as appropriate. It's nice to know spamdyke is helping > prevent a DoS! :) > > As clever as the automatic RBL system is, I would recommend > against it until you can figure out why this is happening. > If this is due to backscatter, you could end up blacklisting > (otherwise) legitimate mail servers. Also, with the kind of > load you're getting, I don't think adding rblsmtpd would be > an improvement -- adding DNS lookups would just increase the > time needed to accept an incoming connection. > > -- Sam Clippinger > > > On Wed, May 07, 2008 at 11:01:43PM -0300, Pablo Medina wrote: > > > >> May 06 943.600 connections. > >> May 05 993.454 connections. > >> May 04 840.815 connections. > >> May 03 1.022.314 connections. > >> > >> Different IP address: 75238 > >> Different class C subnets: 50074 > >> Different class B subnets: 8936 > >> > >> I have selected random addresses to check and IPs are from > different > >> countries (most of them from Asia, but many from Europe) > >> > >> This makes impossible for me to contact each network owner > to alert > >> about the situation. So right now, we are relying only on > spamdyke to > >> control the situation. It is doing it's work great, but i am very > >> concerned by the fact that connections never decrease nor stop. > >> > >> My question is: has anyone experienced this issue before?. > Any advice > >> on how to deal with it?. > > > > Wow, impressive. > > > > Two suggestions: > > > > 1. build and host your own RBL of attacking addresses. This is > > relatively easy to do with a script that reads the spamdyke log on > > stdin (e.g. via > > xtail(1)) and writes rbldns(8) format lines to stdout. > > > > It just so happens that I have a set of similar scripts > which you may > > want to adapt. > > > > #!/bin/sh > > echo +$(echo -n $TCPREMOTEIP. | tac > -s.)__myrbl__:127.0.0.2:0:$(date > > --date '12 hours' +"16o2 62^%s+2 32^* 42949672960+p" | dc | tr A-Z > > a-z) > > >rbltrap-data/$TCPREMOTEIP > > echo "451 Sorry, try again later." > > exit 0 > > > > This isn't directly useful to you; you need to read stdin in an > > endless loop, parse out the client address for offending > lines (using > > maybe sed -n as a replacement for grep | sed), and once you have > > TCPREMOTEIP, you can create an RBL record for it using > something like > > the above. The dc magic makes sure the RBL record expires > after a while. > > > > A cron script can periodically remove old rbl snippets and > commit the > > updated data to svn: > > > > #!/bin/zsh -x > > if [[ "$1" != locked ]]; then > > exec chpst -L /var/lock/rbltrap-cron.lock "$0" locked fi > > > > STATEDIR=/var/lib/rbltrap-data > > SVNPWDFILE=/etc/svn/pwd > > IPTIMEOUTDAYS=1 > > RUNASUSER=qmaild:qmail > > SCRIPTDIR=/usr/local/lib/rbltrap-scripts > > LOCKDIR=/var/lock > > SVNLOCK="$LOCKDIR/rbltrap.svn.lock" > > CDBLOCK="$LOCKDIR/rbltrap.makecdb.lock" > > > > . /etc/default/rbltrap > > > > SVNPWDARGS=$(cat "$SVNPWDFILE" 2>/dev/null) > > > > cd "$STATEDIR" || exit 1 > > > > unset HOME > > > > chpst -u "$RUNASUSER" -L "$SVNLOCK" tryto -n1 -P -t 60 -k 65 \ > > svn cleanup >/dev/null 2>/dev/null > > > > chpst -u "$RUNASUSER" -L "$SVNLOCK" tryto -n1 -P -t 300 -k 310 \ > > svn -q ${=SVNPWDARGS} update > > > > chpst -u "$RUNASUSER" \ > > find . -maxdepth 1 -mtime +$IPTIMEOUTDAYS -exec svn del {} + > > >/dev/null > > 2>/dev/null > > > > chpst -L "$CDBLOCK" tryto -n1 -P -t 300 -k 310 \ > > "$SCRIPTDIR"/rbltrap-makecdb > > > > chpst -u "$RUNASUSER" -L "$SVNLOCK" tryto -n1 -P -t 300 -k 310 \ > > svn --force add . >/dev/null 2>/dev/null > > > > exec chpst -u "$RUNASUSER" -L "$SVNLOCK" tryto -n1 -P -t > 300 -k 310 \ > > svn -q ${=SVNPWDARGS} commit -m "$(hostname -f) autocommit" > > > > The rbltrap-makecdb script looks like this: > > > > #!/bin/zsh > > RBLDOMAIN=myrbl.com > > STATEDIR=/var/lib/rbltrap-data > > NS=(ns1.myrbl.com) > > typeset -A NSIP > > NSIP[ns1.myrbl.com]=127.2.0.53 > > DATAROOT=/service/rbltrap-dns/root > > DATA="$DATAROOT"/data > > > > . /etc/default/rbltrap > > > > cd "$STATEDIR" || exit 1 > > rm -f "$DATAROOT"/data > > for i in [EMAIL PROTECTED]; do > > echo .${RBLDOMAIN}:$NSIP[$i]:$i >>"$DATA" > > done > > > > find . -maxdepth 1 -type f -exec sed "s/__myrbl__/$RBLDOMAIN/g" {} + > > >>"$DATA" > > > > cd "$DATAROOT" > > make -s > > > > cp -a "${DATA}.cdb" "$STATEDIR/cdb/" > > > > Once you have your own RBL, an attacking IP connecting to > server A can > > be denied right away at servers B, C and D. Of course, it's good to > > have local copies of the RBL zone on each. If you include > rblsmtpd in > > the delivery chain before spamdyke and give it only your > own rbl zone, > > it may be faster than spamdyke because it's smaller and does less. > > > > 2. Same as above, but instead of or in addition to building an RBL, > > create firewall rules that block incoming connections from the > > attacking IPs. I don't know what OS you use, but this is > very easy to do on Linux. > > > > Again, a script that does something similar, albeit for ssh: > > > > #!/bin/zsh > > exec 2>&1 > > CONFIG=/etc/ssh-hammerblock/config > > SSHLOG=/var/log/socklog/ssh/current > > STATEDIR=/var/lib/ssh-hammerblock > > THRESHOLD=12 > > TMPREAPER_TIME=1h > > RULE="-I INPUT -s __IP__ -j blacklisted" > > [[ -r "$CONFIG" ]] && . "$CONFIG" > > mkdir -p $STATEDIR > > chmod 700 $STATEDIR > > xtail $SSHLOG 2>/dev/null \ > > | sed -nu ' > > s/::ffff:// > > /Failed/{ > > s/.*for .* from // > > s/ .*// > > p > > } > > /Invalid user/{ > > s/.*Invalid user .* from // > > p > > } > > /error: PAM: Authentication failure for .* from /{ > > s/.* for .* from // > > p > > }' \ > > | while read IP; do > > tmpreaper $TMPREAPER_TIME $STATEDIR/./ > > COUNT=$(cat "$STATEDIR/$IP" 2>/dev/null) > > ((COUNT++)) > > echo -n "$COUNT" >"$STATEDIR/$IP" > > if [[ "$COUNT" -ge "$THRESHOLD" ]]; then > > iptables ${=RULE//__IP__/$IP} > > rm -f "$STATEDIR/$IP" > > fi > > done > > > > You can combine the two (add offending IPs to svn, use cron > to build > > firewall blacklist from svn); this has the benefit that you aren't > > even spawning a spamdyke instance for incoming malicious > connections > > (other than the first time, or during the first few minutes). > > > > Andras > > > > -- > > Andras Korn <korn at chardonnay.math.bme.hu> > > <http://chardonnay.math.bme.hu/~korn/> QOTD: > > Ez a cso is amott all, ahelyett, hogy emittalna. > > _______________________________________________ > > spamdyke-users mailing list > > [email protected] > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
