On 27.3.2009 14:51, Lubos Dolezal:
Narazil jsem na mozna "zajimavy" problem u sitovani na 7.1-RELEASE (amd64).
Server ma dve sitova rozhrani pripojena v rozdilnych sitich (bge0, bge1):
---
defaultrouter="172.25.11.1"
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
inet 172.25.11.23 netmask 0xffffff00 broadcast 172.25.11.255
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
inet 172.25.9.12 netmask 0xffffff00 broadcast 172.25.9.255
Ted k tomu "problemu". Pokud je rozhrani "bge1" aktivni (a
nakonfigurovane na uvedenou adresu) nelze se z jineho serveru v siti
"172.25.9.0/24" dostat na sitove sluzby bezici na adrese 172.25.11.23
(rozhrani bge0). Napr. z 172.25.9.10:
---
$ telnet 172.25.11.23 22
Trying 172.25.11.23...
telnet: Unable to connect to remote host: Connection timed out
Jen aby nam tu nezustali neuzavrene problemy, kdyz je reseni znamo.
Nakonec stacilo poridit tcpdumpem zaznam komunikace z obou koncu.
Ukazalo se, ze pakety neprichazeji tak, jak byly odeslany. Uvodni SYN
packet dorazi na server z odlisnymi sekvencnimi cisly nez s jakymi byl
odeslan z klienta. No a to je cela potiz.
SYN+ACK odeslany v opacnem smeru mel hodnotu ACK odpovidajici tomu, co
na server dorazilo - a protoze "zpetky" paket sel primo, nikoliv pres
router, dorazil v tomto smeru paket nezmeneny. Klientovi hodnota ACK
nesedela k sekvencnimu cislu, se kterym on SYN odeslal a tudiz dospel k
zaveru, ze se nejedna o odpoved na jeho paket. Reagoval proto zaslanim
RST. Spojeni se pochopitelne nesestavilo.
Zbyvalo najit, kdo meni sekvencni cisla a to uz bylo trivialni - po
ceste je CISCO a na nem ASA/PIX. A to defaultne pocita s tim, ze sitove
stacky systemu nejsou bezpecne napsane a sekvencni cisla posouva o
nahodne zvoleny offset aby se nikomu ISN nepodarilo uhadnout. Pokud jde
komunikace zpatky pres nej, je to v pohode (hodnoty ACK posouva o stejny
offset zpet), pokud ne, jako v tomto pripade, smula.
Bohuzel, ani vypnuti randomizace pro komunikaci mezi temito vnitrnimi
sitemi problem nevyresilo, protoze firewall nevidi kompletni handshaking
(kdyz jeden smer pres nej nejde) a nema tudiz spojeni za ustavene a
odmita propustet data.
Podle me je snadne reseni i tady (proste mu jakekoliv filtrovani teto
komunikace zakazat uplne - u stroju, ktere maji nezavisle prime spojeni
to stejne nema bezpecnostni smysl), ale jestli se Lubos rozhodne pro
toto reseni, nebo zustane u workaroundu, ktery uz zvolil (pomoci pf
tlaci "zpetne" pakety take pres router), to je vic politicka nez
technicka otazka a to uz je ciste na nem.
Jinymi slovy, puvodne poskytnuta informace, ze firewall tuto komunikaci
neblokuje se ukazala nebyt uplne presna. Sice neblokoval, ale nevhodne
ovlivnoval - a kdyz se mu to zatrhlo, tak teprve tehdy zacal natvrdo
blokovat ;-)
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
