Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Jak trwoga to do „boga" cz. 4 — SSL, Webmin, Port Knocking, iptables, firewall, ssh, google-authenticator

Za nami już trzy serie "Jak trwoga to do "boga"". Przyjętych przez was, moim prywatnym zdaniem pozytywnie (jeżeli się mylę proszę o uświadomienie mnie w komentarzach :)). Wspominane poprzednie trzy części odnajdziecie tu:

Po komentarzach o braku poprawnego zabezpieczenia usług udostępnionych na tak skonfigurowanym środowisku, wpisy blogowe zostały wzbogacone o wpis o SSH i jego zabezpieczeniach. Materiał ten nie miał wyczerpać "na maksa" tematu zabezpieczeń, bo byłoby to niemożliwe, chociażby patrząc na tempo rozwijania się wszelakich rozwiązań w tym także rozwiązań hakerskich. Miał pokazać, że usługi często instalowane na domyślnych ustawieniach posiadają łatwe do obejścia podstawowe zabezpieczania a te trudniejsze pozostają w naszej kwestii do konfiguracji. Możecie zastanawiać się dlaczego tak jest ale odpowiedź jest prosta. Usługi, systemy czy oprogramowanie po instalacji ma po prostu działać a zabezpieczenia to już nie kwestia "po prostu" :).

Wpis można odnaleźć tu:

Wszystkich którzy jeszcze nie zapoznali się z moimi wpisami zachęcam do lektury, obejrzenia podpiętych materiałów video na YouTube i komentowania publikacji.

Wracając jednak do zaprezentowanych przeze mnie wpisów, nie byłbym sobą gdybym nie wrócił i nie uzupełnił wpisu o parę celnych uwag przekazanych przez czytelników.

Nie zrozumcie mnie źle:

Ciężko jest opisać każdą kwestię szczegółowo. Nie chciałbym by wpis był stawiany jako wzór lub złota praktyka. Za parę miesięcy czy lat gdy odnajdzie się jakaś luka będzie on nie aktualny. Należy też pamiętać, że "bezpieczeństwo" to nie aplikacja, którą zainstalujemy i będzie ok. To proces który ewoluuje z dnia na dzień... Czasami nawet szybciej.

We wpisach poruszając pewne kwestie, tylko o nich wspominając, zachęcam głębokie parte zwojów mózgowych w głowie czytelnika do podążenia w temacie. Rozumiem też obecne oczekiwania, które karmione ogólnym obrazem w filmach, mediach, gazetach, serialach o szybkich natychmiastowych przemianach i przychodzących z łatwością sukcesach, mogą wywoływać protest za formą odbiegającą od powszechnych tutoriali, które prowadza za rękę użytkownika krok po kroku. Postaram się połączyć oba te światy by wyjść na przeciw wszystkim a jednocześnie nie skazywać na głupią formułę kopiuj wklej.

Jeżeli dalej tu jesteś i nie zamknąłeś strony z tym artykułem to zapraszam ponownie do zabawy.

Powrót do przeszłości po dłuższej przerwie

Chciałbym by mój blog w jak największym stopniu był interaktywny, oczywiście na tyle na ile pozwala to portal dobre programy. Zatem dodatkowe odpowiedzi na wasze komentarze będę też umieszczał w przyszłych wpisach o podobnej tematyce. By przedstawić jej w czytelnej i klarownej formie.

Bardzo dobry wpis, dodam od siebie, że w (tak jak autor napisał) bardzo ważna jest częsta aktualizacja naszego serwera SSH. Ten protokół ze względu na swoją obecność w praktycznie każdym serwerze opartym na Linuxie, ma bardzo duże grono "fanów" szukających w nim podatności ;)

Dodatkowo lepsze niż hasło, jest uwierzytelnianie za pośrednictwem kluczy. Warto też podkreślić, że z pomocą Google Authenticator można zaimplementować (w dosyć łatwy sposób) uwierzytelnianie dwuetapowe w SSH ;)

PS. Usunąłbym termin "domowy" z tytułu. Generalnie rady tu zawarte w pewnym zakresie można zastosować także w warunkach produkcyjnych ;)

- Komentarz użytkownika | GBM

Uwierzytelnianie dwuetapowe

Dodatkowe zabezpieczenia serwera SSH możemy uzyskać poprzez wdrożenie weryfikacji dwuetapowej o czym wspominał użytkownik GBM. Firma Google wspiera nas niezbędnym oprogramowaniem, które będzie realizować to zadanie.

Logujemy się na użytkownika root albo bezpieczniej na użytkownika z uprawnieniami sudo i wydajemy polecenie, które zaktualizuje nam nasze pakiety, system i zainstaluje bibliotekę:

sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install -y libpam-google-authenticator

Jeżeli nie mamy tego modułu w liście dystrybucyjnej oprogramowania (w pakietach) do naszego systemu możemy zainstalować go ręcznie. Procedurę recznej instalacji i konfiguracji odnajdziemy pod tym linkiem na koncie GitHub.

Teraz najlepiej zalogować się na użytkownika dla, którego będziemy włączać autoryzacje dwuetapową i wydajemy polecenie:

google-authenticator

