Iptables : quelques trucs sympa

Bijour …

Suite à mes redirections de ports par iptables dans le tuto précédent, je me suis dit que ça pouvait être intéressant de voir un peu plus loin ce que propose iptables, et j’ai trouvé quelques truc sympa (que je cherchais pas ^^), dont on parle pas très souvent :

Je pars du principe que l’on bloque tout par défaut …

Limitation de certains flags sur un port précis :

Ici on autorise un syn par seconde, ça permet d’éviter les floods

[sourcecode language=bash]
/sbin/iptables -A allow-ssh-traffic-in -m limit –limit 1/second -p tcp –tcp-flags \
ALL SYN –dport ssh -j ACCEPT
[/sourcecode]

On peut aussi utiliser limit-burst pour augmenter le nombre de paquets qui équivaudront à un limit genre pour un limit-burst 5, il faudra 5 paquets pour faire un limit … cqfd^^

Détection de certaine méthodes de scan de nmap (et d’autre scanner)

Ici on va pouvoir logger et bloquer les scans de type XMAS, NULL et SYN*

[sourcecode language=bash]
$IPTABLES -N check-flags
$IPTABLES -F check-flags
$IPTABLES -A check-flags -p tcp –tcp-flags ALL FIN,URG,PSH -m limit \
–limit 5/minute -j LOG –log-level alert –log-prefix "NMAP-XMAS:"
$IPTABLES -A check-flags -p tcp –tcp-flags ALL FIN,URG,PSH -j DROP
$IPTABLES -A check-flags -p tcp –tcp-flags ALL ALL -m limit –limit \
5/minute -j LOG –log-level 1 –log-prefix "XMAS:"
$IPTABLES -A check-flags -p tcp –tcp-flags ALL ALL -j DROP
$IPTABLES -A check-flags -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG \
-m limit –limit 5/minute -j LOG –log-level 1 –log-prefix "XMAS-PSH:"
$IPTABLES -A check-flags -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPTABLES -A check-flags -p tcp –tcp-flags ALL NONE -m limit \
–limit 5/minute -j LOG –log-level 1 –log-prefix "NULL_SCAN:"
$IPTABLES -A check-flags -p tcp –tcp-flags ALL NONE -j DROP
$IPTABLES -A check-flags -p tcp –tcp-flags SYN,RST SYN,RST -m limit \
–limit 5/minute -j LOG –log-level 5 –log-prefix "SYN/RST:"
$IPTABLES -A check-flags -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A check-flags -p tcp –tcp-flags SYN,FIN SYN,FIN -m limit \
–limit 5/minute -j LOG –log-level 5 –log-prefix "SYN/FIN:"
$IPTABLES -A check-flags -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
[/sourcecode]

Au pire, on peut aussi s’amuser à logger les mauvaises combinaisons de flags tcp du genre :(certaine règles peuvent rentrer en collision avec les précédentes … par contre, je me souviens plus de où j’ai trouvé ça …)

[sourcecode language=bash]

/sbin/iptables -N BADFLAGS
/sbin/iptables -A BADFLAGS -j LOG –log-prefix "IPT BADFLAGS: "
/sbin/iptables -A BADFLAGS -j DROP

/sbin/iptables -N TCP_FLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,FIN FIN             -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,PSH PSH             -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,URG URG             -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags FIN,RST FIN,RST         -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags SYN,FIN SYN,FIN         -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags SYN,RST SYN,RST         -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ALL ALL                 -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ALL NONE                -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ALL FIN,PSH,URG         -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ALL SYN,FIN,PSH,URG     -j BADFLAGS
/sbin/iptables -A TCP_FLAGS -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j BADFLAGS

[/sourcecode]

Marquer les paquets pour des traitements futures …

