Bądź na bieżąco - RSS

Docker, Portainer i kłopoty z OpenProject

Wrzesień 15th, 2018 | Brak Komentarzy | Kategoria: Felieton, Linux, Porady

Docker

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

  • z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
  • usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
  • uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

 

Tagi: , , , , ,

Aktualizacja hosta ESXi

Sierpień 18th, 2018 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

VMware ESXiWirtualizacja jest obecnie praktycznie standardem. Jest powszechnie dostępna i łatwo można samemu przygotować własny host maszyn wirtualnych. Od jakiegoś czasu testuje aktualnie kilka instalacji VMware ESXi i muszę przyznać, że jestem zaskoczony wygodą obsługi oraz jak dotąd (odpukać) bezawaryjną pracą. Instalacja jest dosyć łatwa pod warunkiem, że przygotujemy się pod kątem sprzętu. Nie każdy zostanie wykryty przez instalator, ale metodą prób i błedów a także przy wsparciu forów technicznych można rozwiązać większość problemów. Potem jest już z górki. Do czasu. Jak zwykle po jakimś czasie powinniśmy pomyśleć o kwestiach bezpieczeństwa, a co się z tym wiąże aktualizacji naszego hosta.

Jeżeli podobnie jak ja używasz wersji ewaluacyjnej ESXi to znaczy, że najprawdopodobniej korzystasz z trybu standalone server, czyli posiadasz tylko jeden host maszyn wirtulanych. Instalacja tego typu wyróżnia się brakiem wygodnej czytaj graficznej obsługi aktualizacji. Pełna instalacja zarezerwowana jest dla dużych farm hostów, a tak naprawdę trzeba zapłacić za oprogramowanie zarządzające hostami, co na jedno wychodzi. W tym przypadku trzeba sobie radzić za pomocą konsoli tekstowej.  Ale po kolei…

Najpierw należy zalogować się na nasz host używając po prostu przeglądarki internetowej. Z poziomu graficznej konsoli zarządzania trzeba uruchomić usługę SSH. Nie jest ona domyślnie włączona – dla bezpieczeństwa. Wybieramy zatem opcję Manage z okienka Navigator po lewej stronie i w okienku po prawej stronie przechodzimy do zakładki Services. Uruchamiamy usługę TSM-SSH (po zakończeniu aktualizacji warto ją wyłączyć ponownie). Od tej pory możemy połączyć się za pomocą SSH do naszego hosta.

Zaczynamy od sprawdzenia wersji poleceniem:

~ # esxcli system version get
Product: VMware ESXi
Version: 6.7.0
Build: Releasebuild-469512
Update: 0
Patch: 0

Następnie udajemy się na stronę z aktualizacjami dla VMware ESXi i pobieramy właściwą dla naszego systemu. Warto zauważyć, że aktualizacje kumulują się, więc nie ma potrzeby wgrywania wszystkich – wystarczy ostatnia. Dodam, że na pewno trzeba wgrać oznaczone etykietką Critical, reszta według uznania.

Przełączamy host ESXi w tryb Maintenance (za pomocą przeglądarki i strony zarządzającej) i możemy przystąpić do działania. Rozpoczynamy od wyświetlenia listy profili dostępnych w naszym patchu:

~ # esxcli software sources profile list --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip
Name Vendor Acceptance Level
-------------------------------- ------------ ----------------
ESXi-6.7.0-20171002001-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.7.0-20171002001-no-tools VMware, Inc. PartnerSupported

