K-NET s.c.

WordPress – włamanie w celu rozsyłania spamu (Apache+PHP+Postfix)

WordPress jako bardzo popularne narzędzie jest często obiektem ataków w celu przejęcia zawartości strony. Podmiana treści serwisu przez hackera jest widocznym skutkiem złamania zabezpieczeń. Sama w sobie nie jest jednak tak groźna jak np. wykorzystanie naszego serwera do rozsyłania spamu (co może spowodować umieszczenie go na czarnych listach). Najczęściej atakujący starają się umieścić w strukturze katalogów serwisu przygotowane skrypty PHP (w formie plików), które następnie wykorzystują do wysyłania maili. Co zrobić, żeby zabezpieczyć się przed tą formą ataku?

Przede wszystkim konieczne jest wykonanie 2 czynności: (a) ograniczenie zainstalowanych motywów do niezbędnego minimum oraz (b) usunięcie wszystkich zbędnych wtyczek (bywają takie, które z powodu słabej jakości kodu umożliwiają natychmiastowy dostęp do serwera). Kolejną rzeczą jest uniemożliwienie przesłania spreparowanego zapytania do naszego serwera. Absolutnym minimum jest przygotowanie pliku .htaccess z odpowiednimi regułami. Jeśli chcemu pójść na skróty można skorzystać ze zbioru gotowych reguł: http://perishablepress.com/5g-blacklist-2013/. W zasadzie dzięki tym dwóm prostym krokom uzyskamy przynajmniej minimalny poziom zabezpieczeń strony w WordPressie. Dodam jeszce, że na końcu .httaccess można  dopisać linijkę

RewriteRule ^(php\.ini|\.htaccess) - [NC,F]

która zabezpieczy nas przed modyfikacją zawartości plików index.php i właśnie .htaccess co z kolei uniemożliwi np. przekierowanie wywołań naszej strony na inny serwer www.

Jednak w jaki sposób powstrzymać doraźnie atak na nasz serwer (jeśli już doszło do niego). Przy założeniu, że korzystamy z domyślnej konfiguracji Apache trzeba zatrzymać wysyłanie poczty z konta www-data. Edytujemy plik /etc/postfix/main.cf i dodajemy na końcu wiersz

authorized_submit_users = !www-data, static:all

Natstępnie wczytujemy nową konfiguracje serwera poczty:

/etc/init.d/postfix reload

Teraz musimy wyczyścić kolejkę maili oczekujących na nadanie:

postsuper -d ALL

Przechodzimy do najbardziej monotonnej częsci całego procesu. Edytujemy plik /etc/php5/apache2/php.ini, żeby znaleźć (i odkomentować lub zmienić na postać przedstawioną poniżej) fragment:

mail.add_x_header = On
mail.log = /var/log/phpmail.log

Pierwsza spowoduje dodanie nagłówka do wszystkich maili nadawanych z wykorzystaniem PHP a druga włączy logowanie informacji na ten temat (do pliku /var/log/phpmail.log). Teraz pozostaje nam żmudne przeglądanie pliku z logami w celu śledzenia historii ataku oraz usuwania niepożądanych plików (zawierających np. skrypty PHP), które są wykorzystywane do rozsyłania spamu.

MG

rsync czyli kopie szybko i bezproblemowo

rsync to narzędzie dobrze znane i szeroko stosowane. Ten niezwykle wygodny w użyciu program pozwala na synchronizowanie zawartości między zasobami w niezawodny sposób. Dzięki kopiowaniu bloków informacji w miejsce całych jednostek np. plików, algorytm kopiowania jest bardzo szybki. Dodatkowo rsync sprawdza się na zawodnych łaczach, gdzie dostępne pasmo potrafi spaść nagle do kilku kb/s. Nie ukrywam, że jest to moja ulubiona metoda tworzenia kopii dlatego chciałem pokazać jak szybko przygotować rsync dla dwóch serwerów w środowisku Debian Linux. Jeden niech będzie serwerem produkcyjnym, drugi zaś serwerem kopii.

