• Serveurs
  • [Discussion] Sécuriser son serveur avec Ossec et Prelude

Super tutoriel !!
Merci Hardware maintenant avec Ossec je suis au Sec !!
Super Hardware Merci
Dis pour la partie OSSEC Web User Interface tu aurais une idée pour ceux qui sont sous lighttpd ?
J'ai essayé de voir sur le net mais après install du dossier /var/www/ossec-wui-0.3 puis script setup.sh je bloque.
j'ai aussi le fichier ossec dans /var/www .
moi sur nginx sa marche pas
Unable to access ossec directory.

sinon ta fait une erreur pour l'installation du web ui de ossec
@Hardware j'ai tenté mais trop chaud pour mon niveau. j'arrivai plus a restart lighttpd.
bon du coup je laisse sans webui
j'ai tenter de mettre ossec en sonde sa marche pas je pense qu'il faut installer prelude avant ossec
et pour snort je pige rien mdr
j'ai fait du gros bordel en plus avec les tuto donc je sais pas faut qu'on voit sa ensemble ^^

Modif de la nuit ba j'ai prelude qui marche plus du tout ^^ comment on le desinstalle ?
wget --header="User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/31.0" http://www.ossec.net/files/ossec-wui-0.8.tar.gz
tar -xzf ossec-wui-0.8.tar.gz
Bonsoir,

comme on peut le voir sur le site de OSSEC ainsi que le GitHub, il existe une version 0.8 de la WebUI de OSSEC. Le tutoriel ne mentionne pas son existence. Ainsi je m'interroge, il y aurait une raison en particulier ? La version 0.3 serait préférable ? Une simple inconnue ?

Autrement, je souhaiterais savoir comment faudrait-il procéder avec OSSEC afin de bannir l'émetteur d'une requête visant l'injection d'url ? Par défaut, OSSEC me semble inactif sur ce point...
Petite erreur de ma part pour le numéro de version, je vais corriger ça de suite
Wagner wrote:Autrement, je souhaiterais savoir comment faudrait-il procéder avec OSSEC afin de bannir l'émetteur d'une requête visant l'injection d'url ?
Injection d'url, c'est à dire ? Si tu parles des injections SQL et XSS, OSSEC prend en charge nativement ces deux types d'attaques avec les règles suivantes :
<rule id="31103" level="6">
    <if_sid>31100</if_sid>
    <url>=select%20|select+|insert%20|%20from%20|%20where%20|union%20|</url>
    <url>union+|where+|null,null|xp_cmdshell</url>
    <description>SQL injection attempt.</description>
    <group>attack,sql_injection,</group>
</rule>

<rule id="31105" level="6">
    <if_sid>31100</if_sid>
    <url>%3Cscript|%3C%2Fscript|script>|script%3E|SRC=javascript|IMG%20|</url>
    <url>%20ONLOAD=|INPUT%20|iframe%20</url>
    <description>XSS (Cross Site Scripting) attempt.</description>
    <group>attack,</group>
</rule>
Je viens de faire un essai sur mon site web avec cette URL :
/index.php?cat=articles&%20lid=-1%20UNION%20SELECT%200,username,userid,password
J'ai été banni en moins de 4 secondes donc ça marche plutôt bien apparement
Ainsi, c'était juste une petite erreur de frappe, merci Hardware.
request: "GET http://une.adresse.url 200
Voici un exemple, c'est extrait des logs de Nginx. Il ne s'agit pas d'injection SQL (ou XSS), juste une url (un nom de domaine). Parfois, c'est toujours la même.
Avec Fail2Ban, ce type de tentatives ont un code d'erreur (404 etc). Avec OSSEC, c'est toujours le code 200. C'est la cause de cette impression... elle serait à tort ?
Les codes de statut du protocole HTTP sont déterminés uniquement par le serveur web. Si la ressource demandée par le client n'existe pas, le serveur web retourne systèmatiquement le code 404. OSSEC de son côté ne fait qu'analyser les logs du serveur web et prend une décision en fonction des règles contenues dans le répertoire /var/ossec/rules.

