Hasło roota w trybie recovery serwera, a Ezeelogin

Po wdrożeniu Ezeelogin na naszych serwerach hostingowych, administratorzy mają możliwość logowania się przez serwer-bramę, bądź używając kluczy.

W przypadku uruchomienia serwera w trybie recovery (np. przy problemie z systemem fsck systemu plików), Debian domyślnie wymaga podania hasła użytkownika root, które jest automatycznie zmieniane na losowe, nieznane hasło przez Ezeelogin.

Poniższe polecenie po podaniu poświadczeń administratora głównego Ezeelogin pozwala na wyświetlenie listy haseł.

php /usr/local/ezeelogin/ezlexport.php tmp && cat tmp | cut -d \’|\’ -f 1,4 && rm tmp

Polecenie nie sprawdza licencji – może zostać wywołane po jej wygaśnięciu.

Przechowywanie kluczy SSH programu PuTTY w KeePass

Powyżej wersji 0.60 klient SSH PuTTY posiada wsparcie dla tzw. agenta uwierzytelniania. Dołączona do programu wersja – Pageant – pozwala na załadowanie do pamięci wielu kluczy i uwierzytelnianie nimi nie tylko połączeń z lokalnego komputera, ale w przypadku połączeń przez serwery OpenSSH również kolejnych sesji (agent forwarding).

KeeAgent – plugin do KeePass \”podszywający się\” pod Pageanta pozwala na przechowywanie kluczy SSH w rekordach bazy kdbx programu KeePass.

Aby dodać plugin do menadżera kluczy, z pobranego ze strony projektu archiwum kopiujemy plik KeeAgent.plgx do katalogu instalacji. Przy ponownym uruchomieniu, zostanie on skompilowany i załadowany.
Pliki kluczy SSH (ppk) dodajemy do rekordów w \”zaawansowanych\” jako załączniki. Jeżeli są zabezpieczone hasłem – podajemy je jako hasło we wpisie.

Następnie przechodzimy do konfiguracji PuTTY.
\"\"
Wybierając opcję \”Attempt authentication using Pageant\” zapewniamy sobie możliwość logowania kluczem z odblokowanej bazy KeePass z komputera lokalnego.
Opcja \”Allow agent forwarding\” pozwala na użycie Pageanta w uwierzytelnianiu kolejnych połączeń z serwera do którego jesteśmy zalogowani. Nie powinno się używać tej opcji na serwerach, którym nie ufamy – klucze mogą zostać użyte wtedy również przez administratora systemu (podobnie jak hasło, które wpisywaliśmy jak dotąd).

Po właściwej konfiguracji, po połączeniu do serwera który rozpoznaje nasz klucz powinno ukazać nam się powiadomienie jak i gotowa do pracy sesja zdalnej konsoli.

\"\"

Limitowanie zasobów użytkowników przy suPHP z wykorzystaniem stosu PAM

Nowy pracownik naszej firmy, administrator Linux Mateusz Małek, w ramach prowadzonych testów podatności przeprowadził udany, a zarazem trywialny atak mający wpływ na stabilność pracy jednego z naszych serwerów hostingowych.

Poniżej prezentujemy sposób częściowy zabezpieczenia serwera przed lokalnymi atakami DoS wykonywanymi przy pomocy funkcji shell_exec() w PHP, jeżeli wykorzystywany jest suPHP.

W przypadku wykorzystywania suPHP, uruchamiane z UID+GID użytkownika procesy nie przechodzą przez stos PAM, tym samym nie dotyczą ich limity pam_limits.so z /etc/security/limits.conf. Opisane poniżej kroki zmieniają to zachowanie.

