Silence OSSEC avvisi di rootcheck

Naviga le tue risposte
3

Sto cercando di disattivare alcuni avvisi di root-root OSSEC come questi: - 

** Alert 1456448991.70239: mail  - ossec,rootcheck,
2016 Feb 26 01:09:51 myhost->rootcheck
Rule: 519 (level 7) -> 'System Audit: Vulnerable web application found.'
System Audit: Web vulnerability - Backdoors / Web based malware found - eval(base64_decode. File: /var/www/somepath/app/code/local/Mlx/Mlx/Model/Observer.php.

** Alert 1456448991.70587: mail  - ossec,rootcheck,
2016 Feb 26 01:09:51 myhost->rootcheck
Rule: 519 (level 7) -> 'System Audit: Vulnerable web application found.'
System Audit: Web vulnerability - Backdoors / Web based malware found - eval(base64_decode. File: /var/www/otherpath/app/code/local/Mlx/Mlx/controllers/ServiceController.php.

Ho aggiunto una regola a rules/local_rules.xml che dovrebbe interrompere gli avvisi impostando level="0" : - 

<group name="rootcheck">

  <rule id="100200" level="0">
    <if_sid>519</if_sid>
    <match>Web vulnerability - Backdoors / Web based malware found - eval(base64_decode</match>
    <match>app/code/local/Mlx/Mlx</match>
    <description>Ignore Magento extension Mlx license restriction PHP</description>
  </rule>

Ecco la catena di regole da cui dipende, da rules/ossec_rules.xml : - 

<group name="ossec,">

  <rule id="509" level="0">
    <category>ossec</category>
    <decoded_as>rootcheck</decoded_as>
    <description>Rootcheck event.</description>
    <group>rootcheck,</group>
  </rule>

  <rule id="510" level="7">
    <if_sid>509</if_sid>
    <description>Host-based anomaly detection event (rootcheck).</description>
    <group>rootcheck,</group>
    <if_fts />
  </rule>

  <rule id="516" level="3">
    <if_sid>510</if_sid>
    <match>^System Audit</match>
    <description>System Audit event.</description>
    <group>rootcheck,</group>
  </rule>

  <rule id="519" level="7">
    <if_sid>516</if_sid>
    <match>^System Audit: Web vulnerability</match>
    <description>System Audit: Vulnerable web application found.</description>
    <group>rootcheck,</group>
  </rule>

Questi comandi, eseguiti dopo aver apportato qualsiasi modifica alla regola, riavviare ossec, cancellare il db rootcheck e avviare (dopo qualche ritardo) un nuovo rootcheck: - 

# bin/ossec-control restart
# bin/rootcheck_control -u 000
# bin/agent_control -ru 000

ossec-logtest può essere utilizzato per vedere come vengono decodificate le righe da un file di registro e quali regole vengono utilizzate per generare avvisi, ma non sembra essere utilizzato per testare le regole di rootcheck: - 

# bin/ossec-logtest
2016/02/26 01:52:55 ossec-testrule: INFO: Reading local decoder file.
2016/02/26 01:52:55 ossec-testrule: INFO: Started (pid: 24633).
ossec-testrule: Type one log per line.

System Audit: Web vulnerability - Backdoors / Web based malware found - eval(base64_decode. File: /var/www/otherpath/app/code/local/Mlx/Mlx/controllers/ServiceController.php.

**Phase 1: Completed pre-decoding.
       full event: 'System Audit: Web vulnerability - Backdoors / Web based
                    malware found - eval(base64_decode. File:
                    /var/www/otherpath/app/code/local/Mlx/Mlx/controllers/ServiceController.php.'
       hostname: 'myhost'
       program_name: '(null)'
       log: 'System Audit: Web vulnerability - Backdoors / Web based
             malware found - eval(base64_decode. File:
             /var/www/otherpath/app/code/local/Mlx/Mlx/controllers/ServiceController.php.'

**Phase 2: Completed decoding.
       No decoder matched.

In effetti, non ci sono decodificatori che decodificano questa linea di 'log' (o le varianti che ho provato).

È possibile sovrascrivere una regola copiandola in local_rules.xml e aggiungendo l'attributo overwrite : - 

<rule id="519" level="0" overwrite="yes">
  <if_sid>516</if_sid>
  <match>^System Audit: Web vulnerability</match>
  <description>System Audit: Vulnerable web application found.</description>
  <group>rootcheck,</group>
</rule>

E dopo aver modificato l'attributo level , tutti gli allarmi 519 sono disattivati.

Quindi deve esserci qualcosa di sbagliato nella mia regola. Cosa sto sbagliando?

    
posta jah 26.02.2016 - 03:42
fonte

1 risposta

1

Quello che stai facendo è sbagliato supponendo che più <match> elementi in una regola siano AND ed quando in realtà sono concatenati. Quindi la tua regola: - 

<group name="rootcheck">

  <rule id="100200" level="0">
    <if_sid>519</if_sid>
    <match>Web vulnerability - Backdoors / Web based malware found - eval(base64_decode</match>
    <match>app/code/local/Mlx/Mlx</match>
  </rule>

non corrisponderà al messaggio sul quale ti stai allertando, ma corrisponderà alla stringa: -

"Vulnerabilità Web - Rilevato backdoor / malware basato sul Web - eval (base64_decod ea pp / code / local / Mlx / Mlx"

Potresti provare questo: - 

<rule id="100200" level="0">
  <if_sid>519</if_sid>
  <match>System Audit: Web vulnerability - Backdoors / Web based malware found</match>
  <match> - eval(base64_decode. File: /var/www/</match>
  <regex>somepath/app/code/local/Mlx/Mlx|</regex>
  <regex>otherpath/app/code/local/Mlx/Mlx</regex>
  <description>Ignore Magento extension Mlx license restriction PHP</description>
</rule>

Questa regola utilizza più match e regex elementi solo per abbreviare i pattern per renderli quindi più leggibili. Anche gli elementi regex multipli vengono concatenati e in questo caso si ottengono due pattern di OR d (utilizzando il simbolo pipe per separarli). Le stringhe di corrispondenza e regex risultanti sono AND ed in modo che questa regola funzioni come desiderato.

Va sottolineato che la regola di lavoro, sopra, è troppo permissiva: corrisponderebbe anche a: -

"Controllo del sistema: vulnerabilità Web - Rilevato backdoor / malware basato sul Web - eval (base64_decode. File: / var / www / percorso completamente diverso / percorso / app / codice / locale / Mlx /Mlx/ReallyEvil.php ".

e non attivare un avviso per la presenza di qualcosa di veramente malvagio. Potrebbe essere meglio usare più regole che sono molto specifiche sui percorsi che corrispondono.

Questa prima regola estende la regola 519 "Verifica del sistema: applicazione Web vulnerabile trovata", utilizza lo stesso livello di avviso e ha una corrispondenza e una descrizione leggermente più specifiche: - 

<rule id="100200" level="7">
  <if_sid>519</if_sid>
  <match>^System Audit: Web vulnerability - Backdoors / Web based malware found - eval(base64_decode.</match>
  <description>System Audit: Vulnerable web application with possible back door or web based malware found.</description>
  <group>rootcheck</group>
</rule>

Quindi queste regole aggiuntive estendono la regola 100200 per sopprimere gli avvisi per file specifici, corrispondenti alla fine del messaggio: - 

<rule id="100201" level="0">
  <if_sid>100200</if_sid>
  <match>File: /var/www/somepath/app/code/local/Mlx/Mlx/Model/Observer.php.$</match>
  <description>Ignore Magento extension Mlx license restriction PHP</description>
  <group>rootcheck</group>
</rule>

<rule id="100202" level="0">
  <if_sid>100200</if_sid>
  <match>File: /var/www/otherpath/app/code/local/Mlx/Mlx/controllers/ServiceController.php.$</match>
  <description>Ignore Magento extension Mlx license restriction PHP</description>
  <group>rootcheck</group>
</rule>

Dettagliato, ma più corretto.

    
risposta data 27.02.2016 - 00:11
fonte

Leggi altre domande sui tag

Perché i nomi utente in genere non sono memorizzati nei cookie di sessione e sono forniti con ID di sessione? I rischi di proteggere l'API REST usando SSL?