Zaczynamy od instalacji aplikacji na obu komputerach:

apt-get install rsync

Następnie tworzymy specjalne konto na serwerze kopii:

adduser zapasowe

Kolejnym krokiem jest wygenerowanie certyfikatu na serwerze produkcyjnym i skopiowanie go na serwer kopii:

ssh-keygen -t dsa

ssh-copy-id -i .ssh/id_dsa.pub zapasowe@serwer_kopii

Możecie wierzyc lub nie ale to już prawie wszystko! Teraz wystarczy wywołanie polecenia na serwerze produkcyjnym:

rsync -aogrvzP --delete -e ssh /wazne zapasowe@serwer_kopii:kopie

Spowoduje ono utworzenie dokładnej kopii zawartości katalogu wazne na serwerze kopii w katalogu kopie. Prosto i skutecznie. Aha, powyższe polecenie możemy umieścić w pliku crontab, automatyzując tym samym cały proces.

MG

Ultra Fast Boot zbyt szybki?

Już od dłuższego czasu większość sprzedawanych płyt głównych wyposażona jest w opcje Ultra Fast Boot. W połączeniu z UEFI i Windows 8 daje ona możliwość bardzo szybkiego startu komputera, nawet na poziomie kilku sekund. Wyzwaniem jest jednak dostanie się do ustawień BIOS po jej włączeniu. W praktyce bootowanie odbywa się tak szybko, że nie można liczyć na ekran POST i wciśnięcie klawisza F2 lub DEL. Użytkownicy Windows otrzymują wraz ze sterownikami płyty głównej aplikację narzędziową. Pozwala ona uruchomić komputer z wejściem do BIOS przy następnym przeładowaniu systemu. Co jednak mają zrobić właściciele Linkusów? Najczęściej można usłyszeć poradę brzmiącą mniej więcej – zdjąć obudowę i wyjąć na kilka sekund baterie podtrzymująca CMOS. Ewentulanie należu skorzystać z odpowiedniej zworki na płycie. Tak czy inaczej jest to operacja ryzykowna. Zakładając na przykład, że mieliśmy skonfigurowany software-RAID w BIOS, możemy sprawić sobie problem. Jednak jak zwykle istnieje dużo prostsze rozwiązanie. Być może nie jest ono oczywiste ale zazwyczaj sprawdza się. Skoro otworzyliśmy już obudowe naszego komputera to wystarczy odpiąć dyski twarde. Po uruchomieniu, BIOS wykryje zmiane konfiguracji i umożliwi bezpośrednio konfiguracje swoich parametrów. Korzystając z okazji wyłączamy opcję Ultra Fast Boot i zapisujemy ustawienia. Po wyłączeniu komputera i ponownym podłączeniu dysków możemy uruchomić system. Tym razem ekran POST powinien być już widoczny a my powinniśmy mieć zawsze szanse dostać się do naszych ustawień w BIOS.

MG

Android – instalacja uprawnień root za pomocą towelroot

Instalacja uprawnień root, popularnie zwana rootowaniem jest zagadnieniem, nad którym zastanawiał się chyba każdy użytkownik telefonu z Androidem. Z jednej strony obawa przed utratą gwarancji, z drugiej zaś dodatkowe funkcje w słuchawce. Przyznam, że również długo wahałem się ale w końcu uległem. I absolutnie nie żałuję. Po wykonaniu rootowania nasz telefon zyskuje zupełnie nowe możliwości. Nie chcę jednak rozpisywać się nad zaletami. Każdy może spróbować sam. No właśnie, czy możliwe jest spróbowanie bez skomplikowanych dla przeciętnego użytkownika czynności takich jak uruchomienie bootloadera, zainstalowanie odpowiedniego modu (np. popularnego ClockWorkMod) itd.

