Half a million might be too much. :) I honestly don't know what iptables can do, it's only ever stopped a couple dozen IPs at a time for me. You'd definitely have to rewrite my script to store the IP files in multiple subdirectories, since most filesystems can't handle half a million files in a single folder.
-- Sam Clippinger On Sep 1, 2012, at 5:30 PM, "J.R. Lillard" <[email protected]> wrote: > Iptables was my first thought but half a million ips seemed like too much for > it. How many rules have you had with your script? > > J.R. Lillard > System / Network Admin > Web Programmer > Hyphen Communications > > On Sep 1, 2012 4:09 PM, "Sam Clippinger" <[email protected]> wrote: > Unfortunately spamdyke can't do this right now. If you really need it to, > you could always modify the filter_rdns_missing() function in filter.c -- > just insert a call to exit() within the if() statement and recompile. Any > time the filter is triggered, spamdyke will immediately exit without logging > anything or outputting anything to the remote client. In order for this to > work correctly, you'll need to enable the reject-empty-rdns filter in the > global configuration file and not use configuration directories. Note this > will break some of spamdyke's other functionality. For example, if someone > is delivering mail from a host without an rDNS name and is whitelisted or > trying to authenticate, this change will drop them too (it'll trigger before > the whitelist and authentication code runs). Also, because no logging will > take place, you won't be able to tell how much activity is still going on. > > However, I agree with Eric that this is probably not the right approach. If > the goal is to reduce the level of packet traffic, I would go all the way and > block the connections at the firewall. That would reduce the traffic to just > a single incoming packet (that gets dropped) instead of three packets to > establish the connection, at least two to look up the rDNS (probably more) > and two to close the connection. It wouldn't be hard -- you could use the > spamdyke log messages to find the IPs that are being rejected for missing > rDNS, then further filter the list based on the target address (presumably > only one or two domains are under attack). The script can use iptables (on > Linux) to add a rule to just drop any SYN packets from those IPs. If you're > clever about it, the script can keep a little more information about the IPs, > such as when they were blocked, so they will fall off the list after a > day/week/month/etc. > > This sort of script would be better than modifying spamdyke because it would > only catch rejections that weren't whitelisted or authenticated. You could > also add exceptions to the script so certain IPs would never be blocked by > it, even if they were being rejected by spamdyke. It would also let you > monitor the ongoing activity to see if it's stopped. > > I happen to have such a script you could use as a starting point. :) I wrote > this years ago when I got tired of watching zombie bots trying to bruteforce > their way into FTP and POP3 connections; I call it bruteforce_blocker.sh and > it runs every 30 minutes on my server. Basically, it searches the logs for > rejection messages from those two services and counts them up. If there are > more than X rejections from an IP, it creates a file in a special folder > (/etc/rc.d/firewall_blocks) with that IP's name. Then it re-runs the script > that sets up my firewall rules (rc.firewall). That script clears the > existing firewall rules, adds blocks for all of the IPs in the special folder > (unless they are listed in /etc/rc.d/unblockable_ips), then sets the normal > access rules. It also checks the timestamp on the files and deletes any that > are more than 7 days old, so IPs eventually "fall off" the block list. You > would need to modify the first script to look for spamdyke's log messages and > the second script to block SMTP access, but it shouldn't be very hard. And > of course modify the normal access rules, since your setup is undoubtedly > different from mine. My server runs CentOS, so if you're on a different > platform you may need to make some changes to the commands (especially > iptables) but the concepts should be the same. > > Good luck! > > > > > -- Sam Clippinger > > > > > On Sep 1, 2012, at 11:45 AM, Eric Shubert wrote: > > > On 09/01/2012 08:17 AM, J.R. Lillard wrote: > >> I have a client that uses spamdyke but I am new to it. I've read > >> through the documentation so I am vaguely familiar with it now. They > >> have been under a DDOS attack for about a month now. It's not enough to > >> bring their servers down. Basically it's a bunch of SMTP traffic > >> attempting to send spam. Spamdyke has been doing a great job of > >> blocking the connections usually with the DENIED_RDNS_MISSING error. > >> The problem is this attack has been eating up a lot of their > >> bandwidth. As a temporary measure their ISP has asked them to just drop > >> the invalid connections instead of issuing the appropriate SMTP response > >> codes. Is this something spamdyke can be configured to do? I did not > >> see anything obvious in the documentation. > >> > >> -- > >> J.R. Lillard > >> System / Network Admin > >> Web Programmer > >> Hyphen Communications > >> > >> _______________________________________________ > > > > Hey JR, > > > > I don't know the answer to this question. Sam will no doubt chime in on > > spamdyke's capability regarding dropping connections. My opinion is that > > this would not be an appropriate thing to do. > > > > Given what you've described, I would consider whether the host is > > running a caching nameserver or not. What are the contents of > > /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic > > can be reduced a bit by running a resolver on localhost (127.0.0.1). > > Personally, I use the pdns-recursor package on CentOS. I expect that > > there's probably a powerdns recursor available for your platform as well. > > > > You'll also want to check that you're not using too many > > dns-blacklist-entry= parameters. In this area, more isn't necessarily > > better. Personally, I use only zen.spamhaus.org and bl.spamcop.net. > > > > While DNS traffic isn't large from a bandwidth standpoint, I expect that > > it's larger than SMTP response codes. If the DDOS attacks are coming > > from a single group of IP addresses, having a caching nameserver on > > localhost will provide a substantial reduction in network/DNS traffic. > > > > HTH. > > > > -- > > -Eric 'shubes' > > > > > > > > _______________________________________________ > > 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
_______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