Najbezpieczniej jest skorzystać z profilu standardowego, a więc ESXi-6.7.0-20171002001-standard. Jest to zazwyczaj pierwszy dostępny profil z listy. Nim w następnym kroku przystąpimy do aktualizacji serwera, powinniśmy najpierw sprawdzić jaki będzie wynik tej operacji. Z pomocą przychodzi opcja –dry-run. Wpisujemy plecenie:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--dry-run --profile=ESXi-6.7.0-20131002001-standard
Update Result
Message: Dryrun only, host not changed. The following \
installers will be applied: [BootBankInstaller]
Reboot Required: true
VIBs Installed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.1.11.623860, \
VMware_bootbank_esx-base_5.0.0-3.41.1311175, \
VMware_bootbank_esx-tboot_5.0.0-2.26.914586, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586, \
VMware_bootbank_misc-drivers_5.0.0-3.41.1311175, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.7.515841, \ 
VIBs Removed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, \ 
VMware_bootbank_esx-base_5.0.0-0.0.469512, \
VMware_bootbank_esx-tboot_5.0.0-0.0.469512, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, \
VMware_bootbank_misc-drivers_5.0.0-0.0.469512, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512,

Jeśli nie otrzymaliśmy żadnych komunikatów o błedach możemy śmiało przystąpić do właściwej aktualizacji. Tym razem korzystamy z komendy:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--profile=ESXi-6.7.0-20131002001-standard 
Update Result
Message: The update completed successfully, but the 
system needs to be rebooted for the changes to be effective. \
Reboot Required: true

Na sam koniec nie pozostaje nic innego jak uruchomić ponownie serwer VMware ESXi (skoro sam tego zażądał):

~ # reboot

Po starcie systemu wyłączamy tryb Maintenance i voilá! Prawda, że proste 😉

MG

Tagi: , , , , ,

Telnet – instalacja na Windows Server 2016

Marzec 17th, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

TelnetŚrodowisko systemów serwerowych Microsoft zmienia się bardzo dynamicznie. Nie ma co ukrywać, że konkurencja rozwija się bardzo szybko i pomimo, że mogłoby wydawać się, iż nic nie zagrozi dominacji serwerów Windows w segmencie małych i średnich firm wykorzystujących rozwiązania oparte o MS SQL, to sam Microsoft wprowadza modyfikacje podążające za najnowszymi trendami. Nie ukrywam, że na przykład bardzo mnie cieszy współpraca z Canonical i migracja części narzędzi terminalowych wprost z Linuxa. Bo właśnie o terminal tutaj chodzi, a będąc bardziej precyzyjnym o wygodę z jego korzystania (czyli np. poleceń telnet, ftp itd.). Narzędzia interfejsu graficznego mają swoje zalety, w szczególności dla początkującego użytkownika, jednak jeśli ktoś przebrnie przez początkowe trudności to zazwyczaj docenia mocno wygodę korzystania z trybu tekstowego.

W dzisiejszym wpisie chciałem pokazać jak zainstalować narzędzia Windows 2016 Server za pomocą 3 metod. Jak można się domyślić z poprzedniego akapitu skupię się raczej na terminalu niż na okienkach konfiguracyjnych. Za przykład posłuży nam program telnet.

Po pierwsze warto sprawdzić czy przypadkiem telnet nie został już zainstalowany w systemie. Można sprawdzić to w bardzo prosty sposób. Otwieramy terminal tekstowy i wpisujemy polecenie:

C:\>telnet google.com 80
 'telnet' is not recognized as an internal or external command, →
 → operable program or batch file.
C:\>

Powyższy komunikat świadczy, że należy włączyć narzędzie na poziomie serwera, czyli po prostu zainstalować aplikację.

Tereaz możemy przejść do instalacji w zwykłym terminalu tekstowym (uruchamianym poleceniem cmd – command prompt):

dism /online /Enable-Feature /FeatureName:TelnetClient

Po krótkim oczekiwaniu aplikacja zostanie zainstalowana.

Na tym nie konczą się nasze możliwości ponieważ można zrobić to samo w słynnym PowerShellu. Tym razem trzeba użyć polecenia:

Install-WindowsFeature -name Telnet-Client

W szczególności to rozwiązanie wydaje się być bardzo ciekawe, a użycie polecenia Install-WindowsFeature daje nam naprawdę duże możliwości. Polecam potestować – więcej informacji można znaleźć w dokumentacji na stronach Microsoftu.