Bon, ici c’est vraiment pour faire geek, mais ça peut permettre de faire des limitations d’utilisation de bande passante ou … limiter l’accès à un service ^^ genre : seul les paquets marqués d’un « 2 » sont autorisés à ce connecter à mon serveur ssh (c’est une hypothèse bien sûr … ça peut être un autre chiffre ;)), mais ça donne ça :
Coté serveur :
[sourcecode language=bash]
/sbin/iptables -A INPUT -m mark –mark 2 -p tcp -dport 22 -j ACCEPT
#on drop le reste
/sbin/iptables -A INPUT -p tcp -dport 22 -j DROP
[/sourcecode]
Coté client :
On marque les paquets à destination du port 22 de l’ip 192.168.0.1
[sourcecode language=bash]
/sbin/iptables -t mangle -A PREROUTING -p tcp -d 192.168.0.1 -dport 22 -j MARK –set-mark 2
[/sourcecode]
Comme dit … suffit de ce faire sniffer les paquets et l’intrus remarquera rapidement le marquage des paquets, et bruteforcer le marquage n’est pas très dur, donc c’est pas très sécurisé comme technique mais ça peut ralentir une attaque 😉

Filtrer le contenu de certain paquets et faire une « chaine » de filtre :

Ici ça deviens intéressant … le firewall peut carrément lire le contenu de certain paquet tcp pour les drops!! (cf. lien SpamCleaner), ici, le but est de supprimer les sympatiques : GET /w00tw00t.at.ISC.SANS de nos logs apache

[sourcecode language=bash]
# création de notre chaîne w00t :
iptables -N w00t

# redirige les paquets TCP sur notre chaîne :
iptables -A INPUT -p tcp -j w00t

# recherche du premier SYN et création de la liste :
iptables -A w00t -m recent -p tcp –syn –dport 80 –set

# recherche du paquet SYN,ACK et mise à jour la liste :
iptables -A w00t -m recent -p tcp –tcp-flags PSH,SYN,ACK SYN,ACK –sport 80 –update

# recherche du paquet ACK et mise à jour la liste
iptables -A w00t -m recent -p tcp –tcp-flags PSH,SYN,ACK ACK –dport 80 –update

# recherche de la signature de DFind dans le prenier PSH+ACK.
# Si elle est présente, on DROP.
# On supprime la liste pour ne pas filtrer les paquets suivants
iptables -A w00t -m recent -p tcp –tcp-flags PSH,ACK PSH,ACK –dport 80 –remove \
-m string –to 70 –algo bm –string "GET /w00tw00t.at.ISC.SANS." -j DROP
[/sourcecode]

Là on se rend compte que ça peut être pas mal puissant.

Si en plus on couple ce genre de méthode avec modsecurity ou fail2ban on peut arriver à faire quelque choses de pas trop mal côté sécurité.

Bon bien sûr, j’allais pas faire un tour complet des possibilités d’iptables donc voici mes sources, si vous voulez continuer la lecture …

Mes différentes sources : (et ouai je ne suis qu’un kevin!! je repique tout!!, par contre, j’ai mis des liens avec des trucs dont je n’ai pas parlé plus haut … ou pas)

  • Gentoo security
  • RateLimit
  • SpamCleaner Le w00tw00t[1] le fail2ban[2]
  • Google ?!?
  • Marquage de paquet et limitation de bande passante [3] et la version fr [4] un autre en fr [6]
  • Marquage de paquet [5]

Sinon, quelques liens à lire sur iptables :

  • La doc d’ubuntu!! Pour les gros noob only!! (attention je fais du tracking toutes vos connexion seront marqués « GROS NOOB » :p)

DNS Tunneling par la pratique

Bijour à vous …

Ben voilà, suite à l’un de mes précédents articles, où je mettais amusé à pomper de façon plutôt glorieuse un tuto en anglais sur le tunneling, je me suis amusé à exécuter le tuto pour « remplir mon temps libre » … et j’ai remarqué que l’idée était sympa, mais l’implémentation, ainsi que l’installation était « laborieuse », ainsi, j’ai tenté de voir pour une autre solution tout aussi sympa, toujours basé sur un tunnel DNS (bien sûr on peut faire du tunneling avec tout et n’importe quoi Icmp, Http, …).

Les outils :

  • un serveur dédié avec 2 ip (genre rps … comment je fait de la pub!!!) ou un dédié et un serveur dns (à part … on à vraiment besoin de 2 IPs distincts).
  • ce superbe script en perl
  • la puissance du script-kidies qui sommeil en vous

Sur le serveur :

