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
