Ana içeriğe geç

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ümlerde tarantool-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_request_cpu_time":1
  • "wallarm_request_mono_time":4
wallarm_serialized_size Integer Serileştirilmiş isteğin boyutu (bayt cinsinden)
wallarm_is_input_valid Integer İsteğin geçerliliği
0 - 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:
  • xss
  • sqli
  • rce
  • xxe
  • ptrav
  • crlf
  • redir
  • nosqli
  • infoleak
  • overlimit_res
  • data_bomb
  • vpatch
  • ldapi
  • scanner
  • mass_assignment
  • ssrf
  • ssi
  • mail_injection
  • ssti
  • invalid_xml
  • file_upload_violation
  • API specification violations:
    • undefined_endpoint
    • undefined_parameter
    • missing_auth
    • missing_parameter
    • invalid_parameter_value
    • invalid_request
    • processing_overlimit
  • blocked_source
  • GraphQL saldırıları:
    • gql_aliases
    • gql_debug
    • gql_depth
    • gql_doc_size
    • gql_docs_per_batch
    • gql_introspection
    • gql_value_size
  • Trigger tabanlı saldırılar (tür yalnızca bir trigger kaynağı denylist’e veya graylist’e aldığında döndürülür):
  • API Abuse (tür yalnızca modül kaynağı denylist’e veya graylist’e aldığında döndürülür):
    • bot
    • api_abuse
    • account_takeover
    • security_crawlers
    • scraping
    • resource_consumption
  • credential_stuffing
Bir istek içinde birden fazla saldırı türü tespit edilirse, türler | 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:
  • 0x00000000 - saldırı yok - "0"
  • 0x00000002 - xss - "2"
  • 0x00000004 - sqli - "4"
  • 0x00000008 - rce - "8"
  • 0x00000010 - xxe - "16"
  • 0x00000020 - ptrav - "32"
  • 0x00000040 - crlf - "64"
  • 0x00000080 - redir - "128"
  • 0x00000100 - nosqli - "256"
  • 0x00000200 - infoleak - "512"
  • 0x20000000 - overlimit_res - "536870912"
  • 0x40000000 - data_bomb - "1073741824"
  • 0x80000000 - vpatch - "2147483648"
  • 0x00002000 - ldapi - "8192"
  • 0x4000 - scanner - "16384"
  • 0x20000 - mass_assignment - "131072"
  • 0x80000 - ssrf - "524288"
  • 0x02000000- ssi - "33554432"
  • 0x04000000 - mail_injection - "67108864"
  • 0x08000000 - ssti - "134217728"
  • 0x10000000 - invalid_xml - "268435456"
  • 0x8000000000000- file_upload_violation - 2251799813685248
  • API Abuse (bot saldırıları):
    • 0x10000000000000 - resource_consumption - 4503599627370496
  • API specification violations:
    • 0x100000000 - undefined_endpoint - "4294967296"
    • 0x200000000 - undefined_parameter - "8589934592"
    • 0x400000000- missing_auth - "17179869184"
    • 0x800000000- missing_parameter - "34359738368"
    • 0x1000000000 - invalid_parameter_value - "68719476736"
    • 0x2000000000 - invalid_request - "137438953472"
    • 0x4000000000 - processing_overlimit - "274877906944"
  • 0x100000 - blocked_source - "1048576"
  • GraphQL saldırıları:
    • 0x20000000000 - gql_aliases - "2199023255552"
    • 0x200000000000 - gql_debug - "35184372088832"
    • 0x8000000000 - gql_depth - "549755813888"
    • 0x40000000000 - gql_doc_size - "4398046511104"
    • 0x80000000000 - gql_docs_per_batch - "8796093022208"
    • 0x100000000000 - gql_introspection - "17592186044416"
    • 0x10000000000 - gql_value_size - "1099511627776"
  • Trigger tabanlı saldırılar (tür yalnızca bir trigger kaynağı denylist’e veya graylist’e aldığında döndürülür):
    • 0x400 - brute - "1024"
    • 0x800 - dirbust - "2048"
    • 0x10000 - bola - "65536"
    • 0x400000 - vectors - "4194304"
  • API Abuse (tür yalnızca modül kaynağı denylist’e veya graylist’e aldığında döndürülür):
    • 0x8000 - bot - "32768"
    • 0x200000 - api_abuse - "2097152"
    • 0x400000000000 - account_takeover - "70368744177664"
    • 0x800000000000 - security_crawlers - "140737488355328"
    • 0x1000000000000 - scraping - "281474976710656"
  • 0x1000000 - credential_stuffing - "16777216"
Bir istek içinde birden fazla saldırı türü tespit edilirse, değerler toplanır. Örneğin: XSS ve SQLi saldırıları tespit edilirse değişken değeri 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:
  • not blocked - istek engellenmedi (örneğin, allowlisted IP üzerinden gönderildi).
  • antibot - istek API Abuse Prevention modülü tarafından engellendi.
  • attack mask=<MASK> - bir saldırı tespit edildi. MASK, bit dizesi formatında saldırı türüdür (ör. mask=0000000000000020 bir ptrav saldırısını gösterir). Tüm saldırı türleri yukarıdaki wallarm_attack_type bölümünde listelenmiştir.
  • overlimit - maskede bir resource overlimit saldırısı tespit edildi.
  • acl blacklist SRC TYPE - istek denylist’te olan istek kaynakları nedeniyle engellendi. Değişken bölümler aşağıdaki değerlere sahip olabilir:
      SRC:
      • ip
      • country
      • proxy
      • datacenter
      • tor
    • TYPE:
      • blocked_source
      • brute
      • dirbust
      • bola
      • bot
      • api_abuse
      • vectors
      • account_takeover
      • security_crawlers
      • scraping
      • resource_consumption
      • session_anomaly
      • enum
      • rate_limit
      • query_anomaly
      • ai_prompt_injection
      • ai_prompt_retrieval

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:

  1. 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';
    
  2. 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ına wallarm_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.

  3. Kullandığınız işletim sistemine bağlı olarak aşağıdaki komutlardan birini çalıştırarak NGINX’i yeniden başlatın:

    sudo systemctl restart nginx
    
    sudo service nginx restart
    
    sudo systemctl restart nginx
    
    sudo systemctl restart nginx
    
    sudo systemctl restart nginx
    

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.