Si un client génère une multitudes d'erreurs 404 pendant un laps de temps assez court, allors OSSEC bannira l'ip du client de manière temporaire simplement par prévention. Dans le cas d'un code de retour égal à 200 :
request: "GET http://une.adresse.url 200..."
c'est parfaitement normal qu'ossec ne réagisse pas car la requête a été traité avec succès par le serveur web, il n'y a donc pas d'action à entreprendre.
Je vois, c'est l'une des causes que j'avais envisagé. Ainsi, je vais devoir créer (ou adapter) des règles afin de l'obtenir.
Quelques exemples de requêtes : 
GET http://une.adresse.IP:64011/echo HTTP/1.0" 404 162 "-" "-""
GET /manager/ HTTP/1.1" 404 162 "-"
CONNECT mx0.UneAdresseURL.com.tw:25 HTTP/1.0" 400 166 "-" "-" 
De temps en temps, un client génère une erreur (tous les x jours avec la même adresse IP ou la même requête), OSSEC (seul) sera en mesure de le détecter ? Pour ce faire, il aura besoin de quoi ?
Si c'est un bot qui a toujours la même adresse IP, tu peux toujours le ban avec définitivement Iptables, c'est simple et efficace. Par contre si il ne s'agit pas toujours de la même IP, il faut créer une nouvelle règle dans le fichier :

/var/ossec/rules/local_rules.xml.

On va prendre pas exemple cette requête :
10.215.115.5 - hostname [06/Sep/2014:08:45:27 +0200] "GET /manager/ HTTP/1.1" 404 162 "-"
Voila la règle qui permet de bannir une IP qui tente d'accéder à /manager :
<rule id="100070" level="6">
    <if_sid>31101</if_sid>
    <url>^/manager/</url>
    <id>^400|^404</id>
    <options>alert_by_email</options>
    <description>Attention : bot détecté</description>
    <group>web_scan,recon,</group>
</rule>
<if_sid>31101</if_sid> est la règle parente, elle se déclenche lors qu'une erreur ^4* est détectée.
Il faut redémarrer OSSEC pour prendre en compte la nouvelle règle :
service ossec restart
Maintenant il faut la tester pour voir si elle fonctionne correctement, on va utiliser la commande ossec-logtest
# /var/ossec/bin/ossec-logtest -v

ossec-testrule: Type one log per line.

10.215.115.5 - hostname [06/Sep/2014:08:45:27 +0200] "GET /manager/ HTTP/1.1" 404 162 "-"

**Phase 1: Completed pre-decoding.
       full event: '10.215.115.5 - hostname [06/Sep/2014:08:45:27 +0200] "GET /manager/ HTTP/1.1" 404 162 "-"'
       hostname: 'franklin'
       program_name: '(null)'
       log: '10.215.115.5 - hostname [06/Sep/2014:08:45:27 +0200] "GET /manager/ HTTP/1.1" 404 162 "-"'

**Phase 2: Completed decoding.
       decoder: 'web-accesslog'
       srcip: '10.215.115.5'
       url: '/manager/'
       id: '404'

**Rule debugging:
    Trying rule: 4 - Generic template for all web rules.
       *Rule 4 matched.
       *Trying child rules.
    Trying rule: 31100 - Access log messages grouped.
       *Rule 31100 matched.
       *Trying child rules.
    Trying rule: 31101 - Web server 400 error code.
       *Rule 31101 matched.
       *Trying child rules.
    Trying rule: 100070 - Attention : bot détecté
       *Rule 100070 matched.

**Phase 3: Completed filtering (rules).
       Rule id: '100070'
       Level: '6'
       Description: 'Attention : bot détecté'

**Un méchant a été détecté, I'M A' FIRIN' MAH LAZER !!
Ok la règle fonctionne comme prévue

Petit bonus pour ban définitivement une IP détectée par la règle ci-dessus avec une réponse active :
# /var/ossec/etc/ossec.conf

<command>
    <name>host-deny-for-life</name>
    <executable>host-deny.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
    <command>host-deny-for-life</command>
    <location>local</location>
    <rules_id>100070</rules_id>
</active-response>
Salut à tous !

Petit soucis a l'installation de prewikka, quand je le lance dans mon navigateur j'ai :

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/prewikka/Core.py", line 386, in process
request.content = template.respond()
File "/usr/lib/python2.7/site-packages/prewikka/templates/HTMLDocument.py", line 144, in respond
_v = VFFSL(SL,"body",True) # u'$body' on line 21, col 9
File "/usr/lib/python2.7/site-packages/prewikka/templates/TopLayout.py", line 133, in body
_v = VFFSL(SL,"toplayout_content",True) # u'$toplayout_content' on line 14, col 3
File "/usr/lib/python2.7/site-packages/prewikka/templates/LoginPasswordForm.py", line 97, in toplayout_content
localization.setLocale(localization._DEFAULT_LANGUAGE)
File "/usr/lib/python2.7/site-packages/prewikka/localization.py", line 79, in setLocale
locale.setlocale(locale.LC_ALL, "%s.%s" %(lang.encode('utf8'), str(_DEFAULT_ENCODING)))
File "/usr/lib/python2.7/locale.py", line 547, in setlocale
return _setlocale(category, locale)
Error: unsupported locale setting


