Archives pour la catégorie Sécurité

Ossec et Iptables : ban à durée variable

Plop à tous …
Encore de l’ossec et de l’iptables au menu, ici le but est de faire face aux crackers et autres kiddies sans se faire spammer de mails toutes les 6 minutes parce qu’un mec s’est planté 3 fois de suite de mot de passe sur SSH (un mec a tenté pendant deux jours de cracker mon ssh, résultat : une bonne centaines de mails d’alertes inutiles (le temps que je lui mettent un ban définitif)).
Continuer la lecture de Ossec et Iptables : ban à durée variable

SSL via GNUTLS sur apache2

Plop à tous …

Aujourd’hui j’ai joué a « qui a la plus grosse » config ssl et c’est là que j’ai remarqué que le mod_ssl d’apache ne supportait que les protocoles SSLv3 et TLSv1.0 (le TLSv1.1 est en cours de dev) ce qui donnait un score pitoyable à mon blog sur ssllabs (qui permet d’avoir une idée du niveau de sécurité de l’implémentation ssl/tls d’un serveur web).


(Au passage certaine banques françaises en sont encore au niveau F, donc c’était déjà pas trop mal pour un blog ^^).

Continuer la lecture de SSL via GNUTLS sur apache2

Protection Ddos (soft)

Plop …

un petit retour sur le Ddos de ce week-end … conformément aux prédictions de certains concernant mon précédent article, un ban permanent n’est généralement pas une bonne idée, notemment lorsque les paquets sont forgés :

  • ça remplit inutilement les règles du firewall (la dernière attaque avait finit avec 600 lignes de DROP, ce qui rend difficile la lecture des règles mise en place)
  • en cas de ban d’un « client/joueur », il est banni à vie
  • il y a un risque si l’attaquant connait l’ip de l’admin et la fait bannir en floodant avec son ip

Donc on m’a filé une autre commande, plus courte et aussi performante, sans remplir inutilement les règles iptables :
(il faut supprimer l’espace entre les deux – – dans les commandes suivantes, wordpress les transforme en un seul -)

/sbin/iptables -A INPUT -p tcp - -dport 25565 -m state - -state NEW -m recent - -set
/sbin/iptables -A INPUT -p tcp - -dport 25565 -m state - -state NEW -m recent - -update - -seconds 60 - -hitcount 5 -j DROP

Ici, on surveille tout les nouveaux paquets sur le port 25565 et si la même ip renvoit de nouveaux paquets on incremente un compteur, si celui-ci atteint le hitcount (ici 5) dans les 60 secondes, on drop les paquets.

Si le visiteur lambda se fait drop, il devra juste attendre la fin de l’intervalle depuis son dernier paquet envoyé (ici 60 secondes à chaque fois),

Si c’est une attaque dos, il ne pourra envoyer que 5 nouveaux paquets par minutes, réduisant de ce fait la puissance de son attaque (si à chaque syn envoyé une nouvelle ip est forgée, cette protection ne servira à rien … et mon ban permanent aussi d’ailleurs ;)).

Et maintenant que la machine est « protégée » (c’est relatif hein ;)), il faut tester la sécurité ^^, on flood donc notre machine en envoyant des paquets SYN (avec scapy) sur le port du service que nous avons protégé.

On crée donc un fichier avec ce contenu en changeant les valeurs des ip, la valeur du loop et le port (derrière une NAT ça remplace l’ip source par votre adresse ip) :

#!/usr/bin/python
from scapy.all import *
send(IP(src=RandIP("0.0.0.0/0"),dst="ipserv")/TCP(sport=1337,dport=port du service,flags="S"),loop=5,inter=0.01)

Pour vérifier que les paquets sont drop, on fait un tcpdump sur le port en question et on compte le nombre de paquets provenant du port 1337.

tcpdump dst port 80 and src port 1337

(Si la règle en interdit plus de 5 et qu’on reçoit les 10 y’a un problème) ou l’on check les stats d’iptables via

iptables -L -v -n

Par contre, on peut s’amuser avec scapy à randomiser les ip (à faire sur des machines non natées) et tenter de flooder le service sans se faire drop un seul paquet :

#!/usr/bin/python
from scapy.all import *
sendp(Ether(src=RandMAC('*:*:*:*:*:*'),dst="port mac passerelle")/IP(src=RandIP("0.0.0.0/0"),dst="ip serveur")/TCP(sport=RandShort(),dport=port du service,flags="S"),loop=100,inter=0.01)

Et là on se rend compte que l’on peut facilement contourner la règle iptables précédente, et qu’il devient important de mettre en place une règle globale pour toute les ip sur un service en particulier.

Donc pour mettre en place une limite globale par exemple sur le port 80 qui peut traiter au max 1000 connexions en parallèle (en imaginant qu’une requête est traitée en 1 seconde (téléchargement d’une page web en générale) ce qui n’est pas forcément vrai pour tout les services, donc on laisse au mimimum 10% du nombres des connexions pour les connexions en cours) ce qui donne :

iptables -A INPUT -p tcp - -syn - -dport 80 -m limit - -limit 900/s -j ACCEPT

Et si l’on rebalance un SYN flood avec le script précédent, en lançant plus de 1000 syn en parallele, seul une partie d’entre eux devrait passer.

Ce système permet surtout de protéger les services derrière le firewall en cas d’attaque permettant de passer les règles présentées jusque là.

