1 |
hi! |
2 |
|
3 |
* KrispyKringle <krispykringle@g.o> [2004-07-28 11:32:17 -0400]: |
4 |
> You could block it with iptables, by restricting allowed domains in your |
5 |
> sshd_config, or by turning off password logins in sshd_config |
6 |
> (restricting to public key). You could presumably limit allowed login |
7 |
> addresses with tcpwrappers if none of the above methods of doing the |
8 |
> exact same thing appeal to you ;) |
9 |
|
10 |
> The thing is, some of these fixes may not be acceptible to all |
11 |
> installations (for instance, I run a server in which users can log in |
12 |
> from anywhere, which nixes restricting source addresses, and on which |
13 |
> many users are clueless about public key authentication, which nixes |
14 |
> that). However, in all honesty, I'm just not that concerned about this. |
15 |
> If it's not even trying real usernames, what's the risk? Root login is |
16 |
> disabled, and I have no guest, admin, etc accounts. Brute forcing over |
17 |
> ssh isn't even a huge risk anyway, since it takes nearly half a second |
18 |
> to try each password, and after three passwords the server disconnects |
19 |
> (and there is a limit on max unauthenticated connections). At that rate, |
20 |
> brute forcing a random 7 character password would take centuries. |
21 |
|
22 |
> I don't know how this is really even a risk. Brute forcing is a known |
23 |
> risk we all should have considered before. Seeing a (particularly |
24 |
> clumsy) attempt at it in the wild just comforts me that at least some of |
25 |
> the people out there trying to break into my server are complete and |
26 |
> total idiots. |
27 |
|
28 |
there was a lot of truth spoken in these sentences - and i laughed my |
29 |
ass off reading the last sentence. thx for this msg :-D |
30 |
|
31 |
so far |
32 |
|
33 |
-- |
34 |
Mark Pfluger |
35 |
.oooO0Oooo...oooO0Ooo |
36 |
|
37 |
-- |
38 |
gentoo-security@g.o mailing list |