For about a week now I’ve been seeing mass attempts to relay through postfix and login to dovecot from the same 2 addresses, none are successful due to how postfix/dovecot are configured and I wouldn’t be overly worried but my isp have picked up on it and are nagging at me
What ways do people go about just dropping connection attempts from offending addresses/ranges when stuff like that happens?
An ideal thing would be something that detects repeated failed attempts from a host or range and subsequently ignore/ban them, perhaps for a specified length of time, something along the lines of denyhosts and fail2ban for ssh would be great
Don’t know if there’s anything out there or just a plain tried and trusted method anyone might use for stuff like this, if not a hint on the most appropriate way to go about it ‘manually’ would do
That’s part of the burden of running a public accessible mail server. There are some recipes for using the ipt_recent netfilter module similar to how it’s used for ssh, but it’s also going to catch legit frequent users so you may have to be selective. Search for ipt_recent.
> For about a week now I’ve been seeing mass attempts to relay through
> postfix and login to dovecot from the same 2 addresses, none are
> successful due to how postfix/dovecot are configured and I wouldn’t be
> overly worried but my isp have picked up on it and are nagging at me
>
> What ways do people go about just dropping connection attempts from
> offending addresses/ranges when stuff like that happens?
>
> An ideal thing would be something that detects repeated failed attempts
> from a host or range and subsequently ignore/ban them, perhaps for a
> specified length of time, something along the lines of denyhosts and
> fail2ban for ssh would be great
>
> Don’t know if there’s anything out there or just a plain tried and
> trusted method anyone might use for stuff like this, if not a hint on
> the most appropriate way to go about it ‘manually’ would do
blockhosts can be used on more than ssh - that’s what I’ve got installed
on my external-facing system and it does a good job.
Cheers ken_yap, just download a copy which I’ll have to wait until tomorrow to look at, silly o’ clock in the morning here now
I really should know more about iptables but I shamefacedly admit to haviong been a bit lazy there
I did try this but it’s not had any effect (I thought iptables used /etc/sysctl.conf but running the command doesn’t add anything to it)
iptables -A INPUT -s [offending-ip] -j DROP
I also found postgrey and installed that, doesn’t seem to be any configuration except the ability for whitelisting, wlll keep an eye on what effect that has over the next couple of days
That’s probably going to add the rule at the end of the chain where the SMTP traffic has already been allowed by a previous rule. You need to get up to speed with iptables. It’s not connected with sysctl.
Bit hard to get started though cos I can’t find where to add rules, doesn’t seem to be an iptables config file anywhere, assumed that being due to it tied up with susefirewall2 so started looking around, closest thing I’ve been able to find is /etc/sysconfig/scripts/SuSEfirewall2-custom
Don’t know if that’s the correct place or not, the file contains sections all with a value of ‘true’ and I’m having a bit of difficulty understanding where I would add stuff if this is the file I should be using, the comments on most of the sections mostly talk about ports and protocols, no mention of hosts or addresses
This comment in there made me smile
# You can use this hook to ... hmmm ... I'm sure you'll find a use for
# this ...
I like the optimism but I don’t think the guy had me in mind when he wrote it
I’ve googled for any kind of opensuse iptables how-to and not really found anything useful, so I could do with some pointers from someone familiar with iptables on opensuse to get me going
Ecky: SuSEfirewall2 lets you insert some additional rules. Have a look at /etc/sysconfig/scripts/SuSEfirewall2-custom
Edit it to contain something like:
fw_custom_before_port_handling() {
# these rules will be loaded after the anti-spoofing and icmp handling
# and after the input has been redirected to the input_XXX and
# forward_XXX chains and some basic chain-specific anti-circumvention
# rules have been set,
# but before any IP protocol or TCP/UDP port allow/protection rules
# will be set.
# You can use this hook to allow/deny certain IP protocols or TCP/UDP
# ports before the SuSEfirewall2 generated rules are hit.
#
# added by vodoo:
# a list of IP numbers to be blocked as listed in a separate file
BLOCKED_IP_NUMBERS=$(cat /etc/sysconfig/scripts/drop-these-ip-numbers-25 \
| sed -e "/^#/ d" -e "s/ *#.*//")
for BLOCKED in $BLOCKED_IP_NUMBERS ; do
iptables -A input_ext -s $BLOCKED -p tcp --dport 25 -m state --state NEW -j DROP
done
true
}
Now, in the same directory, create a new file and name it “drop-these-ip-numbers-25”. In this file you can add all the source IP numbers to be blocked for port 25, one IP number per line. You can use comments starting with #
-m state --state, why is state needed as well as --state (just the way the iptables command is structured?) and is it always used like that?
-m state loads the extended packet matching module “state”. This module is then used to check if the packet has started a new connection (–state NEW). The effect of this is - as far as I understand - that you can still send email to a blocked IP but the remote IP can not establish a connection with you. I think you can omit this in your case.
The chain you have there, input_ext, not come across it in my googling, how does it differ from ‘input’?
SuSEfirewall2 has a chain “input_ext” for the external NIC pointing to the universe. This is where you want to block (DROP). Check this chain:
# iptables -S input_ext | less
Your new rules will appear close to the top of this list. Mine looks like this:
-N input_ext
-A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A input_ext -s 62.202.97.58/32 -p tcp -m tcp --dport 80 -m state --state NEW -j DROP
-A input_ext -s 85.5.108.58/32 -p tcp -m tcp --dport 80 -m state --state NEW -j DROP
-A input_ext -s 129.247.247.239/32 -p tcp -m tcp --dport 80 -m state --state NEW -j DROP
-A input_ext -s 59.180.58.195/32 -p tcp -m tcp --dport 25 -m state --state NEW -j DROP
<...>
As you can see I am blocking three addresses for port 80 and one for port 25. For port 80 I have just one more configuration file and the respective code for insertion in /etc/sysconfig/scripts/SuSEfirewall2-custom. Please report how this is working for you.
Hostnames are not reliable. There may be no reverse IP mapping at all.
You can specify subnets in iptables rules. A single host is just a special case of a subnet with one address.
I would also add, don’t spend all your time chasing this. Maybe you can block off whole geographical regions you never have any interest in communicating with, but at some point, it’s a waste of your time, so just get your services to drop connections as soon as they are known to be not useful, e.g. using blacklists.
On 2011-08-01 16:46, Ecky wrote:
> What about spoofed addresses, when the reported hostname doesn’t match
> the ip address?
That’s something postfix can do, but it is not as wise as it seems. There
are ISPs that do not allow clients to adjust the revers name resolving. Or
they simply have several aliases for the same IP number, so the RDNS can
not match all.
I am assuming that your host is suffering from a dictionary attack on your mail server. If that is so, I recommend looking for a product that offers “greylisting” capability. (We use ASSP, Anti-Spam SMTP Proxy.)
Greylisting is a method that takes advantage of mail robots that “fire and forget” email messages. Greylisting reads a couple of lines of the header then sends a 4xx message to the server that says this host is not available at the moment. Reputable mail servers retry every so often. Disreputable ones do not.
This single feature blocks 85 - 95% (really!) of the spam and dictionary attacks that has plagued our server over the last few years. And does so with very little network overhead. I am deeply impressed. The only noticeable downside is the delay when an unrecognized IP address shows up. (Successful retries are recorded and allowed through in the future.)
My only consideration about using IP addresses and ranges to block the nasty servers is that IP addresses and ranges are always changing.
> I am assuming that your host is suffering from a dictionary attack on
> your mail server. If that is so, I recommend looking for a product that
> offers “greylisting” capability. (We use ASSP, Anti-Spam SMTP Proxy.)
Postfix has it.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
I confirm that greylisting does wonders, but my users don’t like it at all because they expect mail to arrive without delay in any case. But they get used to it over time. For anyone who wants to try greylisting I recommend j-chkmail.
Yeah mate, I am using cbl.abuseat.org & zen.spamhaus.org for postfix, going on the assumption that you wouldn’t want any traffic at all from ‘bad hosts’ I was wondering if the susefirewall2 could be made to utilise such lists (and whether it would be wise or not) for whichever services you wanted to ‘tighten up’, e.g. mail, ssh and ftp, thinking it could be a convenient way of doing things
The mail server’s always been pretty tight as far as I’m able to tell and everyone says they’ve not ever had any malware and hardly any unsolicited spam, it was in fact you helped me get it set up ken_yap so I’ll take this opportunity to thank you once again for that
Indeed robin, I have experienced this myself, most noticeably pm messages from a forum a friend of mine runs, for whatever reason he has pms from his forum sending as billing-otherdomainheowns.com instead of something@hisforumdomain.com and they get caught by it
I’ve been using postgrey for the past week or so, sounds like it works in much the same way as ASSP and does so quite well, especially as there’s a small enough number of users to whitelist each individual user’s mail accounts
I hear ya and know where you’re coming from there mate, but having said that there are numerous entire countries to and from where no traffic of any kind via any services the server runs is either necessary or even wanted and isn’t ever likely to be, which at the very least is food for thought
I’m fairly confident that nothing which shouldn’t get through anywhere gets through, and I do occasionally have a quick scan through logs to see if anything unusual jumps out, but when my isp contacted me that they suspected I was relaying I obviously had to check that out and it just got me wondering if there weren’t ways to make things more secure than they already are. Don’t think it pays anyone to be complacent about such things in this day and age, so I started tossing around ideas and went fishing for more
So far it’s been an interesting discussion and I’ve learnt one or two new things which is always good, so thanks for all the input guys