On configure bind9 (un très bon tuto si le besoin ce fait sentir ;)) … pour ce faire, il suffit juste d’ajouter des lignes du genre (changez bien sûr votre ip et nom de domaine) :
[sourcecode language= »bash »]
tunnel          IN              NS              tun.domaine.org.
tun               IN              A                123.123.123.123
[/sourcecode]
Le tunnel DNS :
[sourcecode language= »bash »]
cd /opt
wget http://dev.splitbrain.org/download/snapshots/dnstunnel-latest.tgz
gunzip dnstunnel-latest.tgz | tar -xvf –
[/sourcecode]

Ensuite on config les différents fichiers :

/opt/dnstunnel/dnstunneld (pour ceux qui ont deux IP sur une même machine, il vous faut modifier le port d’écoute, pour les autres, ne faites rien), pour ce faire, cherchez la ligne :

LocalPort    => 53

et remplacez 53 par 1024, ensuite, il suffit d’utiliser ces deux règles d’iptables pour effectuer la redirection (changez les ip!!!!) :
[sourcecode language= »bash »]
iptables -t nat -A PREROUTING -p tcp -d 123.123.123.123 –dport 53 -j REDIRECT –to-ports 1024
ptables -t nat -A PREROUTING -p udp -d 123.123.123.123 –dport 53 -j REDIRECT –to-ports 1024
[/sourcecode]
Pourquoi faire ça ?? Comme mon serveur à deux ip et que bind écoute sur les deux ip, je ne peux pas lier le script sur le port 53 de ma machine, donc je redirige le traffic à destination de l’ip 123.123.123.123 et du port 53 au port 1024, comme ça, pas de problème 😉 et mon serveur DNS configuré sur l’autre ip fonctionne toujours 😉 (ok dites-le, c’est crade mais ça marche … comme windows ou pas … des fois ^^)

/opt/dnstunnel/dnstunneld.wrapper modifiez les 3 lignes comme ceci (pour ma config, donc changez encore une fois les ip/nom de domaine pour votre config) :
[sourcecode language= »bash »]DNSHOST= »tunnel.domaine.org »           # ici on donne le nom de notre NS
REPLYIP= »123.123.123.123″                                  # l’ip que l’on renvoi si quelqu’un fait une vrai requête DNS sur ce serveur
OPTIONS= »-i 127.0.0.1 -l 123.123.123.123″          # les options … changer l’ip par la votre 😉
[/sourcecode]
puis faire un sympatique :

ln -s /opt/dnstunnel/dnstunneld.init /etc/init.d/dnstunneld

installez ensuite les dépendances de perl et screen :

apt-get install screen libnet-dns-perl libmime-base32-perl

pour ceux qui n’ont pas debian passer par : perl -MCPAN -e shell et faire un install Net::DNS et install MIME::Base32
un coup de

/etc/init.d/dnstunneld start

permettra de lancer la bête. (il faudra peut-être créer l’utilisateur nobody ainsi que son groupe associé ;))

Sur le client :
On copie le fichier dnstunnelc dans /usr/bin (en gros crado …), on install ensuite les même dépendances perl que pour le serveur.

apt-get install libnet-dns-perl libmime-base32-perl

Ensuite, une simple commande SSH à balancer (changez bien sûr le nom de domaine et le login du compte ssh ;))

ssh -D 8080 -o ProxyCommand= »dnstunnelc -v sshdns.tunnel.domaine.org » votre-login@domaine.org

et paf ça fait des chocapics un tunnel dns, ensuite il suffit de configurer son client web (firefox, …) pour utiliser notre proxy sur le port 8080 et enjoy la connexion.

Bien sûr, vous devez être propriétaire de la borne wifi à laquelle vous vous connecter, ou vous devez avoir l’autorisation de son propriétaire (même si c’est public ?? ^^).

Si vous trouvez que c’est trop complexe … vous pouvez toujours regarder ici

Quelques Dénis de services Sympa ou pas

Bijour à vous en ce dimanche ensoleillé (en Alsace ^^).

Petite note : Vous seul êtes responsable de vos actes (de toutes façon, la plupart de ces commandes exécutées par une seule machine ne peuvent plus venir à bout d’un serveur (ou d’une machine quoique …) … donc n’imaginez pas pouvoir planter le serveur de votre petite copine avec les commandes fournit dans l’article … mieux vaut la corriger autrement …)

