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:

• Jak trwoga to do "boga" cz. 1 - VirtualBox, Ubuntu, Bind9
• Jak trwoga to do „boga" cz. 2 - SSH, LAMP, Joomla
• Jak trwoga to do „boga" cz. 3 - LDAP, bash

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:

• Własny domowy serwer — zabezpieczenia SSH

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.

- 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 :) [youtube=https://www.youtube.com/watch?v=99sR7H0MMVw&t=2s]

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/sshd

auth required pam_google_authenticator.so

Wychodzimy zapisujemy i edytujemy konfigurację SSH.

 nano /etc/ssh/sshd_config

ChallengeResponseAuthentication yes

Restartujemy ssh

service ssh restart

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

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_secure

dodajemy informacje o naszej bibliotece:

auth required pam_google_authenticator.so

Oczywiś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 wpis

auth required pam_google_authenticator.so

dodajmy 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

- 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

[list]

[item]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.[/item] [item]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.[/item] [item]RhostsRSAAuthentication no -

The option RhostsRSAAuthentication specifies whether to try rhosts authentication in concert with RSA host authentication.[/item][item]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.[/item]

[item]UsePrivilegeSeparation yes -

Splits up server processes in an attempt to prevent privilege escalation exploits.[/item] [item]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.[/item] [item] 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.[/item] [item]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.[/item][/list]

Ż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&view=.... 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 4096

dodają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.pem

Dodawanie 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 restart

service 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

- 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

-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.

• http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/c...
• https://ubuntuforums.org/showthread.php?t=831372
• http://security.stackexchange.com/questions/22782/security-concerns-wi...
• http://doxfer.webmin.com/Webmin/Main_Page
• http://gsliwinski.strony.wi.ps.pl/j/index.php?option=com_content&view=...
• http://www.webmin.com/faq.html
• https://tecadmin.net/secure-ssh-connections-with-port-knocking-linux/
• https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netfilter/iptables
• https://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netfilter/iptables/dopa...