Linux iptables i SSH - zabezpieczenie serwera

[Fizyda 34]

Cześć, dziś kolejna część mojego męczenia Was na temat serwera. Dziś chciałem się dowiedzieć jak skonfigurować iptables by zabezpieczyć serwer.

 

Jak to w moim przypadku bywa przychodzę z pomysłem, bo w gości nie wypada przychodzić z pustymi rękoma i mam nadzieję że Archi poskromi moje paranoiczne myśli, ewentualnie przyzna im słuszność .

 

Dla osób które nie znają moich poprzednich tematów w których pytam jak coś zrobić napiszę na wstępie, że nie chcę wiedzieć jakimi komendami czy programem się co konfiguruje bo to wiem, ja pytam o aspekt praktyczny, czyli co jak się mniej więcej ustawia w praktyce.

 

W moim przypadku serwer będzie miał 2 adresy IP czyli jeśli dobrze rozumiem interfejsy. Serwer w OVH więc jedno IP będzie przydzielone na stałe, drugie dokupuję PL.

Jeśli dobrze wszystko rozumiem to mogę ustawiać iptables dla dwóch różnych interfejsów niezależnie.

 

Plan mam taki by domyślnie ustawić DROP dla INPUT i OUTPUT.

• Na eth0 (domyślny IP)
  • otworzyć tylko porty (dla mnie - admina) dla SSH. Na INPUT otwieram ten co ustawiam w sshd-config, a dla OUTPUT? Próbowałem ten sam, ale coś nie poszło, dziś domyślam się że może to być 22 (domyślny), ale nie mam siły tego dziś już sprawdzać
  • zezwolić na użycie komendy PING do serwera bym mógł sprawdzić czy maszyna żyje, może jeszcze by serwer mógł też pingować inne maszyny, może przydać się w przypadku sprawdzania czegoś - innego zastosowania nie widzę
• Na eth1 (Polski IP)
  • otworzyć porty dla usług takich jak DNS, WWW, FTP, Mail, TS3 - dla IN/OUT te same reguły, o ile można tak powiedzieć

Jeśli okazałoby się że pomimo 2 adresów IP mam jeden interfejs sieciowy to w tedy wszystko ustawiłbym na jednym. Mam nadzieję że tak nie będzie bo chciałbym to tak odseparować.

 

Powodem czemu tak to wymyśliłem jest jak mi się wydaje ukrycie tylko dla mnie prawdziwego adresu IP serwera, więc ktoś kto będzie chciał celowo włamać się na konkretnie mój serwer przy pomocy SSH będzie miał zadanie utrudnione bo zwyczajnie na tym adresie nie będzie możliwości zalogowania się na SSH.

 

Mam też kilka pytań w kwestiach których nie jestem pewny:

1. Tabela iptables FORWARD nie ma zastosowania w przypadków serwerów takich jak mój, ma zastosowanie tylko w przypadku routingu?
2. Nie ma sensu wyłączyć możliwości logowania po SSH przy pomocy login/hasło, bo w przypadku utraty klucza mamy utrudniony dostęp do serwera. Czy może po wygenerowaniu klucza warto wyłączyć taką możliwość?

[Gość Spoofy]

 

Cześć, dziś kolejna część mojego męczenia Was na temat serwera. Dziś chciałem się dowiedzieć jak skonfigurować iptables by zabezpieczyć serwer.

 

Jak to w moim przypadku bywa przychodzę z pomysłem, bo w gości nie wypada przychodzić z pustymi rękoma i mam nadzieję że Archi poskromi moje paranoiczne myśli, ewentualnie przyzna im słuszność .

 

Dla osób które nie znają moich poprzednich tematów w których pytam jak coś zrobić napiszę na wstępie, że nie chcę wiedzieć jakimi komendami czy programem się co konfiguruje bo to wiem, ja pytam o aspekt praktyczny, czyli co jak się mniej więcej ustawia w praktyce.

 

W moim przypadku serwer będzie miał 2 adresy IP czyli jeśli dobrze rozumiem interfejsy. Serwer w OVH więc jedno IP będzie przydzielone na stałe, drugie dokupuję PL.