Jakiś czas temu trafiłem na stronę https://towelroot.com/. Autor (geohot) oferuje własną aplikację towelroot, która na ponad 500 modelach słuchawek z Androidem potrafi eskalować uprawnienia roota. Wszystko polega na pobraniu pliku APK ze strony i uruchomieniu go na telefonie. Oprogramowanie wykorzystuje błąd jądra Linux (tak to prawda – Android to Linux, wbrew temu co sądzą niektórzy) znany jako Futex bug (CVE-2014-3153). Dzięki niemu możemy z miejsca przetestować uprawnienia root. Metoda ta może wydawać się podejrzana, jednak błąd jest udokumentowany a czasami nie ma innej możliwości zrootowania urządzenia (tak jest np. w przypadku mojego ulubionego tabletu Lenovo A10).

Na zakończenie należy dodać, że na stonie towelroot dostępna jest ostatnia wersja oprogramowania. Nie współpracuje ona jednak ze wszystkimi telefonami. Gdyby tak się stało warto spróbować z poprzednimi wersjami:

• towelroot v.1
• towelroot v.2
• towelroot v.3

MG

Konfigurowanie użytkowników systemowych na serwerze Samba w środowisku Active Directory

Praktyka związana z budowaniem sieci komputerowych w małych i średnich firmach pokazuje, że często jesteśmy zmuszeni tworzyć środowiska heterogeniczne, gdzie np. domena Active Directory AD współpracuje z linuksowym sewerem plików Samba SMB. Aby ten dość często spotykany tandem był w pełni funkcjonalny dobrze jest zintegrować bazę użytkowników AD z kontami dla serwera SMB. Nie chcę tutaj poruszać problemów związanych z samą konfiguracją po stronie Linuksa – jest to wielokrotnie omawione w sieci (jeden z najlepszych poradników howto można znaleźć pod tym adresem). Tym razem chciałbym pokazać jak rozdzielić na serwerze Debian użytkowników AD od systemowych.

W przypadku integrowania serwera plików z domeną mamy dwie możliwości:

• albo wszystkie konta będą przechowywane w katalogu Active Directory
• albo na serwerze linuksowym pozostawimy część natywnych kont systemowych

Osobiście zawsze wybieram tą drugą opcję, chociażby dlatego aby uniezależnić niektóre usługi systemowe od domeny. Takie podejście bywa często krytykowane, szczególnie przez zwolenników centralnego zarządzania. Niemniej jest spotykane i stosowane. Problem z opisywaną konfiguracją polega na tym, że łącząc nasz serwer z domeną musimy włączyć protokół uwierzytelniania Kerberos. Przy standardowej konfiguracji oznacza to, że wszyscy użytkownicy o identyfikatorze UID większym równym 1000, będą autoryzowani na poziomie domeny (oznacza to, że np. nie zadziałają prawidłowo polecenia passwd i useradd).

Jak zwykle w takich przypadkach istnieje wiele rozwiązań, o czym można przekonać się poszukując materiałów w sieci. Niemniej najprostszym i prawdopodobnie najszybszym będzie wyedytowanie pliku/etc/pam.d/common-password. Następnie należy zmienić wartość paramteru minimum_uid (która domyślnie wynosi 1000):

password requisite pam_krb5.so minimum_uid=2000

Powyższy wpis oznacza, że odtąd użytkownicy LDAP (którzy w tym przypadku są użytkownikami AD) mają identyfikatory UID zaczynające się od 2000, zaś lokalny administrator linuksowy może spokojnie operować na kontach systemowych.

MG

Administracja usługami za pomocą rcconf i sysv-rc-conf

Jeśli chcemy precyzyjnie zarządzać demonami systemowymi uruchamianymi w trakcie startu sytemu to pakiety rcconf i sysv-rc-conf mogą okazać niezastąpionym narzędziem. Wyobraźmy sobie, że administrujemy sewerem Debian bez powłoki graficznej. Aby dodać lub usunąć usługę systemową do listy procesów startowych możemy skorzystać z dobrze znanego skryptu update-rc.d. Niestety, zdarza się, że podczas jego użycia napotkamy błędy związane ze skryptami startowymi. Co można zrobić w takiej sytuacji? Jeżeli zależy nam na czasie, proponuje zainstalować z repozytorium odpowiednie narzędzia:

apt-get install rcconf
apt-get install sysv-rc-conf

Następnie wystarczy wydać odpowiednią komende z linii poleceń i rozpocząć konfiguracje systemu. rcconf jest nakładką (front-end) dla skryptów update-rc.d, zaś sysv-rc-conf to rozbudowane narzędzie, które umożliwia np. szczegółowe dodawanie i suwanie usług w zależności od poziomu startowego (runlevel). Tak czy inaczej obydwa są bardzo przejrzyste i intuicyjne. Myśle, że poradzi sobie z nimi każdy, nawet początkujący administrator.

MG

Dovecot, Postfix, IMAP – Operation not permitted

Dzisiaj krótki, wakacyjny wpis dotyczący błędu związanegoz konfiguracją obsługi IMAP za pomocą Dovecot. W tandemie ze standardowo skonfigurowanym Postfixem, gdy zdecydowaliśmy się przechowywać pocztę w formacie mbox w katalogu /var/mail/ przy próbie pobrania poczty za pomocą dowolnego programu pocztowego (np. Thunderbird) w pliku /var/log/mail.log mogą pojawić się następujace błędy:

dovecot: imap(...):
Error: chown(...) failed: Operation not permitted
Error: mkdir(...) failed: Operation not permitted
Error: fchown(...) failed: Operation not permitted
Error: file_dotlock_create(...) failed: Permission denied

Jest to związane z niewystarczającymi uprawnieniami w katalogu użytkownika. Zgodnie z dokumentacją powinniśmy zajrzeć na stronę z opisem roziwązania http://wiki2.dovecot.org/Errors/ChgrpNoPerm. Ponieważ dla mnie obydwa omawiane tam rozwiązania wyglądają niedobrze, proponuję zastosować w pliku /etc/dovecot/conf.d/10-mail.conf zastosować następującą łatkę, w miejsce linijki:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

podstawić:

mail_location = mbox:~/mail/mailboxes:INBOX=/var/mail/%u:→
DIRNAME=mBoX-MeSsAgEs:INDEX=~/mail/index:CONTROL=~/mail/control

Sprawdziłem… pomaga. Tak jak obiecałem – krótko i na temat136.

MG

Konfiguracja blacklist za pomocą Shorewalla – ciąg dalszy

Dawno, dawno temu opublikowałem wpis na temat blokowania ruchu przychodzącego za pomocą czarnej listy w Shorewallu. Artykuł kończy się adresem pliku blacklist z listą podsieci, z których pochodzi najwięcej ataków. Minęło dużo czasu i adres tej aktualizowanej co tydzień listy stał się nieaktualny. Obecnie plik można pobrać z pod adresu:

https://dl.dropboxusercontent.com/u/545869/Config/blacklist

Jak pisałem jest to gotowy do wykorzystania spis. W zasadzie wystarczy umieścić go /etc/shorewall. Jednak tym razem chciałem pokazać jak tworzyć samemu podobne listy. Generalnie wystarczy w tym celu uważna analiza logów systemowych w poszukiwaniu prób włamania. Przykładowy wpis wygląda tak:

Jun 21 06:22:13 server sshd[9820]: pam_unix(sshd:auth): →
authentication failure; logname= uid=0 euid=0 tty=ssh →
ruser= rhost=32.96.49.39  user=root

Jun 21 06:22:15 server sshd[9820]: Failed password for →
root from 32.96.49.39 port 1061 ssh2

Jak łatwo zauważyć adres IP zdalnego hosta (rhost) jest jawny. Można zatem wykorzystać tę informacje do jego zablokowania. Można też posunąć się dalej i zablokować całą podsieć. Jak zamienić pojedynczy adres na adres podsieci? Po pierwsze trzeba zainstalować narzędzie whois. Instalacja w Debianie wygląda następująco:

apt-get install whois

