Deterring mail relay attempts
in [Debian]
|
From: Alan Chandler on 28 Jun 2010 13:30 I have just moved my mail server (exim4 split config based) from one machine to another, and in doing so started examining the logs. I am being hit with multiple attempts to relay - several a second. They come in bursts from one host, then come from somewhere else. I would like to put some for of inconvenient barrier up so perhaps they stop bothering me. What is a good way of deterring them? I've added delay = 10s in conf.d/acl/30_exim4-config_check_rcpt thus:- # Insist that any other recipient address that we accept is either in one of # our local domains, or is in a domain for which we explicitly allow # relaying. Any other domain is rejected as being unacceptable for relaying. require message = relay not permitted domains = +local_domains : +relay_to_domains delay = 10s Does this hang on to the incoming connection for 10 seconds? Is this a mini teergrube? Is 10s a sensible figure? -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C28DA0B.9090002(a)chandlerfamily.org.uk
From: Chris Davies on 29 Jun 2010 07:30 Alan Chandler <alan(a)chandlerfamily.org.uk> wrote: > I have just moved my mail server (exim4 split config based) from one > machine to another, and in doing so started examining the logs. I am > being hit with multiple attempts to relay - several a second. They come > in bursts from one host, then come from somewhere else. > I would like to put some for of inconvenient barrier up so perhaps they > stop bothering me. > What is a good way of deterring them? Fail2ban is remarkably good at helping deter probes such as relay attempts. Get it working "out of the box" and then tweak it to match against other exim messages. Chris -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/2hvof7xs3l.ln2(a)news.roaima.co.uk
From: Alan Chandler on 29 Jun 2010 08:50 On 29/06/10 11:46, Chris Davies wrote: > Alan Chandler<alan(a)chandlerfamily.org.uk> wrote: >> I have just moved my mail server (exim4 split config based) from one >> machine to another, and in doing so started examining the logs. I am >> being hit with multiple attempts to relay - several a second. They come >> in bursts from one host, then come from somewhere else. > >> I would like to put some for of inconvenient barrier up so perhaps they >> stop bothering me. > >> What is a good way of deterring them? > > Fail2ban is remarkably good at helping deter probes such as relay > attempts. Get it working "out of the box" and then tweak it to match > against other exim messages. > > Chris > That looks a great idea. I will try it. I suppose that I can pick up the IP addressed from /var/log/exim4/rejectlog and then use an iptables chain with something like iptables -N smtp-in iptables -A smtp-in -s banned-ip -j DROP .... iptables -A smtp-in -j ACCEPT iptables -A INPUT --dport 25 -j smtp-in I already have something setup like this as my firewall - and I actually already have two chains already defined one "inet-in" and the other "i-estab" for already established connections. A Question. If I drop these banned ip addresses AFTER they have established a connection am I likely to do them more damage than just dropping the first connection. I am thinking that allowing the spam sender to establish the TCP connection and then just dropping all the subsequent packets will be slightly harder for them to detect - and will tie up an outgoing connection on their mail server until they can timeout, rather than dropping the initial connection attempt. On the other hand, just dropping them before even establishing the connection might make them think there is no server there at all. Thoughts ? -- Alan Chandler http://www.chandlerfamily.org.uk -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C29E971.9080901(a)chandlerfamily.org.uk
From: Didar Hossain on 29 Jun 2010 08:50 On Tue, Jun 29, 2010 at 4:16 PM, Chris Davies <chris-usenet(a)roaima.co.uk> wrote: > Alan Chandler <alan(a)chandlerfamily.org.uk> wrote: >> I have just moved my mail server (exim4 split config based) from one >> machine to another, and in doing so started examining the logs. I am >> being hit with multiple attempts to relay - several a second. They come >> in bursts from one host, then come from somewhere else. > >> I would like to put some for of inconvenient barrier up so perhaps they >> stop bothering me. > >> What is a good way of deterring them? > > Fail2ban is remarkably good at helping deter probes such as relay > attempts. Get it working "out of the box" and then tweak it to match > against other exim messages. You could also look at the iptables "limit" and "recent" modules. I use those to drop the automated brute force SSH attempts. What you are seeing is also the same attack using SMTP AUTH. Regards, Didar -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/AANLkTinq-7SlnLbOoAfJk-WSCRUFX73-XvlmZpNyw-Zt(a)mail.gmail.com
From: Chris Davies on 30 Jun 2010 12:30 Alan Chandler<alan(a)chandlerfamily.org.uk> wrote: > I have just moved my mail server (exim4 split config based) from one > machine to another, and in doing so started examining the logs. I am > being hit with multiple attempts to relay - several a second. They come > in bursts from one host, then come from somewhere else. On 29/06/10 11:46, Chris Davies wrote: > Fail2ban is remarkably good at helping deter probes such as relay > attempts [...] Alan Chandler <alan(a)chandlerfamily.org.uk> wrote: > I suppose that I can pick up the IP addressed from > /var/log/exim4/rejectlog and then use an iptables chain [..] Actually, fail2ban does this automatically for you. It adds a DROP for the source IP address into its own fail2ban chain. (And later removes them after a configurable period of time.) Chris -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/422sf7x5pg.ln2(a)news.roaima.co.uk
|
Next
|
Last
Pages: 1 2 3 4 Prev: Current solution for ia32 on amd64? Next: Need dependency bug workaround for pulseaudio. |