Jeśli dobrze wszystko rozumiem to mogę ustawiać iptables dla dwóch różnych interfejsów niezależnie.

 

Plan mam taki by domyślnie ustawić DROP dla INPUT i OUTPUT.

• Na eth0 (domyślny IP)
  • otworzyć tylko porty (dla mnie - admina) dla SSH. Na INPUT otwieram ten co ustawiam w sshd-config, a dla OUTPUT? Próbowałem ten sam, ale coś nie poszło, dziś domyślam się że może to być 22 (domyślny), ale nie mam siły tego dziś już sprawdzać
  • zezwolić na użycie komendy PING do serwera bym mógł sprawdzić czy maszyna żyje, może jeszcze by serwer mógł też pingować inne maszyny, może przydać się w przypadku sprawdzania czegoś - innego zastosowania nie widzę
• Na eth1 (Polski IP)
  • otworzyć porty dla usług takich jak DNS, WWW, FTP, Mail, TS3 - dla IN/OUT te same reguły, o ile można tak powiedzieć

Jeśli okazałoby się że pomimo 2 adresów IP mam jeden interfejs sieciowy to w tedy wszystko ustawiłbym na jednym. Mam nadzieję że tak nie będzie bo chciałbym to tak odseparować.

 

Powodem czemu tak to wymyśliłem jest jak mi się wydaje ukrycie tylko dla mnie prawdziwego adresu IP serwera, więc ktoś kto będzie chciał celowo włamać się na konkretnie mój serwer przy pomocy SSH będzie miał zadanie utrudnione bo zwyczajnie na tym adresie nie będzie możliwości zalogowania się na SSH.

 

Mam też kilka pytań w kwestiach których nie jestem pewny:

1. Tabela iptables FORWARD nie ma zastosowania w przypadków serwerów takich jak mój, ma zastosowanie tylko w przypadku routingu?
2. Nie ma sensu wyłączyć możliwości logowania po SSH przy pomocy login/hasło, bo w przypadku utraty klucza mamy utrudniony dostęp do serwera. Czy może po wygenerowaniu klucza warto wyłączyć taką możliwość?

 

 

Witaj,

 

@Archi to swój człowiek, niemniej jednak postaram się przez tą wolną chwilę odpowiedzieć na Twoje pytania

 

Zacznijmy od tego że w iptables standardowe łańcuchy to INPUT, OUTPUT i FORWARD.

 

W skrócie (ogólnym bardzo ):

 

INPUT - wszystko co wchodzi

OUTPUT - wszystko co wychodzi

FORWARD - wszystko co ma być "przekazane"

 

Tip: Pamiętaj oczywiście że do tego dochodzą jeszcze kwestie "stanu" komunikacji - tzn. czy komunikacja jest nowa czy też nie i np. trzeba ją podtrzymać (stosując regułkę np. używając modułu state albo conntrack state ).

 

1 primo: iptables możesz ustawić per source (albo per destination) - tzn. wykonać *jakąś* czynność dla danej sieci, podsieci lub dla interfejsu - w Twoim przypadku fajnie byłoby rozróżnić eth0 i eth1 - ergo - podział jest jak najbardziej możliwy i zalecany

 

2 secundo: oczywiście możesz zezwolić na ping tylko dla danego adresu/interfejsu (jak wyżej) + pamiętaj o monitoringu OVH który również "pinguje" i wysyła ICMP na niestandardowe porty, sprawdzając czy serwer "żyje" - warto zastanowić się czy właśnie taki monitoring + alerty np. na mail'a nie są lepszym rozwiązaniem niż własny ping

 

3 trieto: Forward może mieć zastosowanie, lecz z tego co mówisz raczej tak nie bedzie. Łańcuchem Forward określasz zarówno source jak i destination, służy do forwardowania - czyli "przekazywania" pakietów z source do destination

 

Jeżeli zaś chodzi o samo bezpieczeństwo SSH, to punkt pierwszy to ochrona przed bruteforce'em - zwykły, najzwyklejszy fail2ban no i zmiana portu ze standardowego na inny (np. 2222) powinna załatwić sprawę. Jeżeli nie chcesz aby serwer łączył się z innym serwerem przez SSH to nie potrzebujesz regułki OUT. Zwykle każdy z nas tutaj ma swoje, sprawdzone metody i każdy powie co innego. Ja np. chowam wszystko za zewnętrznym VPN'em, z krótkim awaryjnym czasem dostępowym w trakcie restartowania serwera i nic więcej

 