Voilà mon premier article un peu orienté attaque de l’année (après plein de truc inutile sur comment fortifier son serveur sauce juvamine), ça fait suite à l’attaque qu’a subit korben, et je suis tombé (par hasard!! ça arrive si si je vous jure) sur un vieux numéro de MISC (le numéro 19 de mai-juin 2005 qui était très intéressant … leurs articles sont toujours très intéressant d’ailleurs), qui analysait diverses méthodes de dénis de services.

Donc voici le petit résumé des commandes sympa du mag en question : (Oui dites-le, je ne suis qu’un copieur … et alors ?! J’ai aussi rajouté quelques trucs trouvés sur le net histoire de me faire pardonner ou pas)

  • SynFloods :
    • L’une des attaques les plus simpliste : on balance un paquet TCP avec un syn et on arrête là (donc pas de syn-ack a réceptionner et donc de ack a envoyer, le serveur attendra une réponse qui ne viendra jamais), ce qui peut à termes bouffer pas mal de ressource côté serveur
    • La commande en mode « normal » : hping3 –syn -M 123456 -L 0 -p 80 <ip> –flood
    • Paquets générés : syn-flood-normal On remarque que les paquets ont tous la même tronche (même adresse source et destination) sympa pour se faire choper ^^
    • La commande en random source : hping3 –syn -M 123456 -L 0 -p 80 <ip> –flood –rand-source
    • Paquets générés : syn-flood-randomOn remarque que les ips sources changent … comme c’est direct écrit dans le paquet tcp, y’a de grande chance de ne pas se faire choper … à part si le FAI le détecte ^^.
  • Syn-Ack Floods
    • Un autre type d’attaque sympa, on balance un syn-ack au serveur, le serveur n’ayant pas de ack associé va renvoyer un rst et là … owned, on peut donc par exemple, flooder un serveur en lui envoyant les syn-ack avec comme ip source un autre serveur, et c’est le premier serveur qui enverra les rst au second serveur … on attaque une machine et ce sont deux machines qui trinquent !! Par contre ici, la consommation de mémoire est moindre à cause de l’envoi du rst. A noter que sur une attaque de grande ampleur, en randomisant/incrémentant les numéros de séquence on peut (peut-être) couper des connexions existante (faut soit avoir du bol, soit avoir pas mal de machines sous la main ;))
    • La commande : hping3 -SA -M 123456 -L 0 -p 80 –flood –rand-source
    • Paquets générés : syn-ackOn remarque le flag syn/ack, et toujours l’ip source spoofé (l’ip de destination est mon serveur … et je m’autorise à me flooder ^^)
  • Le sapin de noël TCP
    • Ici, un envoi de paquets avec un numéro de séquence nul
    • La commande : sudo hping3 -SAFRU -M 0 -L 0 -p 80 –flood
    • Paquets générés : safru-modeOn remarque les flags FIN/SYN/RST/ACK/URG qui sont set … j’ai oublié de prendre le numéro de séquence en screen, mais bon …
  • Le trou noir de niveau 2!! (ARP)
    • Ici, c’est l’attaque d’un sous-réseaux, l’attaque parfaitement inutile … on balance ettercap pour détourner les paquets en local vers sa machine … et on oubli comme un noob le forwarding des paquets … et plus d’accès au net … cela dit, faire passer sa machine pour la passerelle et rediriger le traffic pour choper des pass semble plus intelligent …
    • La commande : cf. l’un de mes articles sur ettercap en omettant le forwarding
  • Le trou noir de niveau 3 (IP)
    • Ici ba c’est pareil que le niveau 2 … aussi naze, sauf que c’est au niveau au-dessus, au lieu de rediriger vers une MAC qui bloque le traffic on envoi le traffic sur une ip inexistante ou non-configuré comme gateway
    • La commande : sing -red -S <ip gateway> -gw <ip nouveau gateway> -dest 0.0.0.0 (le net quoi) -x net <ip victime>
    • Exemple avec captures du paquet : sing -red -S 192.168.0.1 -gw 192.168.0.13 -dest 0.0.0.0 -x net 192.168.0.11
      192.168.0.1 est ma passerelle de base, 192.168.0.13 est la machine qui va servir de nouvelle passerelle qui prendra le traffic à destination de 0.0.0.0 (le net quoi) -x net 192.168.0.11 qui est ma machine « victime »
      icmp-redirectA noter qu’encore une fois … le paquet est entièrement forgé, donc si vous ne mettez pas votre ip dedans … ben elle y sera pas ^^, donc on remarque les différents champs du paquet ICMP source/destination et adresse du nouveau gateway, …
    • On peut aussi faire cette attaque sur un DHCP (genre on le descend avec maraveDHCP encore un DoS!! … un DoS pour faire un autre DoS futé :p) puis on utilise irdp de façon similaire à la commande précédente : irdp -i eth0 -S 192.168.0.13 -D 192.168.0.11 (quand même plus court que l’autre commande ^^).
  • Les attaques sur les sessions
    • Ici, le but est d’ouvrir une session sans la fermer, donc on suit le cheminement SYN/SYN-ACK/ACK et plus rien, sachant que la config par défaut des serveurs est d’avoir genre 150-200 clients simultannés au maximum, ouvrir autant de session rendra le serveur aphone ou le fera pas mal lagguer
    • La commande pour un service apache : webdevil <ip-serveur> 80 <nb session> (je l’ai fait sur localhost cette fois … j’ai pas envie de tester sur mon serveur ^^)flood-apache
      On voit les paquets syn, syn-ack et ack … et plus rien (j’ai pas pris la suite dans le screen parce que y’avait plein de dup … allez savoir pourquoi ;))
    • A noter que webdevil est vraiment orienté bad … l’auteur a même prévu un ensemble d’outil pour lancer des attaques distribuées (suffit de remplir le fichier slaveservers.txt encore un truc de SM … de lancer le webdevild sur les machines esclaves et le devilmaster sur le maitre^^ si c’est pas méchant)
  • Flood sur le service DNS
    • Encore une attaque sympa avec un outils sympa … toujours et encore sur packetstorms … qui permet de flooder un serveur DNS … encore mieux ^^
    • La commande : dnsflood <ip serveur> (j’ai pas fait de capture … too lazy)
  • Flooder un routeur Wifi avec mdk3

