Filtreleme Düğümü Günlükleriyle Çalışma¶
Bu makale, bir Wallarm filtreleme düğümünün günlük dosyalarını nasıl bulacağınız konusunda yol gösterir.
Günlük dosyaları /opt/wallarm/var/log/wallarm
dizininde bulunur. Karşılaşacağınız günlük dosyalarının dökümü ve her birinin içerdiği bilgi türü aşağıdadır:
-
api-firewall-out.log
: API specification enforcement günlüğü. -
appstructure-out.log
(yalnızca Docker konteynerlerinde): API Discovery modülü etkinliği günlüğü. -
wstore-out.log
(NGINX Node 5.x ve daha eski sürümlerdetarantool-out.log
): postanalytics modülünün işlemlerinin günlüğü. -
wcli-out.log
: çoğu Wallarm servisinin günlükleri; kaba kuvvet tespiti, saldırıların Cloud’a aktarımı ve düğümün Cloud ile senkronizasyon durumu vb. dahil. -
supervisord-out.log
: servis başlatmaları, durum değişiklikleri ve uyarılar dahil olmak üzere Supervisor süreç yönetimi günlükleri. -
go-node.log
: Native Node günlükleri.
NGINX‑Tabanlı Filtreleme Düğümü için Genişletilmiş Günlüklemeyi Yapılandırma¶
NGINX, işlenen isteklerin günlüklerini (erişim günlükleri) varsayılan olarak önceden tanımlı combined
günlük biçimini kullanarak ayrı bir günlük dosyasına yazar.
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $request_id $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" ';
Gerekirse diğer NGINX değişkenleriyle birlikte bir veya birkaç filtre düğümü değişkeni ekleyerek özel bir günlük biçimi tanımlayıp kullanabilirsiniz. NGINX günlük dosyası, filtre düğümünün çok daha hızlı teşhis edilmesine olanak tanır.
Filtre Düğümü Değişkenleri¶
NGINX günlük biçimini tanımlarken aşağıdaki filtre düğümü değişkenlerini kullanabilirsiniz:
Ad | Tür | Değer |
---|---|---|
request_id | String | İstek tanımlayıcısı Şu biçimdedir: a79199bcea606040cc79f913325401fb |
wallarm_request_cpu_time | Float | Filtreleme düğümünün bulunduğu makinenin CPU’sunun isteği işlerken harcadığı süre (saniye cinsinden). |
wallarm_request_mono_time | Float | CPU’nun isteği işlerken harcadığı süre + kuyruktaki süre (saniye cinsinden). Örneğin, istek 3 saniye kuyrukta bekledi ve CPU tarafından 1 saniyede işlendi ise:
|
wallarm_serialized_size | Integer | Serileştirilmiş isteğin boyutu (bayt cinsinden) |
wallarm_is_input_valid | Integer | İsteğin geçerliliği0 - istek geçerli. İstek filtre düğümü tarafından kontrol edilmiştir ve LOM kuralları ile eşleşmektedir.1 - istek geçersiz. İstek filtre düğümü tarafından kontrol edilmiştir ve LOM kuralları ile eşleşmemektedir. |
wallarm_attack_type_list | String | İstekte tespit edilen saldırı türleri. Türler metin formatında sunulur:
| simgesiyle listelenir. Örneğin: XSS ve SQLi saldırıları tespit edilirse değişken değeri xss|sqli olur. |
wallarm_attack_type | Integer | İstekte tespit edilen saldırı türleri. Türler bit dizesi formatında sunulur:
6 olur. |
wallarm_attack_point_list (NGINX node 5.2.1 veya daha yenisi) | String | Kötü niyetli payload içeren istek noktalarını listeler. Bir nokta birden fazla parser tarafından ardışık olarak işlenirse, bu parser’lar değere dahil edilir. Kötü niyetli payload içeren birden fazla nokta | ile birleştirilir.Örnek: [post][json][json_obj, 'data'][base64] ifadesi, JSON gövdesindeki base64 olarak kodlanmış data parametresinde kötü niyetli bir payload tespit edildiğini gösterir.Bu günlük verilerinin, Wallarm Console UI içinde sunulan basitleştirilmiş, kullanıcı dostu görünümden farklı olabileceğini unutmayın. |
wallarm_attack_stamp_list (NGINX node 5.2.1 veya daha yenisi) | String | Bir istek içinde tespit edilen her saldırı işareti için dahili Wallarm kimliklerini listeler. Birden fazla işaret kimliği | ile birleştirilir. Aynı saldırı işareti birden fazla ayrıştırma aşamasında tespit edilirse kimlikler tekrarlanabilir. Örneğin, union+select+1 gibi bir SQLi saldırısı 7|7 döndürebilir ve birden fazla tespiti gösterebilir.Bu günlük verilerinin, Wallarm Console UI içinde sunulan basitleştirilmiş, kullanıcı dostu görünümden farklı olabileceğini unutmayın. |
wallarm_block_reason (NGINX node 6.4.0 veya daha yenisi) | String | Engelleme nedeni (uygulanabilirse). Nedenler metin formatında sunulur:
|
Yapılandırma Örneği¶
Aşağıdaki değişkenleri içeren wallarm_combined
adlı genişletilmiş günlükleme biçimini belirtmeniz gerektiğini varsayalım:
-
combined
biçiminde kullanılan tüm değişkenler -
tüm filtre düğümü değişkenleri
Bunu yapmak için aşağıdaki adımları uygulayın:
-
Aşağıdaki satırlar istenen günlükleme biçimini tanımlar. Bunları NGINX yapılandırma dosyasının
http
bloğuna ekleyin.log_format wallarm_combined '$remote_addr - $remote_user [$time_local] ' '"$request" $request_id $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list $wallarm_attack_point_list $wallarm_attack_stamp_list';
-
Aynı bloğa aşağıdaki yönergeyi ekleyerek genişletilmiş günlükleme biçimini etkinleştirin:
access_log /var/log/nginx/access.log wallarm_combined;
İşlenen istek günlükleri
/var/log/nginx/access.log
dosyasınawallarm_combined
biçiminde yazılacaktır.Koşullu Günlükleme
Yukarıda listelenen yönerge ile, bir saldırıyla ilişkili olmayanlar da dahil olmak üzere tüm işlenen istekler bir günlük dosyasına yazılır.
Yalnızca bir saldırının parçası olan istekler için günlük yazmak üzere koşullu günlüklemeyi yapılandırabilirsiniz (bu isteklerde
wallarm_attack_type
değişkeninin değeri sıfır değildir). Bunu yapmak için, anılan yönergeye bir koşul ekleyin:access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;
Bu, günlük dosyası boyutunu küçültmek veya bir filtre düğümünü SIEM çözümleri ile entegre ediyorsanız faydalı olabilir.
-
Kullandığınız işletim sistemine bağlı olarak aşağıdaki komutlardan birini çalıştırarak NGINX’i yeniden başlatın:
Ayrıntılı bilgi
NGINX’te günlüklemeyi yapılandırma hakkında ayrıntılı bilgi için bu bağlantıya gidin.