To jest kanoniczne pytanie dotyczące zabezpieczenia stosu LAMP

Jakie są bezwzględne wytyczne dotyczące zabezpieczania serwera LAMP?

Odpowiedź Davida jest dobrą podstawą ogólnych zasad hartowania serwerów. Jak wskazał Dawid, jest to ogromne pytanie. Określone techniki mogą zależeć w dużym stopniu od środowiska i sposobu użytkowania serwera. Ostrzeżenie: zbudowanie i wykonanie prawidłowej pracy może wymagać dużo pracy w środowisku testowym. Po nich dużo pracy nad integracją ze środowiskiem produkcyjnym i, co ważniejsze, proces biznesowy.

Najpierw sprawdź jednak, czy w Twojej organizacji obowiązują zasady hartowania, ponieważ mogą one być najbardziej istotne. Jeśli nie, w zależności od roli, może to być dobry moment na ich rozbudowę. Poleciłbym również rozwiązanie każdego elementu osobno od dołu do góry.

L
Istnieje wiele dobrych przewodników, które mogą ci pomóc. Ta lista może, ale nie musi pomóc, w zależności od dystrybucji.

• Center for Internet Security Benchmark - Dystrybucja specyficzna dla głównych smaków
• Poradnik hartowania CentOS - ściśle przestrzega przewodnika CIS RHEL5, ale jest o wiele łatwiejszy do odczytania
• NIST SP800-123 - Przewodnik po ogólnych zabezpieczeniach serwera
• NSA Hardening Factsheets - Nie tak niedawno zaktualizowany jak CIS, ale nadal w większości dotyczy
• Tiger - oprogramowanie do kontroli bezpieczeństwa systemu na żywo

Zabezpieczanie
Apache może być zabawne. Łatwiej jest mi zahartować system operacyjny i utrzymać użyteczność niż Apache lub PHP.

• Hartowanie serwera Apache - to pytanie na siostrzanej stronie IT Security zawiera wiele dobrych informacji.
• Center for Internet Security Benchmark - Ponownie, testy porównawcze Apache.
• Wskazówki bezpieczeństwa Apache - prosto z projektu Apache, wygląda na to, że obejmuje podstawy
• DISA Hardening Checklist - Lista kontrolna od członków DoD Information Assurance

Im

• Center for Internet Security Benchmark - Znowu, ale dla testów MySQL
• Hartowanie OWASP MySQL
• Ogólne wytyczne bezpieczeństwa - podstawowa lista kontrolna od twórców projektu

P
Jest to zgodne z ideą Bezpiecznych praktyk programistycznych, która jest całą dyscypliną samą w sobie. SANS i OWASP mają absurdalnie dużo informacji na ten temat, więc nie będę próbował ich tutaj replikować. Skoncentruję się na konfiguracji środowiska wykonawczego i pozwolę programistom martwić się resztą. Czasami „P” w LAMP odnosi się do Perla, ale zwykle PHP. Zakładam to drugie.

• Hardening PHP - Drobna dyskusja, także na stronie IT Security SE.
• Hardened PHP Project - Główny projekt, który produkuje Suhosin , próbę załatania aplikacji PHP, aby wyświetlała się przeciwko niektórym typom ataków.
• Hartowanie PHP za pomocą Suhosin - krótkie instrukcje specjalnie dla Suhosin
• Hardening PHP from php.ini - Krótka, ale niezła dyskusja na temat niektórych opcji związanych z bezpieczeństwem

Zadałeś pytanie, które, szczerze mówiąc, jest warte kilku książek na ten temat. Ale istnieją pewne ogólne podstawowe wytyczne, które działają dobrze:

1. Aktualizuj. Oznacza to system operacyjny, wszystkie usługi, a zwłaszcza wszystkie uruchomione aplikacje internetowe.
2. Wyłącz wszelkie niepotrzebne usługi, ogranicz te, które są potrzebne do minimalnego narażenia (jeśli nie łączysz się zdalnie z MySQL, nie słuchaj go przez TCP) i uruchom zaporę opartą na hoście. (Jeśli jest to ściśle LAMPA, powinieneś być dobry z 80 i 443, ale może SSH również do administracji.))
3. Używaj silnych haseł. Jeszcze lepiej, jeśli korzystasz z SSH, używaj tylko uwierzytelniania opartego na kluczach.
4. Upewnij się, że nie logujesz się jako root. Zaloguj się jako użytkownicy i użyj su & sudo.
5. Chociaż nie zapewnia to większego bezpieczeństwa, powinieneś uruchamiać narzędzia takie jak logwatch, abyś był świadomy tego, co dzieje się na twoim serwerze.

Mam nadzieję, że pomoże Ci zacząć.

Oto dobra lista kontrolna, od której chciałbym zacząć.

Zapora ogniowa