Możesz np. polecieć dalej z tematem i np. zablokować kompletnie dostęp z innych krajów albo np. z krajów które Ciebie nie interesują z pomocą geoip i bazy maxmind. Możesz zezwolić tylko adresy swoich providerów - np. domowy internet + mobilny, lecz tego bym nie polecał.

 

Klucze jednak to temat rzeka. Raczej jak ktoś już je stosuje to trzyma je w bezpiecznym miejscu i raczej nie zakłada że je zgubi, ale można sobie wymyślić jakieś 100 znakowe hasło i zapisać gdzieś "na zaś".

Edytowano Marzec 29, 2016 przez Spoofy (zobacz historię edycji)

[Fizyda 34]

Dziś już trochę się bawiłem, ustawiłem IN i OUT na DROP odblokowałem na IN port który mam ustawiony na SSH (zmieniony) i nie dało rady się połączyć przez Putty z serwerem. odblokowałem ten sam port na OUT i było bez zmian. Więc chyba nie pójdzie SSH z dropem na in/out i otwarciem portu na IN.

 

Na razie nie chcę się bawić w takie ograniczenia jak geolokalizacja logoowania po SSH, na razie chcę uszczelnić serwer i zastosować podstawowe zabezpieczenia. Z bardziej wyrafinowanymi będę się bawił później , już i tak dostatecznie długo przeciągam wykupienie tego VPS i uruchomienie usług które potrzebne mi są od miesiąca . Tylko po prostu nie lubię robić czegoś po łebkach, dodatkowo mam na uwadze to, że jedna ze stron ma być adresowana do "specyficznej" grupy która szybko zweryfikuje podstawowe zabezpieczenia.

[Gość Spoofy]

Dziś już trochę się bawiłem, ustawiłem IN i OUT na DROP odblokowałem na IN port który mam ustawiony na SSH (zmieniony) i nie dało rady się połączyć przez Putty z serwerem. odblokowałem ten sam port na OUT i było bez zmian. Więc chyba nie pójdzie SSH z dropem na in/out i otwarciem portu na IN.

 

Na razie nie chcę się bawić w takie ograniczenia jak geolokalizacja logoowania po SSH, na razie chcę uszczelnić serwer i zastosować podstawowe zabezpieczenia. Z bardziej wyrafinowanymi będę się bawił później , już i tak dostatecznie długo przeciągam wykupienie tego VPS i uruchomienie usług które potrzebne mi są od miesiąca . Tylko po prostu nie lubię robić czegoś po łebkach, dodatkowo mam na uwadze to, że jedna ze stron ma być adresowana do "specyficznej" grupy która szybko zweryfikuje podstawowe zabezpieczenia.

 

Oh dio... dla takich "grup" niedzielnych hakierów bonzo to stosuje się honeypot'y, stawiając go na 22gim porcie + ew. detekcję skanowania portów i problem z głowy + później masz jeszcze awesome pokaz "umiejętności" takiego hakiera zapisany w postaci sesji

 

przykład:

Edytowano Marzec 29, 2016 przez Spoofy (zobacz historię edycji)

[Pan Kot 1535]

Zacznij od http://www.webhostingtalk.pl/topic/41538-security-na-debianie-fakty-i-mity-poradnik/ - trochę się już zestarzał, ale nadal żywy, może kiedyś znajdę chwilę, żeby to odświeżyć.

 

Nie polecam pisać wszystkich regułek iptables samemu, w tym celu można np. użyć CSF, który lepiej to wszystko przygotuje i się tym zajmie.

 

Oprócz definiowania otwartych portów warto też definiować jakiego stanu się spodziewamy. Przykładowo, pierwsza regułka jaka się powinna znaleźć w firewallu to zezwalanie na wszystkie połączenia TCP w stanie RELATED oraz ESTABLISHED. Jak masz taką regułkę, to możesz sprecyzować, że pakietów na porcie 22 (lub jakimkolwiek innym, jak już go zmienisz) spodziewasz się tylko w stanie SYN, z racji że wszystkie inne albo podpadają pod RELATED/ESTABLISHED, albo są nieautoryzowane (nieprawidłowe) i absolutnie nie chcemy tracić na nie więcej zasobów niż to wymagane.

 