Je rajouterai encore des trucs prochainement … ou pas (si j’arrive à déchiffrer le PDF plus bas :p), si ça vous a intéressé, lisez donc le numéro 19 de MISC (vous serez surement surpris de voir le nombre de truc que j’ai pas encore copié de l’article en question 😉 j’ai quand même pris des screenshots :p c’est du boulot, bon je m’enfonce j’arrête là … bon apétit).

Quelques liens :

  • Une doc, (j’ai pas réussi à le lire … probleme de police sa TimeNewsRoman est planté, j’ai juste réussi à lire les titres ^^) sur les attaques DOS, moi qui pensait avoir honteusement pompé sur MISC (ce PDF parle d’autre attaque DoS en plus de ceux présenté ici … faut dire, y’a pas mal de technique possible avec d’autre logiciels et d’autre config), sinon, le site de l’auteur est sympa.
  • Sinon, y’a google qui donne toujours de très bon liens 😉

ModSecurity mise en place de restrictions sur les règles de restrictions ^^

Bonsoir …

Bé voilà, si vous avez installé la dernière version de ModSecurity (>2.5) avec les generic_attack en filtre, vous avez sûrement remarqué que phpMyAdmin ne fonctionne plus (hé oui, ça fait du SQL Injection :p), mais les blogs peuvent aussi ne plus fonctionner (XSS, voir Command/File Injection si vous tentez de poster du code sur votre blog), ce n’est que dernièrement, que j’ai remarqué ces erreurs, sans trop y faire gaffe (à part que là, ben ça remplissait les logs avec une IP que je connaissait très bien … la mienne, le méchant pirate, je vais porter plainte sur 127.0.0.1 ^^, je suis sûr que la procédure judiciaire passerait 😉).

Donc pour remédier à ce problème, les gars qui ont dév la bête sont intelligent, ils avaient prévu le coup avec :

SecRuleRemoveById et SecRuleRemoveByMsg

Ce qui donnent donc pour PhpMyAdmin :

<Location /phpmyadmin/> 
     SecRuleRemoveByMsg "Blind SQL Injection Attack"
     SecRuleRemoveByMsg "SQL Injection Attack"
</Location>

et pour WordPress (partie administration)

<Location /wp-admin/> 
     SecRuleRemoveByMsg "Blind SQL Injection Attack"
     SecRuleRemoveByMsg "SQL Injection Attack"
     SecRuleRemoveByMsg "Cross-site Scripting (XSS) Attack"
     SecRuleRemoveByMsg "Remote File Access Attempt"
     SecRuleRemoveByMsg "System Command Injection"