Pourtant la locale fr-FR est bien active sur mon système ?

Tu n'a pas sélectionné correctement le bon pack de langue, il faut choisir avec [ESPACE] le pack fr_FR.UTF-8 :

Et l'activer par défaut :

# locale -a

C
C.UTF-8
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
en_US.utf8
français
french
fr_FR
fr_FR@euro
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
POSIX
Ok merci j'ai fait la modif , c OK !
Bonjour,

Quand j'essaie de démarrer "prelude-manager", j'ai cette erreur :
service prelude-manager      start
[....] Starting prelude-manager : prelude-manager07 Sep 14:18:29 (process:4614) INFO: Subscribing Normalize to active decoding plugins.
 failed!
Est-ce que c'est lié au fait que je suis sous raspbian?
Est-ce que tu as plus de détail dans le fichier /var/log/prelude.log ?
Voici le contenu du fichier : http://ovh.to/um3tBPv

Pour les autres services j'ai ceci :
service prelude-lml          start
Starting Prelude LML: prelude-lml.
.
 service prelude-correlator   start
[....] Starting prelude-correlator : prelude-correlator07 Sep 16:46:02 PreludeCorrelator.pluginmanager (pid:4974) INFO: [FirewallPlugin]: disabled on user request
07 Sep 16:46:02 PreludeCorrelator.pluginmanager (pid:4974) ERROR: [SpamhausDropPlugin]: missing netaddr module : https://pypi.python.org/pypi/netaddr
07 Sep 16:46:02 PreludeCorrelator.pluginmanager (pid:4974) INFO: [BusinessHourPlugin]: disabled on user request
07 Sep 16:46:03 PreludeCorrelator.main (pid:4974) INFO: 7 plugins have been loaded.
. ok
service prewikka             restart
Arrêt de Prewikka... [OK]
Démarrage de Prewikka... [OK]
Et Quand je vais sur prelude.domain.tld :

http://ovh.to/Y7e64NQ

J'ai testé ça hier et ce matin "Prelude-Correlator" et "Prelude LML" est en rouge. La c'est de nouveau connecté car j'ai arrêté pour démarrer les services pour avoir les différents messages dans la console et faire les copier/coller.
Ok tes services sont bien opérationnels. Pour cette erreur :
07 Sep 16:46:02 PreludeCorrelator.pluginmanager (pid:4974) ERROR: [SpamhausDropPlugin]: missing netaddr module : https://pypi.python.org/pypi/netaddr
Installe le paquet python-netaddr :
apt-get install python-netaddr
J'ai remarqué qu'à partir d'un certain moment la sonde prelude-correlator n'emettait plus son heartbeat. Pour corriger ça, ajoute ce script dans le répertoire /usr/local/bin :
#!/bin/bash

CSI="\033["
CEND="${CSI}0m"
CGREEN="${CSI}1;32m"
CRED="${CSI}1;31m"

PL=$(ps aux | grep prelude-lml | wc -l)
PC=$(ps aux | grep prelude-correlator | wc -l)
PREWIKKA_PID=$(netstat -tlnp | awk '/:8000 */ {split($NF,a,"/"); print a[1]}')
PRELUDE_MANAGER_PID=$(netstat -tlnp | awk '/:4690 */ {split($NF,a,"/"); print a[1]}')

# Vérification du fonctionnement de Prelude Manager
if [[ $PRELUDE_MANAGER_PID -gt 0 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude Manager est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude Manager n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-manager start
fi

# Vérification du fonctionnement de Prelude LML
if [[ $PL -eq 2 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude LML est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude LML n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-lml start
fi

# Vérification du fonctionnement de Prelude Correlator
if [[ $PC -eq 2 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prelude Correlator est actuellement en service"
else
    echo -e "${CRED}[KO]${CEND} Prelude Correlator n'est pas en service, démarrage imminent..."
    /etc/init.d/prelude-correlator start
fi

# Vérification du fonctionnement de Prewikka
if [[ $PREWIKKA_PID -gt 0 ]]; then
    echo -e "${CGREEN}[OK]${CEND} Prewikka est actuellement en service"
else
    echo "Prewikka n'est pas en service, démarrage imminent..."
    /etc/init.d/prewikka start
fi

exit 0
Ce script permet de checker le fonctionnement de Prelude-Manager, Prelude-LML, Prelude-Correlator et Prewikka.
Et pour finir crée une nouvelle tâche cron qui s'exécute toutes les 30 minutes :
# crontab -e

*/30 * * * * /usr/local/bin/prelude-check-components > /dev/null 2>&1