Praktyczne porady? Są w linku wyżej. Najważniejsze - wyrzucić usługi, z których korzystasz na niestandardowe porty (zmiana 22 SSH to podstawa). Firewall ze wszystkimi trzema łańcuchami obowiązkowo na DROP + regułki, które jak najbardziej dokładnie precyzują jakiego ruchu się spodziewasz. Sama obsługa SSH to tak jak powiedziałem 2 regułki - SYNy input na konkretny port, i obsługa related/established.

[Fizyda 34]

Najważniejsze - wyrzucić usługi, z których korzystasz na niestandardowe porty (zmiana 22 SSH to podstawa).

 

Naprawdę wszystko? HTTP(S), FTP, DNS (chyba się nawet nie da), Mail ustawić na customowe porty? W takim wypadku będę musiał poustawiać rekordy SRV dla wszystkich domen, efekt będzie taki że informacje na jakich portach działają te usługi i tak będą dostępne publicznie, a tylko jest dodatkowa praca z SRV. Osobiście myślałem że tego typu usługi zostawia się na standardowych portach.

[Gość Spoofy]

 

Naprawdę wszystko? HTTP(S), FTP, DNS (chyba się nawet nie da), Mail ustawić na customowe porty? W takim wypadku będę musiał poustawiać rekordy SRV dla wszystkich domen, efekt będzie taki że informacje na jakich portach działają te usługi i tak będą dostępne publicznie, a tylko jest dodatkowa praca z SRV. Osobiście myślałem że tego typu usługi zostawia się na standardowych portach.

 

Nope, Archi miał na myśli żeby ograniczyć usługi do minimum - tylko tego z którego korzystasz

 

Raczej nie zmieniałbym portów do komunikacji mail'owej

[Pan Kot 1535]

 

Naprawdę wszystko? HTTP(S), FTP, DNS (chyba się nawet nie da), Mail ustawić na customowe porty? W takim wypadku będę musiał poustawiać rekordy SRV dla wszystkich domen, efekt będzie taki że informacje na jakich portach działają te usługi i tak będą dostępne publicznie, a tylko jest dodatkowa praca z SRV. Osobiście myślałem że tego typu usługi zostawia się na standardowych portach.

 

Oczywiście, że standardowe usługi, które muszą działać na standardowych portach takie jak HTTP, HTTPS, SMTP czy DNS trzeba zostawić, ale już takiego FTP niekoniecznie, chyba że chcesz zezwolić na logowanie anonimowe i potrzebujesz zrobić dostęp dla każdego.

[Bartosz Z 236]

Najważniejsze - wyrzucić usługi, z których korzystasz na niestandardowe porty (zmiana 22 SSH to podstawa).

Co to da? Niestandardowe porty stają się magicznie niedostępne dla robotów?

[Pan Kot 1535]

Co to da? Niestandardowe porty stają się magicznie niedostępne dla robotów?

 

Tak, csf jest w stanie bardzo łatwo wykrywać roboty, które na ślepo próbują się dostać do 22 i je wyciąć zanim narobią większych szkód.

 

Po co akceptować połączenia od robaków i tracić na nie CPU? Po co dawać im w ogóle możliwość komunikacji z sshd? Przecież można przesunąć SSH i tym samym dodać sobie jedną belkę bezpieczeństwa więcej.

[Fizyda 34]

Czytam, czytam i coraz bardziej załamany jestem. Wiem jedno nie jestem w chwili obecnej zastosować wszystkich rad z tematu Archiego dlatego na razie nie zajmuję się jajkiem bo nawet nie wiem czy na moim VPS będę miał taką możliwość. Poza tym nie czuję się w chwili obecnej na siłach na tyle doświadczony by to ogarnąć.

 