Nie potrzebujemy uprawnień root, czy podniesienia przez sudo do wydania tego polecenia.

Jeżeli użytkowników ma być więcej należy wykonać to polencie dla wszystkich, którzy będą z niej korzystać. Jak widać można też napisać prosty skrypt dodający użytkownika i jednocześnie tworzący weryfikacje dwuetapowa dla niego.

#!/bin/bash user_name="Deflaut" echo "Set You User Name: " read user_name user_name="$(echo -e "${user_name}" | tr -d '[:space:]' | tr '[:upper:]' '[:lower:]')" echo "User Name: "${user_name} adduser ${user_name} && google-authenticator --secret /home/$user_name/.google_authenticator && chown ${user_name}:${user_name} /home/${user_name}/.google_authenticator

Oczywiście skrypt ten jest bardzo prosty i nie odporny na bardziej wyrafinowane błędy złośliwych użytkowników przy wpisie.

Warto tutaj zaznaczyć, że gdy mamy aktywną weryfikacje użytkownika po protokole SSH za pomocą klucza/certyfikatu RSA to uwierzytelnianie ma pierwszeństwo i bez klucza nie zalogujemy się. Po pierwsze jak mamy ustawione logowanie za pomocą certyfikatu dla tego użytkownika nie będziemy proszeni o weryfikacje dwuetapową. Po drugie lepszym rozwiązaniem wydaje się zabezpieczenie innego konta, do którego będziemy się logować po przez przełączenie su (switch user) w PAM. Da nam to dodatkowe zabezpieczenie gdy nasz certyfikat zostanie skradziony i ktoś uzyska dostęp do systemu. Zostanie ograniczony do loginu do którego został przypisany certyfikat/klucz.

Zastosowanie dodatkowych zabezpieczeń to w postaci ograniczenia wydawanych komend na koncie, zamknięcie użytkownika w grupie non-root, odłączenie sudo. Przy przełączeniu na użytkownika z uprawnieniami root lub sudo, oprócz hasła wymagane będzie podanie jeszcze tokenu użytkownika z google authenticator.

Chyba, że znów będziemy mieli do czynienia z drugą "Brudną Krową" (ang. Dirty Cow) wtedy leżymy :)

Wracając do wydanego wcześniej polecenia w ramach, którego będą zadawane pewne pytania konfigurujące dwuetapowa weryfikację.

Do you want authentication tokens to be time-based (y/n)y

Tu decydujemy czy nasz token ma być zależny od czasu. Wymaga to od nas by token generowany w telefonie i weryfikowany przez skrypt na serwerze korzystał z tego samego czasu.

Do you want me to update your "/home/piotr/.google_authenticator" file (y/n)y

Pytanie o nadpisanie pliku .google_authenticator. W przypadku gdy wydajemy pierwszy raz komendę utworzy plik, drugi raz aktualizujemy nasz token.

Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y

Bardzo ważne pytanie, w którym decydujemy czy na jednym tokenie może zalogować się kilku użytkowników. Zabezpieczenie to chroni przed atakami man-in-the-middle.

By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) n

Jeżeli mamy problem z synchronizacja czasu możemy włączyć na serwerze by token był ważny dłużej niż 30 sekund.

If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y

Tu ustawiamy ograniczenie wyłapujące próbę ataku brute-force do trzech logowań w przeciągu 30 sekund.

Teraz musimy pobrać aplikację na nasz telefon. Znajdziemy ją w sklepie Google

Aplikacja jest dostępna w Sklepie Gogle na Android, i w AppStore na iPhone. Nazywa się Authenticator, pobieramy i instalujemy. Do aplikacji można wpisać kod ręcznie , lub przeskanowac QR code. Kod do wpisania ręcznego to:
**Your new secret key is: 4J7HMT2O2JUR2UMJ ** pierwsza linijka.
Potem można go podejrzeć w katalogu domowym

cat /home/piotr/.google_authenticator

Musimy dokonać zmian w pliku /etc/pam.d/sshd aby moc logować się po przez generowany token

nano /etc/pam.d/sshdauth required pam_google_authenticator.so

Wychodzimy zapisujemy i edytujemy konfigurację SSH.

nano /etc/ssh/sshd_config

ChallengeResponseAuthentication yesRestartujemy ssh service ssh restart

Warto zaznaczyć, że od teraz działa logowanie także po haśle dla danego użytkownika. Dlaczego?

Change to yes to enable challenge-response passwords (beware issues with some PAM modules and threads)

Stało się tak gdyż w pliku PAM /etc/pam.d/sshd są ładowane też inne moduły w tym moduł odpowiedzialny za logowanie się po loginie i haśle plus nasz wpis o google authenticator.
Tak dobrze się domyśliłeś, nasza maszyna po podaniu loginu i hasła będzie czekać na token. Warto zaznaczyć też, że przy użyciu klucza, tokena już nie podajemy.I od tej pory działa nam weryfikacja dwuetapowa.

Teraz aktywujmy weryfikacje dwuetapową dla sudo i przy przełączaniu użytkownika poleceniem su.