Patchowanie, rekompilacja i rekonfiguracja suPHP

  1. Nakładamy przygotowany patch na suPHP:

    cd /usr/local/directadmin/custombuild
    cp $(find -type d -name \’suphp-0*\’) suphp-patched;
    cd suphp-patched;
    wget http://mkwm.zielonki.info/suphp_patch.diff -O – | patch -p1

  2. Tworzymy nową usługę PAM – np. \”suphp\”, uwzględniającą moduł pam_limits z dedykowaną konfiguracją – wykorzystanie globalnego pliku konfiguracyjnego stwarza pewne problemy (o czym za chwilę):

    cat << EOF > /etc/pam.d/suphp
    auth sufficient pam_permit.so
    session required pam_limits.so conf=/usr/local/suphp/etc/security/limits.conf
    session required pam_permit.so
    EOF

  3. Konfigurujemy limity dotyczące liczby procesów (tak, serwer uległ \”trzynastu znakom\”). Dedykowany plik konfiguracyjny rozwiązuje problem z sytuacją, w której konta użytkowników nie posiadają żadnej wspólnej grupy – w przypadku ustawienia limitów dla wszystkich (*), nie ma możliwości podniesienia ich dla konkretnego użytkownika/grupy (co powoduje problemy z działaniem usług czy administrowaniem serwerem):

    cat << EOF > /usr/local/suphp/etc/security/limits.conf
    * soft nproc 20
    * hard nproc 20
    EOF

  4. Rekompilujemy suPHP i dodajemy \”pam_service=suphp\” do sekcji global w jego pliku konfiguracyjnym.

Kalendarz Microsoft 2010

\"\"

W roku 2010 na pewno wydarzy się wiele ważnych rzeczy, ale poza nimi warto zapisać sobie w kalendarzu trzy daty związane z tak zwanymi \”klienckimi\” systemami:

  • Pierwszy marca 2010 – od tego dnia, Windows 7 RC zacznie się automatycznie restartować co dwie godziny, w ten subtelny sposób zwracając uwagę użytkownika na fakt, że wypadałoby zainstalować wersję finalną. Warto pamiętać, że oficjalnie nie istnieje ścieżka migracji z wersji RC do wersji finalnej, ale szczególnie uparty użytkownik może tego dokonać zmieniając zawartość jednego z plików ini, podobnie jak miało to miejsce podczas upgrade z wersji beta do RC.
  • Trzynasty kwietnia 2010 – koniec wsparcia dla Windows Vista bez Service Pack. Jeżeli ktoś jeszcze nie ma SP1 lub SP2, to lepiej późno niż wcale. SP2 można pobrać ze stron Microsoft.
  • Trzynasty lipca 2010 – koniec wsparcia dla Windows XP SP2 – podobnie jak w poprzednim przypadku, warto pomyśleć o poprawkach. Oczywiście SP3 również można pobrać ze stron Microsoft.
  • Lipiec 2010 – koniec wsparcia dla Windows 2010

Zdaję sobie sprawę, że w większych środowiskach konieczność aktualizacji może być sporym problemem. Ale z drugiej strony – może już pora na aktualizację? SP2 do Windows XP wydaje się taki świeży, a ma już prawie 6 lat…

Bezpieczny Trixbox

Dzisiaj prezentujemy mały przewodnik, który przeprowadzi was przez zmianę haseł w domyślnej instalacji Trixbox\’a.

Unikamy nieszyfrowanego połączenia przez http:

Zmieniamy \"Listen 80\" na \"#Listen 80\" w pliku \"/etc/httpd/conf/httpd.conf\"

Zmieniamy domyślny port dla serwera https:

Zmieniamy \"Listen 443\" na \"Listen 12444\" w pliku \"/etc/httpd/conf.d/ssl.conf\"

oraz \”\” na \”\”

Zmieniamy domyśly port na jakim nasłuchuje panel:

Zamień linię \";listen_port=4445\" na \"listen_port=12555\" w pliku \"/var/www/html/panel/op_server.cfg\"

Zabezpieczenie SSH:

– zmiana portu
Zamień linię \"#Port 22\" na \"Port 12666\" w pliku \"/etc/ssh/sshd_config\"

