K-NET s.c.

FTP z linii poleceń w systemie Windows

O 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

Zakładka Windows Services Recovery

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

MG

Redirect – automatyczne przekierowanie strony www

Bardzo 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

Time has been changed – co oznacza ten komunikat

Jednym 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

Fail2Ban – usuwanie adresu IP z czarnej listy

Jedną 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

Port Forwarding na serwerze Windows

Przekierowanie 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

Jak dodać białą listę dla RBL na poziomie Postfixa

Czasami tak się zdarza, że używając do ograniczenia niechcianej poczty przychodzącej (czyli po prostu spamu) list RBL wytniemy coś niepotrzebnie. Sytuacja ta dotyczy w szczególności konfiguracji, w której używamy w tym celu np. Postfixa, definiując w pliku main.cf z jakich list chcemy skorzystać. Takie rozwiązanie jest dosyć skuteczne, ubijamy pocztę bowiem od razu na samym początku łańcucha przetwarzania, nie obciążając zbytecznie np. demona amavisd. Jednak z drugiej strony możemy stanąć przed dylematem jak utworzyć białą listę hostów nie wyłączająć całej listy RBL. Jak się okazuje w Postfixie nie jest to problem. Poniżej krótka instrukcja:

[1] W katalogu /etc/postfix tworzymy plik rbl_override (nazwa przykładowa):

touch /etc/postfix/rbl_override

[2] Edytujemy jego zawartość:

nano /etc/postfix/rbl_override

dodając wyjątki z białej listy:

1.2.3.4    OK
3.4.5.6    OK

[3] Tworzymy bazę dla Postfixa za pomocą polecenia postmap:

postmap /etc/postfix/rbl_override

[4] Na koniec edytujemy plik main.cf:

nano /etc/postfix/main.cf

i dodajemy odpowiednią linijkę w sekcji smtpd_recipient_restrictions bezpośrednio po komendzie reject_unauth_destination ale przed pierwsza czarną listą reject_rbl_client:

[...]
    smtpd_recipient_restrictions = ...
        ...
        reject_unauth_destination,
        check_client_access hash:/etc/postfix/rbl_override,
        reject_rbl_client multi.uribl.com,
        ...
[...]

Trzeba oczywiście pamiętać o zrestartowaniu daemona postfix po wszystkim…

MG

Postfix main.cf czyli kolejność ma jednak znaczenie

Przez wiele lat konfigurowałem rozmaite serwery poczty opierając się o sprawdzony serwer Postfix w tandemie z Debianem. Były to konfiguracje bardzo proste, średnio złożone i takie, które wymagają posiedzenia nad problemem dłużej. Wykorzystywałem Postfix natywnie i w połączeniu z gotowymi skryptami (np. polecanym iRedMail). Przyznam, że nigdy nie zawiódł i wydawał się być dość prosty w obsłudze przy jednocześnie rozbudowanych opcjach ustawień. Do czasu aż trafiłem na problem, który zatrzymał mnie w miejscu na parę godzin. O co chodzi? Otóż w każdej sieci znajdzie się urządzenie, komputer, router może termometr IP, które będzie chciało wysyłać emaile z komunikatami. I zazwyczaj mają one wbudowaną obsługę autoryzacji dla połączeń SMTP. Jedna raz na jakiś czas trafi się egzamplarz, który za żadne skarby świata nie potrafi się kulturalnie przedstawić naszemu Postfixowi. Wówczas nie pozostaje nic innego jak zrobić małe obejście i dopuścić urządzenie do wysyłania emaili bez żadnych ograniczeń. Wiem, że nie powinniśmy tak nigdy robić ale czasem trzeba. W Postfixie służy do tego opcja (na przykładzie adresu 10.10.10.10):

mynetworks = 127.0.0.1 10.10.10.10

która spowoduje, że wymienione po kolei hosty stają się uprzywilejowane. Czy zawsze to zadziała? W tym właśnie tkwi sedno sprawy, że nie! Otóż jeżeli w naszej konfiguracji stosujemy różne ograniczenia (a jak wspomniałem Postfix jest bogaty w możliwości) czyli np. zastosujemy dyrektywę smtpd_recipient_restrictions to kolejność jej atrybutów zaczyna mieć znaczenie. Czyli np. kod:

smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient

jest prawidłowy bo atrybut permit_mynetworks jest pierwszy na liście. Jednak ten sam kod zapisany:

smtpd_recipient_restrictions =
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient
  permit_mynetworks

jest już nieprawidłowy bo kolejność ma jednak duże znaczenie. Reguła ta obowiązuje dla wszystkich dyrektyw, dla których możemy użyć atrybutu permit_mynetworks.

