"Предсказание номера 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
но судя по результату сканирования, оно не работает (?)