-logowanie na roota
Zamień linię \"#PermitRootLogin yes\" na \"PermitRootLogin no\" w pliku \"/etc/ssh/sshd_config\"

Zmiana hasła roota:

passwd

Dodajemy użytkownika z prawami logowania przez SSH:

adduser nazwa_usera
passwd hasło_usera

Zabezpieczamy MySQL:

mysqladmin -u asteriskuser -p password nowe_super_bezpieczne_hasło

Kiedy zostaniemy poproszeni o hasełko wpisujemy \”amp109\” – jest to domyśle hasło w Trixboxie.

Następnie musimy wprowadzić nowe hasło do plików konfiguracyjnych:

Zamień hasło \"AMPDBPASS\" w pliku \"/etc/amportal.conf\"

Zamień hasło \”password\” w pliku \”/etc/asterisk/cdr_mysql.conf\”

Zamień hasło \”dbpass\” w pliku \”/etc/asterisk/res_mysql.conf\”

iptables, chronimy połączenia przychodzące inne niż:

– SIP
– SSH
– WEB
– FOP

Po zmianie Twojego zewnętrznego adresu IP z 111.222.111.222 w skrypcie, można go skopiować bezpośrednio do konsoli.

IPTABLES=/sbin/iptables
$IPTABLES -F
$IPTABLES -F INPUT; $IPTABLES -P INPUT ACCEPT; $IPTABLES -Z INPUT
$IPTABLES -F FORWARD; $IPTABLES -P FORWARD ACCEPT; $IPTABLES -Z FORWARD
$IPTABLES -F OUTPUT; $IPTABLES -P OUTPUT ACCEPT; $IPTABLES -Z OUTPUT
$IPTABLES -X
$IPTABLES -N ALEX-INPUT;
$IPTABLES -N REJECT-PKT;
$IPTABLES -N SYN-FLOOD;

$IPTABLES -A INPUT -j ALEX-INPUT
$IPTABLES -A ALEX-INPUT -i lo -j ACCEPT
$IPTABLES -A ALEX-INPUT -s 127.0.0.0/8 -j DROP
$IPTABLES -A ALEX-INPUT -d 127.0.0.0/8 -j DROP

$IPTABLES -A ALEX-INPUT -s 111.222.111.222 -j DROP

$IPTABLES -A ALEX-INPUT -p tcp -m tcp ! –syn -m state –state NEW -j DROP
$IPTABLES -A ALEX-INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A ALEX-INPUT -p icmp -m icmp –icmp-type ping -j ACCEPT

$IPTABLES -A ALEX-INPUT -p tcp -m tcp –dport 12444 -j ACCEPT
$IPTABLES -A ALEX-INPUT -p tcp -m tcp –dport 12555 -j ACCEPT
$IPTABLES -A ALEX-INPUT -p tcp -m tcp –dport 12666 -j ACCEPT
$IPTABLES -A ALEX-INPUT -p udp -m udp –dport 5060 -j ACCEPT
$IPTABLES -A ALEX-INPUT -p udp -m udp –dport 5061 -j ACCEPT
$IPTABLES -A ALEX-INPUT -p udp -m udp –dport 10000:20000 -j ACCEPT

$IPTABLES -A ALEX-INPUT -j REJECT-PKT

$IPTABLES -A REJECT-PKT -p tcp -m tcp -j REJECT –reject-with tcp-reset
$IPTABLES -A REJECT-PKT -p udp -m udp -j REJECT –reject-with icmp-port-unreachable
$IPTABLES -A REJECT-PKT -p icmp -m icmp –icmp-type ping -j REJECT –reject-with icmp-host-unreachable

Zapisujemy iptables poleceniem:

service iptables save

Ustawiamy bootowanie skryptu iptables, przy starcie systemu:

ln -s /etc/init.d/iptables /etc/rc3.d/S20iptables

Zmiana hasła maint-password:

passwd-maint

