[DajSięPoznać#18] Hardening IIS

Wstęp

Pomimo gigantycznych zmian nadchodzących w świecie ASP.NET, wprowadzenia nowego serwera Kestrel, na ten moment naturalnym serwerem aplikacyjnym dla aplikacji WebAPI jest IIS. Skoro już decydujemy się na wystawienie naszej aplikacji do publicznej sieci, warto pamiętać o kilku drobnych ustawieniach, które mogą utrudnić życie potencjalnym intruzom.

Nagłówki HTTP

Zaleca się, by nie udostępniać informacji na temat technologii serwerowych czy używanych frameworków. Ułatwia to życie atakującym, którzy mogą szukać znanych dziur w bazach typu exploit.db lub na rynku tzw. 0-dayów.

ASP.NET dodaje od siebie nagłówki takie jak: ServerX-Powered-By, X-AspNet-Version. Pierwszy z nich można wyłączyć poprzez URL Rewrite lub własny moduł IIS, przykłady na stackoverflowX-Powered-By można wyłączyć poniższą komendą PowerShella:

Remove-WebConfigurationProperty -PSPath MACHINE/WEBROOT/APPHOST -Filter system.webServer/httpProtocol/customHeaders -Name . -AtElement @{name='X-Powered-By'}

 

Wyłączenie X-AspNet-Version wymaga dodania takiego wpisu do rootowego web.configa:

<system.web>  
  <httpRuntime enableVersionHeader="false" />
</system.web>

 

Algorytmy kryptograficzne

W ostatnich latach pojawiło się kilka podatności wokół algorytmów wymiany kluczy i Transport Layer Seucity, takich jak logjam czy POODLE. Na każdym serwerze aplikacyjnym warto wyłączyć skompromitowany algorytmy kryptograficzne.Służy do tego świetny tool: IIS Crypto . Wystarczy wybrać opcję “Best practices” i program sam ustawi odpowiednie wartości w rejestrach systemu.

HTTP Strict Transport Security

Aplikacje webowe wystawiane są po HTTPS głównie po to, by zapobiec podsłuchiwaniu ruchu i zapewnić użytkownikom odpowiedni poziom poufności (np. podczas przesyłania hasła). Ustawiając binding w IIS, nie możemy wystawić strony tylko na porcie 443, gdyż użytkownicy będą często próbowali odwiedzić stronę przez HTTP. Rozwiązaniem jest przekierowanie z http na https, tak, by użytkownik przed rozpoczęciem interakcji ze stroną zestawił szyfrowane połączenie. Dla przekierowań typu Permanent Redirect przeglądarka zapisze do swojego cache tą informację i od razu będzie kliencko przekierowywała użytkownika do https.

Problemy ? Ataki man in the middle (łatwe do zasymulowania fiddlerem) oraz linki rozpoczynające się od http, w które nieświadomy user może kliknąć załączając cookie z id swojej sesji.

Oba te problemy adresuje standard HSTS. Przeglądarka po otrzymaniu od serwera specjalnego nagłówka podmieni automatycznie każdy link na https (przed interakcją z serwerem) i uniemożliwi jakiekolwiek próby połączeń http. Ustawienie w web.config:

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Strict-Transport-Security" value="max-age=31536000"/>
        </customHeaders>
    </httpProtocol>
</system.webServer>

 

X-Frame-Options

Clickjacking jest techniką polegającą na osadzaniu strony – ofiary w ramce iFrame’a na złośliwej stronie, która wizualnie przykryje pierwotną treść, np. przez zabawę z opacity i zachęci użytkownika by klikał w miejscach, które spowodują akcję na stronie ofierze (na której jest zalogowany). Wszystko działa dzięki temu, że po osadzeniu strony w iFrame przeglądarka wykorzysta cookie sesyjne (jeśli jesteśmy zalogowani np w innej karcie przeglądarki). Jest to więc atak typowo kliencki i można pomóc przeglądarkom bronić nieświadomych użytkowników, blokując możliwość wstawiania strony do iFrame. Służy do tego nagłówek X-Frame-Options.

<configuration>
   <system.webServer>
      <httpProtocol>
         <customHeaders>
            <add name="X-Frame-Options" value="DENY" />
         </customHeaders>
      </httpProtocol>
   </system.webServer>
</configuration>

 

Dynamic IP Restrictions

Jest dodatkiem do IIS instalowanym jako funkcja systemu Windows.

adb

Z panelu IIS Managera wybieramy ikonę:

wac

Oprócz możliwości permanentnego blokowania ruchu z danych adresów / domen, możemy ustawić dynamiczne blokowanie, jeśli wykryta zostanie próba ataku typu Denial of Service

dyn IP

Advertisements

One thought on “[DajSięPoznać#18] Hardening IIS

  1. Pingback: [DajSięPoznać] Podsumowanie | When the smoke is going down

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s