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