TRANSKRYPCJA VIDEO
Pasja informatyki
Ubuntu Server #6: Apache2 + szyfrowany FTP
Opis wygenerowany przez Skrybot
W filmie Mirka prezentowana jest konfiguracja serwera www na Linuksie dla web-deweloperów, sponsorowana przez NordVPN. Konfiguracja serwera FTP z VSFTPD została omówiona, począwszy od zmiany protokołu na FTP bez szyfrowania, aż do implementacji szyfrowania SSL/TLS. Serwer FTP używa certyfikatu samopodpisanego, co powoduje ostrzeżenia klienta FTP. Planowane jest omówienie połączenia witryny z DNS-em oraz szyfrowania strony z własnymi certyfikatami.
Transkrypcja wygenerowana przez Skrybot
Całkiem niedawno na naszym kanale pojawiło się wideo autorstwa Mirka, który w swoim genialnym stylu przedstawił konfigurację serwera www na desktopowej wersji Linucha dla web-deweloperów. Niniejsze wideo nie będzie kontynuacją tamtego odcinka. Nie będzie również powielać treści poruszanych przez Mirka. Będzie to po prostu inne spojrzenie na temat konfiguracji serwera. Nie pod kątem dewelopera, który tworzy treści i chce je na swoim setupie przetestować, ale bardziej pod kątem admina, który musi przygotować serwer pod obsługę wielu użytkowników. Dla Ciebie Mirek oczywiście wielkie pozdro, a my przechodzimy do zasadniczej części odcinka. Chociaż chwila, prawie zapomniałem o naszym sponsorze. Niniejsze wideo ponownie zasponsorowała dla nas firma NordVPN, za co serdecznie dziękujemy. VPN to jak już pewnie doskonale wiecie, usługa tworząca dla nas w internecie bezpieczny, szyfrowany tunel chroniący naszą tożsamość, pozwalająca dodatkowo na łatwą zmianę lokalizacji z jakiej łączymy się z netem.
Sponsor odcinka, firma NordVPN to potentat na tym rynku. Z ich usług korzysta obecnie grubo ponad 14 milionów użytkowników na całym świecie, obsługiwanych przez tysiące serwerów Norda. Aktywność sieciowa w ramach usługi nie jest w żaden sposób archiwizowana, a korzystanie z niej umożliwia łatwa w użyciu, dostępna na wielu systemach aplikacja. Na jednym koncie można ustanowić aż do sześciu jednoczesnych tunelowanych połączeń. Jeśli ktoś z Was byłby zainteresowanym posiadaniem VPN-a, to firma przygotowała specjalnie dla widzów naszego kanału kod promocyjny. Wystarczy udać się pod adres nordvpn. com prawy slash pasja informatyki. Otrzymacie wówczas zniżkę na dwuletni plan no i dodatkowo dzięki promocji pierwszy miesiąc gratis. Nasz kod promocyjny do koszyka to słowo pasja informatyki pisane razem. Link znajdziecie oczywiście w opisie i zapewne gdzieś w podpiętym na dole komentarzu.
Firmie NordVPN dziękujemy za wsparcie kolejnej produkcji, a my zaczynamy już zabawę z serwerem webowym. Na początek wykonajmy aktualizację listy pakietów w repozytoriach. Ja zawsze taki update polecam wykonać przed właściwą instalacją wybranego softu. Ok, gotowe. Możemy zacząć już instalację serwera. Ja dzisiaj pójdę na łatwiznę i zainstaluję wszystko naraz, czyli serwer webowy, interpreter języka PHP, a także serwer bazodanowy. W systemach opartych na jądrze Linux dostępna jest apka Taskcell, która jest można powiedzieć katalogiem oprogramowania usług serwerowych, I to właśnie ten TaskCell pozwala na instalację serwera webowego wraz z niezbędnym softem bez potrzeby zaciągania każdego pakietu z osobna. Zainstalujmy sobie zatem tego TaskCella za pomocą znanego już Wam dobrze polecenia sudo apt install z dopiskiem TaskCell. Ok, soft zainstalowany, uruchommy go sobie zatem na prawach sudo. Taskcell pozwala wybrać oprogramowanie dla naszego serwera, a następnie sam pobierze potrzebne pakiety.
Spacją zaznaczamy serwer LAMP, czyli skrót od Linux, Apache, MySQL oraz PHP, a enterem rozpoczynamy pracę instalatora. Instalacja chwilę trwa, trochę tych pakietów jest do pobrania, ale dzięki magii postprodukcji jesteśmy już gotowi do pracy. Zanim przetestujemy czy serwer działa poprawnie, no to musimy go uruchomić, no bo jak widzicie po instalacji usługa nie uruchomiła się automatycznie. Zmieniamy w poleceniu status na start. No i teraz weryfikujemy. Jak widzimy serwer wstał i jest gotowy na przyjmowanie żądań. Zobaczmy na kliencie czy tak faktycznie jest. Sieć na wirtualnych maszynach jest skonfigurowana dokładnie tak samo jak było to w poprzednich odcinkach. Tak więc serwer działa na lokalnym adresie 10. 0. 0. 1. Podajemy jego IP w polu adresu. No i jest. Wyświetla nam się strona startowa serwera Apache, a to znaczy, że wszystko gra.
Domyślnie serwer Apache skonfigurowany jest tak, że odczytuje pliki stron z lokalizacji podanej tutaj. Naszym pierwszym zadaniem będzie zatem uruchomienie na serwerze modułu, który pozwoli odczytywać zawartości katalogów domowych użytkowników, a dzięki temu każdy użytkownik serwera będzie miał swoją, niedostępną dla innych użytkowników przestrzeń, w której będzie zapisywał pliki swoich witryn. To pozwoli na hostowanie wielu witryn wielu użytkownikom jednocześnie. Polecenie, które uruchomi ten moduł zaczynamy oczywiście od sudo. a dalej A2, czyli skrót od Apache 2. Następnie skrót od słowa enable. A dalej MOD czyli skrót od słowa MODUŁ. Zapamiętajcie, A2 Enable MOD piszemy łącznie, a zadaniem tego polecenia jest uruchomienie odpowiedniego modułu serwera Apache. Na koniec wydajemy po spacji nazwę tego modułu czyli USERDIR. Pisane oczywiście łącznie. Każdy aktywowany moduł wymaga restartu serwera, tutaj podane jest nawet polecenie, które taki restart wykona. Gotowe.
Moduł USERDIR skonfigurowany jest tak, aby przy żądaniu HTTP odczytywać zawartość katalogu domowego użytkownika, a dokładniej zawartość katalogu public. html znajdującego się w home'ie. To oczywiście można zmienić, to znaczy można skonfigurować jakąś inną lokalizację dla modułu user. dir, ale nazwa katalogu public. html już od wielu lat jest stosowana w świecie hostingu i dobrze się przyjęła. Nie widzę zatem powodu, aby tutaj kombinować. Jedyne co zatem teraz musimy zrobić, to w katalogu domowym użytkownika utworzyć katalog o właśnie takiej nazwie. Maszyna, na której dzisiaj pracuję jest czysta, to znaczy nie ma na niej, poza moim oczywiście, innego konta użytkownika, zatem na potrzeby testów utworzymy sobie dwóch mańków. Ale tutaj mała uwaga. Konta użytkowników, które zaraz utworzymy, będą nieco niekonwencjonalne. Można powiedzieć, że pozbawione cojones, czyli takie wykastrowane.
Dlaczego? Dlatego, że za pomocą tych kont nie będzie można logować się do systemu np. po SSH, a służyć one będą jedynie do obsługi usług serwera webowego oraz transferu plików. Konta użytkowników usług hostingowych zazwyczaj są tak właśnie skonfigurowane, aby można było się logować tylko do usług webowych, a nie do całego serwera, no chyba, że Wy kupujecie całego VPS-a dla siebie, no to wtedy jest inna rozmowa. My tutaj jednak skupiamy się na konfiguracji serwera webowego i u nas użytkownicy do samego systemu logować się nie będą mogli. Tworzenie takiego konta zaczynamy tradycyjnie od polecenia sudo, no a potem add user. Teraz natomiast z podwójnym myślnikiem ustawimy opcję shell. A dalej ścieżkę do pliku no login. Na koniec nazwa użytkownika.
Użycie opcji shell definiującej powłokę użytkownika z parametrem ścieżki do pliku no login spowoduje, iż taki użytkownik nie będzie mógł logować się do systemu z wykorzystaniem powłoki, ale będzie za to mógł używać serwera www czy zdalnie logować się do swojego katalogu domowego. Ok, maniek number one gotowy, no to teraz jeszcze drugi. Też gotowe. Oba mańki zwarte i przygotowane do pracy. No w sumie to prawie, bo teraz musimy utworzyć w ich home'ach po katalogu public. html. Najpierw pierwszy maniek, no a teraz drugi. Okej, na koniec jeszcze przenieśmy własność katalogów public. html na mańków, no bo skoro utworzyliśmy katalogi z wykorzystaniem sudo, no to root jest ich właścicielem, a tak nie powinno być. Wydajemy zatem polecenie sudo chown nazwa grupy, Dwukropek, nazwa użytkownika, no a potem ścieżka do katalogu public. html.
Jeszcze drugi maniek i gotowe. Dla tych co nie ogarnęli poprzednich filmów i są zdziwieni dlaczego dwa razy napisałem nazwę użytkownika, to wyjaśnię szybko, że każdy użytkownik systemu ma też przepisaną grupę o takiej samej nazwie jak nazwa użytkownika. Zatem przenosząc własność na mańka jako użytkownika, musimy również przenieść własność na jego grupę, stąd nazwa maniek1 i maniek2 pojawiły się dwa razy. Okej, wszystko już prawie gotowe do testów, ale brakuje nam jeszcze jakiejś treści, to znaczy plików stron w katalogu public. html, które pozwolą nam serwer przetestować. Najłatwiej myślę, będzie takie pliki sobie stworzyć, korzystając z przekierowania strumienia danych, czyli polecenia cat. To polecenie omówiliśmy w trzecim odcinku serii. Cat, przypomnę tylko krótko, pozwala odczytywać zawartość plików, ale również pozwala przekierować do nich strumienie danych, np. jakiś tekst czy jakieś inne dane pochodzące z innych poleceń.
My skorzystamy teraz z funkcjonalności polecenia cat i przekierowania strumienia danych do tego, aby dodać tekst hello maniek do pliku o nazwie index. php. Zaczynamy od sudo, potem polecenie cat, znak większości oznaczający przekierowanie strumienia danych, a dalej ścieżka do katalogu public. html, no i na koniec jeszcze nazwa pliku z rozszerzeniem. Cut działa tak, że jeśli podany w lokalizacji plik nie istnieje, no to go utworzy, tak więc nie trzeba tego robić wcześniej. A dlaczego PHP, a nie HTML na przykład? No dlatego, że w następnej kolejności będziemy testować czy działa interpreter języka PHP, dlatego takie właśnie rozszerzenie nam się przyda. Okej, próbujemy. Ups, chyba brak uprawnień, dokładnie, tak więc zróbmy to z poziomu ruta. Tylko tym razem oczywiście bez suda. No, teraz jest ok.
Po wykonaniu komendy możemy już zapisać tekst, który trafi do pliku podanego w poleceniu. Niech to będzie hellomaniek1. Teraz Enter. i skrót klawiszowy Ctrl D, który zakończy zapis do pliku. Dokładnie to samo robimy dla Mańka drugiego. Gotowe. Rzecz jasna, te pliki mogliśmy utworzyć sobie tradycyjnie i zapisać do nich tekst za pomocą klasycznego edytora, ale nie ma co zawsze iść utartą drogą. Życie trzeba sobie urozmaicać. Czas moi drodzy na testy. Przeskakujemy sobie ponownie do klienta, a w polu adresowym przeglądarki po adresie IP dodajemy slasha, A teraz znak tyldy. Ten znak znajduje się pod klawiszem zlokalizowanym po lewej stronie jedynki na klawiaturze. Trzeba go wcisnąć z shiftem i to dwukrotnie, bo za pierwszym razem nie wskakuje. A kiedy znak nam się zdubluje, jedną tyldę usuwamy, a dalej podajemy nazwę użytkownika.
Jest! Strona działa! Zobaczmy jeszcze drugiego mańka. No i też mamy pełen sukces. Zastanawiacie się pewnie czemu zapis w polu adresu jest taki dziwny i czy da się to łatwiej ogarnąć. Oczywiście, że się da. Istnieje w Apache taka funkcjonalność, która nazywa się WirtualneHosty i ona w połączeniu z DNSem pozwala to uprościć stosując domenowe nazwy dla witryn. Temat DNSa na Linuxie odłożymy sobie jednak na kolejne spotkanie i wówczas pokażemy jak to ogarnąć. Teraz natomiast przejdziemy do kolejnego etapu konfiguracji serwera webowego i uruchomimy na nim interpreter języka PHP dla użytkowników. W tym miejscu, moi drodzy, warto jeszcze zaznaczyć, iż podczas instalacji PHP przez TaskSela pobiera on tylko niezbędne paczki do pracy. Widzicie je właśnie na ekranie. Jeśli jakiejś paczki Wam brakuje, łatwo możecie takową doinstalować.
Z tym sobie sami poradzicie bez spiny, natomiast istnieje inny problem, który teraz musimy rozwiązać. Interpreter języka PHP na Ubuntu domyślnie działa tylko dla lokalizacji, którą serwer tworzy po instalacji oprogramowania Apache, dla tej startowej. Jeśli chcemy, aby działał również z modułem UserDir, no to musimy to ustawić. Zobaczmy, czy tak faktycznie jest. Do pliku jednego z użytkowników dodamy sobie funkcję PHP, której zadaniem będzie wyświetlenie informacji na temat wersji interpretera PHP i serwera Apache. Ponownie wydajemy polecenie cat z pojedynczym strumieniem danych oraz lokalizację do pliku index. php. Tak dla przypomnienia, to dodam tylko, że pojedynczy strumień powoduje nadpisanie danych w pliku, które już tam są. Dla nas to nie problem, już tego hello mańka tam nie potrzebujemy, ale wolę uprzedzić, aby potem nie było zdziwienia. Ok, zapiszmy sobie teraz tutaj mały skrypt PHP.
Takim zapisem go otwieramy, a potem będzie funkcja phpinfo, zakończona nawiasami i średnikiem, no a po spacji zamykamy skrypt. Teraz Enter, Ctrl D, no i wracamy do klienta. Zmieniamy w polu adresu nazwę użytkownika, i co, i nic. Nic nam się nie wyświetla, a to znaczy, że interpretowanie skryptów PHP jest wyłączone i musimy je uruchomić. Wracamy do serwera, no i edytujemy plik php 7. 2. conf. Jesteśmy na root'cie teraz, więc już bez sudo. Plik znajduje się w katalogu etc, apache2, a dalej mods. available. I tutaj uwaga, jeśli macie inną wersję Ubuntu, ja przypominam nadal pracuję na wersji 18. 04, to będziecie również posiadać inną wersję PHP. Tak więc i ten plik może mieć nieco inną nazwę. Pamiętajcie o tym.
W tym pliku, w dolnej części, zmieniamy w sekcji Engine Off na On. No i to nam załatwia sprawę. Zapisujemy zmiany w pliku. No i oczywiście nie zaszkodzi restart całego serwera Apache. Okej, wróćmy do klienta i coś potestujmy. Ha, teraz działa. Tabela z informacjami odnośnie interpretera PHP, a także ustawień serwera wyświetla się. A to znaczy, że skrypty PHP. . . interpretowane są poprawnie. Zatrzymajmy się teraz na chwilę przy wersji interpretera PHP, bo jeśli ktoś z Was oglądał film od Mirka lub instaluje własny serwer, to może się nieco zdziwić, dlaczego ja mam wersję 7. 2 pomimo wcześniejszego wykonania aktualizacji repozytoriów. Czy to nie powinno być tak, że po aktualizacji wszystkich repozytoriów PHP powinien być w najnowszej wersji? No w teorii tak, ale w praktyce na Ubuntu to tak nie działa.
Każde wydanie dystrybucji ma powiedzmy przypisaną swoją wersję interpretera PHP. Ja mam 7. 2 dla wydania 1804 Ubuntu, Mirek miał u siebie PHP w wersji 7. 4 dla wydania Ubuntu o numerze 2010, o ile pamiętam. Jaka wersja PHP zainstalowana jest na serwerze? Sprawdzimy za pomocą wykorzystanego wcześniej już polecenia, czyli dpkg, dwa myślniki, get myślnik selection, pionowa kreska, grep php. Jeżeli na swoich serwerach chcecie mieć zawsze najnowszą wersję, teraz chyba śmiga ósemka, jeżeli się nie mylę, no to należy po pierwsze dodać odpowiedni wpis do repozytoriów takim poleceniem. Jeśli trzeba, no to oczywiście potwierdzamy jeszcze raz enterem. Gotowe. Teraz musimy zaktualizować sobie listę repozytoriów. No i już na koniec zainstalować odpowiednią wersję. Coś tu nie pykło? No to powtarzamy. Ok, teraz wszystko gotowe.
Najnowsza wersja PHP jest już na naszym pokładzie, ale pamiętajmy, że aby móc z niej korzystać, trzeba ją również uruchomić. Robimy to takim samym poleceniem, którym uruchamialiśmy userdir, czyli a2, enable mod, no i dalej php 8. 0, enter. Teraz wyłączamy PHP w wersji 7. 0, wydając polecenie a2, this, this jako disable rzecz jasna, a dalej mod. PHP 7. 2. Wszystko to robiłem na rucie, więc bez sudo. Jeżeli wy robicie to już na poziomie swojego konta, pamiętajcie o tym sudo zawsze. Teraz zgodnie z sugestią restart serwera, no i to już prawie wszystko gotowe. Prawie. Zainstalowanie nowej wersji PHP nie nadpisuje poprzedniej, tylko stawia ją niejako obok. Dlatego też do pełni szczęścia musimy jeszcze włączyć silnik dla tej nowej wersji dla użytkowników. To już dzisiaj robiliśmy, ale dla wersji 7. 2.
Teraz musimy to zrobić dla wersji 8. 0. Edytujemy sobie plik, który siedzi w etc, dalej Apache 2, potem modes available, no i na koniec już php 8. 0. conf. W tym samym miejscu zmieniamy off na on, zapisujemy zmiany, no i restartujemy serwer. Wróćmy na chwilę do klienta celem przetestowania zmian. Odświeżamy stronę i mamy już nową wersję. Oczywiście nie należy usuwać tej poprzedniej, bo może okazać się, że kiedyś jeszcze się przyda, a z jej ponownym uruchomieniem nie będziecie już mieć żadnego problemu. Idziemy dalej. Musimy teraz skonfigurować możliwość zdalnego łączenia się z serwerem baz danych, czyli z naszym MySQL. Domyślnie serwer bazodanowy skonfigurowany jest w taki sposób, aby odrzucał połączenia, które przychodzą spoza localhosta, no i musimy temu zaradzić. Plik konfiguracyjny MySQL, który musimy sobie wyedytować, siedzi w etc, dalej mysql, potem mysql. conf.
d, ale beznadziejna nazwa, no a sam plik to mysqld. cnf. W linii 43 tego pliku znajduje się opcja bind address, którą musimy zakomentować, bo to właśnie przez nią na razie można łączyć się z serwerem tylko za pomocą localhosta. Ok, zapisujemy zmiany. Zamykamy plik, no i oczywiście restart usługi MySQL. Abyśmy mogli zweryfikować, czy faktycznie można teraz zdalnie łączyć się z serwerem bazodanowym z poziomu innego niż serwer kompa, należy teraz na ten serwer MySQL z wykorzystaniem konta root się zalogować i tam utworzyć konto nowego użytkownika. Będąc na koncie root, tak jak teraz, wydajemy tylko polecenie MySQL i tym samym przeskakujemy do usługi bazodanowej. Dzięki temu. . . że RUT korzysta z systemowego uwierzytelniania, nie musiałem teraz podawać żadnych danych logowania. Ok, słuchajcie, teraz musimy wykonać polecenie, które utworzy nam użytkownika w usłudze MySQL.
Użyjemy do tego takiego polecenia. GRANT ALL PRIVILEGES ON gwiazdka, kropka, gwiazdka. To oznacza nadanie pełnych praw do wszystkich baz i do wszystkich tablic we wszystkich bazach. Docelowo. . . użytkownik powinien mieć dostęp tylko do swojej bazy, ale powiedzmy, że ten to taki superuser, który ma pełnię praw. No a poza tym tworzymy go tylko i wyłącznie do testów. Dalej zapisujemy to, a po tym słowie i w apostrofie podajemy nazwę użytkownika. No, niech będzie taka. Zamykamy apostrof, potem małpa i w kolejnym apostrofie określamy zasięg naszego użytkownika. Jeśli wpiszemy localhost, no to będzie to użytkownik lokalny, czyli taki, który może łączyć się tylko z tego samego kompa co serwer, a my chcemy, aby użytkownik mógł łączyć się z MySQL z dowolnej lokalizacji i dowolnej maszyny.
Możemy zatem zapisać tutaj procent, co jest ekwiwalentem każdego adresu IP. Zamykamy apostrof, no i na koniec jeszcze hasło. Gotowe. Ok, słuchajcie, trzeba by to jakoś przetestować. Ja proponuję wykorzystać domyślny skrypt PHP do łączenia się z bazą, no i zapisać go na koncie pierwszego mańka. Opuszczamy sobie zatem MySQLa, No i edytujemy mańkowy plik index. php. Wyrzucamy zawartość. No i wklejamy skrypt. To jest gotowiec pobrany z neta. Pozmieniałem w nim tylko wartości zmiennych. Zapisujemy zmiany. No i sprawdzamy czy wszystko działa. Hmm, coś jest chyba nie tak. Nie odczytuje nam skryptu nawet, nie mówiąc już o poprawnym jego wykonaniu. Chyba wiem co może być nie tak. Zobaczcie, to są nasze wszystkie pakiety PHP. Przy wersji 7. 2 mamy rozszerzenie PHP MySQL, ale przy 8. 0 już nie.
Zatem musimy doinstalować pakiet, no bo bez tego łączenie z bazą będzie niemożliwe. Po instalacji pakietu restart usługi MySQL, no i oczywiście całego Apache'a. OK, wracamy do klienta na testy. Odświeżamy stronę i jest. Mamy połączenie z bazą. Super! Jak zainstalować i skonfigurować do roboty PHP MyAdmina nie będę już pokazywał. Wszystko dokładnie omówił Mirek w swoim wideo. Jeśli szukacie zatem informacji o tym, jak taką nakładkę graficzną na serwer MySQL zainstalować, odsyłam do jego wideo. My natomiast przejdziemy do ostatniej części dzisiejszego wideo, a mianowicie umożliwimy zdalny dostęp użytkownikom do ich katalogów domowych. Do wyboru mamy dwie technologie. a dokładniej mówiąc dwa protokoły komunikacyjne realizujące transfer plików przez sieć. Tradycyjny FTP lub nieco mniej znany SFTP, który można powiedzieć jest technologią przesyłania plików z wykorzystaniem protokołu SSH.
Nie jest to tradycyjny FTP, ale na transfer plików pozwala. Co więcej, transfer ten jest domyślnie szyfrowany, no bo działa na podbudowie SSH, a jak pamiętamy, ten protokół stosuje domyślnie szyfrowaną komunikację. Minusem SFTP jest nieco kłopotliwa konfiguracja pod obsługę katalogów domowych użytkowników, dlatego do tego zadania wykorzystamy tradycyjnego FTPa. Ci z Was, którzy śledzą nasz kanał dłużej, pewnie pamiętają odcinek, gdzie prezentowałem słabości FTPa i sposób w jaki przesyła on dane logowania do serwera, a także pliki. No jednym słowem lipa. Wszystko wysyłane jest plaintextem. Hacker, który przejmie taką komunikację z łatwością odnajdzie w niej loginy i hasła użytkowników, a także treści, które użytkownicy przesyłają na serwer. Na szczęście FTP da się w dość prosty sposób zaszyfrować, co spowoduje, że komunikacja klienta z serwerem będzie dużo bardziej bezpieczna.
Serwer FTP nie jest elementem pakietu LAMP, dlatego trzeba go zainstalować osobno. Na Linuxie dostępnych jest kilka rodzajów serwerów FTP. Ja dzisiaj konfigurację pokażę Wam na przykładzie popularnego serwera VSFTPD. Tradycyjnie zaczynamy od instalacji. Tak więc sudo apt install vsftpd. Ja jestem teraz już na swoim koncie, a nie na RUCie, stąd ponownie pojawiło się sudo przed poleceniem. Softchick zainstalowany, zatem odpalamy usługę FTP poleceniem sudo systemctl start vsftpd. Sprawdźmy czy usługa wystartowała. No jak widać działa. Domyślnie serwer FTP z wykorzystaniem tego oprogramowania działa tak, iż użytkownicy systemu mogą z automatu łączyć się zdalnie do całej struktury katalogów, wykorzystując login i hasło takie samo jak do systemu. Sprawdźmy to. Dzisiaj do testowania połączeń FTP wykorzystamy fajnego klienta, którego używam na co dzień, czyli WinSCP. Oknie konfiguracji połączenia, zmienić musimy protokół na FTP, bez szyfrowania na razie.
Tutaj podajemy IP-ka naszego serwera, no a dalej login i hasło użytkownika. Aby tych czynności nie powtarzać za każdym razem, możemy sobie tutaj te dane zapisać. OK. Logujemy się i bach. Było bach i jest bęc. Dupa. Nie możemy się zalogować. Podejrzewam coś, ale zanim będę pewien, zobaczę, czy mogę logować się za pomocą swojego konta użytkownika. No tutaj działa. Za pomocą mojego konta mogę się logować, tak więc moje podejrzenia się prawdopodobnie sprawdziły, ale dla pewności sprawdzę jeszcze zawartość plików lokalizacji etc o nazwie shells. No tak, teraz jestem pewien. Brakuje tutaj ścieżki do no login, tej ścieżki, którą podaliśmy przy tworzeniu użytkowników. Wystarczy ją po prostu do tego pliku tutaj dopisać. Jest. Zapisujemy jeszcze zmiany. No i dla pewności restart FTPa. Sprawdzamy. Ha! Teraz jest. Wszystko działa tak jak trzeba.
OK, moi drodzy. Udało się zalogować za pomocą użytkownika Maniek1. Konfiguracja domyślna, jak widzicie, na połączenie pozwala. . . Ale zanim serwer będzie gotowy do tego, aby bezpiecznie i skutecznie realizować połączenie z możliwością zapisu plików, jeszcze trochę pracy przed nami. Na tą chwilę nie możemy jeszcze zdalnie tworzyć ani zapisywać plików, no a to jest przecież kluczowe. Druga kwestia to ograniczenie dostępu tylko do katalogu domowego użytkownika. Teraz user może spokojnie śmigać sobie po plikach i katalogach całego systemu. Tak, dobrze słyszeliście, całego systemu. No a jakby to delikatnie powiedzieć, trochę to nieodpowiedzialne dawać taki dostęp dla użytkowników. Kolejna rzecz to wskazanie użytkowników, którzy będą mogli poprzez usługę FTP się łączyć. Nie każdy user musi mieć taką możliwość, można to kontrolować. Następnie musimy określić zakres portów, które będą obsługiwać na serwerze komunikację FTP.
Na koniec rzecz najważniejsza, czyli szyfrowanie. Nasza komunikacja na razie jest zupełnie nieszyfrowana i to również należy zmienić. Tak więc jak widzicie, trochę jeszcze pracy przed nami. Wracamy zatem do serwera. No i zacznijmy od edycji pliku konfiguracyjnego, który siedzi w etc. Plik nazywa się vsftpd. conf. Plik jest jak widzicie dość obszerny, ale spróbujemy go jakoś ogarnąć, chociaż zanim się za niego zabierzemy, zróbmy sobie jego kopię, aby w razie czego móc szybko przywrócić ustawienia. Ja swoją kopię nazwę tak. Gotowe. Wracamy do edycji pliku. Na początek proponuję umożliwić zapis plików użytkownikom. To będzie opcja znajdująca się w 31 linii. Wystarczy, że ją sobie odkomentujemy. Teraz wydzielimy naszym użytkownikom ich ogródek i postawimy ogrodzenie, tak aby nie mogli oni spoza ten swój ogródek, czyli katalog domowy wychodzić.
Odszukujemy linię 114 i ją również odkomentowujemy. Zanim odtrąbimy fanfary, no to musimy dodać jeszcze jedną opcję, której domyślnie w pliku nie ma, a opcja ta pozwoli zalogować się użytkownikom do zdalnego katalogu po włączeniu opcji Hrút Local Users. Bez tego serwer będzie odrzucał połączenie. Opcja ta nosi nazwę Allo Retable Hrut, no i ją ustawiamy na Yes. OK, zapisujemy zmiany w pliku, restartujemy serwer, no i wracamy do klienta na testy. Udało się połączyć, mamy zatem pierwszy sukces. Teraz próba utworzenia katalogu. Też jest sukces. No to sprawdźmy jeszcze. Czy działa nasze ogrodzenie? No chyba działa. Poza swojego home'a maniek nie podskoczy. Nasza dotychczasowa konfiguracja FTPa pozwala logować się do tej usługi każdemu użytkownikowi systemu.
Gdyby jednak zaszła potrzeba jakiegoś użytkownika zablokować, czyli zwyczajnie nie dawać mu dostępu do folderu domowego przez FTP, no to rzecz jasna da się to załatwić. Zobaczmy. Na początek tworzymy sobie plik, w sumie to o dowolnej nazwie, ale nazwijmy go vsftpd. users. Zapiszmy go oczywiście w katalogu ETC. W tym pliku zapisujemy nazwy kontużytkowników, którzy mogą mieć dostęp do swojego katalogu domowego poprzez FTP. Zapiszmy tutaj naszego pierwszego mańka. Zapisujemy zmiany w tym pliku, no i wracamy do konfiguracji FTP. Spadamy sobie na sam dół, no i dodajemy takie trzy linie. User List, podkreśnik Enable, ustawiony na Yes. Dalej. User List, podkreśnik File, no i ścieżka do pliku, który przed chwilą sobie utworzyliśmy. Na koniec jeszcze opcja User List, podkreśnik Danny, ustawiona rzecz jasna na No. OK, zapisujemy zmiany w pliku.
Teraz restart serwera, no i lecimy na testy. Sprawdźmy połączenie dla Mańka pierwszego. Jest OK. Teraz dla drugiego. No i jak widzimy drugi dostał bana, także no chyba, chyba działa. Dobra, pozostały nam jeszcze dwa tematy związane z FTP. Szyfrowanie oraz określenie numeru portów, które na serwerze będzie można wykorzystać do połączeń z klientami. Zacznijmy od tej drugiej kwestii i wróćmy nieco do teorii. Usługa FTP wykorzystuje w procesie komunikacji dwa porty. Jeden do przesyłania poleceń sterujących, a drugi do przesyłania już konkretnych danych. Taka konstrukcja protokołu powoduje, że może on działać w trybie aktywnym lub pasywnym. Aktywny tryb nazywany jest czasem trybem zarządzanym przez klienta, bo to na kliencie otwierane są dodatkowe porty do przesyłania danych. Jeśli firewall klienta zablokuje połączenie, no to transmisja nie będzie możliwa.
Drugi tryb, czyli pasywny, zarządzany jest z kolei przez serwer, bo to na serwerze dedykuje się określoną liczbę portów, którymi klient łączy się z serwerem do przesyłania danych. Ten tryb stosowany jest najczęściej, ponieważ to na serwerze wskazuje się dodatkowe porty, którymi klienty mogą do serwera przesyłać dane. Takie rozwiązanie jest wygodne dla użytkowników, bo nie trzeba majstrować przy ich zaporach sieciowych. Domyślnie VSFTPD działa w trybie pasywnym, ale my to zaraz w konfiguracji zapiszemy na stałe, a także wprowadzimy zakres portów, którymi klienty będą mogły łączyć się z serwerem. Odpalamy naszego configa, no i znowu spadamy sobie na sam dół, no i ponownie będziemy używać trzech linii. Pierwsza to PASF, podkreśnik ENABLE z ustawioną flagą YES. Następnie za pomocą opcji PASSIVE, podkreśnik MIN, podkreśnik PORT wskazujemy sobie początkowy zakres portów do obsługi FTP.
Na koniec trzecia linia z opcją PASF, podkreśnik MAX, podkreśnik PORT, no i tutaj podajemy końcowy numer portu. Jak duży powinien być ten zakres? No to zależy od tego jak dużo użytkowników i połączeń będzie serwer obsługiwał. Mi tutaj stówka wystarczy. Ok, zapisujemy zmiany. Restartujemy serwer. No i może zobaczmy na Wiresharku, czy faktycznie te numery będą wykorzystywane. Odpalamy program. Ustawiamy interfejs do nasłuchiwania. No i w filtrze wpisujemy FTP. Okej, połączmy się ponownie z FTP. No i teraz zobaczmy wpisy w Wiresharku. Zobaczcie, tutaj mamy info o trybie pasywnym. A tutaj mamy podany nawet numer portu z listy, którą zapisaliśmy sobie do naszego pliku. No tak więc jak widzimy wszystko działa tak jak trzeba. Okej, słuchajcie, została nam ostatnia kwestia, a mianowicie szyfrowanie.
FTP jest protokołem, który w bardzo jawny sposób realizuje komunikację między klientem a serwerem i pozostawienie domyślnej konfiguracji, która szyfrowania nie ogarnia, jest mało rozsądne. Szyfrowanie zapewni nam certyfikat oraz klucz szyfrujący, który sami sobie zaraz na Ubuntu wygenerujemy. Co prawda nie jest to rozwiązanie całkiem legitne, taki certyfikat powinniśmy wykupić u jednego z dostawców, my jednak tutaj płacić za nic nie będziemy, sami se certa zrobimy. Wykorzystamy do tego oprogramowanie OpenSSL, które jest biblioteką kryptograficzną, jak również zbiorem narzędzi wykorzystujących szyfrujące protokoły SSL, no i nowszy TSL. Oprogramowanie to powinno być dostępne również na Waszych maszynach. Jeśli okaże się, że go nie ma, łatwo możecie sobie go zainstalować, wydając takie polecenie. U mnie SSL już działa, zaczynamy zatem generowanie certyfikatu, no oczywiście od polecenia sudo. Dalej wpisujemy OpenSSL, łącznie. a dalej skrót od słowa required czy re-req.
Tutaj wstawimy sobie opcję X509. To oznacza mniej więcej tyle, że chcemy wygenerować certyfikat z żądaniem jego podpisu, ale proces podpisu certyfikatu zostanie zrealizowany na serwerze, a nie przez niezależną organizację. Dalej dodajemy opcję notes, która nie ustawi dla certyfikatu hasła. Następnie opcja days, która określi ważność certyfikatu. Dajmy tutaj rok. Następnie dodajemy opcję new key, z wartością RSA 2. 2048. Ta opcja wygeneruje klucz, który posłuży do podpisania certyfikatu, a klucz ten będzie miał długość aż 2048 bitów. Ostatnie dwie kwestie, które musimy tutaj uwzględnić, no to ścieżki, do jakich OpenSSL wyeksportuje plik klucza i plik certyfikatu. Najpierw klucz, to znaczy opcja Keyout, a tutaj podajemy ścieżkę, w której tradycyjnie Ubuntu przechowuje klucze. To będzie katalog ETC, SSL. Private. No i podajemy nazwę klucza z rozszerzeniem. Zapiszmy tutaj po prostu vsftpd. pem.
Pem to format certyfikatu i klucza, który stosowany jest zarówno w Apache jak i w vsftpd. Na koniec opcja out, która wyeksportuje nam sam certyfikat. Tutaj również podamy tą samą ścieżkę i co ważne tą samą nazwę pliku, co spowoduje, że zarówno certyfikat i klucz będziemy mieć w jednym pliku. Ok, rozpoczęło się generowanie certyfikatu. Musimy teraz podać tutaj informację. które klient FTP uzyska o naszym serwerze i jego certyfikacie. Oznaczenie kraju? No to oczywiście podajemy PL. Potem jest region? Ja tutaj zapiszę sobie Mazury. Jako miasto? Zapiszę sobie Grajewo. W sumie to bardziej już podlasie, ale co tam, niech będzie. Nazwa organizacji? To ja se tu zapiszę Pasja, a jednostkę w organizacji nazwę Ubuntu. Dalsze opcje pozostawię bez zmian.
Pamiętajcie, że jeśli konfigurujecie takiego certa w Realu, to dane, które w nim podajecie, powinny być bardziej wiarygodne. No okej, certyfikat wraz z kluczem wygenerowany. Pora na pogrzebanie w pliku konfiguracyjnym. Interesują nas linie od 152, bo tam są podane ścieżki do certa i klucza. Zmieniamy je na ścieżki, do których wyeksportowaliśmy poprzednio nasz cert i nasz klucz. Teraz uruchamiamy możliwość korzystania z szyfrowania, ustawiając tą opcję na Yes. Następnie za pomocą opcji FORCE, podkreśnik LOCAL, podkreśnik DATA, podkreśnik SSL ustawionej na YES, a także opcji FORCE, podkreśnik LOCAL, podkreśnik LOGINS, podkreśnik SSL również ustawionej na YES, wymuszamy sobie szyfrowanie podczas logowania, a także przesyłania danych. Na koniec uruchomimy sobie jeszcze szyfrowanie TLSV1. a także wyłączymy obsługę SSL w wersji drugiej, no i trzeciej.
To może sprawiać nieco zamieszania, bo z jednej strony wyłączamy obsługę SSL, a z drugiej ją włączamy. To bardzo proste. SSL to określenie zbioru technik szyfrujących komunikację w internecie. Natomiast w ramach tych technik wyróżnia się protokoły SSL i TLS. Protokół SSL jest starszym rozwiązaniem i mniej efektywnym niż TLS, dlatego też tutaj wymusiliśmy używanie tego drugiego. Ok, zamykamy plik. Restartujemy serwer. No i dobrze by było jeszcze sprawdzić czy nie wypluwa błędów. Wydaje się, że wszystko ok, tak więc idziemy do naszego klienta, no i spróbujmy ponowić połączenie. Zmieniając tutaj ustawienia na jawne szyfrowanie SSL TLS. Ok, łączymy się, no i mamy jakiś warning. No mamy, bo to klient FTP krzyczy, że certyfikat, którego używa serwer jest nieznany.
No jest to certyfikat samodzielnie podpisany przez serwer, a do tego jeszcze nigdy nie używany, dlatego tutaj pojawił się taki komunikat. Co ważne, możemy z niego wyczytać dane, które przed chwilą podawaliśmy na serwerze. To jest dla nas potwierdzenie, że serwer, z którym się łączymy, jest tym, za którego się podaje. Klikamy tak, no i już jesteśmy połączeni. Dla klienta nie ma żadnej różnicy, czy łączy się z szyfrowanym, czy nie szyfrowanym FTP, ale zobaczmy, jak wygląda to na Wiresharku. No a wygląda to tak. Zamiast komunikatów, piękne krzaczki, z których mało co da się odczytać. Okej moi drodzy, to już wszystko, co dla Was dzisiaj przygotowałem. Na ekranie widzicie właśnie cały plik konfiguracyjny FTPa z użytymi dzisiaj opcjami. Śmiało możecie stosować go na własnych serwerach.
W następnym odcinku pokażemy jak połączyć naszą witrynę z DNS-em, a także jak zaszyfrować stronę z wykorzystaniem własnych certyfikatów. Jeszcze raz dziękujemy firmie NordVPN za zasponsorowanie tego wideo. nordvpn. com prawy slash pasja informatyki To jest link do możliwości uzyskania dwuletniego planu ze zniżką oraz pierwszym miesiącem gratis. Dziękujemy również naszym patronom za wsparcie naszej działalności. Do usłyszenia. Trzymajcie się ciepło. Pozdrawiam. .
S K R Y B O T
Skrybot. 2023, Transkrypcje video z YouTube
Informujemy, że odwiedzając lub korzystając z naszego serwisu, wyrażasz zgodę aby nasz serwis lub serwisy naszych partnerów używały plików cookies do przechowywania informacji w celu dostarczenie lepszych, szybszych i bezpieczniejszych usług oraz w celach marketingowych.