Nie bardzo rozumiem czym jest CSF, portsentry i fail2ban, jak to działa, czym to jest i jak tego używać? Początkowo myślałem że pierwsze dwa to tylko taka "nakładka" na iptables, ale teraz mam wrażenie jakby to były osobne firewalle. F2B myślałem że tylko dodaje do iptables adresy IP z których jest wykonanych X błędnych prób logowań po ssh. Po temacie który dał Archi już sam nie wiem .

 

Zainstalowałem portsentry i nic mi to nie zmieniło w iptables, niby zablokowałem TCP i UDP w configu, ale nie wiem jak ten program ma mi pomóc.

CSF jakoś w bardziej "widoczny" sposób działa bo zawalił nieźle iptables ... większość portów nawet nie wiem po co jest otwarta, jedyne co w sumie zmieniłem to w configu testing wyłączyłem. Plik konfiguracyjny jest naprawdę zacny.

 

EDIT:

Nic już z tego nie rozumiem, nagle (nic nie zrobiłem) zniknęły wpisy z iptables i dalej jest jak po instalacji systemu.

Edytowano Marzec 30, 2016 przez Fizyda (zobacz historię edycji)

[Fizyda 34]

Dobra jedna bestia poskromiona, CSF wygląda naprawdę ciekawie, ale ogrom możliwości konfiguracyjnych jest przytłaczający. Z początku nie chciał działać i współpracować.

 

Dla potomnych:

Problem z znikaniem (czyszczeniem) iptables był ze względu na włączoną opcję

TESTING

przez to po czasie ustawionym w TESTING_INTERVAL czyszczony był iptables i ustawiana polityka na ACCEPT.

 

Drugi problem jaki miałem to niedziałające blokowanie ICMP (ping) oraz otwierania zamykania portów, tutaj problem był w

LF_SPI = "1"

po ustawieniu na 0 mamy statyczny itables a nie dynamiczny i tracimy jakieś funkcjonalności powodem jest coś tam w krenelu a konkretnie to brak czegoś.

 

Pytanie czy jeśli ustawiam LF_SPI = "0" to jest sens korzystania z CSF, drugie pytanie to jak ustawiać w tym różne reguły dla różnych interfejsów. Jedyne co znalazłem to możliwość wybrania na jakich interfejsach ma działać, a nie widzę nigdzie np otworzenia portu 80 na eth0, a 22 na eth1.

 

PS. Nie mogłem edytować poprzedniego postu, może to i nawet lepiej trochę czasu minęło a dodatkowo poprzednie się trochę zdezaktualizował i sam sobie już odpowiadam na część pytań.

[Jarosław Szmańda 42]

Nie lepiej zmienić port SSH + logowanie tylko po kluczu?

[Miłosz 2311]

Nie lepiej zmienić port SSH

Nie zapomnij przełożyć zamka w drzwiach do domu 15 cm wyżej. Może włamywacz się nie zorientuje

[robson345 53]

Nie zapomnij przełożyć zamka w drzwiach do domu 15 cm wyżej. Może włamywacz się nie zorientuje

 

No właśnie się nie zorientuje bo większość to boty ustawione na zarzynanie standardowego portu.

[Pan Kot 1535]

Nie zapomnij przełożyć zamka w drzwiach do domu 15 cm wyżej. Może włamywacz się nie zorientuje

 

Jakby włamywacze działali tak jak robaki internetowe to świat byłby o wiele piękniejszy .

[Fizyda 34]

Nie wiem czy dobrze rozumiem konfigurację CSFa w przypadku różnych reguł dla kilku interfejsów.

 

1. w csf.conf ustawiam ogólne ustawienia całej usługi + wspólne dla wszystkich interfejsów reguły otwartych/zamkniętych portów

2. w csf.allow oraz csf.deny mogę ustalić reguły dla konkretnych adresów IP - które są przypisane do różnych interfejsów np.

tcp|out|d=22|d=11.22.33.44
tcp|in|d=22|d=11.22.33.44

ustawię tylko dla adresu 11.22.33.44 otwarty port 22?

 

Jeszcze tej konfiguracji nie testowałem w boju, ale z opisu w readme wynika że powinno to zadziałać. Pytanie jest czy robię to dobrze czy na około.

Kolejna sprawa to czy jest możliwość ustawienia tego dla interfejsu przez podanie jego nazwy czy tylko przez adres ip.