• Dobrym podejściem jest nie zezwalanie na rozpoczęcie ruchu, a następnie otwieranie tylko tego, czego potrzebujesz , tak jak potrzebujesz. Powoduje to otwarcie minimalnych portów / ips, aby wszystko działało, a to minimalizuje twoją ekspozycję.
• W przypadku serwera LAMP może być konieczne otwarcie portów dla http / https dla świata i ssh dla sysadmins.
• Upewnij się, że rzeczy takie jak ruch IPv6 są zablokowane, jeśli go nie używasz
• AWS zapewnia grupy bezpieczeństwa, Linux ma iptables, a także mnóstwo pakietów do wyboru.

SSH i użytkownicy

• Brak hasła dostępu do ssh (użyj klucza prywatnego)
• Nie zezwalaj rootowi na ssh (odpowiedni użytkownik powinien ssh in, następnie su lub sudo)
• Użyj sudo dla użytkowników, aby polecenia były rejestrowane
• Rejestruj nieautoryzowane próby logowania (i rozważ oprogramowanie blokujące / blokujące użytkowników, którzy próbują uzyskać dostęp do twojego serwera zbyt wiele razy, np. Fail2ban)
• ssh na niestandardowym porcie (może to być przydatne, aby upewnić się, że nie masz nisko wiszących owoców i powstrzymać duży irytujący ruch, ale nie zrobi wiele dla bezpieczeństwa, szczególnie sam w sobie)
• zablokuj ssh tylko do wymaganego zakresu ip (duży zasięg jest lepszy niż brak zasięgu)

Baza danych

• Wyczyść dane użytkownika
• Sparametryzuj zapytania
• Rozważ wyodrębnienie bazy danych na jej własnym komputerze. Ta separacja może utrudnić atakującemu dostęp do stosu internetowego i odwrotnie.
• Ważne jest, aby każde oprogramowanie było aktualne .
• Użytkownik dla każdego celu . Tworząc użytkowników, rozpocznij bez uprawnień i dodaj tylko tych, których potrzebują, aby wykonać swoją rolę. Posiadanie oddzielnych użytkowników dla różnych aplikacji (lub czasami odrębnych części aplikacji) pomoże zmniejszyć korzyści, jakie atakujący może uzyskać, gdyby zagrali jedno konto. Uważaj również na specjalne uprawnienia, takie jak GRANT, których nie należy lekceważyć.
• Dobrym pomysłem jest posiadanie zasad okresowej zmiany haseł. Jeśli martwisz się nakładem pracy, pamiętaj, że rzadziej jest lepiej niż nigdy.
• Zrozumienie szyfrowania hasła. Hasła do soli . Nie używaj md5!

Oprogramowanie

• Aktualizuj oprogramowanie (system operacyjny, serwer WWW, język skryptowy, CMS). Wiele osób będzie szukało znanych luk w starych (niepakowanych) wersjach
• Usuń niepotrzebne oprogramowanie (najlepiej nie przechowuj pakietu wymaganego do kompilacji oprogramowania na serwerach produkcyjnych, lepiej jest wstępnie skompilować oprogramowanie i udostępnić je jako pakiet dla twoich maszyn produkcyjnych)
• Upewnij się, że uprawnienia do plików są zablokowane (szczególnie w przypadku przesyłania plików przez użytkowników i plików konfiguracyjnych)
• Ochrona obszaru administracyjnego CMS hasłem na poziomie serwera WWW ( uwierzytelnianie HTTP może znajdować się przed wrażliwym CMS i blokować dostęp, co jest dobrym sposobem na zapobieganie atakom)
• Użyj protokołu SSL do danych obszaru administracyjnego i innych poufnych danych
• Zautomatyzuj zarządzanie serwerami i infrastrukturą (coś w rodzaju Puppet, Chef lub SaltStack. Jeśli używasz również AWS CloudFormation). Pomoże to załatać różne rzeczy na wielu serwerach i ograniczyć scenariusze, takie jak ustalanie uprawnień na serwerze A, ale zapomnienie o zrobieniu tego na serwerze B
• Tam, gdzie to możliwe, nie podawaj konkretnej wersji swojego CMS, PHP lub WebServer. Mimo że ukrywanie tych informacji nie stanowi bezpieczeństwa, wiele osób skanuje w poszukiwaniu określonych wersji różnych programów, a im mniej informacji udostępniasz, tym więcej musi atakować. Jest to dobry sposób, aby upewnić się, że nie jesteś jednym z nisko wiszących owoców. Oczywiście nie zrobi to nic komuś, kto chce poświęcić nieco więcej wysiłku na wejście
• Ogranicz osoby, które mają dostęp do serwera

Dodając do tego, co sugeruje David, im bardziej modularna jest twoja instalacja, mam na myśli ograniczenie dostępu do określonych użytkowników / grup utworzonych specjalnie dla jednego zadania i ograniczenie ich zakresu, tym bezpieczniejszy jest twój stos LAMP: przykładem tego jest posiadanie użytkownika Apache dla plików / folderów Apache z odpowiednio ustawionymi uprawnieniami, a nie w żadnej grupie, która ma dostęp do krytycznych plików / folderów systemowych. Użytkownik, który może uzyskać dostęp do tabel MySql powiązanych z Twoimi witrynami internetowymi, które zamierzasz wyświetlać, i tylko tych tabel. Dodatkowo możesz ograniczyć ich dostęp, aby zapewnić minimalną ilość dostępu z połączenia PHP. Upewnij się również, że nazwa użytkownika MySQL używana / widoczna w pliku PHP nie jest tą samą nazwą użytkownika lub hasłem, które zastosowano dla innego użytkownika.

