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!
bruteforce_blocker.sh
Description: Binary data
rc.firewall
Description: Binary data
-- 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