Wystarczy odszukać plik /etc/pam.d/common-auth otworzyć go np.: przez edytor nano i powyżej linii:auth [success=1 default=ignore] pam_unix.so nullok_securedodajemy informacje o naszej bibliotece:auth required pam_google_authenticator.soOczywiście na koniec plik zapisujemy.

Od teraz możemy się cieszyć logowaniem z weryfikacja dwuetapową do systemu w trybie graficznym jak i tekstowym.

Gdyby jednak pojawił się problem wpisauth required pam_google_authenticator.sododajmy w menadżerze logowania pam.d /etc/pam.d/lightdm

UWAGA

Jeżeli wpis o google authenticator podamy nad innymi modułami nasz kod 6 znakowy będziemy musieli podać przed podaniem hasła (jeżeli pod ładowanymi modułami po podaniu hasła) co przy prostych środowiskach graficznych może być nie jednoznaczne i komunikaty w graficznym interfejsie mogą być mylące.

Zachęcam też do zabawy z innymi modułami znajdującymi się w /etc/pam.d

Jest to dosyć dobra funkcjonalność na zwiększenia bezpieczeństwa naszej maszyny :) oczywiście przy właściwej konfiguracji.

Dodatkowe parametry sshd_config

Natrudzisz się człeku, a później wystarczy, że połączysz się gdzieś spoza zaufanej strefy/sieci ... i cały misterny plan w PiSdoo :D Problemem może być bezproblemowe przechwycenie sesji ssh, o czym autor chyba nie wspomniał, bo zapuścił poradnik jakich w sieci całe multum (przez co nie chciało mi się tego czytać kolejny któryś tam raz). Poza tym, kiepski wpis, bo nawet nie wyjaśnił po co i na co wyłączyć opcje, które zaserwował na końcu. Bezmyślne wyłączenie czasem niesie bardziej opłakane skutki, niż ich pozostawienie...
- komentarz użytkownika | Anonimowy

Dziękuję za opinię :) niech wpis blogowy broi się dalej. Pozwolę sobie przytoczyć oryginalne wpisy po angielsku, które można znaleźć choćby w dokumentacji systemu Debian

  • IgnoreRhosts yes -

    The option IgnoreRhosts specifies whether rhosts or shosts files should not be used in authentication. For security reasons it is recommended to no use rhosts or shosts files for authentication.

  • RhostsAuthentication no -

    The option RhostsAuthentication specifies whether sshd can try to use rhosts based authentication. Because rhosts authentication is insecure you shouldn't use this option.

  • RhostsRSAAuthentication no -

    The option RhostsRSAAuthentication specifies whether to try rhosts authentication in concert with RSA host authentication.

  • ServerKeyBits 1024 -

    The option ServerKeyBits specifies how many bits to use in the server key. These bits are used when the daemon starts to generate its RSA key.

  • UsePrivilegeSeparation yes -

    Splits up server processes in an attempt to prevent privilege escalation exploits.

  • StrictModes yes -

    The option StrictModes specifies whether ssh should check user's permissions in their home directory and rhosts files before accepting login. This option must always be set to yes because sometimes users may accidentally leave their directory or files world-writable.

  • X11Forwarding no -

    The option X11Forwarding specifies whether X11 forwarding should be enabled or not on this server. Since we setup a server without GUI installed on it, we can safely turn this option off.

  • AllowTcpForwarding no -

    TCP forwarding allows users to use SSH to set up a VPN which they can use to tunnel into a network. This could allow an attacker to circumvent network security measures like firewalls. SSH tunneling can be an extremely useful tool, but it is also a security risk, so it should be disabled unless it is explicitly required.

Żyję w 21 wieku (nie traktujcie tego jako zgryźliwość) ale wiedza pozyskiwaną z Google czy innej wyszukiwarki, też jest wiedzą cenną jeżeli umiemy wyłuskać ziarno od plewy. Dla przykładu oficjalna dokumentacja Debian.

Dodatkowo Anonimowy ma racje, łączenie się z nie zaufanej sieci lub przy wykorzystaniu z niezaufanej sieci/łącza można oczywiście narazić się na ataki typu Man-in-the-Middle. Jednak nie przypominam sobie bym namawiał wszystkich do wyłączenia mózgu przed przystąpieniem do czytania tego materiału.

Port Knocking

Pamiętacie może scenę z filmu "Leon zawodowiec", w której to młodziutka Natalii Portman podaje magiczną sekwencje grupie Antyterrorystycznej dzięki, której będzie mogła bezpiecznie wejść do mieszkania. Dokładnie tym samym jest Port Knocking dla twojego serwera. Tylko w naszym przypadku rolę zwisającego Jeana Reno pełni Linuksowy Firewall. Samo zmienienie domyślnego portu serwera SSH nie wystarczy. Hakerzy (crakerzy) mogą w łatwy sposób przeskanować nasz serwer w poszukiwaniu otwartego SSH na innym porcie. Przyjrzyjmy się jak skonfigurować Port Knocking. Instalujemy potrzebne pakiety.

sudo apt-get update && sudo apt-get upgrade -y sudo apt-get install openssh-server && sudo apt-get install knockd

Jeżeli nie mamy w systemie iptables to instalujemy go

sudo apt-get install iptables