Co to oznacza: jeśli użytkownik apache lub MySql zostanie zagrożony, nie mogą wyrządzić żadnej szkody poza zakresem folderów, do których apache ma dostęp (w przypadku użytkownika apache) i poza tabelą ( s) / database (s) (w przypadku użytkownika bazy danych MySQL).

Jeśli w jakiś sposób użytkownik MySQL miałby zostać skompromitowany, nie mógłby na przykład uzyskać dostępu do bazy danych i upuścić wszystkich baz danych z MySQL i zniszczyć wszystkie dane. W niektórych okolicznościach MOGĄ być w stanie upuścić tabele lub wstawić informacje do niektórych tabel w izolowanej bazie danych, dlatego ważne jest, aby udzielać dostępu do tabeli tylko tam, gdzie jest to absolutnie konieczne, i udzielać niezbędnych uprawnień ... jeśli nie Muszę mieć uprawnienia do upuszczania tabel lub uprawnienia do aktualizacji, a następnie nie dawaj ich temu użytkownikowi.

Ponadto, jeśli z jakiegoś powodu twoja nazwa użytkownika i hasło do konta administracyjnego zostaną znalezione dla MySQL, jeśli użyjesz innej nazwy użytkownika niż jakakolwiek inna nazwa użytkownika w systemie, muszą oni najpierw złamać zabezpieczenia systemu, zanim dostaną się do bazy danych, aby wyrządzić szkody. To samo dotyczy użytkownika apache i dostępu do plików.

Przykładowy czas! Podam przykładowy system, który uprości ten pomysł.

powiedz, że masz użytkowników w swoim systemie (root powinien być wyłączony dla bezpieczeństwa przez coś takiego jak umod -l lub passwd -l itp.): John, Barney, Terence i Lisa.

możesz utworzyć użytkownika w MySQL o nazwie bigbird (upewnij się, że używasz zaszyfrowanego hasła). Bigbird ma tylko wybrane uprawnienia i uprawnienia do aktualizacji, ale nie upuszcza ani nie tworzy, a na pewno nie . Ponadto tworzysz kolejnego administratora MySQL o nazwie garfield do pracy z bazą danych MySQL i usuwasz użytkownika root z bazy danych MySQL, aby nie można było go skompromitować. garfield został przyznany . uprawnienia w MySQL (w rzeczywistości jest to po prostu zmiana nazwy roota).

teraz tworzysz grupę apache lub użytkownika, a my nazwiemy to apweb2. Appweb2 nie należy do innych grup, a wszystkie pliki / foldery dla apache są przechowywane w / home / apweb2 /. Każdy wirtualny host miałby swój własny podfolder, a każdy z tych hostów miałby ustawiony katalog główny tego podfolderu. Dowiązania symboliczne zostałyby wyłączone, aby przypadkowo nie zapewnić dostępu do reszty systemu.

Możesz także ograniczyć dostęp ssh tylko do niektórych użytkowników (lub niektórych grup, lubię umieszczać ich w grupie ssh i sprawić, że jedyna możliwość korzystania z ssh).

Możesz także wybrać, którzy użytkownicy mają uprawnienia sudo, aby jeszcze bardziej ograniczyć ograniczenia. Kolejnym krokiem, który możesz zrobić, jest uczynienie wszystkich użytkowników ssh niezdolnymi do sudo, możesz stworzyć specjalnych użytkowników, którzy będą mogli używać sudo, którzy nie mogą używać ssh, aby po ssh zalogować się do innego użytkownika, aby mieć dostęp do sudo.

Tak więc, poprzez modularyzację każdego segmentu, jeśli jeden jest zagrożony, cały stos nie zostanie naruszony i możesz rozwiązać problem 1 zamiast zaczynać wszystko od nowa od zera.

Znalazłem ten dokument z SANS.org bardzo pomocny http://www.sans.org/score/checklists/linuxchecklist.pdf

W chwili obecnej nie zaniedbuj wirtualizacji kontenerów, a mianowicie Dockera, systemd-nspawn i mechanizmów wirtualizacji kontenerów, na których są one zbudowane (przestrzenie nazw, grupy grup). Korzystanie z wirtualizacji kontenerów pozwala izolować procesy, na przykład jeśli jedna z usług zostanie naruszona, osoba atakująca nie uzyska dostępu do innych usług.

W przypadku LAMP można na przykład użyć czterech kontenerów Docker z serwerem SSH, Apache, MySQL, PHP-FPM / Python / Perl / itp.