Showing posts with label Intrusion Prevention System. Show all posts
Showing posts with label Intrusion Prevention System. Show all posts

Thursday, May 25, 2017

Next-Generation IPS Requirements

From the White Paper of "McAfee Network Security Platform: The Next-Generation Network IPS"

Requirements for next-generation network intrusion prevention

Gartner Research recently introduced several new criteria for “next-generation network intrusion prevention” that, if adopted, will help organizations deal with the new threat landscape. The Gartner definition for next-generation network intrusion prevention includes the following:

  • Standard first-generation IPS capabilities to support vulnerability-facing signatures and threat-facing signatures: An IPS engine that can perform detection and blocking at wire speeds and rapidly develop and deploy signatures, is a primary characteristic. Integration can include features such as providing suggested blocking at the firewall, based on IPS inspection.
  • Application awareness and full-stack visibility to identify applications and enforce network security policy: This needs to occur at the application layer, independent of the port and protocol, rather than only ports, protocols, and services. Examples include the ability to block families of attacks, based on identifying hostile applications.
  • Context awareness to bring information from sources outside the IPS to make improved blocking decisions or to modify the blocking rule base: Examples include using directory integration to tie decisions to user identities and using vulnerability, patching state and geolocation information (such as where the source is from or where it should be from) to make more effective blocking decisions. It could also include integrating reputation feeds, such as blacklists and whitelists of addresses.
  • Content awareness of various file types and communications: It should be able to inspect and classify inbound executables and other similar file types, such as PDF and Microsoft Office files (which have already passed through antivirus screening), as well as outbound communications. In addition, it should make pass, quarantine, or drop decisions in near real time.
  • Agile engine: It should support upgrade paths for the integration of new information feeds and new techniques to address future threats, including hitless upgrades, global threat intelligence integration, scalable hardware, signature updates, Snort-capable), packet capture, and complementary solutions (Source: Gartner, Defining Next-Generation Network Intrusion Prevention, 2011)

Wednesday, September 7, 2016

Suricata "Content" Parametresi

Suricata saldırı tespit/engelleme sistemi -beklendiği üzere- şifrelenmemiş paketlerin "veri" (payload) kısmına da bakarak saldırı örüntülerini (pattern) tespit edebilmektedir.
 
Bu tespitleri yapabilmek için Suricata imzalarında bir "content" alanı bulunmaktadır. Bu yazımızda Suricata imzalarındaki "content" alanıyla ilgili bilgi vermeye çalışacağız.
 
Öncelikle içeriğinde "content" geçen rastgele bir örnek imza aşağıda verilmiştir:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Lowercase User-Agent header purporting to be MSIE"; flow:established,to_server; content:"user-agent|3a 20|Mozilla/4.0|20|(compatible|3b 20|MSIE|20|"; http_header; content:!"|0d 0a|VIA|3a 20|"; http_header; classtype:trojan-activity; sid:2012607; rev:4;)

Örnekten de görülebileceği gibi bir Suricata imzasının içerisinde birden fazla "content" alanı da olabilmektedir.
 
"content" parametresiyle, gelen paketin veri (payload) kısmında aranacak harf-rakam kombinasyonunun tırnak içerisine yazılması gerekiyor. Örneğin Suricata imzasında content:"SALDIRIYORUM ULEYYNNN!!" yazmış olduğunuz takdirde Suricata, gelen paketlerin veri kısımlarında "SALDIRIYORUM ULEYYNNN!!" içeriği olan paketleri tespit edecektir.
 
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"YABAN SALDIRISI!!!"; flow:established,to_server; content:"SALDIRIYORUM ULEYYNNN!!"; classtype:yaban-activity; sid:2222220; rev:3;)
 
"content" parametresinin içerisine harflerin, rakamların ya da özel karakterlerin hexadecimal karşılıkları da yazılabilmektedir.