Wpisujemy nowe hasło dwukrotnie.

Zmiana hasła do FOP\’a:

Zamień \”FOPPASSWORD=passw0rd\” to \”FOPPASSWORD=nowe_super_bezpieczne_hasło\” w pliku \”/etc/amportal.conf\”

Zmieniamy hasło dla użytkownika admin na stronie z nagraniami (ARI):

Zaień linię $ARI_ADMIN_PASSWORD =\”ari_password\” na $ARI_ADMIN_PASSWORD =\”nowe_super_bezpieczne_hasło\” w pliku \”/var/www/html/recordings/includes/main.conf.php\”

Zmieniamy hasło do AMP-Managera:

Zamień \”AMPMGRPASS=amp111\” na \”AMPMGRPASS=nowe_super_bezpieczne_hasło\” w pliku /etc/amportal.conf

Zamień \”secret = amp111\” na \”secret = nowe_super_bezpieczne_hasło\” w pliku \”/etc/asterisk/manager.conf\”

Jak dostać się do Trixbox\’a?

User page: https://111.222.111.222:12444/user/

Maintanance page: https://111.222.111.222:12444/maint/ (user=maint, pass=nowe_super_bezpieczne_hasło)

FreePBX page: https://111.222.111.222:12444/admin/ (user=maint, pass=nowe_super_bezpieczne_hasło)

Recordings page: https://111.222.111.222:12444/recordings/ (user=admin, pass=nowe_super_bezpieczne_hasło)

SSH : login with nazwa_usera oraz hasło_usera następnie wykonaj polecenie \”su -\” oraz podaj swoje nowe_super_bezpieczne_hasło root\’a 😉

Na koniec, 9 rad dotyczących bezpieczeństwa central telefonicznych.


Rodzaje zagrożeń w sieci

Bezpieczeństwo użytkowników w sieci jest najważniejsze. Niestety nieświadomość zagrożeń wpływa na podatność utraty cennych danych. Zawsze tak było i będzie, że użytkownicy są najsłabszym ogniwem jakichkolwiek zabezpieczeń. To ich brak wiedzy, lenistwo lub zwykła bezmyślność może doprowadzić do niewystarczającej ochrony. Nie jest żadną nowością, że Internet jest najpopularniejszym medium, które pozwala na łątwą i szybką wymianę informacji. Oprócz pozytywnych aspektów używania sieci, istnieje wiele form nieuczciwości i naruszenia bezpieczeństwa danych. Żeby dokładniej przybliżyć niebezpieczeństwa poniżej krótko przedstawiam mój podział ewentualnych ataków na sieć (host/-y).

Podział ataków:

Ataki w warstwie drugiej – łącza danych, modelu OSI:

1) atak na tablicę MAC, czyli MAC flooding wykorzystujący skończoną wielkość tablicy CAM. W momencie przepełnienia tej tablicy, wszystkie ramki, które przychodzą na określony port, będą wysyłane na pozostałe porty switch’a. Do przeprowadzenia ataku może posłużyć Macof z pakietu Dsniff lub Yersinia. Rozwiązanie ochronne to m.in.: port security.

2) atak na protokół ARP, czyli ARP spoofing – łatwość w przechwytywaniu haseł w ruchu między innymi FTP, Telnet, http (czyli np. hasła i loginy z forum lub bloga), POP (czyli loginy i hasła z poczty internetowej)… wystarczy skorzystać z dobrych snifferów (Wireshark, Tcpdump, Ettercap, Dsniff, Snort). Jest to atak typu MITM, czyli popularny Man In The Middle. Atak ARP spoofing polega na podszywaniu się agresora pod jednym z komputerów w sieci poprzez wysłanie wielu sfałszowanych adresów ARP Reply co powoduje (celowe i błędne) zmiany wpisów w systemie odwzorowań ARP pamięci podręcznej. Jednym z rozwiązań bezpieczeństwa jest, na przykład, Dynamic ARP Inspection.

