On 6/30/2013 2:20 PM, Pascal Hambourg wrote:
staticsafe a écrit :
On Sun, Jun 30, 2013 at 03:15:47PM +0200, Pascal Hambourg wrote:
Redalert Commander a écrit :
---------- Forwarded message ----------
From: Igor Cicimov
You can block repeated attempts to log in with iptables using the
'recent' module, an alternative is 'fail2ban', which monitors your
server logs (ssh, apache, and others) for failed login attempts and then
adds an iptables rule for the offending IP.
The 'recent' match is vulnerable to source IP address spoofing and can
be abused to cause a DoS for the spoofed address. fail2ban is much less
vulnerable to such attacks.
Jerry Stuckle a écrit :
I don't understand this statement. How is 'recent' more vulnerable to
source IP address spoofing than fail2ban? Both depend only on the
supplied address.
The ruleset using the 'recent' match is based only on TCP packets with
the NEW state, i.e. the initial SYN. A single SYN packet can be easily
forged with a spoofed source address. Fail2ban is based on
authentication failures, which first requires a TCP connection to be
established with the 3-way handshake. As it involves a positive reply
from the spoofed address, this is much harder to achieve, unless the
attacker is in a special position on the network.
And how can recent 'be abused to cause a DoS...' any more than fail2ban?
This is just the consequence of the above.
IP address spoofing with TCP, what?
Yes.
That only works with UDP.
No. It works with any mechanism which is based on a simple packet
instead of a real "stateful" connection (including a positive reply).
Which is the case here, see below.
(Hint - three way handshake for TCP).
As I wrote above, the proposed rulesets using the 'recent' and 'limit'
matches are only based on the initial SYN packets. They do not care
about the 3-way handshake.
OK, that makes a lot of sense. However, there are two problems with
fail2ban, also. The first one is it requires an authentication failure.
Port probing will not trigger it (but recent can). The second being
it depends on log entries, which can be buffered. I have it monitoring
my email (smtp/imap/pop3) ports. Even though it is set to trigger after
two failures, I have seen as many as 50+ failures logged from the same
ip address within seconds before fail2ban is triggered.
I'm not so worried about SYN attacks from spoofed IP addresses as I am
attempts to break in (despite several security measures). I want to
shut them off ASAP.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d08841.9040...@attglobal.net