Suricata imzasının içerisine yazacağımız; content: "|53 41 4c 44 49 52 49 59 4f 52 55 4d 20 55 4c 45 59 59 4e 4e 4e 21 21|" ile content:"SALDIRIYORUM ULEYYNNN!!" aynı anlama gelmektedir. Harflere karşılık gelen hexadecimal değerler aşağıda verilmiştir.
S = 53, A =41, L = 4c, D = 44, I = 49, R = 52,I = 49, Y = 59, O = 4f, R = 52, U = 55, M = 4d, = 20, U = 55, L = 4c, E = 45, Y = 59, Y = 59, N = 4e, N = 4e, N = 4e, ! = 21, ! = 21
Normal karakterler iki adet "<örnek>" (tırnak) arasına yazılırken, hexadecimal karakterler iki tane |<örnek>| (pipe) arasına yazılmaktadır.

Bazı karakterler imzanın okunmasında karışıklığa yol açtıklarından dolayı bu karakterleri Suricata imzasının içerisine iki tırnak arasına yazmak mümkün olmamaktadır. Bu karakterleri imzanın içerisine mutlaka hexadecimal olarak yazmak gerekmektedir. Bu karakterler ve hexadecimal karşılıkları aşağıda verilmiştir:
" = |22|
; = |3B|
: = |3A|
| = |7C|
Buna bir örnek vermek gerekirse; Suricata imzasının içerisine content:"http://" yazılamamaktadır. Bunun yerine content:"http|3A|//" yazılabilmektedir. 
"content" parametresinin içeriği büyük-küçük harf duyarlıdır. Yani content:"SALDIRIYORUM ULEYYNNN!!" ile content:"saldiriyorum uleyynnn!!" aynı anlama gelmemektedir. Büyük-küçük harf duyarlılığımı iptal etmek için imzanın içerisinde "nocase" parametresinin kullanılması gerekmektedir.
 
Örneğin; content:"SALDIRIYORUM ULEYYNNN!!"; nocase; ile content:"saldiriyorum uleyynnn!!"; nocase; aynı anlama gelmektedir.
Peki bir Suricata imzası içinde iki adet "content" parametresi olması durumunda Suricata nasıl davranmaktadır? Öncelikle bu, anlaması biraz zor bir algoritmaya dayanmaktadır. Bu algoritmanın ayrıntılarına girmeyeceğiz. Genel olarak; "content" parametresi içerisindeki "daha uzun" (longer) ve "en çok değişen" (varied) harf/rakam kombinasyonları tercih edilmektedir.
 
Örneğin: Suricata imzası içerisinde content:"SALDIRIYORUM ULEYYNNN!!" ve content:"YAKALA oni!" parametrelerinin bulunduğunu kabul edelim. Birinci "content"in içerisinde 23 karakter bulunmakta, ikinci "content"in içerisinde de 11 karakter bulunmaktadır. Bu durumda Suricata content:"SALDIRIYORUM ULEYYNNN!!" parametresine öncelik verecektir.
 
"En çok değişen" kavramına da bir örnek vermeye çalışalım: content:"SALDIRIYORUM ULEYYNNN!!" ile content:"S|41|LD|49|R|49|YORUM ULEYY|4E||4E||4E|!!" arasında bir karar verilmek istenmesi durumunda Suricata content:"S|41|LD|49|R|49|YORUM ULEYY|4E||4E||4E|!!" parametresini tercih edecektir. Çünkü ikinci "content"in bizim tabirimizle "değişen parçaları" daha fazladır. (|41|, |49| vb...)

Suricata imzalarında "daha az değişen" veya "daha kısa" olan değişkenlere öncelik vermek istediğimiz takdirde de "fast_pattern" adlı parametreyi kullanmamız gerekmektedir. Örneğin, Suricata'ya daha uzun ve değişeni daha çok olan content:"SALD|49|R|49|YORUM ULEYY|4E||4E||4E|!!" yerine daha kısa ve değişeni olmayan content:"az bi dakka!" parametresini tercih ettirmek istiyorsak bunların imzanın içerisine aşadaki gibi yazılması gerekmektedir:
content:"SALD|49|R|49|YORUM ULEYY|4E||4E||4E|!!"; content:"az bi dakka!"; fast_pattern;
 
(İki adet "en çok değişen" ve iki adet "daha uzun" parametrelerine sahip olan "content" için bkz. https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Fast_Pattern_Determination_Explained)
 
Suricata imzasındaki "content" parametresi http trafiği için de özelleştirilmiştir. "content" parametresinin http trafiğinde nasıl kullanıldığını da başka bir yazıya bırakalım.