Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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:

/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:

Get-NetFirewallProfile -Name Public | Get-NetFirewallRule | more

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.

 

windows bezpieczeństwo

Komentarze

0 nowych
  #1 29.01.2013 21:41

Dla mnie wpis może okazać się przydatny. Obecnie automatyzuję w pracy konfigurację środowiska i instalację aplikacji pod pingwinem ale pojawiają się też serwery z okienkami, nie było czasu usiąść do tego ale może po tym wpisie się zbiorę i nad tym też uda się popracować... tylko czasu jakoś mało.

Druedain   14 #2 29.01.2013 23:12

1. Przepraszam, że tekst przeleciałem… Po prostu nie moja działka.
2. Taka rada na przyszłość, by polecenia dla konsoli wrzucać do znacznika [code], a nie jako cytat, bo dużo może na tym zyskać względem czytelności wpis :) .

_qaz7   6 #3 29.01.2013 23:32

Powodem dla którego windowsowy firewall jest traktowany jako narzędzie drugiej kategorii jest brak interakcji z użytkownikiem. W otoczeniu biurowym gdzie admin odgórnie ustawia reguły to może i dobre, ale w domowym już nie. W firewallach 3rd party zazwyczaj jest inaczej - interaktywnie - i przy połączeniu aplikacji która nie podlega regułom dostajemy pytanie co zrobić - np. allow/block always, allowa/block once, czy create rule. I do pracy w domu to jest znacznie wygodniejsze, bo dokładnie wiemy co kiedy i z czym chce się połączyć nie przeglądając logów.

W windowsowym natomiast tej interakcji brak - jeśli aplikacja której NIE MA na liście reguł chce się połączyć z siecią to w zależności od tego czy FW pracuje w trybie block czy allow - zostanie automatycznie albo zblokowana albo przepuszczona beż żadnej interakcji, beż żadnego pytania co z takim połączeniem zrobić - a przecież często nawet nie wiemy czy aplikacja chce się łączyć i bez loga się nie dowiemy - słabe.

Po drugie, są sytuacje w której taki popup dostajemy - z możliwością zablokowania połączenia, ale informacje o tym połączeniu są bardzo skromne -nie ma np. informacji z jakim portem chce się łączyć aplikacja, nie pamiętam też, czy jest info o adresie/IP a dodatkowo FW potrafi wywalić takie info o aplikacji nawiązującej połączeniu: "serwer {B415CD14-B45D-4BCA-B552-B06175C38606}" i żeby było mniej fajnie, to nazwa ta jest wyświetlona w kontrolce static, wiec nie dało się jej wyciąć i wkleić do regedita/google, trzeba z palca ją przepisywać.

Po trzecie, gdy dostajemy popupu z 3rd party firewalla o tym, że aplikacja chce się połączyć z czymś i co z tym fantem chcemy zrobić, to do czasu naszego wyboru połączenie nie jest przepuszczane, ale timeout na połączenie nie jest naliczany, wiec nie dochodzi do sytuacji, że odpaliliśmy aplikację, poszliśmy na herbatę,wracamy a tam błąd, że nie ma połączenia z netem - połączenie wisi i czeka. W windowsowym firewallu jest inaczej - jak jest w trybie allow, to aplikacja łączy się jak chce, a popup wisi - przez co może się wydawać, że fw nie działa.

Autor edytował komentarz.
bachus   20 #4 30.01.2013 10:16

@Druedain: ta, też już widzę że się ciężko czyta, będę robił jako CODE
@_qaz7: ja bardziej pisałem z perspektywy power usera. W przypadku desktopów i standardowego użytkownika masz rację.

  #5 30.12.2013 15:01

polecenie Set-NetFirewallProfile -name domain -DisabledInterfaceAliases NotConfigured
nie przywraca ustawień fabrycznych zapory.

  #6 30.12.2013 15:22

ustawienia fabryczne można przywrócić w ten sposób:

$fw=New-Object -ComObject HNetCfg.FwMgr
$fw.RestoreDefaults()

xomo_pl   21 #7 30.12.2013 16:52

generalnie Windows Firewall w Viście dostał niezłego odświeżenia i rozbudowy. Od tamtej pory spokojnie można go stosować zamiast kupować osobno pakiety Internet Security. Owszem, nadal jest uboższy w możliwości (uboga interakcja na lini zapora-użytkownik) ale swoje zadanie spełnia całkiem dobrze.

co do wyłączania firewalla to moim zdaniem prościej zamiast komendy wejść w ustawienia i kliknąć "wyłącz Firewall"...

@bachus, świetny wpis, leci do zakładek bo może się przydać :)