</Location>

Pour la partie commentaires … à voir suivant la confiance que vous avez en vos visiteurs ^^ (tentez pas de poster des commentaires sur mon blog avec des commandes systèmes … vous seriez surpris sur mon niveau de confiance 😉 … y’a quand même des gars qu’ont tenter de brute-forcer mon phpmyadmin, bande de naab!!!).

A mettre dans l’un de vos fichiers de conf d’apache, et vous ne tomberez plus sur les erreurs 501 (protocole non implémenté) que cela générait.

Voilà … Bonne nuit

Analyse automatisée des logs apache

Bonjour à tous …
[la traduction du terme analyse dans le texte est GREP ^^ faut pas s’attendre à une analyse mathématique !!]

Bé voilà, comme j’adore raconter ma vie, voici un petit truc sympa :

Aujourd’hui on a eu droit à un cours … le premier depuis des mois!!! L’ennui se faisant sentir (un cours sur les tests … déjà vu en DUT), je me connecte à mon serveur et après un petit tour du proprio … comme d’hab koi ^^ Je lis les logs de mon serveur … (c’est grave docteur ??) et là horreur plein de ligne du ModSecurity m’indiquant pleins de tentatives diverses et variées (XSS, SQL Injection, …).

Un petit aperçu d’une ligne du log :

[Fri May 15 16:36:35 2009] [error] [client 74.55.32.34] ModSecurity: Access denied with code 501 (phase 2).
[msg "Remote File Access Attempt"]
[severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"]
[hostname "blog.gaetan-grigis.eu"]
[unique_id "Sg1981diuFsAADJ2ypYAAAAC"]

Le genre du truc qu’en terminal on aime pas trop lire (surtout sur l’écran du téléphone portable) … et pis y’en avais une bonne cinquantaine … et là mes venu la superbe idée (j’imagine que plein d’admins l’on déjà fait, mais bon ^^ au cas où si ça vous intéresse), j’ai crée un petit script qui analyse le log d’erreur d’apache (par grep quoi ^^) et envoi un mail avec les lignes incriminées, ce qui donne donc (il vous faudra bien sûr le mod_security d’installé … cf. mon blog ;))

#!/bin/sh
LOG_ERROR="/var/log/apache2/error.log"
LOG_MODSEC=`cat $LOG_ERROR |grep ModSecurity | wc -l`
if [ $LOG_MODSEC -gt 0 ]
then
        SEVERITY_ALERT=`cat $LOG_ERROR | grep "severity \"ALERT\"" | wc -l`
        SEVERITY_CRITI=`cat $LOG_ERROR | grep "severity \"CRITICAL\"" | wc -l`
        if [ $SEVERITY_ALERT -gt 0 ]
        then
                cat $LOG_ERROR | grep "severity \"ALERT\"" |mail -s "[LOG]HTTP ALERT" addr@gmail.com
                echo "NB ALERT : $SEVERITY_ALERT"
        fi

        if [ $SEVERITY_CRITI -gt 0 ]
        then
                cat $LOG_ERROR |grep "severity \"CRITICAL\"" | mail -s "[LOG]HTTP CRITICAL" addr@mail.com
                echo "NB CRITICAL : $SEVERITY_CRITI"
        fi
fi

et voila passionnante ma vie ^^, en ASM ça se résumerait ainsi : (MOV al,1 XOR ebx,ebx, int 0x80), reste plus qu’à exécuter le script avant le rotatelog histoire d’avoir le résumé des attaques de la journée/semaine …
Je vais peut être en profiter pour faire des graphiques suivant les types d’attaque, leurs nombres, leurs provenances, … ou pas

Petit ajout du 17 mai … pour rajouter un script du genre celui donné plus haut, il faut aller voir dans le fichier /etc/logrotate.d/apache2 et ajouter les lignes suivantes :

        prerotate
                sh /scripts/logAnalyzer.sh > /dev/null
        endscript

après la ligne sharedscripts et hop, on envoi les mails avant la rotation des logs, comme ça on passe pas pour le nolife-ki-li-ses-logs-apache-pendant-les-cours devant ses camarades de classe.

Voilà … bon we 😉

Dédié … premiere choses à faire après l’install

