Jakie kroki podejmujesz w celu zabezpieczenia serwera Debian? [Zamknięte]

Instaluję serwer Debian, który jest podłączony bezpośrednio do Internetu. Oczywiście chcę uczynić to tak bezpiecznym, jak to możliwe. Chciałbym, abyście dodali swoje pomysły, aby je zabezpieczyć i jakich programów do tego używacie.

Chcę, aby część tego pytania dotyczyła tego, czego używasz jako zapory ogniowej? Wystarczy ręcznie skonfigurowany iptables, czy korzystasz z jakiegoś oprogramowania, które Ci pomoże? Jaki jest najlepszy sposób? Zablokować wszystko i pozwolić tylko na to, co jest potrzebne? Czy mogą być dobre samouczki dla początkujących na ten temat?

Czy zmieniasz port SSH? Czy używasz oprogramowania takiego jak Fail2Ban, aby zapobiegać atakom typu bruteforce?

Obowiązkowy:

• instalacja systemu w trybie eksperckim, tylko potrzebne mi pakiety
• ręcznie napisana zapora ogniowa z domyślną polityką dotyczącą wejścia iptables: upuszczanie, zezwalające na dostęp do SSH, HTTP lub czegokolwiek innego uruchomionego serwera
• Fail2Ban dla SSH [a czasem FTP / HTTP / inny - w zależności od kontekstu]
• wyłącz logowanie roota, wymuś używanie zwykłego użytkownika i sudo
• niestandardowe jądro [tylko stary nawyk]
• zaplanowana aktualizacja systemu

W zależności od poziomu paranoi dodatkowo:

• upuść politykę wyjścia, z wyjątkiem kilku dozwolonych miejsc docelowych / portów
• integritdo sprawdzania, czy niektóre części systemu plików nie zostały zmodyfikowane [z sumą kontrolną przechowywaną poza maszyną], na przykład Tripwire
• zaplanowane skanowanie przynajmniej z nmap systemu z zewnątrz
• automatyczne sprawdzanie dziennika w poszukiwaniu nieznanych wzorców [ale to głównie w celu wykrycia awarii sprzętu lub niewielkich awarii]
• zaplanowane uruchomienie chkrootkit
• niezmienny atrybut /etc/passwddodawania nowych użytkowników jest nieco trudniejszy
• / tmp zamontowane z noexec
• port knocker lub inny niestandardowy sposób otwierania portów SSH [np. odwiedzanie „tajnej” strony internetowej na serwerze sieciowym pozwala na przychodzące połączenie SSH przez ograniczony czas z adresu IP, który wyświetlał stronę. Jeśli się połączysz, -m state --satete ESTABLISHEDdbasz o przepływ pakietów, o ile korzystasz z jednej sesji SSH]

Rzeczy, których sam nie robię, ale mają sens:

• grsecurity dla jądra
• zdalny syslog, aby dzienniki nie mogły zostać zastąpione, gdy system zostanie naruszony
• powiadamianie o wszelkich logowaniach SSH
• Skonfiguruj rkhunter i skonfiguruj go do działania od czasu do czasu

Tylko uwaga na temat zapory ogniowej twojego komputera ...

• Używaj białej listy, a nie czarnej listy - tzn. Blokuj wszystko i zezwalaj tylko na to, czego potrzebujesz, odmawiaj wszystkiego innego.
• Nie używaj GUI / ncurses ani żadnego innego oprogramowania, które próbuje napisać dla ciebie zaporę ogniową. Jeśli to zrobisz, pozwolisz oprogramowaniu na przyjęcie założeń dla ciebie - nie musisz podejmować tego ryzyka i nie powinieneś. Skonfiguruj go sam, jeśli nie masz pewności, wyłącz go - wkrótce dowiesz się, czy jest to wymagane. Jeśli jest to już działający system i nie możesz zakłócać ruchu (przez przypadkowe zablokowanie go), uruchom tcpdump (zrzut do pliku) i pobierz próbki - sprawdź je później, a następnie dowiedz się, co jest prawidłowe, a co nie.
• Osobiście nie widzę sensu w uruchamianiu usługi na niestandardowym porcie, narzędzia nie są obecnie tak głupie, aby zakładać, że ponieważ coś działa na przykład na porcie 22, to musi to być ssh, a nie inaczej - dla Przykład amapi nmapjest -Arozwiązaniem. Powiedziawszy to, możesz (i prawdopodobnie powinieneś się martwić) zmodyfikować swoje usługi, aby ukryć się przed wścibskimi oczami, na przykład następujące informacje dadzą atakującemu dokładną wersję OpenSSHuruchomionej aplikacji, a następnie będą mogli szukać exploitów dla ta dokładna wersja. Jeśli ukryjesz takie rzeczy, utrudnisz im to.

    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Próbuję 127.0.0.1 ...
    Połączony z localhost.localdomain (127.0.0.1).
    Znakiem ucieczki jest „^]”.
    SSH-2.0-OpenSSH_3.9p1

