1 |
From everything I've read on this topic, I've come up with the |
2 |
following suggestions (from the security in layers department): |
3 |
|
4 |
Set PermitRootLogin to no |
5 |
Disallow password logins |
6 |
Use DSA keys. |
7 |
Move the SSHD port to something other than 22 (security by obscurity). |
8 |
Yes, we all know that someone will find it, but that someone will be 1 |
9 |
in 1000 rather than all 1000 hitting the port. |
10 |
Use a combination of denyhosts, fail2ban, sshdfilter (iptables based) or |
11 |
nothing at all depending on how secure you feel these applications are |
12 |
(see Andrew Ross' post in this thread). |
13 |
I've seen one mention of jailing SSHD with grsecurity, but this doesn't |
14 |
seem to be the norm, at least as far as I can gather. |
15 |
|
16 |
Thanks, |
17 |
Brian |
18 |
|
19 |
Guillaume Castagnino wrote: |
20 |
> Hi, |
21 |
> |
22 |
> Le mercredi 25 octobre 2006 16:29, Longman, Bill a écrit : |
23 |
> |
24 |
>>> I've seen many recommendations for port knocking, but I feel that's |
25 |
>>> unnecessarily complex when compared to simply changing the port |
26 |
>>> sshd listens on. While the use of port knocking no doubt further |
27 |
>>> decreases your exposure over an alternate sshd port, the difference |
28 |
>>> is only a small percentage of the benefit you receive from moving |
29 |
>>> away from port 22 in the first place. |
30 |
>>> |
31 |
>> I've moved most of my public SSH ports off 22 because it reduces by |
32 |
>> thousandfolds the script kiddies playing with their toys and filling |
33 |
>> my logs and pipes. There is no more efficient means that will give |
34 |
>> you such returns with such little effort. |
35 |
>> |
36 |
>> I only wish I'd done it sooner. Yeah, you'll still get port scanned |
37 |
>> and someone will snoop around, but that's not in the face of the |
38 |
>> storm on port 22. |
39 |
>> |
40 |
> |
41 |
> This is REALLY not a solution against bruteforce attacks... You say the |
42 |
> reason : a port scan and the bruteforce can begin... |
43 |
> |
44 |
> Solutions could be : |
45 |
> |
46 |
> - using a daemon that analyse the logs and blacklist the guy (with |
47 |
> iptables or host.deny) after X login tries, such as fail2ban (in |
48 |
> portage), or |
49 |
> |
50 |
> - using ipt_recent like this (for example) : |
51 |
> |
52 |
> iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m |
53 |
> recent --set --name SSH |
54 |
> iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m |
55 |
> recent --update --seconds 120 --hitcount 5 --rttl --name SSH -j DROP |
56 |
> |
57 |
> my 2 cents, |
58 |
> Guillaume |
59 |
> |
60 |
> |
61 |
-- |
62 |
gentoo-hardened@g.o mailing list |