MG

Budowa serwera SFTP na bazie SSH i Debiana

Jak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu WinSCP czy FileZilla to zasadniczo nie powinien mieć żadnych problemów z korzystaniem z SFTP bowiem obsługa tego ostatniego została już zaimplementowana w tych windowsowych klientach. Zatem do dzieła.

Po pierwsze sprawdzamy czy obsługa SFTP została włączona w konfiguracji serwera OpenSSH. Plik /etc/ssh/sshd_config powinien zawierać wpis:

Subsystem sftp internal-sftp

Teraz, na końcu pliku możemy dodać sekcje dla nowego konta z dostępem SFTP:

Match User KontoSFTP
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Oczywiście zakładam, że wcześniej założyliśmy sobie takie konto w systemie. Po ponownym uruchomieniu serwera SSH wszystko powinno zacząć działać… oprócz dwóch drobnostek.

Na pewno warto zadbać aby użytkownik KontoSFTP nie miał dostępu shellowego do systemu. W tym celu musimy zmienić mu domyślny shell. Najpierw sprawdzamy czy możemy użyć shella typu sftp-server:

cat /etc/shells

Jeśli nie zostanie wyświetlona nazwa sftp-server powinniśmy użyć polecenia:

echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Teraz możemy już zmodyfikować konto naszego użytkownika:

usermod -s /usr/lib/openssh/sftp-server KontoSFTP

Druga sprawa to powinniśmy zmienić prawa dostępu do tych podkatalogów w /home, do których chcemy zabezpieczyć dostęp. W ten sposób nasz użytkownik nie będzie mógł zwiedzać innych podkatalogów. Dla każdego z zabezpieczanych katalogów należy wydać polecenie:

chmod 700 /home/NazwaZabezpieczanegoKatalogu

Po wykonaniu powyższych czynności możemy cieszyć się nowym serwerem SFTP. Powyższe uwagi dotyczą rzecz jasna mojego ulubionego Debiana.

MG

ClamAV-clamd av-scanner FAILED

Całkiem niedawno instalowałem po raz kolejny serwer poczty dla klienta. Niestety wsparcie dla mojego ulubionego Debiana Squeeze skończyło się w kwietniu tego roku dlatego postanowiłem od razu pominąć dystrybucje Wheezy i skorzystać z Jessie. W jednym ze wcześniejszych wpisów podałem adres bardzo dobrego poradnika, który omawiał jak niewielkim kosztem przygotować bardzo wydajną i sprawną bramkę mailową typu Antivirus/Antispam. Świat idzie szybko do przodu i okazało się, że poradnik już nie jest dostępny. Co więcej autor poleca skorzystanie ze skryptów iRedMail. Skrypty skryptami, niby rozwiązanie wygodne i szybkie ale co ma zrobić administrator przyzwyczajony do konfigurowania wszystkiego ręcznie? Przez wiele lat nagromadziłem własne gotowe pliki konfiguracyjne i nie bardzo uśmiechało mi się przeglądanie gotowców z iRedMail. Dlatego postanowiłem sprawdzić co pozmieniało się w stosunku do informacji (konfiguracji) które już posiadam i jednak zbudować serwer poczty od początku na własną ręke. Musze przyznać, że zmian było stosunkowo niewiele. Oczywiście niektóre repozytoria wygasły a w ich miejsce pojawiły się inne. Miłą niespodzianką okazała się na przykład dostępność w podstawowym repo pakietu clamav-unofficial-sigs, o czy zupełnie nie wiedziałem i zawsze instalowałem „z palca”. W trakcie instalacji trafiłem jednak na spory problem. Coś co do tej pory działało niezawodnie, nagle w Jessie przestało funkcjonować prawidłowo. Chodzi o pakiet Clamav, który zaczał zgłaszać błędy:

... run_av (ClamAV-clamd) FAILED ...
... ClamAV-clamd av-scanner FAILED ...
... WARN: all primary virus scanners failed, considering backups...

Sprawa wyglądała dość poważnie bo dotyczyła jednego z kluczowych elementów każdego systemu pocztowego. Jak zwykle w takich sytuacjach rozwiązanie okazało się dość banalne. W pliku konfiguracyjnym /etc/clamav/clamd.conf, w dystrybucji Jessie zmieniła się jedna linijka. Wygląda ona obecnie tak:

AllowSupplementaryGroups false

a powinna wyglądać jak w poprzednich dystrybucjach, czyli:

AllowSupplementaryGroups true

I to wszystko.

MG