Trzeciej opcji, którą jest instalacja w trybie okienkowym, nie będę opisywał. Z premedytacją – jako zwolennik terminali tekstowych.

MG

Tagi: , , , ,

sudppipe – tunel UDP dla Windows

Luty 17th, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

UDP sudppipeSystemy serwerowe rodziny Windows stają się praktycznie niezastąpione w środowisku, gdzie jesteśmy zmuszeni korzystać z firmowych systemów bazodanowych. Oferta tych ostatnich zakłada w zasadzie wykorzystanie tylko jedynego słusznego środowiska pracy. Czasami nastręcza to nietypowych trudności, w szczególności gdy chodzi o sterowanie przepływem komunikacji. Oprogramowanie zapory sieciowej wbudowane w serwer w zasadzie nie pozwala na łatwe przekierowywanie komunikacji TCP nie wspominając już o UDP. Jeśli trafimy na środowisko homogeniczne, to skonfigurowanie wyżej wymienionych przekierowań może być trudne. Podstawowym narzędziem jest tutaj komenda linii poleceń netsh opisana w innym artykule.

Jeśli posiadamy urządzenia takie jak np. drukarki sieciowe, to przydatne staje się zarządzanie nimi za pomocą protokołu SNMP. W tym momencie może się okazać, że powinniśmy przygotować przekierowanie portów UDP na serwerze Windows. Zakładam tutaj, że drukarki sieciowe są skonfigurowane w oddzielnym VLANie, ale również w oddzielnej podsieci IP. Jeśli zatem chcielibyśmy dostać się do urządzenia SNMP z puli klienckiej (posiadającej własny VLAN) musimy włączyć tzw. port forwarding, z tym że dla UDP.

Zmagając się z opisanym problemem trafiłem na bardzo przydatne narzędzie dostępne na stronie Luigiego Auriemmy. Wśród dostępnych aplikacji znajduje się mały program o nazwie sudppipe. Wywołany z linii poleceń pozwala skonfigurować tunel UDP na serwerze Windows. Całość wygląda w działaniu zachęcająco:

Usage: sudppipe.exe [options] <server*> <server_port> <local_port>

Sprawdziłem i działa bez zarzutu. Zachęcam do szczegółowego zapoznania się z jego możliwościami.

MG

Tagi: , , ,

FTP z linii poleceń w systemie Windows

Listopad 18th, 2017 | Brak Komentarzy | Kategoria: Porady, Windows

FTPO tym, że linia poleceń w przypadku systemów takich jak Linux daje szerokie możliwości nie trzeba się specjalnie rozpisywać. Czasami jednak jesteśmy zmuszeni napisać skrypt systemowy dla serwera Windows i wtedy nie jest już tak prosto. Mam na myśli całkiem konkretny przypadek z własnego podwórka. W dużym skrócie zadanie polegało na okresowym wysyłaniu pliku baz danych MSSQL na zewnętrzny serwer FTP. Z jednej strony sprawa dosyć prosta, bo od razu przychodzi na myśl wykorzystanie harmonogramu zadań systemowych i użycie odpowiedniego skryptu wsadowego, z drugiej strony okazało się jednak, że narzędzie linii poleceń Windows takie jak komenda ftp niespecjalnie radzi sobie z trybem pasywnym transmisji. Zgodnie z dokumentacją wszystko powinno działać bez problemu, można nawet użyć spreparowanej wcześniej listy poleceń ftp, aby zautomatyzować zadanie jednak bardzo często w trakcie wykonania program zawiesza się. W sieci można znaleźć mnóstwo porad co zrobić w takiej sytuacji. Postanowiłem się tym razem podzielić innym rozwiązaniem.

W miejsce polecenia ftp można użyć dobrze znanego programu WinSCP. W skład tego pakietu wchodzi program o nazwie winscp.com, który pozwala na użycie w trybie wsadowym:

winscp.com /command "open ftp://uzytkownik:haslo@serwer.ftp/" →
→ "put plik.sql /home/user/" "exit"

Warto zwrócić tutaj uwagę na niezwykłą prostotę składni polecenia. Po przełączniku command następuje po prostu lista poleceń do wykonania. Ponieważ całość mieści się w jednej linii można w zasadzie całą komendę wpisać wprost do harmonogramu zadań systemowych. Dodatkowym plusem będzie możliwość obsługi protokołu szyfrowanego np. SFTP, czego nie potrafi zrobić narzędzie wbudowane w Windows.

MG

Tagi: , , ,

Zakładka Windows Services Recovery

Czerwiec 17th, 2017 | Brak Komentarzy | Kategoria: Porady, Windows

System ServiceAdministratorzy serwerów opartych o systemy firmy Microsoft, podobnie jak pozostali, zmagają się często z usługami systemowymi, które z niewyjaśnionych przyczyn odmawiają posłuszeństwa. Problemy tego typu potrafią być bardzo uciążliwe. Zwłaszcza jeżeli dotyczą serwisów działających w tle. Z jeszcze gorszą sytuacją mamy do czynienia jeżeli chodzi o serwer kluczowy dla działania większego systemu. Obserwowanie tzw. zwisów usług jest ciężkim doświadczeniem w życiu każdego admina. Wyobraźmy sobie, że jakaś usługa po prostu staje w miejscu co jakiś czas. Zaglądamy do komponentu Usługi Systemowe i widzimy, że niemalże regularnie jest zatrzymywana. Oczywiście zawsze można uruchomić ją ponownie ręcznie i najczęściej udaje się to bez problemu. Niemniej za jakiś czas ponownie zatrzymuje się i tak się dzieje bez wyraźnej przyczyny oraz co gorsza są to zdarzenia cykliczne.

Oczywiście w powyższym przypadku zawsze należy znaleźć źródło błedu aby wyleczyć jego przyczynę. Zgodnie z zasadą aby nie tylko usuwać objawy. Co jednak jeśli nie mamy na to czasu? System to rozpędzony serwer produkcyjny a każda przerwa w działaniu usługi oznacza duże kłopoty. W takiej sytuacji możemy skorzystać z tymczasowego rozwiązania, wbudowanego w serwery firmy Microsoft. Ciężko się przyznać, ale sam przez wiele lat obsługiwania takich systemów nie miałem pojęcia, że są takie możliwości.

Mowa tutaj o zakładce Recovery, która jest dostępna jeżeli wyświetlimy właściwości usługi sytemowej sprawiającej problemy. Zasadniczo na szybko możemy zaznaczyć opcje widoczne na poniższej ilustracji. Od tego momentu system sam będzie podnosił nieposłuszną usługę. Zawsze jednak trzeba pamiętać, że jest to rozwiązanie tymczasowe i na pewno powinniśmy dokonać głębszej analizy problemu. Póki co jednak zyskaliśmy cenny czas… i o to chodziło.

Windows Services Recovery

MG

Tagi: , ,

Redirect – automatyczne przekierowanie strony www

Marzec 18th, 2017 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

URL RedirectBardzo często zdarza się, że chcemy przenieść serwis www, swoją stronę domową czy nawet pojedyncze statyczne dokumenty HTML pod zupełnie nowy adres. Aby poinformować swoich użytkowników o zmianach można umieścić odpowiedni komunikat na stronie – tzw. URL Redirect Information. Jest to zdecydowanie najprostsza metoda ale czasami warto zastanowić się nad innymi sposobami. Jeśli akurat jesteśmy administratorami serwera to można oczywiście tak skonfigurować serwer wirtualny Apache aby robił to automatycznie:

<VirtualHost *:80>
  ServerName poprzedni_adres.pl
  Redirect permanent / http://nowy_adres.pl
</VirtualHost>

