Bezpieczeństwo w systemach GNU / Linux, czy zależy to od systemu czy administratora?

W minionych dniach biegali przez sieć raporty o atakach Wykorzystują lukę w PHP, która umożliwia niektórym legalnym witrynom serwowanie fałszywych stron internetowych i reklam, narażając odwiedzających na instalację złośliwego oprogramowania na ich komputerach. Te ataki wykorzystują niezwykle krytyczna luka w zabezpieczeniach PHP publicznie ujawnione 22 miesiące temu i dla których zostały wydane odpowiednie aktualizacje.

Niektórzy zaczęli uporczywie wskazywać, że duża część serwerów zaatakowanych podczas tych ataków korzysta z wersji GNU / Linux, udając, że kwestionują bezpieczeństwo tego systemu operacyjnego, ale bez wchodzenia w szczegóły dotyczące natury luki lub powodów dlaczego tak się stało.

Systemy z zainfekowanym systemem GNU / Linux, we wszystkich przypadkach używają Jądro Linux w wersji 2.6, wydany w 2007 roku lub wcześniej. W żadnym wypadku nie wspomniano o infekcji systemów z wyższymi jądrami lub które zostały należycie zaktualizowane; Ale oczywiście nadal są administratorzy, którzy myślą: „... jeśli nie jest zepsuty, to nie trzeba go naprawiać” i wtedy takie rzeczy się zdarzają.

Ponadto ostatnie badanie przeprowadzone przez firmę zabezpieczającą ESET, szczegółowo ujawnia wezwanie „Operacja Windigo”, w którym poprzez kilka zestawów atakujących, w tym jeden tzw Zamknięty specjalnie zaprojektowany dla Apache i innych popularnych serwerów internetowych typu open source, a także innego o nazwie SSH, byli ponad 26,000 XNUMX systemów GNU / Linux zostało przejętych Czy od maja zeszłego roku oznacza to, że GNU / Linux nie jest już bezpieczny?

Po pierwsze, umieszczając rzeczy w kontekście, jeśli porównamy poprzednie liczby z prawie 2 milionami komputerów z systemem Windows zainfekowanych przez bootnet Zero dostępu Przed zamknięciem w grudniu 2013 r. Łatwo stwierdzić, że pod względem bezpieczeństwa Systemy GNU / Linux są jeszcze bezpieczniejsze niż te, które używają systemu operacyjnego Microsoft, ale czy to wina GNU / Linuksa, że ​​26,000 XNUMX systemów z tym systemem zostało naruszonych?

Podobnie jak w przypadku omówionej powyżej krytycznej luki w zabezpieczeniach PHP, która wpływa na systemy bez aktualizacji jądra, te inne ataki obejmują systemy, w których domyślna nazwa użytkownika i / lub hasło nie zostały zmienione i które zachowały porty 23 i 80 są niepotrzebnie otwarte; Czy to naprawdę wina GNU / Linuksa?

Oczywiście odpowiedź brzmi NIE, problemem nie jest używany system operacyjny, ale nieodpowiedzialność i zaniedbanie administratorów tych systemów, którzy nie do końca rozumieją maksimum podane przez eksperta ds. Bezpieczeństwa Bruce Schneier które powinny zostać wypalone w naszych mózgach: Bezpieczeństwo TO proces, a NIE produkt.

Nie ma sensu, jeśli zainstalujemy sprawdzony bezpieczny system, jeśli następnie zostawimy go porzuconym i nie instalujemy odpowiednich aktualizacji, gdy tylko zostaną wydane. Podobnie nie ma sensu aktualizowanie naszego systemu, jeśli dane uwierzytelniające, które pojawiają się domyślnie podczas instalacji, są nadal używane. W obu przypadkach tak jest podstawowe procedury bezpieczeństwa, które nie wynikają z powtórzeń, są odpowiednio stosowane.

Jeśli masz pod swoją opiekę system GNU / Linux z Apache lub innym serwerem WWW typu open source i chcesz sprawdzić, czy został on naruszony, procedura jest prosta. W przypadku pogrzebać, musisz otworzyć terminal i wpisać następujące polecenie:

ssh -G

Jeśli odpowiedź jest inna niż:

ssh: illegal option – G

a następnie listę poprawnych opcji dla tego polecenia, oznacza to, że system jest zagrożony.

W przypadku Zamkniętyprocedura jest trochę bardziej skomplikowana. Musisz otworzyć terminal i napisać:

curl -i http://myserver/favicon.iso | grep "Location:"

Jeśli system został naruszony, to Zamknięty przekieruje żądanie i wyświetli następujące dane wyjściowe:

Location: http://google.com

W przeciwnym razie nie zwróci niczego ani innej lokalizacji.

Forma dezynfekcji może wydawać się surowa, ale jako jedyna okazała się skuteczna: pełne czyszczenie systemu, ponowna instalacja od podstaw i zresetuj wszystkie poświadczenia użytkownika i administratora z niezatwierdzonego terminala. Jeśli okaże się to trudne, weź pod uwagę, że gdybyś natychmiast zmienił poświadczenia, nie naraziłbyś systemu.

Aby uzyskać znacznie bardziej szczegółową analizę sposobów działania tych infekcji, a także konkretnych sposobów ich rozprzestrzeniania i odpowiednich środków, które należy podjąć, zalecamy pobranie i przeczytanie pełnej analizy „Operacja Windigo” dostępne pod następującym linkiem:

Operacja Windigo

Wreszcie: fundamentalny wniosek: Nie ma gwarancji systemu operacyjnego przed nieodpowiedzialnymi lub nieostrożnymi administratorami; Jeśli chodzi o bezpieczeństwo, zawsze jest coś do zrobienia, bo pierwszym i najpoważniejszym błędem jest myślenie, że już to osiągnęliśmy, czy nie?