W

szystkie firmy wydające własną dystrybucję (tj. zestaw programów rozpowszechnianych łącznie i dający po zainstalowaniu gotowy do użycia system) walczą o to, aby ich produkt był bezpieczny. Można stwierdzić, że każdy system jest na tyle bezpieczny, na ile odpowiednie środki zastosuje jego użytkownik. Wiele osób nie korzysta z dostarczonych im wraz z systemem metod zabezpieczania swoich danych. Największym problemem jest wyuczenie tej dyscypliny u użytkowników systemu. Kiedy istnieje przypadek, gdy obdarzamy swoim powszechnym zaufaniem wybraną dystrybucję, a ona zawodzi – rozpoczyna się przysłowiowe “polowanie na czarownice”. Wówczas twórcy, instytucje, programiści, autorzy oraz inne osoby odpowiedzialne za stworzenie samej funkcjonalności systemu stają się obiektem krytyki, zarzutów i ataków ze strony sfrustrowanej grupy użytkowników. Wykrycie luk w mechanizmach zabezpieczeń wywołuje dokładnie te same reakcje. Czy uzasadnione?
[ czytaj całość… ]

I

kto powiedział, że technika ułatwia życie? Dziś rano mój podręczny b-ticino otworzył okna sypialni i zapalił światło już o piątej rano. Jeden błąd w gadżecie i tracę pełną godzinę snu! (…)
[ czytaj całość… ]

Artykuł ten został opublikowany w numerze 2/2003 (2) magazynu hakin9.

Dnia 16 lipca 2003 polska grupa Last Stage of Delirium (w składzie: Michał Chmielewski, Sergiusz Fornrobert, Adam Gowdiak i Tomasz Ostwald) ogłosiła odkrycie groźnej dziury w systemach z rodziny Windows NT. W numerze 2/2003 ukazał się wywiad z członkami grupy.
[ czytaj całość… ]

K

ażdy szanujący się serwer powinien zawsze posiadać, dokładny czas charakterystyczny dla jego strefy czasowej. Dlaczego? Ponieważ korekcja zdarzeń zachodzących w serwerach może być czynnością żmudną, jeżeli występują różnice w czasie wskazywanym przez ich zegary. Synchronizacja zegarów może zaoszczędzić nam wiele cennego czasu podczas analizowania dzienników zdarzeń (mamy pewność, że zdarzenia zdarzyły się dokładnie o tej godzinie i minucie) po wykryciu próby włamania lub nawet podczas rozwiązywania codziennych problemów sieciowych.
[ czytaj całość… ]

(root@osiris ~)# uname -srmp
Linux 2.4.26 i586 Pentium_MMX
(root@osiris ~)# gcc --version
2.95.4

[ czytaj całość… ]

B

łędy typu buffer overlow (b0f) należą do błędów implementacyjnych – ponieważ są one nieuchronne. Wynika to z faktu, że żadna aplikacja z reguły nie może zostać przetestowana w sposób wyczerpujący. Błędy b0f były wykorzystywane od 1988 roku, kiedy pojawił się pierwszy internetowy robak Morris Worm, atakujący na całym świecie serwery Uniksowe na platformie VAX i Sun, działające pod kontrolą systemu BSD. Robak wykorzystywał m.in. błąd w usłudze finger w celu nadpisania bufora, zawierającego nazwę pliku lokalnego klienta finger. Autorem owego robaka był wówczas 23 letni Robert Tappan Morris uczęszczający na studia doktoranckie na wydziale informatyki Uniwersytetu Cornell (posiadał stopień magistra Uniwersytetu Harward). Lubił on wykrywać błędy w systemach operacyjnych, dlatego na jesieni 1988 roku zaczął pracę nad programem mającym na celu ukazanie wykrytych błędów w zabezpieczeniach systemu 4 BSD Unix.
[ czytaj całość… ]

Z

awsze są dwie strony medalu. Skanery to bardzo przydatne narzędzia bezpieczeństwa, ale mogą zostać użyte w złym zamiarze – pozwalają na szybką ocenę słabości systemu. Dlatego przedmiotem tego artykułu jest program PortSentry autorstwa Craiga H. Rowlanda z dawnej firmy Psionic Software. Był on częścią pakietu oprogramowania Abacus do ochrony systemu przed włamaniami (aktualnie jest on rozwijany wyłącznie przez jego autora). PortSentry jest to zaawansowane narzędzie, do monitorowania, którego działanie nie mieści się w wąskiej definicji skanera portów, lecz wykrywania skanowania portów systemów i odpowiednie reagowanie.
[ czytaj całość… ]

S

canlogd jest kolejnym programem dzięki, któremu możemy posiadać rozeznanie czy ktoś poddaje nasz system skanowaniu. Autorem scanlog’a jest ekspert od zabezpieczeń o pseudonimie Solar Designer. Scanlogd wyróżnia się prostotą instalacji i obsługą. Choć posiada proste mechanizmy wykrywania skanowania przy pomocy protokołu TCP potrafi dostarczyć nam niezbędnych informacji o próbie przeprowadzenia wywiadu na naszym systemie. Poza tym jest to bardzo mały program nie zużywający większych ilości pamięci oraz procesora, działający na różnych systemach operacyjnych. Aby w pełni wykorzystać możliwości programu będą nam potrzebne biblioteki poza systemowe. Oczywiście program można skompilować bez żadnych dodatkowych bibliotek, ale zaleca się, aby w systemie były one zainstalowane. Mowa jest tu o typowo sieciowych bibliotekach takich jak: libpcap, libnids i libnet. Lokalne kopie tych bibliotek możemy znaleźć na domowej stronie scanlog’a.
[ czytaj całość… ]

I

plog jest programem logującym ruch w sieci. Obsługuje on takie protokoły jak TCP, UDP i ICMP. Dzięki tej zdolności jego kompatybilność pozwala na wykrywanie skanowania określonych przez nas portów takimi metodami jak: TCP port scan, TCP Null scan, FIN scan, TCP SYN scan, TCP “Xmas” scan, UDP scan (opis poszczególnych metod skanowania możemy znaleźć sekcji “Ataki internetowe”). Dodatkowo potrafi on wykryć przeprowadzenie takich ataków jak: “Smurf” (przy użyciu pakietów UDP oraz ICMP), ICMP ping flood oraz bogus TCP flag (używanego przez skanery w celu wykrywania rodzaju systemu operacyjnego jaki jest używany na danej maszynie).
[ czytaj całość… ]

O

becnie system możemy zabezpieczyć na dwa sposoby: 1). Ręcznie – poprzez poprawę wszystkich “niedociągnięć” (jednak wymagana jest tu dogłębna wiedza na temat platformy systemowej), lub 2). Automatycznie – przy użyciu zestawu odpowiednich skryptów (tutaj wymagana jest tylko powierzchowna znajomość własnego systemu). Projekt “uszczelniania” systemu RedHat Linux został zapoczątkowany przez Jona Lassera oraz Bena Woodarda. Bastille Linux został napisany w języku Perl, w założeniu ma poprawić bezpieczeństwo systemu “Czerwonego Kapelusza”.
[ czytaj całość… ]