Po drugie warto znaleźć dobry, ogólnodostępny serwer whois. Mogę z czystym sumieniem polecić serwer whois.cymru.com. Zwraca precyzyjne odpowiedzi, więc nie spowoduje, że przypadkiem zablokujemy dostęp dla połowy sieci. Polecenie whois jest dosyć proste w obsłudze:

whois -h whois.cymru.com -v 32.96.49.39

W odpowiedzi, w kolumnie BGP Prefix znajdziemy adres podsieci w notacji CIDR. Tak uzbrojeni możemy rozpocząc prace nad własną czarną listą.

MG

Plik wsadowy ze skryptem PowerShell dla serwera MS Exchange

PowerShell to rozbudowane, konsolowe narzędzie do administracji systemem operacyjnym Windows Server. Długie polecenia, ilość opcji a także niezrozumiałe, na pierwszy rzut oka, przełączniki powodują, że rozwiązanie to może zniechęcić. Tym bardziej, jeśli ktoś jest amatorem tzw. 'wyklikiwania’ poleceń. Niemniej jest to najlepsza, o ile nie jedyna, droga do pisania skryptów systemowych, które można dodać do schedulera systemowego i tym samym załatwić sobie dużo wolnego czasu.

Standardowo PowerShell wykorzystywany jest do czynności ogólno-systemowych. Jednak instalując nowe usługi na swoim serwerze np. Microsoft Exchange Server, otrzymujemy dostęp do zmodyfikowanego pod kątem Exchange środowiska PowerShell, która umożliwia zarządzanie. Czy można zatem przygotować skrypt, który będzie wykonywany w tle i będzie korzystał z komend właściwych dla wspomnianego środowiska? Można i należy to robić, szczególnie w przypadku takich zadań jak chociażby raportowanie zdarzeń itp.

Zamieszczony poniżej przykład pokazuje jak powinien wyglądać plik wsadowy (może być to popularny batch), który wywoła środowisko PowerShell dla MS Exchange a następnie przygotuje raport w pliku, zawierający listę przekierowanych kont pocztowych. W praktyce, część polecenia, oznaczona kolorem szarym jest uniwersalna, w oznaczonej na zielono skorzystałem z komendy (cmdletu) Get-Mailbox-Server. Może zostać ona zamieniona na każdy inny cmdlet wg pomysłu użytkownika.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0→
-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\→
Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1';→ 
Connect-ExchangeServer -auto; Get-Mailbox -Server→ 
{nazwa serwera MS Exchange} -Filter 'ForwardingAddress -ne $null' |→ 
out-file -filepath {nazwa pliku ze ścieżką}"

MG

Heartbleed, Shorewall i czarne listy

Dzisiaj, krótki świąteczny wpis dla adminstratorów codzienie zmagających się ze skryptami skanującymi porty naszych serwerów. Rozgłos jaki zyskał Heartbleed, w rzeczy samej jedna z najpoważniejszych luk w bibliotece OpenSSL, zaowocował zwiększoną aktywnością tzw. script-kiddies, którzy natychmiast ruszyli do 'ataku’. W logach systemowych zaczęły pojawiać się w dużej ilości ostrzeżenia dotyczące błedów sesji TLS. Niezależnie o typu usługi tj. SMTPS, POP3S, HTTPS, każda może zostać zaatakowana. Jak zauważyłem większość tego typu starań ma swoje źródła w państwach powszechnie znanych z sieciowych parktyk siłowych, mam na myśli metodę brute-force. Znudzony nieustannym zalewaniem informacją o nieudanych połączeniach postanowiłem pójść na całość i dosłownie wyciąć ruch pochodzący z najbardziej aktywnych sieci IP. W jaki sposób? Z pomocą przychodzi jak zwykle niezawodny Shorewall, który znacznie upraszcza zarządzanie iptables. W tym przypadku w pliku blacklist podajemy adres sieci w notacji CIDR bez żadnych opcji, np. po prostu:

10.10.10.0/24

W ten sposób blokujemy cały ruch. Trzeba jednak pamiętać, żeby przypadkiem nie odciąć swoich użytkowników. Zatem ostrożnie!

MG