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ę:
Termin ten może odnosić się zarówno do dedykowanego sprzętu komputerowego wraz ze specjalnym oprogramowaniem, jak i do samego oprogramowania blokującego niepowołany dostęp do komputera. Do jego podstawowych zadań należy filtrowanie połączeń wchodzących i wychodzących oraz tym samym odmawianie żądań dostępu uznanych za niebezpieczne.
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:
“Microsoft recommends that you transition to Windows PowerShell if you currently use netsh to configure and manage Windows Firewall with Advanced Security. Type Get-Command -Module NetSecurity at the Windows PowerShell prompt to view a list of commands to manage Windows Firewall with Advanced Security. Visit http://go.microsoft.com/fwlink/?LinkId=217627 for additional information about PowerShell commands for Windows Firewall with Advanced Security. etsh advfirewall>”
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:
netsh dump | more
Dla PowerShell:
Get-NetFirewallProfile
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:
netsh advfirewall set allprofiles state off
PS:
Set-NetFirewallProfile -All -Enabled “true”
lub:
Set-NetFirewallProfile -name * -Enabled “false”
ewentualnie przy np. opornym Windows 8:
Import-Module NetSecurity -ea Stop ; Get-NetFirewallProfile | Set-NetfirewallProfile -Enabled False
Na tej samej zasadzie można wykonywać operacje na poszczególnych profilach
CMD.exe:
netsh advfirewall set domainprofile state off netsh advfirewall set privateprofile state off netsh advfirewall set publicprofile state off
PS:
Set-NetFirewallProfile -name * -Enabled “false”
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...
netsh advfirewall reset
PS:
Set-NetFirewallProfile -name domain -DisabledInterfaceAliases NotConfigured
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:
%systemroot%\system32\LogFiles\Firewall\pfirewall.log
(czyli np. %systemroot%\system32\LogFiles\Firewall\pfirewall.log)
Zmiana lokalizacji pliku z poziomu CMD.exe:
netsh advfirewall set currentprofile logging filename "X:\LOGS\SERV1\pfirewall.log"
Z poziomu PS:
Set-NetFirewallProfile -name domain -LogFileName “X:\LOGS\SERV1\pfirewall.log”
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:
netsh advfirewall set currentprofile logging filename "X:\LOGS\SERV1\pfirewall.log 1234096 enable enable"
PS i przykład dla profilu DOMAIN:
Set-NetFirewallProfile -name domain -LogMaxSizeKilobytes 1234096 Set-NetFirewallProfile -name domain -LogAllowed true -LogBlocked true
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.