Kikoo …

Allez hop … souvent après la compromission d’un serveur, après avoir fait le tour des services installés, des ports en cours d’utilisation, des processus qui tournent, la relecture pour la 4ème fois des logs d’accès … vide 😉 l’exécution de chkrootkit pour la 2ème fois, … et là on se demande si l’attaquant n’a pas « empoisonnée » une ou plusieurs commandes et donc on demande gentiment le fichier contenant les md5 des commandes UNIX principale et la on à droit aux superbes regards interrogateur et amusé des proprios du serveur piraté ^^.

Donc voilà, le truc que certains oublient après l’install, la première chose à faire :

md5sum /bin/* | tr -s  »  » « – » > md5-binaries

ça sert à quoi ??

En cas de compromission il faut comparer le md5 de chaque commande principal (su, cp, cd, …) avec ceux contenu dans le fichier md5-binaries, mais comme on n’aime pas le faire à la main, on utilise ce genre de script :

#!/bin/sh

for i in `cat $1`
do
        md5S=`echo "$i"|cut -d "-" -f1`
        binS=`echo "$i"|cut -d "-" -f2`

if [ -f $binS ]
then
        md5C=`md5sum $binS|cut -d " " -f1`

        # echo "BINARY : $binS MD5 Sauvegardé :$md5S | MD5 Courrant : $md5C"
        if [ $md5C=$md5S ]
        then
                echo "BINARY       OK : $binS MD5 Sauvegardé :$md5S | MD5 Courrant : $md5C"
        else
                echo "!!BINARY PAS OK : $binS MD5 Sauvegardé :$md5S | MD5 Courrant : $md5C"
        fi
fi
done

Et hop, encore un truc d’inutile mais indispensable … comme tous en informatique 😉 à noter qu’il faut le refaire après chaque mise à jour de votre OS 😉

Accès restreint sur certain ports dans le temps

Bijour à tous

Ben voilà … pour des raisons de sécurité évidente, il est souvent utile de bloquer l’accès sur certains ports depuis l’extérieur, et parfois on se rend compte qu’il faut tout de même laisser un accès sur ces services depuis l’extérieur (genre un TP qui nécessite une base de données … Oracle pour ne pas le citer), et bien sûr, on a pas envie de laisser l’accès ouvert en continu, d’autant plus que si les personnes ont une ip dynamique faire une liste des ip et sous-réseau autorisés risque d’être long, donc la solution (j’avoue que j’ai pas cherché si des logiciels faisaient ça) :

Faire 2 scripts :
– l’un qui reset les règles du firewall en tâche cron une fois par jour qui contiendrait quelques chose du genre :

#!/bin/bash
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
#les ports dont on veut bloquer l'acces par défaut ici le port 1337 allez savoir pourquoi 😉
iptables -A INPUT -p tcp --dport 1337 -j DROP

-l’autre qui autorise les ip contenu dans un fichier (en taches cron toutes les 5 minutes) du genre :

#!/bin/sh
IP_FILE="/var/www/ip.txt"
if [ -f $IP_FILE ]
then
        for i in `cat $IP_FILE`
        do
        #t=`echo $i|tr "-" " "`
        if [ -n $i ]
        then
                t="iptables -I INPUT 1 -p tcp -s $i --dport 1337 -j ACCEPT"
                #echo $t
                $t
        fi
        done
        rm $IP_FILE
fi

et hop, faut juste faire un script PHP qui rajoute les IPs (voir les ports, mais faudra modifier le script d’ajout des IP) dans le fichier txt pointé par le fichier txt du genre :

 $f=fopen("ip.txt","a+");
fwrite($f,$_SERVER['REMOTE_ADDR']."\n");
fclose($f);

Bien sûr, il faudra mettre une authentification dessus … sinon, c’est la porte ouverte à tout et n’importe quoi. Et voilà, vous pouvez dormir sur vos deux oreilles maintenant 😉

A noter que si vous le faites pour votre serveur SSH, faudrait pas que votre script plante, sinon, vous perdez tous les accès à votre serveur, mais ça peut permettre de pas mal réduire les tentatives de brute force, puisque par défaut personne ne pourra ce connecter dessus, il faudra juste passer par votre page web pour autoriser votre IP a y accéder et hop …

En espérant que ça puisse être utile 😉 Bon week-end.

ACL avec GRSecurity2

Plopinou …

Suite à mon précédent article sur la mise en place de mon serveur Tor, je suis tombé sur cette page concernant les améliorations de la sécurité concernant la bestiole et notamment les ACL (Access Control List) que propose GRSec2 en plus du W^X et des autres sécurités embarquées dans ce patch, pour ceux qui ont installés ce superbe patch ou qui cherchent à l’installer, il suffit d’installer le paquet gradm2, suivre les instructions d’installation et modifier le fichier /etc/grsec/acl

Les gros intérêts :

On peut :

  • restreindre les accès aux dossiers/fichiers (execution, lecture, ecriture)
  • restreindre les accès au réseau (bind, connect, …).
  • logger les accès aux fichiers
  • restreindre les actions de certain logiciels sur des protocoles en particulier
  • restreindre la consommation CPU, de mémoire, de données, …

Comme une configuration en dit plus qu’un long discours :
La config fournit par le projet Tor pour … tor 😉

subject /usr/sbin/tor o {
        /                               h
        /var/lib/tor                    rwcdl
        /lib                            rx
        /usr/lib                        rx
        /dev/urandom                    r
        /dev/null                       rw
        /etc/tor                        r
        /var/log/tor                    rw
        /var/run/tor                    rwcdl

        -CAP_ALL

        connect 127.0.0.1:9050 stream tcp
        # Not very good, but since servers listen on different ports...
        connect 0.0.0.0/0:9001-9100 stream tcp
        connect 0.0.0.0/0:443 stream tcp
        bind    127.0.0.1:9050 stream tcp
}

Un tuto en français pas mal complet pour GrSec et GrSec2
La documentation complète pour les ACLs : http://www.grsecurity.net/gracldoc.htm

Voilà, sécurisez-vous bien 😉

Mettre en place un serveur TOR … qu’est-ce que ça bouffe ??

Bijour à vous cher internautes en manque de liberté …

Aujourd’hui, un truc tout bête, monter un serveur TOR, sans prétention vu qu’il y a beaucoups de tuto sur le net, je montrerais juste la config que j’ai mise sur mon dédié, ainsi que les statistiques concernant le CPU/BP/Connexion générées par la mise en place d’un tel serveur … attention, ça consomme pas mal de ressource surtout processeur, bande passante (encore que ce n’est que le nombre de connexion TCP simultanées qui monte).

Donc voilà, pour la configuration d’un relais Tor (ça signifie que mon serveur ne servira pas de noeud de sortie du traffic Tor, je ne suis donc que l’intermédiaire entre deux autres serveurs Tor), et j’ai aussi rajouté la config d’un « Directory Miror » qui consomme plus qu’un serveur Tor normal, j’ai de la BP à claquer … vive l’illimité ;).

SocksPort 9050 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
Nickname MonNomDeMachine
Address mon.ip.a.moi
RelayBandwidthRate 1000 KBytes
RelayBandwidthBurst 1500 KBytes
ORPort 9001
DirPort 9030 # what port to advertise for directory connections
ExitPolicy reject *:* # no exits allowed

Les petits changements par rapport à un simple client Tor sont :

  • Le Nickname, qui sert juste à nommer la chose
  • l’Address, l’ip ou le ndd de la machine
  • Les Relay * qui permettent de limiter la bande passante, j’ai du 100 Mpbs, donc j’aurais pu mettre plus, mais j’ai pas envie de faire lagger mon site
  • ORPort, est le port utilisé par le relay
  • DirPort, est utile si l’on veut servir de mirroir au autres serveurs Tor (y parait que quand on à de la bande passante ça peut être utile).
  • ExitPolicy, permet de rejeter l’utilisation de certain port si l’on est en noeud, sinon il peut permettre d’interdire l’utilisation de notre serveur en noeud de sortie.

Voilà pour ma config, et donc la très attendu page de stats :
tor-server
Le jeu s’appel : « à quelle heures ais-je mis le serveur Tor en place ? » ^^ à noter qu’à 17 heures le serveur était configuré, il lui a donc fallu une bonne heure  pour créer les routes et être intégré au réseaux Tor. Donc voilà, si vous avez un ordi, ainsi qu’une bande passante à claquer, mettre en place un serveur Tor pourra surement vous convenir 😉