{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"Ewolucja zapory aplikacji webowej: od zap\u00f3r sieciowych do chmurowych system\u00f3w ochrony z uczeniem maszynowym","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

W naszym poprzednim materiale na temat chmur m\u00f3wili\u015bmy, opowiadali\u015bmy<\/a><\/noindex>, jak chroni\u0107 zasoby IT w publicznej chmurze i dlaczego tradycyjne programy antywirusowe nie s\u0105 do tego do ko\u0144ca odpowiednie. W tym wpisie kontynuujemy temat bezpiecze\u0144stwa w chmurze i om\u00f3wimy ewolucj\u0119 WAF oraz co lepiej wybra\u0107: sprz\u0119t, oprogramowanie czy chmur\u0119.\u00a0<\/b><\/p>\n

\"Ewolucja
\n<\/p>\n

Czym jest WAF<\/h3>\n

\nPonad 75% atak\u00f3w haker\u00f3w skierowanych jest na luki w aplikacjach internetowych i stronach: takie ataki s\u0105 zazwyczaj niedostrzegane przez infrastruktur\u0119 i us\u0142ugi bezpiecze\u0144stwa informacji. Luki w aplikacjach internetowych nios\u0105 ze sob\u0105 ryzyko kompromitacji i oszustw zwi\u0105zanych z kontami oraz danymi osobowymi u\u017cytkownik\u00f3w, has\u0142ami i numerami kart kredytowych. Ponadto, luki na stronie internetowej stanowi\u0105 punkt wej\u015bcia dla cyberprzest\u0119pc\u00f3w do sieci korporacyjnej.<\/p>\n

Web Application Firewall (WAF) to ekran ochronny, kt\u00f3ry blokuje ataki na aplikacje internetowe: SQL injection, cross-site scripting, zdalne wykonywanie kodu, ataki brute-force i bypassowanie autoryzacji. W tym r\u00f3wnie\u017c ataki wykorzystuj\u0105ce luki zero-day. Zapory aplikacyjne zapewniaj\u0105 ochron\u0119 poprzez monitorowanie tre\u015bci stron internetowych, w tym HTML, DHTML i CSS, oraz filtrowanie potencjalnie szkodliwych \u017c\u0105da\u0144 po HTTP\/HTTPS.
\n<\/a><\/noindex><\/p>\n

Jakie by\u0142y pierwsze rozwi\u0105zania?<\/h3>\n

\nPierwsze pr\u00f3by stworzenia Web Application Firewall podejmowano ju\u017c na pocz\u0105tku lat 90. Znamy co najmniej trzech in\u017cynier\u00f3w, kt\u00f3rzy pracowali w tej dziedzinie. Pierwszym by\u0142 profesor informatyki Gene Spafford z Uniwersytetu Purdue. Opisa\u0142 on architektur\u0119 zapory aplikacyjnej z proxy i w 1991 roku opublikowa\u0142 j\u0105 w ksi\u0105\u017cce \u201ePraktyczna bezpiecze\u0144stwo UNIX\u201d<\/a><\/noindex>.<\/p>\n

Drugim i trzecim byli specjali\u015bci ds. bezpiecze\u0144stwa informacji William Cheswick i Marcus Ranum z Bell Labs. Opracowali oni jeden z pierwszych prototyp\u00f3w zap\u00f3r aplikacyjnych. Rozpowszechnia\u0142o go przedsi\u0119biorstwo DEC \u2014 produkt zosta\u0142 wydany pod nazw\u0105 SEAL (Secure External Access Link). <\/p>\n

Jednak SEAL nie by\u0142 pe\u0142noprawnym rozwi\u0105zaniem WAF. Stanowi\u0142 on klasyczn\u0105 zapor\u0119 sieciow\u0105 z rozszerzon\u0105 funkcjonalno\u015bci\u0105 \u2014 mo\u017cliwo\u015bci\u0105 blokowania atak\u00f3w na FTP i RSH. Z tego powodu pierwszym rozwi\u0105zaniem WAF uznawanym dzisiaj jest produkt firmy Perfecto Technologies (p\u00f3\u017aniej Sanctum). W 1999 roku firma ta przedstawi\u0142a<\/a><\/noindex> system AppShield. At that time, Perfecto Technologies was developing cybersecurity solutions for e-commerce, and the target audience for their new product became online stores. AppShield could analyze HTTP requests and block attacks based on dynamic cybersecurity policies.<\/p>\n

Around the same time as AppShield (in 2002), the first open-source WAF emerged. It became ModSecurity<\/a><\/noindex>. It was created to promote WAF technologies and is still supported by the IT community (here is its repozytorium na GitHubie<\/a><\/noindex>). ModSecurity blocks application attacks based on a standard set of regular expressions (signatures) \u2014 tools for checking requests against a pattern \u2014 OWASP Core Rule Set<\/a><\/noindex>.<\/p>\n

As a result, the developers succeeded in their goal \u2014 new WAF solutions began to appear on the market, including those built on ModSecurity.<\/p>\n

Three generations \u2014 now that\u2019s history<\/h3>\n

\nIt is customary to distinguish three generations of WAF systems, which have evolved with the development of technologies.<\/p>\n

The first generation<\/b>. It works with regular expressions (or grammars). This includes ModSecurity. The system provider studies the types of attacks on applications and creates patterns that describe legitimate and potentially malicious requests. The WAF checks these lists and decides what to do in a particular situation \u2014 whether to block the traffic or not.<\/p>\n

An example of detection based on regular expressions is the aforementioned project Core Rule Set<\/a><\/noindex> open source. Another example is Naxsi<\/a><\/noindex>, which is also open-source. Systems using regular expressions have a number of drawbacks, particularly when a new vulnerability is discovered, the administrator has to manually create additional rules. In the case of a large IT infrastructure, there could be thousands of rules. Managing such a large number of regular expressions is quite difficult, not to mention that checking them can reduce network performance.<\/p>\n

Wyra\u017cenia regularne maj\u0105 r\u00f3wnie\u017c do\u015b\u0107 wysoki poziom fa\u0142szywych alarm\u00f3w. S\u0142ynny j\u0119zykoznawca Noam Chomsky zaproponowa\u0142 klasyfikacj\u0119 gramatyk, dziel\u0105c je na cztery warunkowe poziomy trudno\u015bci. Zgodnie z t\u0105 klasyfikacj\u0105, za pomoc\u0105 wyra\u017ce\u0144 regularnych mo\u017cna opisa\u0107 jedynie regu\u0142y zapory ogniowej, kt\u00f3re nie przewiduj\u0105 odst\u0119pstw od wzoru. Oznacza to, \u017ce napastnicy mog\u0105 \u0142atwo \"oszuka\u0107\" zapor\u0119 WAF pierwszej generacji. Jedn\u0105 z metod walki z tym jest dodanie do zapyta\u0144 do aplikacji specjalnych symboli, kt\u00f3re nie wp\u0142ywaj\u0105 na logik\u0119 z\u0142o\u015bliwych danych, ale naruszaj\u0105 zasady sygnatur.<\/p>\n

\"Ewolucja
\n
\nDruga generacja<\/b>. Aby obej\u015b\u0107 problemy zwi\u0105zane z wydajno\u015bci\u0105 i dok\u0142adno\u015bci\u0105 WAF, opracowano zapory aplikacji drugiej generacji. Pojawi\u0142y si\u0119 w nich analizatory, kt\u00f3re s\u0105 odpowiedzialne za identyfikacj\u0119 \u015bci\u015ble okre\u015blonych typ\u00f3w atak\u00f3w (na HTML, JS itd.). Te analizatory pracuj\u0105 ze specjalnymi tokenami, opisuj\u0105cymi zapytania (np. zmienna, ci\u0105g, nieznana, liczba). Potencjalnie z\u0142o\u015bliwe sekwencje token\u00f3w s\u0105 przenoszone na osobn\u0105 list\u0119, kt\u00f3ra jest regularnie por\u00f3wnywana z systemem WAF. Po raz pierwszy podej\u015bcie to zaprezentowano na konferencji Black Hat 2012 w postaci biblioteki C\/C++\u00a0libinjection<\/a><\/noindex>, kt\u00f3ra pozwala na wykrywanie SQL injection.<\/p>\n

W por\u00f3wnaniu z WAF pierwszej generacji, wyspecjalizowane analizatory mog\u0105 dzia\u0142a\u0107 szybciej. Jednak nie rozwi\u0105za\u0142y one trudno\u015bci zwi\u0105zanych z r\u0119czn\u0105 konfiguracj\u0105 systemu w przypadku nowych z\u0142o\u015bliwych atak\u00f3w. <\/p>\n

\"Ewolucja
\n
\nTrzecia generacja<\/b>. Ewolucja w logice wykrycia trzeciej generacji polega na zastosowaniu metod uczenia maszynowego, kt\u00f3re pozwalaj\u0105 jak najbardziej zbli\u017cy\u0107 gramatyk\u0119 wykrywania do rzeczywistej gramatyki SQL\/HTML\/JS chronionych system\u00f3w. Ta logika wykrywania jest w stanie dostosowa\u0107 maszyn\u0119 Turinga do obj\u0119cia rekurencyjnie wyliczanych gramatyk. Co wi\u0119cej, wcze\u015bniej zadanie stworzenia dostosowywalnej maszyny Turinga by\u0142o nierozwi\u0105zywalne, a\u017c do momentu opublikowania pierwszych bada\u0144 nad neuronowymi maszynami Turinga.<\/p>\n

Uczenie maszynowe daje unikaln\u0105 mo\u017cliwo\u015b\u0107 dostosowania ka\u017cdej gramatyki do r\u00f3\u017cnych typ\u00f3w atak\u00f3w bez r\u0119cznego tworzenia list sygnatur, jakie by\u0142y wymagane w detekcji pierwszej generacji, oraz bez opracowywania nowych tokenizator\u00f3w\/parser\u00f3w dla nowych typ\u00f3w atak\u00f3w, takich jak ataki Memcached, Redis, Cassandra, SSRF, jak wymagano w drugiej generacji. <\/p>\n

\u0141\u0105cz\u0105c wszystkie trzy pokolenia logiki detekcji, mo\u017cemy narysowa\u0107 nowy diagram, na kt\u00f3rym czerwonym konturem zaznaczone jest trzecie pokolenie detekcji (rys. 3). Do tego pokolenia nale\u017cy jedno z rozwi\u0105za\u0144, kt\u00f3re wdra\u017camy w chmurze we wsp\u00f3\u0142pracy z \"OnSec\", deweloperem platformy adaptacyjnej ochrony aplikacji internetowych i API Valarm. <\/p>\n

Obecnie w logice detekcji wykorzystywana jest informacja zwrotna z aplikacji do automatycznej kalibracji. W ramach uczenia maszynowego ta p\u0119tla informacyjna nazywana jest \"wzmocnieniem\". Zwykle istnieje jeden lub kilka typ\u00f3w takiego wzmocnienia:<\/p>\n