| ..from_thE_cabLe |
..Poetry |
| |
dave_vANDal in_the_Project | ||||
|
|
-= news =- |
CyberTech_Co |
--= new_year..new_page..new_all =-- |
davy lidí valící se po rozsáhlých komunikacích .. příběh reprodukce odehrávající se v parku na lavičce, pod pokrývkou z telefonních kabelů ..postava za obrazovkou terminálu, tvář ozářená outputem binárního světa.. martenska drtící špačka lakyny, cvrkot kláves v rytmu techna; skučící digitální věže nadnárodních korporací, pod náporem bajtových bojovníků atakujících sídla smrtonosné vlády.. bouře hutných tónů vzplála ve chvíli pokoření brány světů gontapenu.. svět za okem webové kamery se stal tichým svědkem umění vypálit chrom dave_vandal, CyberTech_Co. [[email protected]]
..místnost plná štiplavýho kouře smrdutý marsky, poloprázdný lahváče na pokálený zemi. za stařičkým celerónem[nechť je prostoupen veškerou energií kybersvětů..amen] ,poblinkává obludka [vzdáleně připomínající posmrkaný kapesník] klávesnicový sunárek.. zkrvavené oči prosí o pomoc, ale zakrslík se dál pokouší o prolomení IDS vzdálený stejšns. marně. nad ránem odpadává tělíčko příšerky do vlastního hnojíčku, pohroužíc se do přenádhernýho snu o krásách kybersvětů, jež se skrývají za těmi, zasraně nedobytnými stejšns, používající nějaký zvláštní druh IDS..vzdáleně mi to připomíná balení smetáku kosmetičky_podlahových_krytin.. sen se rozpíná jak okvětní lístek orchydeje; krása chůze v martenskách, vůně kávy, zapálená lakyna. zůžené zorničky - ďábelská jízda optickými vlákny světa za branami gontapenu.. obludka se probouzí s pohledem plným naděje, směřující k outputu terminálu. i kliká na odkaz bájných světů, vrhající obludku do roviny tak známé a přitom tak tajemné.. místnost zalily hřejivé paprsky slunce, listy roslin vydávily vrstvy prachu a nikotinu, začaly produkovat binární kód. on se už nevrátí.zůstal uvnitř, kde se mohl stát pevnou a nedílnou součástí projektu. dave_vandal, CyberTech_Co. [[email protected]]
řev budíku. control chápe do pařátků ten ďábelskej vynález a vrhá jím do nejvzdálenějšího kouta místnosti. vinou gravitace padá budík s rachotem na zem a konečně utichá. fak..uleví si ten pípl a trhanými pohyby se zvedá z loužičky blitek, vytvořené za účelem spánku v jiné dimenzi. totiž spánku v zajetí démona alkoholu, krásy konopné vlny. nevšímaje si toho humplu, s úlevou si usedá za output terminálu, hákem bere klávesu po klávese, direkt pálí potvrzení..ping 193.84.160.101 . odpověď na sebe nenechává dlouho čekat a jeho božský xterm v sekundě plive život vzdálený stejšny. kontrol se trochu uvelebí, dírou v krku saje týdení kávičku..vychutnává si plíseň, jež je z nějakého historického důvodu konzistentí se zbytkem obsahu kejblu pochutiny. ach, jaká to mňamka.. drbajíc se v rozkroku, trasuje cestu paketu k adrese lahůdky; 6
194.50.100.190 156ms 109ms 266ms TTL: 0 (nix2-ge.cesnet.cz fraudulent
rDNS) se zapálenou lakynou, vychutnávajíc si zbytky penicilínu, pozorně studuje sjetinu traceroutéru.. .rachot padající rozvrzané židle[zažila nespočetné množství virtuálního sexu a ještě větší množství orgasmů na úrovni kosmu a snad i jeho nekonečna] odkazuje na skutečnost kvapného odchodu jejího majitele, směrem ku saund_sajstému.. neskutečných 166bípíem v rovině 2kw a taktu vznětového motoru, odhazuje svoje tělíčko zpátky do identického hnojíčku, aby pokračoval ve studii vzdálený stejšny. monotóně rozjíždí dotazy na databáze whois[http://www.ripe.net/]..kdo má tohle, sakra, pod palcem?? lámaným beatem, plní okno mozilly seznámek jmen, telefoních čísel, e.mailů.. inetnum:
193.84.160.0 - 193.84.175.255 route:
193.84.160.0/20 person:
Vladimir Hykys person:
Ivan Adamek
control, houpající se na vlnách drogový letargie, opět pálí 193.84.160.101 do komandlajny windozovský util. vzdálená stejšna mu s radostí do xichtu vrhá, krom external_linků, e.mailový odkazy týkající se týhle domain, subnetwork.., světa za routerem 193.84.175.206 ali bubu2.. Server:
193.84.160.101 ..s prstem v nose kouká control na tu vyblitinu a přemýšlí co dál. .. to be continue next time.. dave_vandal, CyberTech_Co. [[email protected]]
chtě nechtě s tím na povrch zemský prostě někdo přijít musel. říci, že telekomácký os posazenej na dslam pofidérní kvality - starající se o přihlášení do globální sítě internet - je v podstatě pěkně nestabilní hovínko, obsahující bambilion bezpečnostních much, jež dokáží přivést celou ček repablik do stavů posrání se z nemožnosti připojení k i Netu. Proč? v případě připojení pomocí ADSL, je samotné přihlášení provedeno přes takzvaný DASHBOARD, což je webovské rozhraní Service Selection Gateway, které pomáhá v menežování poskytovaných služeb providerovy. Vzhledem k faktu, že každý výpadek spojení znamená opětovné se přihlášení přes božský DASHBOARD, stává se toto velice nepohodlné a doslova otravné - vezmeme-li v úvahu skutečnost, že ono připojení není zcela stabilní.. Celou tu nesmyslnou přihlašovací proceduru může vyřešit utilita slovenské společnosti AUTODSL, utilita ADSLReconnect. krása, nádhera. Až na.. ačkoli je dosaženo úspěšného spojení, program neustále žádá providera o potvrzení uživatelského jména a hesla, aniž by docházelo k odpojení /přerušení samotného spojení! v podstatě dochází k zacyklení někde na aplikační úrovni, což má za následek nějakých 8ooo žádostí o potvrzení júzrnejmu a páswórd[ve 24 hodinách], několika násobné shození služeb připojení na straně telecomu.. [v podstatě: tento problém řešený všude a všemi a byl způsoben zrušení původní testofní IP. ta byla obměněna za jinou ajpí, ale čubky mě nějak neinformovaly.. pak se tedy nemůžou divit, že..] čtenář záhy pochopí, že zde máme opravdu primitivní DoS útok[konkrétně process table attack], kde je služba pověšena na systémové volání fork(). Samotný útok může podle časopisu PRIELOM#13 vypadat takto: dizajn niektorych sietovych protokolov prave vedie programatorov k robeniu tychto chyb. priklad takehoto protokolu je finger protokol (tcp port 79), ktory pracuje podla nasledujucej schemy: # 1.
klient urobi spojenie na server na spustenie process table attacku, klient potrebuje otvorit len spojenie na server a neposlat ziadnu informaciu. tak ako dlho klient drzi spojenie otvorenu, tak dlho proces okupuje serveru slot v serverovej systemovej tabulke. na vacsine pocitacoch, finger je nastartovany cez inetd. autori inetd umiestnili viacero kontrol v zdrojovom kode programu, ktore musia byt zrusene na to, aby mohla nastat uspesna inicializacia procesoveho utoku. ak inetd prijme viac ako 40 spojeni v patricnej sluzbe pod 1 minutu, sluzba sa vypne na 10 minut. ciel tychto kontrol nebol zabezpecit server proti process table attacku, ale zabezpecit ho proti chybovemu kodu, ktory moze vytvorit viacero spojeni v rapidne-rychlej sekvencii. na spustenie uspesneho process table attacku proti pocitacu na ktorom bezi inetd a finger musi byt vykonany nasledujuci postup: # 1.
otvorenie spojenia na cielovy finger port zostrojit utocny program sa neobide bez technickych problemov. vela systemov limituje mnozstvo tcp spojeni, ktore muozu byt inicializovane jednym procesom. proti tomu, je potrebne spustit utok z viacerych procesov, mozno pustenim z viacerych pocitacov. bolo otestovanych viacero sietovych sluzieb na viacerych operacnych systemoch. uw imapove a sendmailove servery su pravdepodobne tiez zranitelne. uw imap neobsahuje kontrolu pre rapidne rychle spojenia. preto je mozne shutdownut pocitac otvorenim viacerych spojeni na imap server v kratkom casovom rozpati. so sendmailom je situacia obratena. normalne, sendmail neprijme spojenia pokym systemove zatazenie nepresiahne isty predefinovany stupen. preto na inicializaciu uspesneho sendmailoveho utoku je potrebne otvorit spojenie velmi pomaly, tak ze tabulka procesov sa bude zvacsovat postupne pricom zatazenie systemu zostane viacmenej konstatne. vela problemov je v bsd masinach pouzivanych utocnikom. ked cielova masina zamrzne alebo padne, utocnikova masina niekedy padne tiez. zjavne tcp zasobnik nedokaze dobre obsluzit stovky spojeni na rovnaky port rovnakej masiny simultanne s prechodom do fin_wait_2 stavu. je viacero variantov tohot utoku: # 1.
pouzijeme ip spoofing, kedy prichadzajuce spojenie prichadza alebo sa
skuor zjavuje z nahodnych oblasti internetu. umoznuje to dostatocne tazsie
hladanie. existuje viacero spuosobov na zabranenie utoku: # 1.
inetd a ine programy by mali kontrolovat mnozstvo volnych slotov v procesovej
tabulke pred prijatim noveho spojenia. ak je mensie ako ista predefinovana
hodnota volnych slotov, nove spojenia nebudu akceptovane. -==- v našem případě dochází k samotnému obnovování v intervalu 1000 milisekund, což by neměl být problém stanovených limitů v množství otevřených procesů v případě uživatele, ale nikoli roota. právě přicházející spojení tcp/ip je povětšinou obslouženo službou běžící pod rootem, který je limitován až samotnými možnostmi systému. takže se naskýtá otázka: je možné, aby telecom zcela nezodpovědně provozoval na přípojných bodech služby pod rootem? abychom mohli tuto doměnku potvrdit nebo vyvrátit, provedeme menší audit :)) ----> připojujeme-li se přes VPN operátora nad telecomem, pak dochází k dvojnásobnému překladu MAC adres. problém? možná. v případě propojení stanic po ADSL ve stejnem rozsahu IP adresy, může docházet k odmítnutí paketu na vnější adrese[ta je přidělovaná telecomem] vzdálené stanice -> error of dslam on side telecom. hm. uskutečnit spojení[opět ve stejném rozsahu IP]local_stejšna - remote_stejšna lze buď za pomoci dial-upu nebo jinou formou pevného připojení. základní princip adsl: station <> spliter <------> spliter <> dslam [datová siť IP, ATM] <> iNet [side_of_zákazník] |-------| [side_of_provider_services] telefon <> spliter <------> spliter <> tel. ústředna <> tel. síť <> iNet ech..na straně zákazníka bývá obvyklé rozvrhnutí zařízení v této hrubé podobě.. adsl_spliter <> ústředna <> adsl_modem <> router <> switch zde dochází k filtrování paketu až za rozbočovačem a modemem, logicky na routeru, který je buď HW nebo aplikační[any proxy+fw]. lze se setkat s možností připojení na virtuální server, který se může nacházet kdekoli na intranetu[docela o držku]. nicméně, tento virtuální server je fyzická stejšna s IP přidělenou routerem[DHCP], nebo statickou IP od správce. což znamená..spousta malých společností, které se v minulosti připojovali přes ISDN, postupně přecházejí na technologii ADSL..počítače uvnitř těchto sítí jsou povětšinou ovládané windozy, splňující office potřeby běžného uživatele. se sdílenými disky na síti. mnohdy je na stejšnu za routerem[4 oktet IP adresy není vyšší 10] stahována pošta pomocí lan_suite, outlookem a jinými prasečinkami. nicméně, za předpokladu částečné konfigurace hw routeru, kdy jsou nastaveny adresy DNS1 a DNS2, uživatelské jméno a heslo[telefonní číslo dané společnosti], pak zůstávají ponechána tovární nastavení, která v mnohých případech nesou tyto znaky: vypnutý remote_control[port 8080], DMZ, hacker scan blocking, ping blocking[proti ataku ping_of_death...yeahhh], NAT blocking, zůstávají vypnuté virtuální servery. defaultní júzr a password: admin, admin. mohou být i variace jako administrator,etc. u většiny těchto routerů zůstávají defaultně nastaveny tyto účty!! vzhledem k faktu, že povětšinou provádí instalaci routeru zkušená osoba, pak se můžeme setkat s jeho nastavením, kde se může povolit buď DMZ nebo alespoň jeden virtuální server, který je buď hned za firewallem nebo někde na intranetu. což je samozřejmě možné, protože spousta lidí provozuje počítače pod win2k a win9x, kde je třeba ze začátku samotného zřízení připojení přes adsl provést nespočet testů aplikací, které pak chtějí mít pod redirektem routeru a mnohdy pro důvody nějakých nezdarů spojených se sprovozněním těchto aplikací pod win2k, je tento server povolován na stejšnu ,s win9x, hluboko uvnitř sítě - kde je zřejmé, že se ,po mnoha pokusech rozeběhnutí oné aplikace, rozhodne ona zkušenější osoba na volbě mezi fyzickou návštěvou a řízením přes telefon, právě pro druhou variantu. tím se maximalizuje riziko opomenutí některých zhoubných bezpečnostních faktorů, ať už z důvodu komunikace mezi integrátorem a zaměstnancem dané společnosti, který může VTčku trochu rozumět, nebo z důvodu dalšího testování či nedostatku času nebo pouhé lenosti[pozdějšího navrácení - zde je nutno upozornit na fakt, že tato stejšna během noci může spát a přes den normálně běžet, takže je v tuto dobu dostupná z internetu!..a může jet pod win9x..]. je docela možné[v závislosti na zkušenostech integrátora], že počítače na vnitřní síti mohu spadat do demilitarizované zóny opět z důvodů prováděných testů. navíc, u těchto společností se můžeme setkat i s rozvláčněností těchto testů, takže nastavení povolující vstup do vnitřní sítě může trvat celé měsíce, než dojde k nějaké změně - třeba k lepšímu:)) rovněž, vzhledem k poskytovaným produktům na trhu se sw, je pravděpodobně nejvíce v naší české zemičce oblíben aplikační firewall WinProxy, kde v tomto případě neuvažujeme o přítomnosti hardwarového routeru, ale stejšny s tímto softwérem. na těchto stejšnách je možné najít instalnutý nějaký firwall[kerio,zone_alarm,etc], ale to bychom uvažovali o lidech jako myslících bytostech - zatím jsem se v praxi setkal s opakem..I'm sorry. tudíž, při uvažované skutečnosti o pouze nainstalovaném winproxy_serveru, lze tento říznout některým z exploitů, kterých je na globálu opravdu spousty. nicméně, někteří poskytovatelé připojení k iNetu přidělují IP adresy svým hostitelům službou DHCP s rezervací neurčitou, takže i v případě vypnutého routeru zůstává v tu dobu aktuální adresa stále přidělena danému hostiteli. z čehož může plynout, že dnes proscanujete rozsah adres a přitom narazíte na některé zajímavé skutečnosti, ale o několik dní později může být situace přidělených adres poněkud jiná - vlasy mi z toho vztávají hrůzou na hlavě, ale tento předpoklad je v případě neustále živého hostitele zcela nemožný. vždyť kolika lidem a společnostem se tak otevírá možnost provozu www, ftp, smtp... serverů, za částku menší než je pronajímací poplatek různých společností?? nyní na řadu přichází otázka, jak lze v takovém množství providerů a adres nalézt pouze ty adresy, které jsou přidělené adslku? uvažujme; máme zde providery poskytující tuto službu [Skynet, Volny, Telecom, Contactel, Český bezdrát, IPEX, NETWAY.CZ, NEXTRA Czech Republic, Pemac Systems, TELE2, TISCALI Telekomunikace, Aliatel, Czech On Line, Dial Telecom, eTel , GTS CZECH, INTERNET CZ, SpiNet, WIA]. každá z nich má přidělen svůj rozsah adres - ty vyzjistím za pomoci služby whois, dotazem směřujícím na whois.ripe.net . při studování výsledků služby je třeba uvažovat logicky a zamyslet se na tím, proč netname u skynetu je skynet-II.. při zjišťování dotazů týkajících se autoratitivnívh odpovědí DNS je docela dobré používat jako dyfoltní DNS server ns.bohemia.net[v závislosti na používaném nástroji] - odkaz na tento nejmserver je dobrý i v případě použití nástroje dig. proč? za použití nejmserveru[u všech případů] vašeho providera je dost pravděpodobné vyfakování vaší žádosti.. v případě vlastního proscanování adres využijte možnosti reverse DNS, která vám převede ajpí adresu na její kanonické jméno[ty jsou přiřazovány DNS serverem..pro nechápavce]. tím lze alespoň u některých poskytovatelů určit daný rozsah adres, jež jsou přiřazeny právě xDSL uzlům. za určitých předpokladů, lze tuto síť využít pro DDoS útok..třeba. tímto jsem se snažil popsat bezpečnostní situaci na straně zákazíka, doufajíc v její budoucí zhoršení pro zlepšení přístupů do vnitř sítí.. a uzavírám tak jednu teorii[vycházející z praxe]týkající se adsl připojení. .."zajímalo by mne, co telecom provozuje na dslamech za systém, který tak snadno může způsobit výpadek celé oblasti.." ---> o rozhovoru s technikem jednoho poskytovatele služeb o výpadcích připojení a jak to vůbec vypadá na straně telecomu..to be continued. dave_vandal, CyberTech_Co. [[email protected]]
Chyby
ve směrovačích zastaví internet spolehlivěji než útoky hackerů Zákazníci některých českých i zahraničních poskytovatelů připojení k internetu si v posledních dnech stěžovali na výpadky. Mezi prvními postiženými byla v pátek ve Velké Británii část sítě British Telecomu, v sobotu došlo k výpadku u čekého operátora Tele2 a v neděli po půlnoci se uživatelé kabelového internetu Mistral nabízeného u nás společností UPC octli bez internetového připojení o víkendu celkem zhruba 20 hodin. Někteří uživatelé internetu se domnívali, že výpadky způsobili hackeři útoky na bezpečnostní slabinu směrovačů firmy Cisco, které páteřním sítím internetu dominují. Ve středu 16. července byla na webových stránkách Cisca a v konferenci Bugtraq publikována bezpečnostní chyba v operačním systému IOS, který běží ve směrovačích (routerech), některých přepínačích (switchích) a bezdrátových access pointech pro Wi-Fi, které Cisco vyrábí. Na internetu se pak objevily i zdrojové kódy funkčních exploitů, které dokázaly problém zneužít. Příčina výpadků však byla záludnější. Cisco radí blokovat provoz směřující na napadnutelné zařízení z neautorizovaného zdroje, dokument přináší i detailní informace o tom, které verze IOS jsou napadnutelné a na které verze je nutné upgradovat. V sítích British Telecomu a UPC byl IOS upgradován, došlo však ke komplikacím (popis potíží u BT naleznete zde, popis problémů u UPC najdete tady). Výpadek u TELE2 byl důsledkem výpadku u operátora, který pro TELE2 zajišťuje zahraniční konektivitu. Někteří operátoři dopadli lépe. Společnost Tiscali, jejíž datová síť je z převážné části vybudována na technologiích Cisco, přistoupila podle vyjádření tiskové mluvčí k opatřením, které zamezily možnosti zneužití bezpečnostní chyby IOS. Upgrade IOS na všech směrovačích byl prováděn postupně tak, aby byla minimalizována bezpečnostní rizika a zároveň vliv tohoto upgradu na zákazníky. Díky redundantní topologii sítě nedošlo k žádným výpadkům páteře, v ostatních částech sítě byl upgrade proveden s minimálním výpadkem, který nepřekročil jednotky minut nutné pro restart směrovače. Ani společnost Czech On Line nebyla podle sdělení tiskové mluvčí negativně zasažena následky upgrade Cisco IOS. Technici začali pracovat na upgradech IOSu jednotlivých páteřních routeru v síti během noci v pátek 18. července. Mezi další opatření patřilo filtrování problematických paketů. Pavel Rusý z Contactelu uvedl, že firma na svých hlavních páteřních zařízeních provozuje softwarové verze, které jsou proti popsanému způsobu napadení odolné, a obecně má Contactel ve své síti implementovány další mechanismy omezující možnost napadení útoky podobného typu. Dodal však, že "starší a menší zařízení v naší síti mohou být vůči tomuto způsobu útoku náchylná. Pokud by k útoku došlo, jeho dopad by byl omezený. V rámci plánované údržby budou i tato zařízení vybavena lepší úrovní ochrany." Problémy nezaznamenal podle Aleše Dryáka z oddělení rozvoje sítí ani Pragonet / T-Systems. David Duroň z GTS uvedl, že "implemetace nového Cisco IOS proběhla v síti GTS na úrovni IP páteře do 21.7. a na úrovni přístupových zákaznických zařízení (accss routerů) do 23.7. bez dopadů na dostupnost služeb. Na úrovni zákaznických CPE zařízení, zejména pro služby IP VPN a pod., bude upgrade podle plánu proveden do 24.7., ostatní zákaznická zařízení, která upgrade vyžadují, v souladu s kapacitními možnostmi personálu útvaru IP provozu v termínu do konce srpna." Podle Jiřího Proška z BroadNetu jsou jejich páteřní směrovače odolné proti útokům popsaným minulý týden, jejich IOS software není zmíněnou chybou dotčen. Síť Broadnet není postavena jako kaskádovitě řízená síť koncentračních routerů. Routery jsou navázány na transportní infrastrukturu na bázi ATM vedoucí až ke koncovému zakaznikovi. Zákazníci, kteří využívají pro připojení k internetu malé routery Cisco řad 80x, 17xx, 26xx, 36xx nebo switche Catalyst, byli operativně zabezpečeni prostřednictvím filtrů umístěných na páteřních směrovačích. V současné době technická skupina BroadNet paralelně realizuje kompletní upgrade IOS na zákaznických přístupových routerech Cisco. Broadnet navíc nabízí jako placenou službu využívání stavového paketového firewallu. Zajímala
nás i situace v síti Českého Telecomu (ČTc). Podle jeho oficiálního vyjádření
"obecně platí, že ČTc realizuje upgrade IOS svých routerů, a to tak,
aby byla používána taková verze SW, která je z hlediska ČTc optimální.
Pokud má změna SW dopady na zákazníky, upozorňujeme je na tuto skutečnost.
Pokud je výměna bez dopadu, pak je záležitostí ČTc, kdy změnu provede." Jim Kirby, síťový inženýr u amerického řetězce mlékáren Wells' Dairy, si ještě loni pochvaloval síťový hardware vyráběný firmou Cisco. Poté, co se rozhodl kromě routerů a switchů od Cisca používat i zařízení pro bezdrátové sítě Cisco Aironet, byly jeho pozitivní zkušenosti citovány v oborovém časopisu Dairy Foods i na webových stránkách společnosti Cisco. Mezitím však Cisco ohlásilo propuštění 8000 zaměstnanců a podle Kirbyho se rapidně snížila kvalita hardware, software i zákaznické podpory. Kirby
tvrdí, že od začátku tohoto roku musí reklamovat 50 % hardware
od Cisca, přičemž u některých modelů (Cisco Catalyst
4500, Cisco 7204 a Cisco AS5350) dosahuje poměr reklamací 100 %.
Kvalita zákaznické podpory je podle Kirbyho neuspokojivá, údajně není
zaručeno, že se problému ujme u Cisca kompetentní inženýr. U všech zhruba
25-30 letošních problémů byla nutná eskalace, výměna inženýra nebo kontaktování
místního zástupce Cisca. Zveřejnění slabiny operačního systému IOS bylo pro společnost Cisco i její zákazníky jistě nepříjemné, uvažovat o přechodu k jinému dodavateli telekomunikčního hardware však nemá velký smysl, zítra se může obdobný problém objevit v kterémkoli jiném konkurenčním produktu. Ukazuje se však, že problémy může působit určitá monokultura směrovačů Cisco na páteřních sítích internetu. Podobnou monokulturou jsou třeba kancelářské počítače s operačním systémem Windows a poštovním programem Outlook, v této monokultuře působí problémy již několik let e-mailové červy typu ILOVEYOU či Klez. Opět se projevil rozpor mezi nutností aplikovat záplaty software a nutností tyto záplaty předem vyzkoušet. Podobný rozpor u databázového software Microsoft SQL Server způsobil, že správci ohrožených databázových serverů tak dlouho nespěchali s opravou zveřejněnou v červenci 2002, až došlo 25. ledna 2003 k masivnímu útoku internetového červa Slammer (zvaného též Sapphire). Pro správce i manažery IT a IT může být užitečné sledovat alespoň běžné informační zdroje informací o aktuálních bezpečnostních problémech, jako jsou mailing listy Bugtraq, NTBugtraq a Secunia Security Advisories (na své si v některých případech přijdou milovníci horrorů). Některé společnosti by si přály, aby informace o bezpečnostních problémech software kolovaly pouze mezi úzkým okruhem specialistů, Bugtraq a NTBugtraq však vycházejí z zásad nazývaných Full Disclosure, po objevení chyby je tedy kontaktován dodavatel a je mu poskytnuta lhůta na opravu. Po uplynutí lhůty je pak chyba zveřejněna, ať již s opravou, nebo bez ní. Popis zásad Full Disclosure najdete zde. Investiční banka Merrill Lynch ohlásila, že stáhne všechny své pobočkové ústředny Cisco CallManager pro IP telefonii právě proto, aby se vyhnula zmiňované monokultuře. Nahradí je modelem S8700 firmy Avaya, která se před několika lety odštěpila od Lucentu. S8700 umí využívat internetovou telefonii i klasické přepínání okruhů na TDM. Mluvčí Merrill Lynch uvedl, že "zdvojnásobování útoků" na datovou síť Merrill Lynch mělo za následek nové zvážení firemní strategie. Internetové telefony Cisco jsou však naneštěstí svázány s ústřednami Cisca a nelze je používat s ústřednami jiných výrobců, proto budou i telefony od Cisca nahrazeny telefony dodanými firmou Avaya. Následky
problému v IOS pro firmu Cisco Systems je nyní možno odhadnout jen obtížně,
v naší zemi se však nejedná o první vážný problém související s produkty
Cisca v poslední době. Vývoj kolem upgrade IOS ve světě je možno sledovat
téměř v reálném čase zde. zdroj: idnes.cz
users, passwords, dokumentation.. in tHe future any nice SW, *.dwf and *.dwg, security bugs,etc.. from tHe IP: 193.86.227.4 comdave_vandal, CyberTech_Co. [[email protected]]
pribyla
stranka o XPerimentech se smart_drugs, eBookz obsahujici odkaz na Stealing
tHe netWork [fakt se mi za to nechtelo platit $34.97] a konecne
dlouho pripravovana zalezitost [ackoli disajnove nicmoc]: pejdz zabyvajici
se DDoS/DoS |
||||||