• Aktualizuj wszystkie swoje usługi publiczne i dodawaj najnowsze łaty bezpieczeństwa.
• Nie przechowuj żadnych danych na samym serwerze bramy, przynajmniej kupisz czas, gdy uda im się włamać do tego komputera, a stracisz usługę lub dwie, a czasem, ale nie dane.

Najważniejsze jest to, że nigdy nie uda ci się uczynić niczego w 100% bezpiecznym - to po prostu niemożliwe - więc celem jest uczynienie go tak bezpiecznym, jak to możliwe - jeśli po prostu zbyt duży wysiłek włamuje się do twojego systemu, jest wystarczająco dobry i najbardziej opóźniony Skrypciarze przejdą do następnego systemu.

• iptables jest sposobem na skorzystanie z dowolnego systemu Linux - ale skonfiguruj go sam.

Nigdy nie używaj żadnego „oprogramowania zabezpieczającego”, które nie jest oparte na otwartych standardach - są skazane na słabą pisownię i zostaną zhakowane (nie chodzi o to „jeśli”, ale „kiedy”). Otwarte źródła i otwarte protokoły są otwarte dla publicznej kontroli i stają się dojrzałym i niezawodnym produktem; oprogramowanie zamknięte źródło opiera się głównie na autorów pewności siebie, jak wielką / bezpiecznego-a produktem oni , że to jest - czyli małej liczbie oczu vs na ziemi pełne oczu.

Mam nadzieję, że to pomoże :)

• wyłącz logowanie roota
• wyłącz logowanie za pomocą hasła (zezwalaj tylko na logowanie za pomocą klucza publicznego)
• zmień port SSH

• użyj denyhosts (lub podobnego)

• napisz własny skrypt iptbles (więc dokładnie kontrolujesz, na co zezwalać i możesz upuścić wszystko inne)

• wymusić użycie bezpiecznej komunikacji SSL / TLS i upewnić się, że ma ważne, nie wygasłe i podpisane certyfikaty

• włącz ścisłą weryfikację certyfikatu dla wszystkich usług zewnętrznych (na przykład podczas uwierzytelniania użytkowników za pomocą serwera LDAP na innym komputerze)

Zacznij tutaj:

http://www.debian.org/doc/manuals/securing-debian-howto/

Jako ogólny punkt wyjścia kieruję się testem porównawczym / przewodnikami Centrum Bezpieczeństwa Internetowego , które są kompleksowymi kompilacjami najlepszych praktyk bezpieczeństwa. Nie wygląda na to, że ich test Debiana został zaktualizowany od jakiegoś czasu, ale ogólny przegląd tych kroków jest następujący:

• Zastosuj najnowsze poprawki / pakiety systemu operacyjnego
• Włącz rozliczanie systemowe / jądro / procesowe.
• Włącz MAC (np. SELinux lub AppArmor).
• Włącz zaporę hosta (iptables).
• Sprawdź źródła APT. Lista (klucze są poprawne, źródła są zaufane).
• Minimalizuj usługi sieciowe, wyłącz wszystko, co nie jest wymagane, i zaporę ogniową.
• Użyj TCPWrapperów, aby dodatkowo ograniczyć dostęp do systemu.
• Używaj tylko zaszyfrowanych protokołów sieciowych, wyłącz niezaszyfrowane usługi (telnet, ftp itp.).
• Skonfiguruj zdalny dostęp tylko do SSH.
• Wyłącz hasła logowania użytkownika i wymagają uwierzytelnienia na podstawie klucza.
• Wyłącz udostępnianie systemu plików (NFS, SMB).
• Włącz zdalne / scentralizowane rejestrowanie systemu (i regularnie przeglądaj dzienniki!).
• Ustaw hasło na poziomie BIOS / firmware.
• Ustaw hasło bootloadera.
• Skonfiguruj kopie zapasowe systemu, przygotuj plan odzyskiwania po awarii i TESTUJ, czy kopie zapasowe są prawidłowe i czy personel zna procedury odzyskiwania po awarii!

