Choć piszę głównie o testach i bezpieczeństwie aplikacji internetowych, to zdarzają się również testy penetracyjne infrastruktury sieciowej, często zresztą połączone z testami aplikacji internetowej korzystającej z danej infrastruktury. Jednym z pierwszych kroków w takich testach jest skanowanie portów. Czas skanowania (a właściwie jego minimalizacja) jest dość istotna w przypadku testów (lub nawet tylko skanowania z wykorzystaniem narzędzi automatycznych) dużej ilości adresów.
Na schemacie, który umieściłem w pierwszym poście O implementowaniu haseł zaznaczone są dwa data store. Jednym z nich są logi. Po co znalazł się on na schemacie i jaki ma związek z (poprawną) implementacją haseł?
Dawno, dawno temu, jak jeszcze Firefox nazywał się Phoenix, praktycznie codziennie korzystałem z nowego nightly build , teraz nie mam już na to czasu. Dzisiaj pojawił się Firefox 3.5, zainstalowałem i... szczerze mówiąc w odbiorze “prawie zwykłego użytkownika” nie widzę żadnych różnic w stosunku do wersji 3.0, pomijając tradycyjny problem z niekompatybilnością niektórych z add-ons, między innymi słownik języka polskiego (przynajmniej w tej chwili).
Oryginał tego wpisu dostępny jest pod adresem Firefox 3.5
W komentarzach do wpisu Protecting Against the Snatched Laptop Data Theft (Schneier on Security) jest kilka pomysłów na automatyczne blokowanie laptopa w sytuacji, gdy z pewną pomocą osób trzecich oddali się od właściciela w stanie włączonym. Poza metodami opartymi na wykrywaniu bezczynności użytkownika, są też inne pomysły, na przykład automatyczne blokowanie laptopa, gdy telefon komórkowy użytkownika zniknie z zasięgu Bluetooth albo wykorzystanie wbudowanej w większość modeli kamerki do wykrycia sytuacji, gdy (prawowity) użytkownik znika z “pola widzenia”. Wszystko po to, by bronić się przed scenariuszem, w którym ktoś kradnie aktywnego laptopa i odzyskuje z niego dane pomimo wykorzystania mechanizmu szyfrowania całego dysku. Może to zrobić, ponieważ klucze kryptograficzne w trakcie działania systemu muszą być dostępne (co zwykle oznacza, że są w pamięci). Tu trzeba zauważyć, że proste zablokowanie konsoli nie będzie wystarczającym rozwiązaniem (system wciąż działa, klucze są dostępne), należałoby system wyłączyć lub przynajmniej posłać do “głębokiego snu”.
Jakiś czas temu udostępniłem wyzwanie (http://bootcamp.threats.pl/lesson08/), które do tej pory przeszły chyba dwie osoby, a przynajmniej tylko te dwie osoby się tym chwalą. Tym razem udostępniam zmodyfikowaną wersję tego samego wyzwania (http://bootcamp.threats.pl/lesson11/), która implementuje (ale nie dokładnie, bardziej na zasadzie PoC) koncepcję opóźnienia przy kolejnych nieudanych próbach uwierzytelnienia, (patrz: O implementowaniu haseł).
Pojawiła się wersja beta Microsoft Security Essentials dostępna, jak na razie, dla ograniczonej liczby użytkowników. Choć z zasady nie używam antywirusa (rezydentnego), planuję przyjrzeć się temu produktowi, ale raczej dopiero wówczas, gdy wyjdzie z fazy beta. Nie ukrywam, że wiążę pewne nadzieje z twierdzeniem It is a lightweight (...) , bo ociężałość “tradycyjnych” antywirusów mocno mnie do nich zniechęca. Swoją drogą ciekawe czy w dobie mody na green IT ktoś policzył koszty wynikające z używania antywirusa (dodatkowe obciążenie systemu, które przekłada się choćby na pobór prądu i wydzielanie ciepła), choć koszty dla środowiska wynikające z nieużywania antywirusów również mogą być wysokie – komputery będące częścią botnetów też raczej się nie nudzą...