Windows Server 2012 - firewall i obsługa z linii komend

Ostatnio miałem przyjemność dyskutować z kolegą, którego spotkała "przyjemność" instalacji środowiska bazodanowego w Windows Server 2012, który "jest złym systemem operacyjnym, bo tam tyle klikania". Ból jest tym większy, gdyż pierwszym rzucie miał do skonfigurowania około 300 instancji.

W przypadku jednego - dwóch serwerów, wszystko można "wyklikać":

• pobranie odpowiednich komponentów oprogramowania,
• instalacja oprogramowania,
• konfiguracja,
• konfiguracja firewalla, reguł itd.

Jak jednak przychodzi wykonać to na kilkuset hostach, dodatkowo zautomatyzować proces w przypadku przeinstalowania, zamienia się to w tygodnie pracy.

Ogniomurek

Wracając do wyżej wymienionego środowiska, zapomnijmy na chwilę o innych aspektach, poza jednym - zapora sieciowa. Firewall - jeden ze sposobów zabezpieczania sieci i systemów przed intruzami. Cytując Wikipedię:

W systemach Windows pierwszy firewall ("ICF") pojawił się w roku 2001 w odpowiedzi na komercyjne produkty. Produkt zyskał dość złą sławę, był uznawany za "zbędny dodatek, który trzeba zastąpić dobrym programem". Przez ostatnie ~10lat FW istotnie ewaluował i moim zdaniem jest obecnie niedoceniony - spełnia wszystkie wymogi firewalla "programowego". Zdarzają się oczywiście "security bypass vulnerability", ale wpis nie dotyczy porównania różnych rozwiązań, oraz ich wad i zalet. Jest to temat na ciekawą dyskusję, oraz tym bardziej ciekawy flame: należy jednak pamiętać, że zawsze się może znaleźć cwaniak o hakerskim pseudonimie (np. G0r10n), który obejdzie potrójną ścianę i cytując klasyka wejdzie: "emacsem przez sendmail: [youtube=https://www.youtube.com/watch?v=wFXLzr86MQ4]

/sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

Firewall w Windows Server 2012

Zasada działania i ustawienia firewalla w wersjach deskptopowych i serwerowych nie różnią się znacząco.

Podstawowe okno przedstawia osobne ustawienia dla trzech profili:

• Domain profile- komputer podłączony do domeny (czyli tam, gdzie następuje uwierzytelnianie w środowisku AD),
• Private profile - przypisane "do użytkownika", np. w sieci domowej,
• Public profile - np. korzystając z hot-spotu na lotnisku

Użytkownicy Windowsa pewnie znają, że podłączając się do nowej sieci (firewall włączony), zostaniemy poproszeni o zaznaczenie z jakiego profilu sieciowego chcemy korzystać - jest to o tyle wygodne, gdyż profil publiczy może zostać skonfigurowany bardzo restrykcyjnie w celu zwiększenia bezpieczeństwa przy korzystaniu z sieci "zaśmieconych".

Szczegółowe ustawienia umożliwiają konfigurację ustawień dla połączeń przychodzących i wychodzących, monitorowanie (logi), oraz reguł:

Jak wspomniałem wyżej, ustawienia można "wyklikać", jednak niektórym brakuje w Windowsie prostego oskryptowania procesu konfiguracji zapory, jak np. Linuksie (iptables) dostęp do SSH to w większości sytuacji dwie linijki:

/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Netsh

Netsh (Network Shell) jest narzędziem do konfiguracji interfejsów sieciowych (w tym firewalla), wprowadzonym już za czasów Windows 2000. Pomijając setki opcji netsh, warto wspomnieć, że poza wyżej wymienionym "shellem" (interaktywna konsola), polecenia można zamienić w skrypty i zamiast powoli przekopywać się przez komendy, wkleić jedną linijkę zawierającą wszystkie przełączniki:

Pomimo obecnego od kilku lat (genialnego) PowerShell, ja nadal nie wyobrażam sobie niektórych skryptów bez netsh, chociaż Microsoft odgraża się, że w nowszych wersjach Windowsa może już być tylko możliwość administracji ustawieniami tylko z poziomu PS:

W PowerShell składnia bywa dość skomplikowana, jednak bez straszenia... o tym za chwilę.

Przykłady pracy z firewallem

Najpierw przyglądnijmy się wszystkim aktywnym ustawieniom FW.

Wszystkie ustawienia: CMD.exe:

Dla PowerShell:

Bardziej szczegółowo:

Dla testów, lub w niektórych środowiskach konieczne jest wyłącznie firewalla na  pojedycznym, lub na wszystkich profilach:

• Wyłącznie firewalla na wszystkich profilach:

CMD.exe:

PS:

lub:

ewentualnie przy np. opornym Windows 8:

Na tej samej zasadzie można wykonywać operacje na poszczególnych profilach

CMD.exe:

PS:

No a jak już zbyt dużo "namieszaliśmy", przydatna może być komenda przywracająca "ustawienia fabryczne" firewalla. Tu mała uwaga: w ten sposób można sobie łatwo odciąć drogę do serwera, co może być szczególnie kłopotliwe, gdy znajduje się on w odległości 6 godzin lotu samolotem a nie ma kogo poprosić o pomoc...

PS:

Chcę oglądać twoje logi...

W zarządzaniu serwerami warto zwrócić uwagę na logi a szczególnie na ich lokalizację. Nie jest rekomendowane, aby przy zmiane domyślnych wartości (jak maksymalna wielkość pliku) przechowywać go na głównej partycji. W przypadku kompromitacji serwera dużo prościej jest analizować log z zewnętrznego udziału sieciowego (np. NAS), oraz parsować za pomocą programów do monitoringu.

Windows Server 2012 przy ustawieniach standardowych ma maksymalnie 4kB i jest przechowywany w pliku:

(czyli np. %systemroot%\system32\LogFiles\Firewall\pfirewall.log)

Zmiana lokalizacji pliku z poziomu CMD.exe:

Z poziomu PS:

Powyższe komendy zadziałają, ale wypada jednak zmienić domyślną wielkość pliku na większą (zależną od potrzeb), oraz zacząć logować zdarzenia (domyślnie odrzucone i dopuszczone pakiety nie są logowane):

CMD.exe:

PS i przykład dla profilu DOMAIN:

Praca z indywidualnymi regułami

Istotnym zagadnieniem jest praca z indywidualnymi programami i portami - czasem np. chcemy mieć pewność, że tylko jedna usługa ma dostęp do pakietów wychodzących przez port SMTP.

W przypadku ustawień za pomocą "czarodzieja", zostaniemy prowadzeni za rączkę przez kolejne etapy ustawień, tj.:

• Rule Type
• Requirements
• Authentication methods
• Profile
• Name

W drugiej części postaram się przytoczyć przykłady dodawania reguł, portów i reguł za pomocą PS i netsh.