1 |
On Fri, Dec 5, 2008 at 10:05 AM, Evgeniy Bushkov <zhen@×××××××××.ru> wrote: |
2 |
> Adam Carter пишет: |
3 |
>>> |
4 |
>>> Also take a note that there are no "known-compromised hosts" |
5 |
>>> |
6 |
>> |
7 |
>> What about hosts listed in RBLs? |
8 |
>> http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. It would be |
9 |
>> interesting to see if how much correlation there is between ssh brute |
10 |
>> forcing bots and the contents of the various lists. |
11 |
>> |
12 |
> |
13 |
> It's just interesting. But I don't trust them enough. I don't know how these |
14 |
> lists were composed. We've periodically seen viruses outbreaks, some |
15 |
> computers IPs could get into lists because of trojans and so on. One day you |
16 |
> won't reach your server from your own home computer... |
17 |
|
18 |
The fact that a lot of 'compromised hosts' are home users with |
19 |
providers like comcast, verizon, etc lends another trouble as well... |
20 |
dynamic IPs mean that the next person with the luck of the draw in |
21 |
getting that IP can't reach your servers either, and if *you* happen |
22 |
to be that person, no reasonable whitelist will ever get you back in |
23 |
from that location until you get another IP. |
24 |
|
25 |
>> |
26 |
>> |
27 |
>>> |
28 |
>>> because ANY IP can be forged. |
29 |
>>> |
30 |
>> |
31 |
>> Its easy enough to forge a SYN, but to setup a session so you can make a |
32 |
>> password guessing attempt requires that you also get the packets back from |
33 |
>> the server, which is an order of magnitude more difficult. Ever since OSes |
34 |
>> have implemented well chosen initial sequence numbers, spoofing of TCP |
35 |
>> sessions has become very difficult. |
36 |
>> |
37 |
>> |
38 |
> |
39 |
> I agree but as admin I prefer to think about many things worse than they |
40 |
> really are. If something wrong is possible it's better to avoid it |
41 |
> beforehand. |
42 |
> |
43 |
> Best regards, |
44 |
> Evgeniy B. |
45 |
|
46 |
Careful with that line of thinking... you'll inevitably come to the |
47 |
conclusion that there's no hope and you're better off just turning the |
48 |
system off, unplugging it from the wall, and locking it into a very |
49 |
sturdy vault deep beneath a very solid mountain! (until you ponder |
50 |
yourself insane over the security risks that exist even then, let |
51 |
alone the impact on usability) |
52 |
|
53 |
-- |
54 |
Poison [BLX] |
55 |
Joshua M. Murphy |