3) MAC spoofing, czyli zmiana adresu MAC u intruza na MAC ofiary co może prowadzić do zmiany w tablicy przełączania. Atak jest mało skuteczny bo prowadzi przeważnie do częściowego przechwytu danych. W przełącznikach zabezpieczeniem prze takim atakiem są statyczne wpisy w tabeli przełączania.

4) DHCP spoofing jest kolejnym typem ataku MITM przeprowadzanym na serwer DHCP, który umożliwia uzyskanie danych do konfiguracji w sieci, czyli adres IP hosta, maski, adres IP bramy, adres serwera DNS. Atak polega na manewrowaniu komunikatami DHCP Offer oraz DHCP Ackonwledge. Narzędziem do przeprowadzenia tego ataku jest Ettercap, który po odpowiedniej konfiguracji będzie fałszywym serwerem DHCP. Jednym z rozwiązań jest DHCP snooping.

5) atak, który wykorzystuje słabość Spanning Tree. Odpowiednim zabezpieczeniem jest BPDU Guard i BPDU Filter.

Ataki w warstwie trzeciej – sieci, modelu OSI:

1)ataki rodziny DoS – można tutaj wypisać niesamowicie wiele informacji, w tym artykule ograniczę się do wymienienia najważniejszych, bez wgłębiania się w ich działanie. Generalnie najlepiej jest podzielić ataki DoS, ze względu na działanie, na trzy grupy
a) ataki, które bazują na implementacji stosu TCP/IP i wykorzystują słabość w specyfikacji TCP/IP w określonym systemie operacyjnym. Do tej grupy zaliczam: Ping Of Death (znany tez jako Long ICMP attaca; zniekształca pakiet ICMP Echo Request), Teardrop (dotyczy fragmentacji pakietów protokołu IP i pól offset field), SMBnuke, WINnuke
b) ataki, które bazują na słabościach standardów stosu TCP/IP. Przykładowo bardzo niebezpieczny SYN Flood, Naptha oraz Land. Są to klasyczne ataki wyczerpujące zasoby systemowe.
c)Ataki, które w swoim działaniu wykorzystują tzw. „brutalną siłę”, czyli brute force. Generują one duży ruch w sieci, który wyczerpuje dostępną przepustowość. Najbardziej znane to: Smurf, UDP Flood, Fraggle, Pingflood oraz Jolt.

2)ataki z rodziny DDoS, taki atak jest przeważnie efektywny a źródła są trudne do wytropienia. Do najpopularniejszych ataków DDoS można zaliczyć: Torinoo (UDP flood), Mstream (TCP ACK Flood + IP spoofing), Shaft (UDP+TCP SYN+ICMP flood i przeprowadzanie statystyk), Stacheldraht (UDP+TCP SYN,ACK,NULL+ICMP flood , IP spoofing, komunikacja w ramach sieci jest szyfrowana), TFN (UDP+ICMP Echo+TCP SYN flood i atak Smurf), TFN2K (UDP+TCP+ICMP flood, atak Smurf oraz Targa3, IP spoofing, komunikacja w ramach sieci jest szyfrowana) . Do zbudowania tak zwanej sieci DDoS wykorzystuje się dodatkowo takie elementy jak: exploity (służą do uzyskania praw administratora), rootkity (służą do ukrywania włamania zaatakowanego systemu), skanery portów (szukanie kolejnych ofiar), sniffery (podsłuch danych) oraz autorootery (konie trojańskie, które wprowadzają automatyzm tworzenia sieci DDoS) i daemony (procesy pracujące w tle bez interakcji z użytkownikiem).