Jednak nie mając tak szerokich możliwości również możemy skonfigurować zaawansowane przekierowanie. Najprościej będzie zrobić to w HTML:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url=http://nowy_adres">
</head>
<body>
</body>
</html>

Zdarza się jednak, że przeglądarki nie dopuszczają do tego typu przekierowań. Dlatego możemy skorzystać z pliku .htaccess:

Redirect 301 / http://nowy_adres

Jeśli nie mamy powyższych możliwości, nadal możemy próbować, używając JavaScript:

<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
    window.location.replace("http://nowy_adres");
</script>
</body>
</html>

lub języka PHP:

<?php
header("Location: http://nowy_adres", true, 301);
exit();
?>

Tak czy inaczej, mamy do wyboru całkiem sporo różnych metod.

MG

Tagi: , , ,

Time has been changed – co oznacza ten komunikat

Grudzień 17th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Time has been changedJednym z problemów w administracji serwerami (nie tylko inuxowymi) jest synchronizacja czasu. Praktycznie każda usługa systemowa może odmówić posłuszeństwa jeżeli nie zadbamy o prawidłową podstawę czasu. Z pozoru zadanie to jest dość proste. Wystarczy zainstalować pakiet ntp:

 

 

apt-get install ntp

i od razu wszystko powinno działać. Osobiście polecam takie rozwiązanie na każdym sewerze z Linuxem aby właśnie zadbać o zsynchronizowanie naszej skali czasu z serwerami źródłowymi dostępnymi w Internecie. Musimy jednak pamiętać, że oprócz zegara systemowego, każdy komputer wyposażony jest w zegar sprzętowy. Funkcjonowanie tego ostatniego, a raczej jego zła praca, na pewno będzie miała wpływ na stabilność zegara systemowego. Są to bardzo rzadkie przypadki ale zdarzają się. Np. w Debianie Jessie aby zrealizować synchornizację wykorzystywane są kolejno usługi i funkcje systemd, swdate i w konsekwencji Slow Clock Adjuster. Co w moim przypadku, przy korzystaniu z maszyny VirtualBox, i zapewne błędnej obsłudze czasu przez środowisko wirtualne, zaowocowało komunikatami systemowymi (rsyslogd):

host systemd[1]: Time has been changed

Jak wspomniałem, jest to błąd oprogramowania i aby pozbyć się powyższych komunikatów trzeba je po prostu odfiltorwać na poziomie logu systemowego. W tym celu logujemy do konsoli roota i zakładmy plik time_msgs.conf:

touch /etc/rsyslog.d/time_msgs.conf

Następnie edytujemy plik:

vi /etc/rsyslog.d/time_msgs.conf

i dodajemu linijkę:

:msg, contains, "Time has been changed" stop

Po wszystkim musimy ponownie uruchomić usługę:

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Tym samym pozbyliśmy się niepotrzebnych komunikatów z logów systemowych.

MG

Tagi: , , , , ,

Fail2Ban – usuwanie adresu IP z czarnej listy

Listopad 19th, 2016 | Brak Komentarzy | Kategoria: Linux, Porady

Fail2BanJedną z najbardziej popularnych metod obrony przed atakami typu brute-force, które realizowane są automatycznie za pomocą skryptów sieciowych, jest zastosowanie aplikacji Fail2Ban na serwerze. Być może wspomniane ataki nie są szczególnie niebezpieczne, zwłaszcza jeżeli pamiętamy o stosowaniu odpowiednio skomplikowanych haseł dla kont użytkowników, generują jednak tony niepotrzebnych wpisów w logach systemów. Utrudnia to późniejszą analizę zdarzeń systemowych. Poza tym przy nieodpowiedniej konfiguracji naszych sieciowych usług serwerowych może to doprowadzić do zatrzymania się całego serwera – atak typu denial-of-service. Stąd trudno dziwić się popularności Fail2Ban, który po prostu umożliwia zablokowanie na jakiś czas adresu IP, jeśli jest on źródłem często powtarzających się zapytań, skierowanych do wybranej usługi sieciowej np. SSH, FTP itd.

