OT:SYN FLOODING

Ing. Pavel PaJaSoft Janousek janousek na fonet.cz
Pondělí Prosinec 11 09:52:10 CET 2000


> Pozor, nadmerne dlouhy prispevek! (Neco jako LONG VEHICLE. :>) Aby to

	Velmi jsem zkratil, bez obav... '-)

> Existuje vetsi mnozstvi reseni s ruznou urovni spolehlivosti, jenom to
> chce trochu kreativni pristup. O co jde: chceme, aby FTP demon mohl

	Jiste, mohu si napsat 'bezpecneho' FTPD daemona sam, taky kreativni
pristup. (BTW wu_ftpd ma direktivu na ty pasivni porty sam, netreba
omezovat cely OS)

> 1. Nastavenim rozsahu anonymnich portu (local_port_range nebo jak se to
>    jmenuje) vymezime mj. i rozsah portu, na kterych muze ftpd poslouchat
>    (protoze socket poslouchajici na datovem spojeni je typicky autobound),
>    a pokud je male riziko, ze by tam mohl chtit poslouchat i nekdo jiny,
>    pak muzeme povolit navazovani spojeni na tyto porty. Tohle jste nejak
>    odmital, ale pri vsi ucte, asi jste to nejak nepochopil.

	Odmitam to z jednoho duvodu - obecne nemohu kernelu rici, tyto porty
nepridel nikdy nekomu jinemu (pokud si neupravim jadro). Jde o to, ze
defaultne se skutecne prideluje to co je ve
/proc/sys/net/ipv4/ip_local_port_range (pro 2.2. kernely). Ale... -
pokud klient pozada nikoli o auto prideleni, ale pozada natvrdo o port
XY, pokud neni root proces, muze jen z neprivilegovaneho rozsahu, tento
port neni jiz obsazen, dostane ho... (stejne jako vsichni zadaji
daemoni) - takze rekneme, ze porty 58000-59000 pridelm FTP, bohuzel
nemohu zarucit, ze 58543 nebude FTP, ale nejaky trojan... - to je duvod,
proc odmitam toto reseni - je polovicate a hasi dusledek, nikoli pricinu
problemu.

> 2. Vybereme nejakou volnou mnozinu portu disjunktni s mnozinou portu, na
>    kterych posloucha nebo by mohlo poslouchat neco jineho, upravime ftpd,
>    aby explicitne pouzival porty z teto mnoziny a povolime k nim pristup.

	Nemozne... - resp. FTP by muzes vsechny tyto porty obsadit hned pri
startu (a pokud se mu aspon jeden nepovede, ukoncit svou cinnost uplne),
coz muze vest k tomu, ze to same udela trojan...

> 3. Upravime ftpd tak, aby firewallu sam ohlasil, ze by chtel nejaky port
>    otevrit, nasledkem cehoz to firewall provede (s vhodnymi omezenimi,
>    aby naborenim ftpd nebylo mozno fw odstavit).

	Tim se dostavame k problemu, jak se autorizovat na firewall - tedy jak
by mel FTPd prokazovat svou identitu...

> 4. Pouzijeme takovy firewall, ktery sam pozna, ze ma otevrit pristup, kdyz
>    uvidi odpoved na prikaz PASV (tohle uz dlouho umi maskarada, ale je
>    to spojeno s jistymi riziky).

	Maskarada ano (pomoci modulu, std. ne!)), packet routing/filtering
ne...

> >       HTTP je definovano jak pro TCP, tak UDP - staci se podivat do
> > /etc/services
> 
> IANA (ted nevim, jestli se tehdy jmenoval ten organ jinak, nebo jestli se
> ted jmenuje jinak :P) se kdysi celkem pochopitelne rozhodla, ze by
> oddelene pridelovani cisel pro TCP a UDP zpusobovalo prilisny bordel, a
> tudiz se od te doby pro sluzby prideluje zaroven well-known TCP i UDP
> port, i kdyz typicky je pouzivan jen jeden. Napr. HTTP nemuze pres UDP
> fungovat, protoze HTTP je definovano pro "stream".

	A muzete mi rici, proc by napr. pro pozadavek HEAD nemohl byt jednoduse
vyuzit UDP protokol?

> > > O heuristicke analyze se tu bavime neustale. Ovsem, tezko ji bude delat
> > > firewall. Musi ji delat nejake nezavisle zarizeni.
> >
> >       Zarizeni neexistuje ani jako matematicky model typu Turinguv stroj
> > (Teze: (vsichni ji zatim veri, protoze nikdo nedokazal opak) Neexistuje
> > mocnejsi matematicky prostredek nez TS), jakpak byste ho chtel potom
> > implementovat?
> 
> Co to, s prominutim, blabolite? Matematickych prostredku mocnejsich nez TS
> existuji spousty: existuji problemy, ktere nelze pomoci TS vyresit,
> nicmene ktere reseni maji (viz zakladni ucebnice vycislitelnosti), ergo
> kazdy stroj tvoreny TS a orakulem resicim takovy problem je ostre silnejsi
> nez TS.
> 
> Zrejme jste poukazoval na Churchovu tezi rikajici, ze pojem algoritmu
> (chapany intuitivne) a pojem TS (majici presny matematicky vyznam) jsou
> jedno a totez.

	Tady budu oponovat tim, co mi jeste pred 2 lety (a co jsem mel tvrdit u
statnic) lili do hlavy (a prave jsem to konzultoval s kolegou Ing. teze
skoly - VUT FEI VTI Brno pro presnost) a opet musim konstatovat, ze je
teze, ze neexistuje mocnejsi matematicky prostredek nez TS. Existuji
ekvivalentni prostredky (minimalne 1) k TS. Tim ovsem nerikam, ze
neexistuji problemy, ktere nelze resit TS, napr. z toho duvodu, ze muze
dojit k zacykleni nebo i z jinych, ktere jste zminil. O mocnejsim
prostredku nez TS mi vsak neni nic znamo.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 00  Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------


Další informace o konferenci Linux