今天刚刚看到一个mail上面写的.但是我没有试验过
This is easier:
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP --syn -m limit --limit 3/minute --limit-burst 3
-j ACCEPT
$IPTABLES -A allowed -p TCP -j LOG --log-level "NOTICE" --log-prefix
'[DROP:RATE_LIMIT] '
$IPTABLES -A allowed -p TCP -j REJECT
$IPTABLES -A tcp_packets -p TCP -s 0/0 -d $INET_IP --dport 22 -j allowed
Mojito
>;>; -----Original Message-----
>;>; From: Jeff Rosowski [mailto:rosowskij@ie.ymp.gov]
>;>; Sent: 06 May 2005 14:50
>;>; To: Price, Christopher
>;>; Cc: MPHMedia.Net;
secureshell@securityfocus.com>;>; Subject: RE: Login Attempt Limits
>;>;
>;>; take a look at the following:
>;>;
>;>;
http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks>;>;
>;>; On Thu, 5 May 2005, Price, Christopher wrote:
>;>;
>;
>;>;>; >;
>;>;>; >; Your proposal could lead to a DoS attack designed to deny large
>;>;>; >; ranges of IP addresses access to your SSHD service by using
>;
>;>; IP spoofing,
>;
>;>;>; >; no?
>;>;>; >;
>;>;>; >; -----Original Message-----
>;>;>; >; From: MPHMedia.Net [mailto:MPHMedia@InfoWest.com]
>;>;>; >; Sent: Thursday, May 05, 2005 8:53 AM
>;>;>; >; To:
secureshell@securityfocus.com>;>;>; >; Subject: Login Attempt Limits
>;>;>; >;
>;>;>; >;
>;>;>; >; I had around 650 failed atttempts on the SSHD server from about 5
>;>;>; >; different IPs yesterday.
>;>;>; >;
>;>;>; >; From prior daily reviews of the log file it is clear that
>;
>;>; the majority
>;
>;>;>; >; of the attempts come from hacked SSHD servers because the attempt
>;>;>; >; username pattern is the same from IPs located in different
>;
>;>; parts of the
>;
>;>;>; >; world (though South Korea seems to have the largest volume of any
>;>;>; >; country).
>;>;>; >;
>;>;>; >; The clear evidence is that the SSHD system fails in a good number of
>;>;>; >; cases.
>;>;>; >;
>;>;>; >; One way to look at this failure is to say that the managers of those
>;>;>; >; servers are not requiring sufficiently random passwords for
>;
>;>; their uesrs.
>;
>;>;>; >;
>;>;>; >; The clear mathematics is that use of 8 byte random
>;
>;>; passwords from the
>;
>;>;>; >; complete available password character set will not be
>;
>;>; cracked (to a very
>;
>;>;>; >;
>;>;>; >; high probability).
>;>;>; >;
>;>;>; >; But the clear reality is that very few passwords are
>;
>;>; selected from the
>;
>;>;>; >; widest possible selection pool and rather from a rather
>;
>;>; small pool of
>;
>;>;>; >; familar words and phrases. This reality combined with a
>;
>;>; high volume of
>;
>;>;>; >; attempts obtains an SSHD system failure at a fairly regular rate, as
>;>;>; >; evidence by the attacking IP variation.
>;>;>; >;
>;>;>; >; I looked briefly at some earlier secureshell pages along
>;
>;>; the lines of my
>;
>;>;>; >;
>;>;>; >; following suggestions with the apparent conclusion that the
>;
>;>; suggestions
>;
>;>;>; >;
>;>;>; >; have been considered but not implemented for one reason or
>;
>;>; another. They
>;
>;>;>; >;
>;>;>; >; are:
>;>;>; >;
>;>;>; >; 1. When an IP has failed attempts for different usernames
>;
>;>; within a short
>;
>;>;>; >;
>;>;>; >; period block that IP for some number of minutes. This would be done
>;>;>; >; automatically using configuration file parameters. With
>;
>;>; this option I
>;
>;>;>; >; would block an IP for 30 minutes after three failed attempts with
>;>;>; >; different usernames occuring under a minute.
>;>;>; >;
>;>;>; >; 2. Execute an IP block as above when there are 3 root user failures.
>;>;>; >;
>;>;>; >; 3. Execute an IP block as above when there are 5 same user failures.
>;>;>; >;
>;>;>; >; Apparently there is an option to block an IP completely
>;
>;>; after the fact.
>;
>;>;>; >; I am not seeing repeated attempts on subsequent days from
>;
>;>; the same IP.
>;
>;>;>; >; Hence that option would not address the current attack patterns.
>;>;>; >;
>;>;>; >; With the above automatic IP block features, the 650 failed attempts
>;>;>; >; yesterday would have been reduced to less than 20. That
>;
>;>; could be seen as
>;
>;>;>; >;
>;>;>; >; a 5 bit (32 times) reduction in the probability of a
>;
>;>; successful attack
>;
>;>;>; >; and similarly a 5 bit reduction in the number of failed
>;
>;>; SSHD servers.
>;
>;>;>; >;
>;>;>; >; The effective result would be some multiple greater than 5
>;
>;>; bits overall
>;
>;>;>; >; in that the hacked server pool would decline by a 5 bit
>;
>;>; multiple. That
>;
>;>;>; >; is, the attack volume originates from already hacked servers meaning
>;>;>; >; that the overall attack volume derives from at least two
>;
>;>; layers to which
>;
>;>;>; >;
>;>;>; >; 5 bit attenuation could be applied. I would consider an
>;
>;>; obvious 5 bit
>;
>;>;>; >; attenuation very useful, but an apparent compounded 5 bit
>;
>;>; attenuation
>;
>;>;>; >; seems to argue for immediate implementation. Looked at
>;
>;>; another way, the
>;
>;>;>; >; effective randomness of the currently used password pool
>;
>;>; should increase
>;
>;>;>; >;
>;>;>; >; by 5 to, say, 15 bits. Or we could say that overall SSHD
>;
>;>; security would
>;
>;>;>; >; be increased by a similar degree.
>;>;>; >;
>;>;>; >; Whatever the implementation difficulties, the design is clear.
>;>;>; >;
>;>;>; >; Save failures by IP in the above categories and execute the
>;
>;>; block using
>;
>;>;>; >; new configuration file parameters.
>;>;>; >;
>;>;>; >; Neil Nelson
>;>;>; >;
>;>;>; >;
>;>;>; >;
>;>;>; >;
