OT:SYN FLOODING

[Pavel Kankovsky]

Pozor, nadmerne dlouhy prispevek! (Neco jako LONG VEHICLE. :>) Aby to
nebylo tak strasne off-topic, pokusim se tam, kde je to relevantni, dat
vec trochu do souvislosti s Linuxem.


On Fri, 8 Dec 2000, Tomas Kudlac wrote:

> Mam tu pocit akoby ste mi vsetci chceli dokozat ze branit sa proti
> znamym utokom je blbost.

On kazdy tzv. odborny casopis pise veci jako "kupte si dobry AV software a
budete v bezpeci a jeste k tomu svezi i bez namaceni," tak tady musime
prezentovat i druhy extrem, aby se to trochu srovnalo. :)

Tady jde spis ale o neco jineho. Predstavte si, ze ve meste radi banda
delikventu, kteri se vyznacuji tim, ze nosi ksiltovky a vykradaji auta,
ktera otviraji za pomoci vhodne ohnuteho dratu. Antivirovy software je pak
policista, ktery zatkne kazdeho, kdo nosi ksiltovku, coz je z dlouhodobeho
hlediska ponekud ehm...zpozdile. IDS (ted mne napada, ze by to spis melo
byt ADS jako Attack Detection System, protoze *Intrusion*  D. S. by
spravne nemelo poznat utoky, ktere nebyly uspesne ;>) zatkne kazdeho, kdo
nosi podezrele ohnuty drat a mota se kolem ciziho auta, coz je znatelne
lepsi. Ale ja osobne bych to stejne resil nejradeji tak, ze si poridim
auto, co dratem proste otvirat nejde (jinak receno v prvni rade slabinu
odstranim a teprve pak resim pripadne zbytkove riziko).

> OK. A ja tvrdim ze branit sa proti neznamym principialne nejde.

Nejdriv bychom si museli definovat, co je to znamy a neznamy utok (jinak 
receno, jak moc se dva utoky musi lisit, aby to byl ruzny utok). Ale
dejme tomu, ze to vime. I tak nemate pravdu. Proc? Protoze mame-li rozum,
tak system stavime tak, aby 1. kriteria jeho bezpecnosti bylo mozno
formulovat a verifikovat na vysoke urovni (nikoli ve tvaru "nelze pretect
buffer zaslanim 555 znaku ve zprave XYZ", ale ve tvaru "server nikdy
neumozni klientovi provest operaci, ktera neni povolena ve specifikaci")
a 2. aby implementace byla maximalne odolna proti chybam pokud mozno
libovolneho charakteru (a la pasivni bezpecnost...tedy jste-li obyvatel
Hornorakouska, tak pochopitelne neverite, ze neco takoveho existuje, ale 
pro nas ostatni je to snad dobry priklad ;>).

Ostatne podobne jako jsem vyse popisoval tri stupne ochrany proti utokum,
tak si lze predstavit tri stupne pristupu pri tvorbe sw: Nejnizsi formou
je opravovani zverejnenych pripadne jinak zvnejsku nabonzovanych chyb
(bezpecnostnich slabin apod.). Vyssi formou je proaktivni hledani chyb,
jeste pred tim, nez je najde nekdo jiny. A nejvyssi je predchazeni chybam,
resp. omezovani rizika, ktere by z pripadnych chyb mohlo vzniknout (aniz
bychom predem vedeli, jestli tam nejaka chyba je). Vetsina sw je stale
nekde na tom prvnim stupni. OpenBSD si moc zaklada na tom druhem (obcas
bych rekl, ze az tolik, ze je to trochu brzdi v rozvoji treti urovne).
Linuxove systemy jsou rozplizle od jednicky, pres dvojku (ponekud
chaoticky ale snad trochu fungujici LSAP) az obcas do trojky (treba
StackGuard, at si o nem myslime, co chceme, je v podstate mechanismus na
urovni cislo tri).


On Fri, 8 Dec 2000, Ing. Pavel PaJaSoft Janousek wrote:

> 	Presne tuto politiku se snazim striktne dodrzovat, bohuzel existuje
> jeden protokol, ktery mi ji silne nabourava - konkretne Pasivni FTP
> prenos, jinak u beznych ISP hostingovych sluzeb si myslim, ze mam (to je
> velmi odvazne tvrzeni, ze?) pomerne vystarano.

Existuje vetsi mnozstvi reseni s ruznou urovni spolehlivosti, jenom to
chce trochu kreativni pristup. O co jde: chceme, aby FTP demon mohl
v pripade potreby poslouchat i na jinych portech a prijimat na nich
spojeni, ergo na tyto porty bychom chteli udelat diru ve firewallu, ale
bohuzel predem nevime, co to za porty bude.

Mozne pristupy k reseni (minimalne dve lze snadno na linuxovem systemu
pouzit):
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.
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.
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).
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).