Skonfigurujmy teraz nasz iptables:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Polecenie to tworzy nam regułę (-A) gdzie do tego łańcucha trafiają pakiety, które docelowo są odbierane przez komputer (INPUT i -j ACCEPT) dopasowane do modułu (-m) na podstawie stanu z mechanizmu conntract, (--ctstate) do aktualnego połączenia (ESTABLISHED,RELATED).

iptables -A INPUT -p tcp --destination-port 22 -j DROP

Polecenie to tworzy nam regułę (-A) gdzie do tego łańcucha trafiają pakiety, które docelowo są odrzucane przez komputer (INPUT i -j DROP) wykorzystujące protokół warstwy transportowej TCP (-p TCP) dopasowane do portu 22 (--destination-port 22).

Czyli bardziej po polsku odrzuca nowe połączenia do portu 22 a obecne podtrzymuje do czasu ich zakończenia :). Proste, prawda?

Zainstalujemy też pakiet, który będzie automatycznie ładował nasze reguły

sudo apt-get install iptables-persistent

I zapisujemy

iptables-save

Teraz konfiguracja odpowiedniej kombinacji puknięć :). Otwieramy plik /etc/knockd.conf i poszukujemy w nim sekcji [openSSH] i [closeSSH], które będą podobna do tej:

[openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn

Interpretację wpisu Command w obu sekcjach open and close pozostawię wam :) (mała podpowiedź iż /sbin/iptables i samo iptables z poprzedniego polecenia to to samo.

Dalej skorygujmy tylko zmienną seq_timeout na wartość 10, porty w sequence pozostawmy takie jak są, ewentualnie skorygujmy port ssh (22) w obu sekcjach.

Aktywujmy, edytując plik /etc/deflaut/knockd i w sekcji START_KNOCKD zero (0) zmieniamy na jeden (1) plik zapisujemy.

service knockd start

Sprawdzamy i otwieramy:

nmap -p 7000 SERVER-IP nmap -p 8000 SERVER-IP nmap -p 9000 SERVER-IP

Zamykamy :)

nmap -p 9000 SERVER-IP nmap -p 8000 SERVER-IP nmap -p 7000 SERVER-IP

Grafika ta powinna ułatwić Ci zobrazowanie tego co zrobiliśmy

Wracamy do ćwiczeń

Pozostała nam ostatnia seria zamykająca temat poruszany ze strony http://gsliwinski.strony.wi.ps.pl/j/index.php?option=com_content&v.... Zatem drogi czytelniku zapraszam Cię w ostatnią już podróż z serii.

SSL

W pierwszej kolejności generujemy 4096-bit długi klucz RSA dla naszego centrum (root CA) i zapisujemy go w pliku ca.key:

openssl genrsa -out ca.key 4096dodając opcję –des3 możemy klucz zabezpieczyć hasłem:

openssl genrsa –des3 -out ca.key 4096

Następnie tworzymy własny samodzielnie podpisany przez root CA certyfikat o nazwie ca.crt (konieczne będzie wprowadzenie identyfikacji naszej organizacji). –x509 używane jest dla certyfikatów z własnym podpisem (self-signed)

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Utworzyliśmy centrum certyfikacji. To centrum może podpisywać dowolne certyfikaty przyszłych klientów.
Generowanie certyfikatu usługi / klienta (np. dla Apache2 danego hosta)

Tworzymy klucz dla usługi (w tym przypadku q.pem):

openssl genrsa -out q.pem 1024

Kolejnym etapem jest generowanie żądania podpisu:

openssl req -new -key q.pem -out q.csr

Jako CA podpisujemy przygotowane żądanie i tworzymy q-cert.pem (podpis) z podpisem na 10 lat oraz generowanie numeru seryjnego dla wykonanego podpisu.

openssl x509 -req -in q.csr -out q-cert.pem -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial –days 3650

Otrzymany podpis sklejamy z generowanym kluczem w jeden plik zawierający certyfikat usługi i podpis CA tego certyfikatu.

cat q-cert.pem >> q.pemDodawanie PEM do usług
„Apache2”

Przykładowy plik z zawartością SSL dla usługi "/etc/apache2/sites-available/default-ssl"

Przykładowy plik z zawartością SSL "/etc/apache2/sites-available/default-ssl" po zmianach.

Po naniesieniu zmian należy:

Przekopiować plik wynikowy po operacji tworzenia certyfikatu "q.pem" do katalogu apache wskazanego w pliku konfiguracyjnym. W tym przypadku "/etc/apache2"cp q.pem /etc/apache2/

Włączyć moduł SSL dla usługi apache poleceniem:

a2enmod ssl

Włączyć strukturę dodatkową dla apache w drugim pliku konfiguracyjnym opisanym powyżej "default-ssl" poleceniem:

a2ensite default-ssl

Zrestartować usługę apache poleceniem:/etc/init.d/apache2 restartservice apache2 restart[/code]

Testowanie:
Połącz się przy pomocy przeglądarki z wykorzystaniem HTTPS do swojego serwera
https://IP_MASZYNY-WIRTUALNEJ
Jeżeli nie wystąpi błąd certyfikacji to powinny się wyświetlić podobne okienka z Twoimi informacjami jak poniżej

