Bonjour à tous !
Voila j’ai un petit soucis.
J’aimerai bien voir les connexions active avec la commande netstat, petit soucis il n’affiche pas les connexion des route qui passe par mon VPS.
J’ai chercher toutes l’après-midi, sans trouver de solution, je me tourne donc vers vous.
Avez vous une solution ?
Voici la commande que j’ai entrée pour faire ma route: ip route add 192.168.99.202 via 192.168.99.102 dev eth0
Elle apparait bien dans ma table de routage, et sans elle je peux aussi me connecter à montre autre VPS
Désoler si je m’y prend pas, je m’y connais peu en réseau;
A savoir que mes VPS tourne grâce à Proxmox,
Merci à tous de votre aide !
La première commande ne me renvoie rien, la seconde me renvoie juste les routes actif…
Je me suis mal exprimé, ce que je souhaite, c’est que depuis mon routeur, je sache qu’elle connexion est ouverte.
Par exemple, si je suis un utilisateur est connecté sur le serveur apache de mon VPS qui est routé, j’aimerai que celui apparaisse dans le netstat du routeur (il apparait bien sur le VPS lui même, mais pas sur le routeur)
arf Donc y a vraiment aucune solution à part le TCPDump…
Car j’ai une commande netstat qui permet de détecter si le VPS subit un « DDoS », mais je ne sais pas comment la traduire avec tcpdump justement
La voici: netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | uniq -c | awk '{ if ($1 > 20) print "Attaque DDoS en cours !"; }'
Pour résumer ce qu’elle fait, même si je pense que vous le savez mieux que moi, elle calcul le nombre de connexion ouverte avec une IP et si celle ci est trop élever, alors on lance une alerte (par mail par exemple)
Je ne sais pas si c’est possible de la traduire en tcpdump, j’ai vaguement chercher en n’ayant rien de concluant
Outre ta méconnaissance du réseau, ta confusion vient peut-être du mot « connexion » qui est vague et peut désigner des choses différentes.
netstat n’affiche pas des « connexions » mais des « sockets », qui sont des points de communication entre un processus local et un hôte distant. Une socket de type TCP indique implicitement une connexion car TCP est un protocole dit « connecté ». Par contre une socket de type UDP n’indique pas forcément une connexion car UDP est un protocole dit « non connecté », bien que certains protocoles applicatifs qui l’utilisent se comportent comme des connexions.
D’autre part, une socket n’existe que pour les communications avec un processus local. Si la machine fait seulement office de routeur pour des communications entre des hôtes distants, elle n’ouvre pas de sockets ; les sockets sont ouvertes sur les hôtes distants.
Un routeur « pur » ne s’occupe pas des connexions. Son travail se limite à router des paquets IP en appliquant sa table de routage. Sur ce type de routeur, la seule façon d’avoir une idée des connexions est de capturer le trafic et de le traiter, comme le font iftop ou ntop par exemple. Mais un routeur peut aussi faire du filtrage à état (stateful filtering) ou de la translation d’adresse (NAT/masquerading). Dans ce cas il doit maintenir une table d’état de toutes les connexions qu’il gère. Cette table peut être manipulée avec le programme conntrack ou consultée directement quelque part dans /proc/net/ip_conntrack ou /proc/net/nf_conntrack (je ne me souviens plus du chemin exact).
Salut !
Merci à toi pour cette réponse très détailler.
Effectivement, pour moi un socket et une connexion c’était la même chose, et je viens de documenté sur le sujet pour en apprendre plus
Je vois, mais des logiciel comme snort ou PRTG peuvent faire cette surveillance à la place de iftop ou ntop ?
Je te confirme que c’est celui-là … je m’en suis servi cet après midi pour détecter un brute force effectuer sur la machine par un paquet d’ip (ça remplissez la capacité maximale pour dire :/)
J’ai étais obligé de jouer sur la valeur de time_out des connexions le temps que l’équipe réseau mitige l’attaque.
Tu as la main sur ton Hyperviseur ? si oui surveille depuis celui-ci le nombre de connexions, mais comment estimé lorsque tu prends un pic de fréquentation légitime et une attaque (c’est à toi d’y réfléchir) ?
un simple cat /proc/net/nf_conntrack | wc -l devrais déjà te permettre de connaître le nombre de connexion en cours lorsque tu as du suivi de connexion.
#!/bin/bash
# Quick script to check nf_conntrack table and potentially block troublesome IPs
# IP addresses originating more than $THRESHOLD conntrack entried
# will be banned.
THRESHOLD=30
cat /proc/net/nf_conntrack | awk -F ' *|=' '{print $8}' | \
sort | uniq -c | awk -v threshold=$THRESHOLD '$1 > threshold {print $0}' |
while read count ip
do
# "blacklist1" is the name of a locally defined ipset.
echo ipset add blacklist1 $ip
ipset add blacklist1 $ip
# Delete the conntrack entries of the offending IP, so a second ban attempt
# is not made next time this script is run.
conntrack -D --src $ip > /dev/null
echo
done
Script déjà testé mais fonctionne avec Iptables (attention utilisation d’ipset, ne pas se tromper et bien analyser pour ne pas bloqué" les ip privé de tes machines.
Sinon un articles dans la langue de Shapkespear expliquant comment mettre ne place une limitations d’ip mais encore une fois attention à l’effet de bord, il faudra bien analyser et définir ce qui est légitime de ce qu’il ne l’est pas.
Le mieux étant tout de même de mettre un ipset avec des ip whitlistées, et ensuite enrichir un ipset à grand coup d’ip via un fail2ban, le tout avec une règle de DROP.
Mais comme déjà dit c’est juste pour virer du pénible qui allonge les logs, pas pour se protéger d’un vrai DDOS.
PS AH au passage proposer Snort pour surveiller un simple hyperviseur ou quelques machines c’est comme utiliser un bazooka pour tuer une mouche …
Enfaite mon soucis n’est pas tant d’anticiper les attaques ou autre, pour le moment c’est un petit projet, mais je pense dans l’avenir ouvrir un hébergeur de VPS, donc je chercher une technique fiable pour détecter les DDoS sortant de mes machines pour bloquer le VPS en question.
Pour les DDoS on a déjà une protection au niveau du DataCenter mais ajouter une couche en plus ne fait pas de mal j’ai envie de dire.
En tout cas merci de toutes vos réponse, j’ai appris beaucoyp grâce à vous et je pense que je vous pouvoir faire quelque chose d’assez fiable !
Donc y a vraiment aucune solution à part le TCPDump…
