"Предсказание номера TCP-последовательности" - насколько это актуально ?

Всем привет.
Такой вопрос - насколько действительно актуальна непредсказуемость генерации номеров TCP последовательности? Вот результат сканирования моего хоста снаружи -


nmap -A -v -O -P0 xx.xx.xx.xx

Starting Nmap 4.20 ( http://insecure.org ) at 2007-08-06 00:15 MSD
Initiating Parallel DNS resolution of 1 host. at 00:15
Completed Parallel DNS resolution of 1 host. at 00:15, 3.92s elapsed
Initiating SYN Stealth Scan at 00:15
Scanning xx.xx.xx.xx [1697 ports]
SYN Stealth Scan Timing: About 8.57% done; ETC: 00:21 (0:05:20 remaining)
Discovered open port 55/tcp on xx.xx.xx.xx
Completed SYN Stealth Scan at 00:22, 396.79s elapsed (1697 total ports)
Initiating Service scan at 00:22
Scanning 1 service on xx.xx.xx.xx
Completed Service scan at 00:22, 1.18s elapsed (1 service on 1 host)
Warning: OS detection for xx.xx.xx.xx will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Initiating OS detection (try #1) against xx.xx.xx.xx
Retrying OS detection (try #2) against xx.xx.xx.xx
Initiating gen1 OS Detection against xx.xx.xx.xx at 424.211s
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
For OSScan assuming port 55 is open, 33082 is closed, and neither are firewalled
For OSScan assuming port 55 is open, 44509 is closed, and neither are firewalled
For OSScan assuming port 55 is open, 33785 is closed, and neither are firewalled
Host xx.xx.xx.xx appears to be up ... good.
Interesting ports on xx.xx.xx.xx:
Not shown: 1696 filtered ports
PORT STATE SERVICE VERSION
55/tcp open ssh OpenSSH 4.5 (protocol 2.0)
Device type: broadband router|WAP
Running (JUST GUESSING) : Linksys embedded (91%), Cnet embedded (89, D-Link embedded (86, US Robotics embedded)
Aggressive OS guesses: Linksys WAG54G Wireless Broadband Router (91, Cnet CNIG904B Internet Broadband Gateway firmware version 1.11 (89, Linksys BEFW11S4/WRT-54G Wireless Broadband router or BEFSR41 Cable/DSL router (88, Linksys BEFW11S4/BEFSR41/BEFSR81/WRK54G Broadband router or RT31P2 VoIP router (88, D-Link DI-804HV VPN Router or US-Robotics 8022 WAP or DI-714P+ Wireless router (86, Broadband router or WAP: D-Link DI-series, Sitecom BHS WAP, or SMC Barricade (86, D-Link, SMC, Tonze, or US Robotics Wireless Broadband router (86)
No exact OS matches for host (test conditions non-ideal).
TCP Sequence Prediction: Difficulty=0 (Trivial joke)
IPID Sequence Generation: All zeros
OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 509.901 seconds
Raw packets sent: 3525 (162.132KB) | Rcvd: 91 (4456B)

Это роутер & файловый сервер, на нем сейчас крутится squid, samba и open ssh под генту, и судя по результату сканирования, все удовлетворительно, кроме этого -
TCP Sequence Prediction: Difficulty=0 (Trivial joke)

в мануале по iptables (http://www.opennet.ru/docs/RUS/iptables/#SYNACKANDNEW)
в разделе "B.3. SYN/ACK - пакеты и пакеты со статусом NEW" про это написано так -

1.

Хост [A] отправляет SYN-пакет (запрос на соединение прим. перев.) хосту [V] с обратным IP-адресом хоста [O].
2.

Хост [V] отвечает хосту [O] пакетом SYN/ACK.
3.

Теперь, по логике вещей, хост [O] должен разорвать соединение пакетом RST, поскольку он не посылал запрос на соединение (пакет SYN) и попытка атаки провалится, однако, допустим, что хост [O] не ответил (оказался выключенным, перегружен работой или находится за брандмауэром, который не пропустил пакет SYN/ACK).
4.

Если хост [O] не отправил пакет RST, прервав таким образом начавшуюся атаку, то атакующий хост [A] получает возможность взаимодействия с хостом [V], выдавая себя за [O].

Собственно, вопрос. Если для успешного прохождения такой атаки достаточно чтобы хост [О] был "просто выключен" , то есть ли вообще смысл добиваться хорошего значения Difficulty TCP Sequence Prediction?

Если это действительно актуально, то буду домучивать мануал по iptables в сжатые сроки. А если не очень актуально или совсем неактуально, то и черт с ним. Сделаю когда сделается.

PS сейчас в iptables есть такое правило --A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
но судя по результату сканирования, оно не работает (?)

Дык это, имхо,

Дык это, имхо, работает оно только в локалке. Через нормально настроенный маршрутизатор пакет снаружи с обратным адресом изнутри должен рубиться на раз. Соответсвенно вероятность успеха локальной атаки как бы велика. А вероятность возникновения как бы не очень (ибо не кому). Кроме того для атаки изнутри более эффективен, на мой взгляд, тн arp spoofing :( потому как на неуправляемых свичах не лечится ничем, а на управляемых токо мониторингом и бейсбольной битой :).

Автор ты

Автор ты просканил линксисовский маршрутизатор, а не свой хост на дженту. У ядра линуха номера TCP генерятся без возможности предугадать.

Нет, просканен таки мой хост на дженту.

Сканировал товарисч, находящийся в той же провайдероской локалке, что и я. Сначала я у себя сбросил все правила iptables, посканировали. Получили результаты. Все так как и должно быть - все запущенные сервисы торчат наружу, все открыто, ось определяется правильно. Потом правила обратно, и снова посканировали. Результат в первом посте.

Ну тогда это

Ну тогда это просто nmap некорректно кажет результаты в связи с тем, что все заблокировано. Попробуй открыть хотя бы один из портов рабочего сервиса и просканировать опять.

ок попробую но

ок попробую
но эт не знаю когда получится, надо стыковаться с этим товарищем

1) Да, кстати,

1) Да, кстати, что вы сделали со своим ядром? На 2.6.20 диффиклт, хоть тресни, 2.4.20 опять жеж диффиклт. Ничего особо не крутил. По этому поводу ядро патчили еще в 2002 году ()http://www.uwsg.iu.edu/hypermail/linux/net/0211.3/0000.html)
2) В том же разделе по настройке iptables где расписан путь подобной атаки прописаны два правила. В редких случаях помогает. Только эти правила никоим образом не влияют на генерацию каких либо последовательностей. Они просто пакеты рубят и посылают запрос на сбрасывание незапрошенного соединения (который кстати может и не дойти).
3) Несмотря на все эти ухищрения кто угодно может запросто прикинуться отключенным хостом. Потому как ни сетевой ни транспортный уровень за идентификацию хоста не отвечают. Эти вопросы в юрисдикции протоколов уровня приложения/представления типа ssh.

Quote:1) Да,

Цитата:
1) Да, кстати, что вы сделали со своим ядром? На 2.6.20 диффиклт, хоть тресни, 2.4.20 опять жеж диффиклт. Ничего особо не крутил. По этому поводу ядро патчили еще в 2002 году ()http://www.uwsg.iu.edu/hypermail/linux/net/0211.3/0000.html)

Раньше, в 1996. Ссылчка не на то, там в 2002 чувак предлагал MD5 использовать для генерации TCPSeq, на что был послан ибо сказано было что текущего MD4 и так с головой хватает чтобы на предугадывание последовательности ушло как минимум пару дней и оно сооветствует RFC1948. А так:

/drivers/char/ChangeLog
Sun May 26 09:33:52 1996  Theodore Ts'o  <tytso@rsts-11.mit.edu>
                 (secure_tcp_sequence_number): New function which returns a
                 secure TCP sequence number.  This is needed to prevent some
                 nasty TCP hijacking attacks.

дык ничего

дык ничего особо извращенного я с ядром не делал. ядро как ядро. может и правда шутка в том, что процесс сканирования проходит криво.. потому и кривые результаты. не знаю. я вообще когда пробую снаружи с работы этот хост посканировать, сканирую вместо себя маршрутизатор провайдера. а один человек аж с Молдавии (!) меня по моей просьбе сканировал пару раз, и получал вменяемые результаты. т.е. сканировал именно мой хост.
черт его знает.
честно говоря думаю уже положить на все это известную часть тела.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".