On Fri, 8 Dec 2000, Tomas Kudlac wrote:

> pardon, moja ruka bola rychlejsia ako mysel, to moje tvrdenie sa
> tykalo predchadzajucej diskusie o trojanoch. Teda malo zniet ze (IMHO)
> neda sa postavit system ktory zarucene odhali neznameho trojana.

Ja nechci trojskeho kone odhalit, ale ja chci ochranit svuj system. To je
dost velky rozdil. V tom rozdilu se mj. skryva moznost vubec zvenku
nepustit dovnitr libovolny zly kod (v sirsim smyslu slova, diky snazeni
mnoha sw firem a tisicu jejich bezejmennych vyvojaru, kteri se za to --
doufam -- budou poradne smazit v pekle, je ted spustitelny kod temer
cokoli), nebo ho sice nechat spustit, ale neumoznit mu delat nic spatneho 
(tahle moznost je tak trochu hra s ohnem...viz ne moc oslnive uspechy ve
vyrobe opravdu bezpecneho JVM...ovsem staci se podivat na ActiveX a hned
to vypada s JVM optimisticteji :P).

> Suhlasim ze taky system sa da postavit, ale vo vela pripadoch by bol
> nepouzitelny. Ked sa ma s nim robit tak musite povolit ludom pouzivat
> nejakeho napriklad Outlooka. A tam sa celkom lahko moze objavit nejaky
> dalsi sposob ako trojana do tej siete dostat.

Oznamkujeme-li programy znamkami od 1 (maximalni snaha o bezpecnost) do 5
(aktivni sabotaz zabezpeceni), je MS Outlook (a OE) asi na hodnote 4,
pripocteme-li jeste inteligenci prumerneho uzivatele, jsme na maximalni
hodnote 5 (ve skutecnosti je ten soucet aspon 8, ale rekli jsme, ze
mame hodnoty od 1 do 5). Jak zni napis nad vchodem do pekla? Vzdejte se
vsi nadeje, vy kdoz vchazite...


On Fri, 8 Dec 2000 Michal.Vymazal na deltax.cz wrote:

> Tusim, ze v kategorii OS ma B1 Trusted Solaris. Nevim, zda existuje u
> trusted Oracle, ale asi ano.

Trusted Oracle existoval, ale AFAIK jen do verze 7, protoze ted pry jeho
funkce "zaintegrovavaji do standardni verze"...jestli jsem to dobre
pochopil.

Ale problem je, ze veci postavene podle oranzove knihy jsou udelany tak,
aby vyhovovaly pozadavkum (americkych) zelenych mozku z doby pred 10 lety,
coz dokonce casto ne zcela odpovida jejich soucasnym pozadavkum, natoz
pozadavkum jinych skupin (jako jsou treba PHB).

> Nechtejte ale znat cenu:-)

Ten kdo prezil cenu standardniho Oracle Serveru... :)


On Fri, 8 Dec 2000, Ing. Pavel PaJaSoft Janousek wrote:

> 	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".

> 	Znate vy vubec protokolovou hierarchii? Vlastni komunikace je v IP, nad
> ni je TCP nebo UDP - vse standardni - firewall se rozhoduje na zaklade
> IP hlavicky, data ho nezajimaji.

Jak jiz bylo diskutovano, tak zalezi na tom, co si predstavujete pod
pojmem firewall (coz je ostatne pojem tak marketingove a medialne
zprofanovany, ze take uz skoro nema zadny obsah :P), ale v kazdem pripade
plati, ze az na specialni a asi velice ridke vyjimky, existuje hranice
toho, cemu je dany firewall schopen rozumet a co je schopen vyhodnotit
jako anomalii. Jinak receno, prakticky vzdycky existuje kanal s nenulovou 
-- i kdyz nekdy mozna velice malou sirkou pasma --, kterym lze
komunikovat, aniz by mu to firewallu pripadalo jako neco, co ma zakazat,
nebo hlasit jako podezrele (ostatne i u systemu s pomerne vysokymi
pozadavky na zabezpeceni se vetsinou nepozaduje nutne eliminace vsech
skrytych kanalu, ale postacuje nalezeni horniho odhadu -- primerene maleho
-- jejich kapacity).

> > 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.


On Fri, 8 Dec 2000 Michal.Vymazal na deltax.cz wrote:

> Na flame wars skutecne neni tato konference urcena.

Jak to? Ja myslel, ze ano?! ;)

> Pokud nekdo vite, jak fungoval BrownOrifice...