Należy potwierdzić wyjątek, lub podejrzeć sobie certyfikat

By podejrzeć szczegóły.

Choć jak widać certyfikat nie będzie zaufany ponieważ przeglądarka nie może go zweryfikować zapewnia on pewien poziom bezpieczeństwa w komunikacji z naszym serwerem po protokole HTTPS.

Oczywiście to tylko pewien krok w konfiguracji serwera apache i zabezpieczenia komunikacji i nie jest on zabiegiem który daje nam 100% pewności i bezpieczeństwa. I tak wiem że certyfikat można podrobić, podmienić itd, itd.

Webmin

ok, themamuth został(eś) moim ulubionym blogerem na tym portalu ;)

wartość merytoryczna wpisów przerasta o lata świetlne pozostałych blogerów "linuxowych".

wpis można ładnie rozszerzyć też o coś z webmin ;)

np. jak najlepiej zabezpieczyć SSH przez webmina:
http://www.webmin.com/

- komentarz użytkownika | NieGooglujMnie

Instalacja oprogramowania webmin też jest dosyć prosta. W pierwszej kolejności musimy pobrać najnowszy pakiet ze strony w postaci paczki .deb, przykładowe polecenie może wyglądać tak:

wget hhtp://prdownloads.sourceforge.net/webmin_1.801_all.deb

Po pobraniu paczki oprogramowania .deb możemy go zainstalować korzystając z narzędzia dpkg. Jest to oprogramowanie będące podstawową częscią systemu zarządzania pakietami dystrybucji systemu operacyjnego Dabian Gnu/Linux.

Aby zainstalować pakiet .deb należny wydać polecenie:

dpkg -i webmin_1.801_all.deb

instalujemy pakiet, w przypadku powstania błędu możemy zależności naprawić poleceniem:

apt-get install -f

dokończymy instalację wcześniejszego pakietu .deb
Po zakończeniu instalacji webmin będzie dostępny pod adresem https://adres_ip:10000/ otwieramy nasza przeglądarkę.

Logujemy się na naszego użytkownika dostępnego w systemie.
Dane do logowania są identyczne jak dane logowania do system. Pewnie zauważyliśmy, że otworzyliśmy kolejna drogę do naszego systemu, dlatego ważne jest by korzystać z protokołu https by nie przesyłać jawnym tekstem danych pozwalających zalogować się do systemu.

Oprogramowanie webmin w pierwszym kontakcie prezentuje się bardzo surowo, jednak możemy interfejs przełączyć na bardziej "modern"

Ale zapewne skoro dotrwałeś do tego miejsca drogi czytelniku na pewno nie interesuje Ci możliwość zmiany szaty graficznej w webmin.

Przejdźmy do sekcji networking w panelu umieszczonym z lewej strony w webmin i rozwińmy ją. Przejdźmy dalej w rozwijanych pozycjach do Linux Firewall.
Otworzy nam się w oknie głównym aplikacji webmin panel zarządzania Linux Firewall. Na początku jak możesz zobaczyć i przeczytać komunikat sekcja IPtables jest on jeszcze nie skonfiguriowany. Webmin może Ci w tym pomóc i utworzyć plik /etc/iptables.up.rules

Wybieramy w tym oknie Allow all traffic i klikamy przycisk Setup Firewall.
W kolejnym oknie po przeładowaniu tak naprawdę otrzymamy graficzne narzędzie, edytor do edycji pliku /etc/iptables.up.rules a tak naprawdę graficzny interfejs do zarządzania Linuksowym Firewall.

Będziemy mogli w nim tu skonfigurować patrząc od góry i idąc po kolei w dół zasady dla pakietów:

  • Przychodzących (INPUT)
  • Przekierowanych (FORWARD)
  • Wychodzący (OUTPUT)
Po przez skorzystanie z przycisku Add Rule. Poniżej wspomnianych trzech pozycji mamy przyciski dzięki, którym możemy zaakceptować ustawioną konfigurację, Zresetować do aktualnie działającej, aktywować firewall ze startem systemu oraz zresetować cała konfigurację do ustawień domyślnych. Oczywiście Firewall możemy edytować przez nasz terminal zaglądając do pliku wyżej wymienionego w oknie konfiguracja.

Dodajmy teraz naszą pierwszą rolę do sekcji INPUT. W Rule comment dodajmy nazwę/komentarz opisujący i identyfikujący nasza rolę. W Action to take zaznaczamy Drop, w Network protocol wskazujemy Equals i TCP. Na sam koniec w Destination TCP or UDP port ustawiamy Equals i Port(s) na 80. Na koniec klikamy w dolnej części Save.

Po przeładowaniu okna dostaniemy informacje o dokonanym wpisie, wystarczy zaakceptować konfigurację.
Co tak naprawdę udało nam się ustawić? Przyjrzyjmy się idąc od góry w ustawieniach reguły HTTP. Powiedzieliśmy naszemu iptables by odrzucał cały ruch "DROP" po protocole TCP "NETWORK PROTOCOL EQUALS TCP" przychodzący z dowolnego hosta, sieci i pytający o wewnętrzny port 80 w tym przypadku usługę apache i serwer www "DESTINATION TCP OR UDP PORT EQUALS PORT(S) 80. Spowoduje to w przypadku odpytania o serwer www na porcie 80 odrzucenia naszego połączenia.