W celu zabezpieczeń i częściowym ograniczeniu zapędów agresora należy stosować:
1) szyfrowanie MD5 wykorzystywane tylko i wyłącznie w celu ochrony protokołów routingu (RIPv2, OSPF itd.) poprzez dodatkowe uwierzytelnienie sąsiadów lub uaktualnień – co zapobiega atakom w warstwie gdzie funkcjonują protokoły routingu.
2) GTSM – czyli Generalised TTL Security Mechanizm – dzięki temu GTSM chroni sesje BGP przed atakami, które mogą nastąpić od oddalonych hostów. Także 2 routery między którymi jest sesja eBGP wymieniają się pakietami IP z polem TTL ustawionym na 255, wszelkie wartości poniżej są odrzucane.
3) filtry prefiksów rozgłaszanych do Internetu i otrzymywanych z Internetu. Właśnie tutaj można zastosować uRPF (unicast Reverse Path Filtering) do automatycznego wykrywania fałszowania adresu źródłowego (adres źródłowy będzie filtrowany po zawartości tablic routingu).
4) do ograniczenia ataków rodziny DDoS można korzystać z Blackholing, który jest wyzwalany zdalnie (RTBH) oraz Anycast Sinkhole.

Ataki w warstwie czwartej – transportowej, modelu OSI:

Protokół TCP i UDP odpowiada warstwie 4 – transportowej. Z definicji: Porty protokołu – pojęcie związane z protokołami transportowymi TCP i UDP używanymi w Internecie do identyfikowania procesów działających na odległych systemach.
Warto zwrócić uwagę na skanowanie portów, które jest szalenie obszernym tematem. Samo w sobie nie jest szkodliwe, ale może być wykorzystane w złych celach. Najpopularniejsze narzędzie do przeprowadzania takich ataków to Nmap. Żeby zebrać dokładne informacje o danym porcie, trzeba przeprowadzic kilka rodzajów skanowania. Niektóre z nich to skanowania: TCP SYN, TCP-connect, UDP, Null, ACK, TCP Window, Maimon, Idle oraz FTP-bounce. Po wykonaniu takich skanowań można bez problemu określić usługi i aplikacje jakie są zainstalowane na hoście, protokołach jakie są wykorzystywane przez usługę i rodzinie systemów operacyjnych. Dodatkowo można określić stan każdego z portów (otwarty, zamknięty, filtrowany, niefiltrowany, otwarty/filtrowany, zamknięty/filtrowany).

Rozwiązaniem bezpieczeństwa jest stosowanie firewall’a. Są różne postacie zaczynając od sprzętowych rozwiązań (Juniper i Cisco) a kończąc na programowych (Outpost, Zonealarm i w szczególności zasługuje tu na uwagę iptables). Na poniższym rysunku widoczne jest porównanie, gdzie działa firewall w stosunku do warstw modelu OSI oraz TCP/IP.
[singlepic id=26 w=320 h=240 float=center]

Ataki w warstwie siódmej – aplikacji, modelu OSI:

Warstwa w której są obsługiwane najważniejsze protokoły (SMTP, FTP, HTTP, TFTP, Telnet). W szczególności aktywne tu są takie niebezpieczeństwa jak oprogramowanie typu malware (wirusy, konie trojańskie i robaki), przepełnienie bufora, SQL injection oraz XSS, czyli Cross-Site Scripting.

Pojęcia takie jak robaki internetowe, wirusy, konie trojańskie, ataki z rodziny DoS, podsłuch ruchu sieciowego (sniffing) lub fałszowanie podstawowych usług lub protokołów sieciowych (spoofing) mogą dać wiele do myślenia, przestraszyć albo, odwrotnie, utwierdzić w przekonaniu, że problem nie dotyczy użytkownika. Zagadnienia związane z bezpieczeństwem rozwijają się w dynamiczny sposób. Istnieje nieustająca potrzeba tworzenia nowych rozwiązań i eliminowaniu słabych punktów systemu operacyjnego lub aplikacji wykorzystujących sieć internetową. W sposób zdecydowany trzeba powiedzieć, że bezpieczeństwo to nieustający proces, który musi być ciągle udoskonalany.

text by Patryk \’Whizz_BANG\’ Bator 🙂