Istnieje wiele zasobów dotyczących wszystkich tych różnych ustawień, w tym konkretnych poleceń i plików konfiguracyjnych do wdrożenia w systemie w testach porównawczych CISecurity.

Sugeruję, aby nie podłączać komputera bezpośrednio do Internetu. Umieść zaporę ogniową między maszyną a Internetem. Pozwala to na monitorowanie bezpieczeństwa i sieci bez większego obciążenia serwera. Osobiście uważam, że segmentacja sieci i funkcji często upraszcza rozwiązywanie problemów z siecią, chociaż czasami dodatkowa złożoność utrudnia analizę.

Najbezpieczniejszym, ale najbardziej irytującym w zarządzaniu, zaporą ogniową jest odrzucanie wszystkich i jawne dopuszczanie tylko ruchu, na który musisz zezwolić. Jest to denerwujące, ponieważ często trzeba aktualizować zasady zapory sieciowej, gdy zmienia się sieć.

Sugerowałbym również użycie pewnego rodzaju zapory ogniowej interfejsu na serwerze - kluczem jest głęboka ochrona. Używanie niestandardowych portów do usług związanych z administracją nie szkodzi. fail2ban jest w porządku. Odpowiedz na bardziej szczegółowe pytania dotyczące aplikacji bezpieczeństwa w usłudze Serverfault, aby znaleźć więcej pomysłów.

Bezpieczeństwo jest jak żart o dwóch wędrowcach i niedźwiedzie - chociaż nigdy nie można osiągnąć doskonałego bezpieczeństwa, pomocne jest bycie trudniejszym celem niż pozostali faceci.

Niektórzy wskazywali na Podręcznik Zabezpieczania Debiana . Powinno to być całkowicie odpowiednie do wszystkiego oprócz wymagań wojskowych.

Wiele osób uważa, że ​​bycie śmiesznie paranoikiem jest fajne, profesjonalne lub coś w tym rodzaju. To nie jest po prostu denerwujące dla innych administratorów i wręcz represyjne dla użytkowników. Większość rzeczy, które zobaczysz polecane, to po prostu fałszywa praca, aby czuć się przydatna dla paranoicznego administratora, ale w rzeczywistości nie jest pomocna, ponieważ prawdziwe naruszenie bezpieczeństwa może być spowodowane niewystarczająco zaktualizowanym systemem i / lub ze źródła wewnętrznego.

To powiedziawszy, uważam to za jeden z moich założeń, aby nie ufać niczego w sieci lokalnej bardziej niż cokolwiek z Internetu. Dlatego wszystko konfiguruję tak, aby wymagało uwierzytelnienia nawet w sieci lokalnej. Szyfruję i uwierzytelniam cały ruch między każdym komputerem za pomocą protokołu IPsec.

Jestem w trakcie konwersji na szyfrowanie całego dysku dla wszystkich moich serwerów.

Instaluję tylko usługi, z których korzystam. Nie mam zapory ogniowej; Konfiguruję usługi, które muszę wymagać uwierzytelnienia, lub ograniczam je (poprzez własną konfigurację programu lub przez opakowania TCP) do określonych adresów IP. Jedyną rzeczą, którą kiedykolwiek potrzebowałem zablokować za pomocą iptables, było to memcached, że nie miał on pliku konfiguracyjnego i nie używał opakowań TCP.

Korzystam z dobrych, losowo generowanych haseł do moich kont i ufam mojemu serwerowi SSH (i wszystkim innym usługom), aby powstrzymać tych, którzy nie znają hasła. fail2banjest tylko dla tych, którzy mają ograniczone miejsce na pliki dziennika, IMO. (Powinieneś mieć wystarczająco dobre hasła, aby móc im zaufać).

Przejrzyj ten fajny poradnik na stronie www.debian.org/doc/manuals/securing-debian-howto/

Osobiście zmieniam port ssh i używam fail2ban + denyhosts. I blokuję wszystko, co nie jest potrzebne. Im więcej blokujesz, tym mniej musisz się martwić.