Detaily z hlavy neznam, ale idea je proste ta, ze se vyuzije kombinace
dvou problemu: 1. aplet by normalne nemel mit moznost poslouchat na
nejakem portu a prijimat spojeni odkudkoli, 2. aplet by normalne nemel mit
moznost sam cmuchat po pocitaci, kde bezi, a jeho okoli, konkretne by
nemel mit moznost z pozice uzivatele nacist soubor odkazovany libovolnym
URLkem a pak se na nej divat, ovsem podminky 1 i 2 byly zaroven poruseny,
coz umoznilo vyrobit jakysi proxy HTTP server v Jave.

Jedna z tech chyb byla tusim implementacni (chybna kontrola pristupu),
druha pak spocivala v tom, ze Netscape si svevolne do JVM pridal svou
knihovnu, bez jakekoli kontroly, coz umoznilo se obejit bez standardni
knihovny, ktera by to (teoreticky) nepovolila.

Z cehoz plynou dve ponauceni: 1. i do jiste miry neskodne chyby se mohou
stat velkym problemem, kdyz se zkombinuji s necim jinym, 2. kdyz do
systemu neco pridate, tak si koledujete o bezpecnostni prusvih (typicka
formulace bezpecnostniho pozadavku je negativni, tj. ze neco nelze, ale
kdyz system rozsirujete, tak cinite veci, co byly driv nemozne, moznymi, a
tudiz jdete proti zminenym bezpecnostnim pozadavkum). Pro linuxovy
svet, ktere nema moc sklony k redukcionismu, jsou to IMHO veci, ktere
by mel mit na pameti.


On Fri, 8 Dec 2000 Michal.Vymazal na deltax.cz wrote:

> Jenomze Vas zklamu. Provadi nejakou analyzu paketu. Ovsem, co hleda, to
> presne nevim.

A nejmenuje se to "Snake Oil Firewall"? ;)

> No vida a otazka do pranice - jakpak udelat (verohodnou) verifikaci klienta
> oproti firewallu?

Verifikaci ceho? Ze je to spravny a schvaleny program? To jiste udelat
lze, ale je to verohodne jen do te miry, do jake je dany program (at uz
v pasivni forme na disku nebo v aktivni forme v pameti), chranen pred
nepritelem, ktery by ho mohl chtit ovladat, upravovat, nebo mu aspon
ukrast data, kterymi svou autenticnost (pripadne "autentificnost" pro
nektere ucastniky teto konference ;>) prokazuje.


On Fri, 8 Dec 2000, Jan Satko wrote:

> BTW: Niekde som cital ze je spraveny system, ktory rozoznava uzivatelov
> podla nejakej postupnosti prace s pocitacom. System si vsimne nejake casto
> sa opakujuce sekvencie a podla nich si Vas zapamata. Pripadny "hacker" by
> sa musel asi dost snazit aby zistil podla ktorej sekvencie si Vas system
> pamata. Teraz sa mi vyjavuje ze to tusim kontroloval podla toho akym
> sposobom pisete na klavesnicu. 

Tohle je celkem perspektivni smer, ale take je tam par zadrhelu:

1. Jsou kontrolovana ta mista, na kterych by nepritel pusobil, nebo nejaka
   jina? (Kontrola klavesnice asi tezko chyti nekoho, kdo se naboril pres
   sit.)

2. Dovede se hlidac ubranit pred tim, aby ho nepritel vyradil z provozu
   nebo na nem provedl radikalni kyberlobotomii? (Uprava programu za
   ucelem vyrazeni nejake funkce...tradicne ochrany proti kopirovani...
   neni nic noveho.)

3. Nelze umelou inteligenci hlidace snadno oblbnout? (Hlidac musi byt
   schopen se adaptovat na urcite zmeny chovani uzivatele, aby
   nezpusoboval prilis velke mnozstvi falesnych poplachu, protoze
   falesne poplachy pusobi extremne kontraproduktivne, ale co kdyz je
   ta zmena nikoli prirozena, ale zpusobena pusobenim nepritele?)

A pochopitelne si nelze myslet, ze to funguje na 100 %. Lidi maji bohuzel
sklon k tomu, ze nejake dilci reseni prohlasi za uplne (a pak se nestaci
divit).


On Fri, 8 Dec 2000, Petr Tomasek wrote:

> BTW, tak me napada: nemuze stavove filtrovani ovlivnit stabilitu firewallu
> (myslim na DoS utok provedeny otevrenim velkeho poctu konexi)?

Zcela nepochybne. Stavove filtrovani si musi ex definitiones pamatovat ke
kazdemu spojeni nejaky stav, a tudiz je z principu omezeno velikosti
pameti, ktera je vzdy konecna. Na druhou stranu (ted budu uvazovat utok
zvenci nikoli zevnitr) je to tak, ze rozumne implementovany a flexibilni
firewall by mel byt nastavitelny tak, ze veskery DoS utok na nej vedeny
nebude mit nikdy horsi nasledky, nez by mel v pripade, kdyby tam ten
firewall nebyl a utok byl veden primo na koncovy server.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."