Protection DDos et ban de masse

Plop …
J’ai eu droit à ma première intervention sur serveur DDosé, au départ 2/3 machines qui envoyaient des paquets SYN en boucle sur un serveur minecraft (écrit en java donc avec 200 SYN/sec le serveur tombe), et à la fin c’est environ 150 machines qui se sont relayés pour Dosé.

La plupart du temps lorsque l’on recherche des protections DDos on trouve des sites qui recommandent de mettre direct un limit sur un port sans tenir compte de la source … ce qui peut se révéler utile sur des petits serveurs, mais pas lorsque l’on tourne à plusieurs centaines de connexion seconde.

Continuer la lecture de Protection DDos et ban de masse

[OSSEC et SSH]Bannissement ip définitif de cracker

plop,

today du ban au menu, à la base j’utilise au minimum fail2ban pour me protéger des attaques par bruteforce et ossec pour une protection plus personnalisée, mais depuis peu, j’ai remarqué que bannir un host 5/10 minutes ne servait à rien contre des machines automatisées dédiée à cette tâche, et une fois la période de ban terminée recommençaient leur manège, me polluant de mails me signalant une tentative de bruteforce.
Continuer la lecture de [OSSEC et SSH]Bannissement ip définitif de cracker

Nouvelle version de Prewikka sur debian testing

Plop à tous …

ça fait déjà depuis quelques temps que la version 1.0 de prewikka (le frontend python de l’IDS prelude) est présente dans les dépôts de testing, mais comme je viens seulement de faire la mise à jour … ^^. (Au passage, prelude a aussi été mise à jour 😉 et OSSEC est passé en 2.4 le mois dernier … il était donc temps de mettre à jour l’architecture de mon système de sécurité).
Continuer la lecture de Nouvelle version de Prewikka sur debian testing

Mise en place d’un portknocking pour limiter les ports accessibles sur le net

Hello …

Protéger des services non-public (type ssh) d’être accédés par n’importe qui ça peut être assez utile (pour éviter les connexions intempestives pour la prise d’information, tentative de login/bruteforce …), le tout sans avoir à déclarer d’ip, …

On peut utiliser pour cela du portknocking, le but étant de mettre en place une séquence de « toc toc qui est là » qui permettra ensuite d’ouvrir la porte, et si la séquence n’est pas bonne … ^^).
Continuer la lecture de Mise en place d’un portknocking pour limiter les ports accessibles sur le net

Limiter les droits d’un utilisateur sur Debian/Ubuntu (lshell)

Plop à tous ….

Lorsque l’on doit partager/administrer une machine, on a souvent peur que les individus fassent de belles boulettes sur la machine en question (surtout si l’accès est partagé entre plusieurs utilisateurs).

Une technique consisterait à faire un chroot via SSH (si ça vous tente ^^ mais c’est super long).

Ou passer par un truc du genre dans /etc/ssh/sshd_config :

Subsystem sftp internal-sftp
Match user nomUser
         ChrootDirectory /home/nomUser
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

Qui bloque la plupart des commandes et n’autorise que le sftp …

Pour les admins flemmards, il existe une solution : lshell, on peut choper un .deb sur le site et une fois installé, il n’y a pas grand chose à faire :

Modifier le fichier /etc/lshell.conf (assez facile à comprendre), avec des paramètres du genre :
Pour les commandes autorisées :

allowed         : ['ls','echo','cd','ll','svn','vi','rm']

Pour kiker l’utilisateur après un certain nombre d’erreurs :

warning_counter : 2

dans ce cas, après 2 erreurs, la connection SSH est coupée.

On peut chrooter un utilisateur :

path            : ['/var/www/']

Pour obliger un utilisateur à utiliser ce shell, il y a 2 cas :
On modifie un utilisateur :

usermod --shell /usr/bin/lshell nomUser

On créer un utilisateur

adduser nomUser --shell /usr/bin/lshell nomUser

Et voilà … connectez vous avec un utilisateur « lshellé » (pour ma part chrooté et limité aux commandes « allowed » plus haut) :

You are in a limited shell.
Type '?' or 'help' to get the list of allowed commands
kikoo:~$ 
kikoo:~$ ls
index.php  license.txt  robots.txt  svnup.php  system
kikoo:~$ cat /etc/ssh/sshd_config
*** forbidden path -> "/etc/ssh/sshd_config"
*** You have 0 joker(s) left, before getting kicked out.
This incident has been reported.
kikoo:~$ svn up
À la révision 12.
kikoo:~$ echo "LOL"
LOL
kikoo:~$ echo "LOL" > /etc/ssh/sshd_config
*** forbidden synthax -> "echo "LOL" > /etc/ssh/sshd_config"
- Kicked out -
Connection to 1.3.3.7 closed.

Voilà … bonne administration 😉

De l’USB en grillade ?? Destruction de périphériques USB à la volées

Plopinou …

ATTENTION : Cette méthode détruit purement et simplement tout périphériques USB branchés sur le port USB qui a été inversé. Vous devez savoir ce que vous faites, tout en sachant que vous êtes seul responsable de vos actes ;).

Parfois on a besoin d’empêcher l’utilisation de périphériques USB sur son ordinateur, dans le cas des PC en entreprises, certain SI n’hésite pas à boucher les ports USB avec de la pâte à modeler/colle, …

Continuer la lecture de De l’USB en grillade ?? Destruction de périphériques USB à la volées