Dla potwierdzenia, że iptables blokuje tylko ruch z serwera i do serwera wystarczy sprawdzić nasz www po protocole HTTPS(443).

Warto przećwiczyć wiele kombinacji w naszych rolach w iptables, a w przypadku zbytniego zamieszania można wszelkie zmiany usunąć ręcznie.

Ćwiczenie z Laboratorium 10 będziecie już pewnie w stanie wykonać samodzielnie. Oczywiście zachęcam do zabawy z firewall.

Porzućmy na chwile zaporę ogniową i przyjrzyjmy się ponownie naszemu SSH tylko teraz przez lupę zwaną webmin.

Czyż nie wygląda znajomo? Oczywiście, że tak dokładnie to opisywałem w poprzednim moim wpisie o SSH. A tutaj możemy to wszystko skonfigurować z poziomu interfejsu www.

Gdy aktywujemy opcje w User SSH Key Setup by klucz rsa był generowany przy tworzeniu nowego użytkownika zostanie ona automatycznie utworzony i przeniesiony do jego domowego katalogu.

Użytkownika też dodamy z poziomu webmina.

W ten sposób mamy dodatkowo zaliczone Ćwiczenie z Laboratorium 14

Na tym zakończymy zabawę z webmin w tym wpisie blogowym.

Samba

Oczywiście nie o taka sambę mi chodzi. Ale zabawa też będzie przednia. Spróbujmy uruchomić ja na naszej maszynie wirtualnej.

sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install samba

Po instalacji przechodzimy do pliku konfiguracji /etc/samba/smb.conf - otwieramy go w dowolnym edytorze. W wyżej wymienionym pliku na końcu tego pliku dodajemy sekcje konfiguracyjną, która może wyglądać podobnie do tego:

[udostepnionyfolder] comment = udostępniony Folder LAB 9 path = /samba/udostepnionyfolder browsable = yes writeable = yes guest ok = yes read only = no force user = nobody veto files = /*.ini/*.inf/

Zatem nim wytłumaczymy sobie co oznaczaja każde z tych wpisów stwórzmy katalogi i nadajmy uprawnienia.

mkdir -p /samba/udostepnionyfolder chown -R nobody:nogroup /samba/udostepnionyfolder chmod -R 0775 /samba/udostepnionyfolder

Wszelkie zmiany wprowadzamy poprzez restart usługi samba

/etc/init.d/samba restart

Teraz sprawdźmy nasze ustawienia. Udział SMB oczywiście jest dostępny pod adresem IP komputera, na którym zainstalowaliśmy naszą sambę. Nazwa udziału jest adekwatna do tego co wpisaliśmy w ustawieniach. A zatem sekcja [udostepnionyfolder] w pliku konfiguracyjnym jest jednocześnie nazwą naszego udziału jaka będzie widoczna na serwerze SMB.
Dalej zmienna PATH to nic innego jak ścieżka do katalogu który chcemy udostępnić.

Jak widzicie folder udostępniony możemy podejrzeć, czyli zajrzeć do jego zawartości i zobaczyć co tam się znajduje. Odpowiada za to zmienna BROWSABLE z wartością YES.
Serwer też nie wymaga od nas hasła ponieważ zastosowaliśmy zmienną GUEST OK z parametrem YES

Zobaczmy dodatkowo czy mamy możliwość tworzenia rożnego rodzaju plików. Zapewnia nam to zmienna WRITEABLE ustawiona na YES oraz zmienna READ ONLY z parametrem NO. Dodatkowo wymusiliśmy by uprawnienia miał użytkownik nobody dzięki zmiennej FORCE USER z parametrem nobody

Podejrzyjmy sobie teraz ten katalog na serwerze. Teraz możemy się zastanowić co z plikami z rozszerzeniem *.ini oraz *.inf. To też jest proste, zostały one zawetowane tzn, ukryte oraz nie mamy możliwości ich tworzenia.

Możemy sobie to prosto sprawdzić. Tym samym wykonaliśmy ćwiczenia z SAMBA.

PS. Zmierzyć się z własnymi koszmarami

I uważasz, że po tym artykule każdy sobie sam postawi serwer na linuxie? Dla większości osób problemem już będzie gdzie klepać komendy. Pisząc taki artykuł trzeba się zastanowić do kogo jest skierowany. Ktoś kto wiedzę gdzie to wszystko w klepać, nie potrzebuje tego artykułu. Słodzenie kolegów linuxowców, jaki to artykuł świetny jest oczywiście bezpodstawne.

ps. Nadal uważacie, ze linux jest prosty i dla każdego?

-Komentarz użytkownika | Anonimowego

Zainstalować serwer może każdy. Nieroztropny użytkownik nie zabezpieczony serwer udostępni publicznie. Serwer taki można sobie testować wewnątrz własnej sieci na wirtualnych maszynach lub nawet skorzystać z oprogramowania GNS3 i pokusić się o jakąś większa i bardziej skomplikowaną strukturę. Podzielenie się wiedza w żaden sposób mi chleba nie zabierze. Nawet jeżeli jacyś Janusze biznesu odszukają ten artykuł i na podstawie niego będą sprzedawać żywcem w 100% skopiowane rozwiązania to też nie stracę ani ja ani ty. Wręcz przeciwnie. Potem trzeba będzie załatać lub naprawić tak skompromitowane środowiska IT po włamaniach. Jednak przyznam ukryta w twym komentarzu racje, że ten wpis i przednie nie wyczerpują tematu w 100%.

Sam pingwin i jego używanie nie jest skomplikowane. Wymaga od nas często leniwych istot wniesienia w tą zabawę własnej inwencji twórczej. Co czasami jest trudne przy podawanym na tacy okienku :)

Na koniec tego wpisu i serii życzę wszystkim miłej lektury i zabawy.

PS2. "Boga"

Do wszystkich, którzy narzucili mi narcyzm lub inną megalomanie artykuł ten i poprzednie trzy części będzie ładnie wyszukiwany w Google... Jak trwoga to do "boga" :)

Bibliografia

Wpis testowany na najnowszej wersji Debian - przy lekkiej modyfikacji poleceń i lokalizacji plików konfiguracja na innych dystrybucjach powinna być analogiczna.

 

linux porady serwery

Komentarze

0 nowych
parranoya   9 #1 24.05.2017 19:50

Nigdy nie zrozumiem dlaczego ludziska dokładają jakieś dziwne rzeczy typu "knockd" do fenomenalnego i świetnie zrobionego openssh-server'a. Toż to nic innego jak robienie kolejnego wyłomu w ścianie.
Stawiam dolary przeciwko orzechom, że potencjalny cracker zabierze się za openssh na samym końcu. Webmin, Apache... tu można poszaleć.

zielony_morderca   6 #2 25.05.2017 01:56

A tak na marginesie zna ktos DOBRA ksiazke jak tworzyc iptables.

  #3 25.05.2017 08:37

@zielony_morderca: może to: Zapory sieciowe w systemie Linux. Kompendium wiedzy o nftables. Wydanie IV .

~MacG   5 #4 25.05.2017 09:26

Czyżby fan Leona? ;)

  #5 25.05.2017 12:17

"Materiał ten nie maił wyczerpać "na maksa" tematu zabezpieczeń, bo byłoby to nie możliwe, chociażby patrząc na tępo rozwijania się wszelakich rozwiązań w tym także rozwiązań hakerskich."

Jedno zdanie, trzy błędy a to dopiero początek artykułu.

1. "maił" - maić «zdobić coś zielonymi gałązkami, liśćmi, kwiatami»
2. "nie możliwe" - nie z przymiotnikami piszemy łącznie
3. "tępo" - tępy - «źle tnący lub słabo kłujący», «spłaszczony, ścięty», «świadczący o braku inteligencji lub o bierności», «odczuwany, słyszany niewyraźnie; też: męczący», «o niektórych zmysłach: osłabiony, pozbawiony ostrości», obraźl. «ograniczony umysłowo»

sr57be45   7 #6 25.05.2017 16:00

@themamuth
Port Knocking - Jest tu jakiś cwaniak? ;)
Schemat pkt 2.
Chyba nie ma opisu / odnośnika jak utworzyć rsa key dla dla konsoli/programy ftp.

Może oprócz tematów o bezpieczeństwie napisz coś jak szukać wycieków(oprócz optymalizacji) w VPS/serwer bo htop pokazuję mi niejednoznacznie mi co najbardziej może rosnąć w committed memory w logu munin.

@parranoya
Czy chodzi o to że można przechwycić "klucz" ? Jak wiesz jak jak zrobić to lepiej napisz choć tytuł/link/wskazówkę do przykładowego materiału ;)

Apache... tu można poszaleć. ech wszędzie Apache i po co człowiek wybierał Ngnix ;)

Autor edytował komentarz w dniu: 25.05.2017 16:04
themamuth   6 #7 25.05.2017 16:52

@Anonim (niezalogowany): poprawione :)

parranoya   9 #8 25.05.2017 18:03

@sr57be45: Chodzi o to żeby zmniejszać wektor ataku a nie powiększać przez podawanie kolejnych nasłuchujących programów. Openssh jest naprawdę dobrze "zrobiony" i nie trzeba nic dodawać? A jakiś knockd? Wystarczy jedna w nim luka i masz dostęp bezpośrednio do kernela (poprzez iptables).

sr57be45   7 #9 25.05.2017 19:05

@parranoya: "Openssh"

Czyli wystarczy https://www.youtube.com/watch?v=3NQp613llRA ? + w ustawieniach zmienić "coś" na autoryzacje tylko z kluczem ?

Ale zaraz po znalezieniu portu potrzebny jest też poprawny login wtedy po kilku próbach fail2ban nie zablokuje IP ?

parranoya   9 #10 25.05.2017 19:47

@sr57be45: Autoryzacja kluczem wystarczy w 100%.

tom90vPL   1 #11 25.05.2017 20:13

Nareszcie coś konretnego. Tego szukałem :). Tylko mam jedno pytanie, czy można zastosować podobne ustawienia w stosunku do innych protokołów ?

themamuth   6 #12 25.05.2017 20:16

@tom90vPL: Tak jak najbardziej. Przykład pokazałem na standardowych by łatwiej zobrazować problem. Niema ograniczeń.

  #13 25.05.2017 20:55

Pokazywanie użytkownikom aby ufać niezaufanym certyfikatom powinno być karalne :)
Czy słyszałeś o https://letsencrypt.org/ - darmowe certyfikaty i poprawnie rozpoznawane przez przeglądarkę.

Therion7777   1 #14 29.05.2017 08:52

@parranoya: Umówmy się, że blokowanie portu sshd i otwieranie go poprzez knockd tylko w sytacjach, kiedy połączenie ssh jest potrzebne jest o wiele większym zmniejszeniem wektora ataku niż pozostawienie portu sshd wiecznie otwartego.

I nie masz dostępu do kernela poprzez knockd. Skąd w ogóle taki pomysł?

parranoya   9 #15 29.05.2017 14:33

@Therion7777: Żeby knockd mógł otwierać i zamykać porty firewalla, musi działać z uprawnieniami roota. Przejmując roota bierzesz wszystko.

eskimosek   7 #16 30.05.2017 03:43

@sr57be45: Jak chodzi o ten klucz to wpisujesz ssh-keygen w konsoli i generuje.Pozniej uploadujesz na serwer ssh-copy-id user@domena i nastepnie możesz się logować za pomocą tylko klucza ssh user@domena bez podawania hasla.Dodatkowo można ustawić w sshd_config żeby logował tylko przy użyciu klucza: PermitRootLogin without-password .

@tom90vPL: Raczej da sie otworzyc i zamknąć dowolna usluge zależy co wpiszesz w iptables w configu.: jak wpiszesz rozne porty np.
iptables -A INPUT -p tcp -m multiport --dports 22,53,80,135,137,138,139 -j ACCEPT
to wtedy ten knock wywoła te regułkę w firewallu i otworzy te porty.

Ciekawy wpis,dobrze wiedzieć ze istnieje taki programik jak ten knock.Mozna tym włączać i wyłączać usługi sieciowe.Tylko gorzej jak sie zapomni tej sekwencji i sie zablokuje caly serwer.

Autor edytował komentarz w dniu: 30.05.2017 04:02
eskimosek   7 #17 30.05.2017 12:07

@zielony_morderca: Wez sobie jakis skrypt i przeanalizuj.W tych wpisach z bloga themamutha jest tez sporo wyjasnione jak to ogarniac.Najprosciej mozna to zrobic w taki sposob:
1. sprawdzasz jakie uslugi wymagaja odblokowanych portow

netstat -plunt | grep LISTEN | grep -v tcp6 | grep -v 127.0.0.1


2. piszesz skrypt ktory ,blokuje wszystkie polaczenia ,czyli blokujesz wszystko INPUT OUTPUT FORWARD:

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP


3. dodajesz cały ruch sieciowy w obrebie loobback bo inaczej moze byc problem z dzialaniem uslug i ich komunikacja.

$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

4. teraz serwer jest zablokowany z zewnatrz i od wewnatrz ,wiec musisz otworzyc porty ktore sa wymagane - napewno ssh - i te ktore wczesniej sprawdziles poleceniem netstat.

$IPTABLES -A INTPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
$IPTABLES-A OUTPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT

i analogicznie resztę potrzebnych

No i masz podstawowa konfiguracje.Reszte poczytaj jakies skrypty.Zasada dzialania wszystkich firewalli jest taka sama tylko skladnia jest rozna.I chodzi tylko zeby w miare ogarnac skladnie.Co do bardziej zaawansowanych to https://www.cyberciti.biz/faq/linux-web-server-firewall-tutorial/
https://www.cyberciti.biz/faq/rhel-fedorta-linux-iptables-firewall-configuration.../

moj skrypt ktory sobie napisalem jako cwiczenie z roznych innych skrypyow zainspirowany tym wpisem themamuta
http://frog.certik.pl/?p=6

Autor edytował komentarz w dniu: 31.05.2017 22:38
sr57be45   7 #18 07.06.2017 17:43

@eskimosek: Dzięki za rady musze kiedyś to ogarnąć :) aktualnie Filezilla daje komunikat "fzSftp started" czyli coś szyfrowanego ale to chyba tylko jest szyfrowany transfer a nie uwierzytelnianie przy logowaniu.

eskimosek   7 #19 07.06.2017 19:28

@sr57be45: Filizilla? a co ma do tego filezilla ,to jest klient FTP no i SFTP.

eskimosek   7 #21 10.06.2017 15:25

Co do FTP to dodałem opcje
modprobe nf_conntrack_ftp
i teraz wszystko ładnie działa.

Gratulacje!

znalezione maszynki:

Twój czas:

Ogól Naczelnego!
Znalazłeś(aś) 10 maszynek Wilkinson Sword
oraz ogoliłaś naszego naczelnego!
Przejdź do rankingu
Podpowiedź: Przyciśnij lewy przycisk myszki i poruszaj nią, aby ogolić brodę.