Problemem jaki jest związany ze stosowaniem Fail2Ban jest blokowanie dobrych adresów IP. Na przykład może do tego dojść jeśli nasz użytkownik zapomni hasła do poczty i będzie usiłlował wielokrotnie zalogować się z błędem. Zgodnie ze zdefiniowanymi regułami zostanie zablokowany. Taka sytaucja zdarza się dosyć często. Wie o tym każdy kto zajmuje się administrowaniem. W dokumentacji Fail2Ban można znaleźć informacje jak odblokować wskazany adres za pomocą narzędzia fail2ban-client. Niestety ze względu na różnicę wersji samego oprogramowania dla różnych dystrybucji systemu Linux, jak również niepoprawnie obsługiwane funkcje, bywa, że Fail2Ban nie radzi sobie z tym zadaniem prawidłowo. Dlatego chciałem zaproponować inną metodę, bazującą na poleceniu iptables. Fail2Ban wykorzystuje iptables do blokowania połączeń, zatem poniższa metoda jest jak najbardziej bezpieczna.

Z poziomu administratora – konto root – wydajemy polecenie w konsoli systemowej:

iptables -L -n --line-numbers

Następnie odnajdujemy poszukiwany adres IP na liście i zapamiętujemy nazwę łańcucha np. Chain dynamic – nazwa dynamic, oraz numer linii. Parametry te posłużą do usnięcia adresu IP z czarnej listy za pomocą polecenia:

iptables -D nazwa_lancucha numer_linii

W tym momencie przywracamy dostęp do serwera naszemu zapominalskiemu użytkownikowi.

MG

Tagi: , , ,

Port Forwarding na serwerze Windows

Październik 15th, 2016 | Brak Komentarzy | Kategoria: Porady, Windows

Windows termina - port forwardingPrzekierowanie portów (port forwarding) za pomocą reguł iptables jest dobrze znaną i często wykorzystywaną funkcją w systemach Linux. Każdy kto z niej korzystał wie, że bywa bardzo przydatna w różnych sytuacjach. Jednak czy można uzyskać podobny efekt na serwerze z zainstalowanym systemem Windows? Na pierwszy rzut oka wbudowana zapora Windows Firewall nie posiada takich możliwości. Pomimo szczegółowego przeszukiwania wszystkich opcji dostępnych z poziomu menu graficznego, trudno jest tam nawet znaleźć wzmiankę o podobnych usługach. Okazuje się jednak, że pod spodem, pod warstwą interfejsu mającego upraszczać i ułatwiać codzienne czynności administracyjne kryje się całe bogactwo rozmaitych narzędzi. Tym razem chciałbym zwrócić uwagę na polecenie netsh.

Netsh jako narzędzie linii poleceń pozwala zrealizować wiele ciekawych i rozbudowanych czynności związanych z obsługą sieci w Windows. Bardzo dobrym źródłem informacji na ten temat jest Microsoft TechNet. Ponieważ omawianie wszystkich możliwości wykracza daleko poza ramy krótkiego artykułu chciałem pokazać wspomniany w tytule przykład:

netsh interface portproxy add v4tov4 →
listenaddress=localaddress listenport=localport →
connectaddress=destaddress connectport=destport

Poszczególne opcje oznaczają:

  • listenaddress: lokalny adres IP oczekujący na połączenie,
  • listenport: nasłuchujący port,
  • connectaddress: adres IP, na który zostanie przekierowane połączenie,
  • connectport: port, na który zostanie przekierowane połączenie.

Powyższy przykład pokazuje jak ciekawe narzędzia kryją się pod powłoką graficzną. Mam nadzieję, że jest to wystarczająca zachęta do zabawy z terminalem tekstowym. Podobnie jak w Linuksie 🙂

MG

Tagi: , ,