Bonjour,
ne souhaitant pas voir mon serveur passer en mode "aspiration d'attaque" pendant de longues heures supplémentaires,  
je viens demander ici l'avis des plus experts d'entre nous.
 
 
Il s'agit d'un serveur Kimsufi, qui sert pour héberger un site web, un serveur de login (4 dédiés de gamme SP pour le jeu), et des backups.
 
Il s'agit donc de la "porte d'entrée" sur ma plateforme, et j'imagine que les concurrents s'amusent bien à pousser OVH à déconnecter mon serveur.
 
J'aimerais savoir tout d'abord s'il s'agit de DoS ou DDos, et de quel type. (SYN, TCP, ...?)
 
Et ensuite, j'aimerais pouvoir repérer les IP en question et les bannir, ainsi que mettre en place quelques règles de sécurités sur mon dédié.
 
J'utilise mod_evasive, fail2ban, et iptables, il y a aussi ntop qui est installé; mais mes connaissances en sécurité réseau sont moindres et ne me permettent pas de réagir dans une telle situation.
 
 
Merci à vous.

up

Euh... et quelle est la question ?
Si c'est de savoir comment tu dois faire, regarde tes logs et relève les IP. Configure ton fail2ban pour protéger tes différentes applis.

Salut

"J'aimerais savoir tout d'abord s'il s'agit de DoS ou DDos, et de quel type. (SYN, TCP, ...?)
 
Et ensuite, j'aimerais pouvoir repérer les IP en question et les bannir, ainsi que mettre en place quelques règles de sécurités sur mon dédié. "

je n'ai visiblement aucun log correspondant à ces connexions. (les connexions sont surement "SYN" et donc rien n'aparait dans les logs Apache)
OVH m'a dit que la prochaine fois que j'ai une attaque, ils réinstalleraient mon serveur, il s'agit donc de prendre de bonnes mesures !

Des idées de configuration fail2ban pour Apache ?
ou bien comment loger réelement tout le traffic entrant ?

merci

Mmh... en netstat tu dois pouvoir voir les connexions non établies, si tu en as plein depuis la même adresse IP c'est facile d'ajouter une règle iptables pour éviter ce genre de chose, je pense.
 
Pourquoi OVH te menacent-ils de réinstaller ton serveur ? Ça a une incidence sur les autres clients ? Et d'ailleurs, ça changerait quoi ?

"Ça a une incidence sur les autres clients ?"
 
ils souhaitent protéger leur infrastructure apparament.
 
j'ai mis un script en cron qui fait un netstat avec les ip connectés ainsi que le nombre de connections.

Sinon iptables a un target LOG pour ça... (Avec un petit rate limit quand même)

Déjà au moment des attaques regardent la volumétrie. Si ton lien est saturé, tu peux pas y faire grand chose si ce n'est de demander à OVH de protéger ses clients contre ce type de chose. Certains DDoS n'ont pour but que de remplir le tuyau de la cible. La tu peux rien faire une fois que ça a atteint ton serveur. C'est avant qu'il faut blackholer le traffic. Et ça c'est le taf de l'infrastructure.

Si l'attaque est plus fine, blacklistage au niveau du firewall iptables/netfilter pourrait suffir. fail2ban, c'est gentil, mais c'est limité.

Déjà configure les log via iptables avec un petit rate-limit histoire que tu ne satures pas ton espace de stockage. Après, apprends à utiliser iptables pour blacklister des IP/subnet en entrée. Si l'attaque est réellement distribuée, ça pourrait être compliqué au niveau iptables.

Juste un conseil : si tu n'y comprends rien, et qu'il s'agit d'un projet pro, il vaut mieux que tu fasses appel à un expert réseau ou sécurité pour gérer le problème à ta place.
 
On ne peut pas te dire ce qui se passe exactement sur ton serveur à partir de rien. J'aime filer un coup de main, mais il est impossible de faire un cours iptables sur un forum.
 
P.S. D'habitude, OVH ne menacent pas de "reinstaller le serveur", à moins qu'ils aient détecté une intrusion sur ton serveur, et que ton serveur est maintenant infecté par des logiciels malveillants qui propagent d'autres attaques sur le réseau.

Enfait ils m'ont dit après m'avoir passé en mode rescueftp, que si je le remettais en mode normal et que les attaques continuais, il serait obligés de réinstaller le serveur, sans moyen de sauvegarder.
 
Bon j'ai réussi à sauvegarder mes fichiers cependant.
 
Et la il y a quelques minutes, une nouvelle attaque est tombée !
 
Qu'en est il de cette histoire de log iptables o'gure ? merci
 
et ma ligne :
netstat -n|grep :|cut -c 45-|cut -f 1 -d ':'|sort|uniq -c|sort -nr|more > "/root/ipslog/ips_$(date '+%Y-%m-%d_%H-%M').log"
 
qui tourne en cron n'enregistre visiblement rien lors d'une attaque ...
 
le lien de mon serveur sature en effet, des pics à 70-80Mb/s entrant; pas moyen de se co en SSH depuis chez moi ou bien même depuis un autre serveur dédié OVH.
 
Il ne s'agit pas réellement d'un projet pro :x si tu es près à m'aider, envoie moi un MP
 
encore merci pour vos aides
 
ps : j'ai des notions en informatique, mais tout ce qui touche au réseaux et plus particulièrement à la sécurité n'est pas mon truc ... encore moins dans un environnement linux

up

A tout hasard pour "prévenir" les attaques, utilises-tu un knockd pour ouvrir l'accès au SSH et au FTP sur ton serveur ?

Je n'ai aucune idée de ce que cela est :x
 
il n'y a pas de serveur FTP installé sur mon dédié, et je ne sais pas (penses pas) que l'attaques se fassent sur du SSH, mais on ne sais jamais !
 
merci

Encore ce midi je prend 90Mb/s entrant depuis 2h environ ...

si c'est saturation bande passante en input, tu ne peux rien faire si ce n'est demandé à ton fournisseur d'identifier d'où viens l'attaque et de bloquer ce traffic.

aucune solution logicielle pour contrer cela et bannir les IP ?

OVH n'as visiblement pas de solution à me proposer.

(les attaques ne concerne que le port 80 visiblement)

(peut etre que ce thread devrais etre mis dans "reseau pro" ?)

Essaye de visualiser ce qui se passe...
Tu crées un bâtiment au bout d'une route. Tu ne contrôles que les portes de ton bâtiment, aucun contrôle sur de la route ni avant la route, si quelqu'un t'envoies 10000 personnes par seconde sur cette route, que peux tu faire pour qu'elles n'arrivent pas à tes portes ? rien.
Au mieux c'est filtrer un peu si ces personnes sont fortement reconnaissable afin que seule les personnes voulue rentre dans le bâiment. Mais au final, si la route est saturée, ça ne va pas te servir à grand chose... Les personnes légitimes pour rentrer vont être considérablement ralentient par les autres.

Pour filtrer correctement sur ton serveur, comme je t'ai déjà dit regarde déjà avec la target LOG de iptables (et un rate-limit) pour visualiser les IP (as tu pris 15 minutes pour googler sur ces mots clés ?). Derrière renseigne toi sur iptables et sur comment ça fonctionne. Tu as 10000 tuto sur le net, réexpliquer le fonctionnement d'iptable sur un post de forum alors qu'il existe des sites très bien fait...
Après si l'attaque est fête correctement (spoofing adresse IP ou utilisation de bot), ton fitlrage ne servira à pas grand chose.

Autre solution, le prendre à l'envers, est-ce que les gens autorisés à se connecter à ton serveur sont reconnaissable fortement par leur adresse IP ? si oui, tu n'autorises qu'elles. (mais ça règlera pas le problème de volumétrie)

J'ai déja des règles iptables qui bloquent tous les pays non francophones (mes joueurs)

Concernant les rate-limit, j'en ai quelque fois trouvés mais rien de signifiant !

Le target LOG j'ai fais quelques recherches effectivement les résultats sont nombreux, mais je ne sais pas exactement avec quelles options l'utiliser pour l'exploiter.

Le truc de base suffit, on limite à 10 par seconde

Après si tu as déjà règles iptables , il faut l'insérer au bon endroit... Après les logs seront dans le fichier de log principal de ta distribution (/var/log/syslog ou /var/log/message) Il ne faut pas laisser cela en place dans le cas d'un ddos sous peine de voir ton disque se remplir.

Ou alors via un

control + C poru arrêter au bout de quelque seconde.
puis tu lis le fichier avec

Tu auras une idée du trafic précis qu'on envoie

tu n'auras pas mieux vu que tu ne peux controler ce qu'on envoie

(enfait le script dos deflate ne semble pas ok, puisqu'il utilise une commande service crond restart et il n'y a pas ce service)

je vais essayer les commandes que tu m'as donné; le premier ne fonctionne pas, j'ai remplacer mon interface par eth0, mais le "rate" ne semble pas être ok.

et le fichier traffic.log deviens vite un gros bordel.

(sinon existe t'il des endroits ou je peux recruter quelqu'un pour m'aider, mais pas pour trop cher ?)
OVH Global Solutions = 500€ HT/mois ...

Ne tape pas les commandes (jamais) sans comprendre comment elle fonctionne
pour les logs, comme j'ai dis, il faut que ça s'intègre à ton existant (c'était -m limit --limit, erreur de mémoire)

Rien n'apparais dans les fichiers de log ...
 
et les attaques continues ! la plaie !
 
j'aimerais pouvoir récuperer la liste d'IP, mais c'est comme si mon lien saturait sans aucune traces.

cf. le moindre tuto d'iptables. Les règles sont appliquées séquentiellement, si tu rajoutes une règle telle que celle de log à la fin mais que tu droppes/acceptes avant, tu ne verras rien.

ça m'étonnerait qu'avec tcpdump tu n'aies rien.
Pour le reste, faut faire les choses correctement mais sans rentrer dans la machinerie et comprendre les différentes briques, c'est pas trivial...

ok, j'ai donc repris mon fichier de règles de firewall, et placé la ligne avec le LOG dans le haut, avant les premières règles de DROP.
 
par rapport au tcpdump, il y a énormément d'informations qui y apparaissent, et c'est difficile de s'y retrouver :x
 
merci encore pour ton aide.

Si tu veux tu peux ouvrir le fichier de sortie avec Wireshark, ce sera plus facile à analyser. Tu dois pouvoir facilement déterminer si les attaques viennent toutes de la même adresse IP.

Pas avec la commande que je lui ai fourni. C'était uniquement une redirection de l'output dans un fichier texte.

Exact, il faut sortir un pcap avec l'option -w.

Rien à faire ... je n'arrive pas à grand chose et mon serveur croule sous les attaques ...
 

as-tu réussi (avec ce que je t'ai donné) à identifier le traffic et les adresses sources de ces attaques ?
Si tu n'as que peu d'attaquants tu peux tenter sans garanties quelques mail à la cellule abuse du provider associé.

non je ne parviens pas à grand chose ...
j'ai obtenu un fichier de dump, mais même avec Wireshark, cela reste pour moi inexploitable :x

j'aimerais bien identifier le type d'attaque, et eventuellement la source.

merci

(et concernant le LOG je n'ai rien réussi à faire avec, même en le placant en début de script par exemple)

EDIT : avec iftop j'ai reussi a voir que juste quand le serveur "lag" il y a énormement de requête sur le service "domain"
pas normal non ? attaque ou pas ? (coincidence sinon?)
(et ma connexion wifi à laché à peu pres au meme moment que le serveur apache la ...)

Tu peux le mettre à disposition quelque part ?
 

Effet de bord, iftop doit essayer de résoudre toutes les IP en nom de machine. (d'où le -n quand je t'ai demander le tcpdump)

Pour le dump, je vais voir si je peut le mettre à dispo, je te redis çà dans quelques minutes. (je ne sais pas si il est bon et contient des attaques)
et pour le iftop, je l'ai lancé avec "iftop -P -n"
j'ai remis mon firewall bloquant tous les pays non francophones.

EDIT : merde mon script pour bloquer les IP ne s'applique que sur le port 80 >< j'aurais du le mettre sur tous les ports ...
 (aucun risque avec les dns et tout ??)

PS : concernant le dump, si je le laisse longtemps, pour avoir une attaque, le fichier sera plusieurs Go :x

OVH viens de me passer en aspiration pendant 1h ...

les joueurs s'en vont chez la concurrence ...

il se passe quoi si je bloque le port 53 ? (dns)

je viens d'apprendre que les DNS Amplification existe, serait ce un truc du genre ?

En même temps monter des services de ce type sans connaissance réseau... c'est le risque...
 

Renseigne toi sur ce qu'est le DNS
Tu veux le bloquer dans quel sens ? As tu un service DNS hébergé sur ton serveur ? On ne connait pas le sens de requête DNS dont tu parlais, on ne peut pas te répondre.
 

On ne peut pas deviner...

Je n'héberge pas de serveur DNS, j'ai donc bloqué celui ci en INPUT.

En effet, mes connaissances réseaux sont limités, surtout quand on arrive dans ce genre de problèmes ...

Le fait que le iftop ai affichés lorsque le serveur à perdu la connexion des dizaines et des dizaines de requêtes entrantes sur le port 53 ne signifierait pas une attaque de cette façon ?

merci

EDIT : bah je ne sais rien de plus, la le iftop à planter avec des requètes sur des ports qui sont fermés ...
j'essaye de lancer un tcpdump mais vu que la connexion sature ...

EDIT2 : il y a bien un lien avec le port 80, dès que l'on stop apache, l'attaque disparait.
je dois avoir un tcpdump à t'envoyer si tout c'est bien passé.

Pour apache tu as le mod evasive contre le DOS  

D'après les explications de o'gure le problème n'est pas là, d'ailleurs les requètes n'arrivent pas jusqu'au logs d'Apache; à mon avis c'est du UDP ou autre chose ...
 
merci quand même

D'après les traces qu'il m'a fourni en MP, il s'agit d'un DDoS qui vise à saturer son accès (traffic UDP provenant d'un grand nombre de machines en face)

En iptables, on peut limiter le trafic UDP ? Ça doit pouvoir l'aider, non ?

Comme j'ai déjà dit plusieurs fois, iptables limite une fois que le traffic a atteint ta carte réseau, Dans le cas d'un DDoS, c'est trop tard. Si on t'envoie 100Mbps sur ton serveur, tu peux dropper tout ce que tu veux sur ton serveur, ton lien sera toujours saturé. Pour reprendre une analogie que j'ai donné à rapha-35 en MP
C'est un problème d'architecture/d'infrastructure...
 - imagine un tuyau
 - d'un côté dans ta baignoire
 - de l'autre côté on ne sait pas.
tu auras beau mettre n'importe quel filtre entre ta baignoire et le tuyau, les autres personnes de l'autre côté mettrons ce qu'ils voudront, et cela arrivera au filtre situé entre la baignoire et le tuyau.

Si on tente de t'envoyer 200Mbps de pétrole dans ton tuyau de 100Mbps et que tes clients légitimes t'envoient 10Mbps de jus d'orange, tu auras beau mettre un filtre entre ta baignoire et le tuyau, dans ta baignoire, grace au filtre tu n'auras que du jus d'orange, mais tu n'auras pas tes 10Mbps de jus d'orange en sortie.  Tu as une belle congestion

Le filtre doit être mis en amont là où le traffic incriminé n'entraine pas de congestion
 

Ovh me dis qu'ils ne peuvent pas filtrer le vrai trafic UDP du port 53 d'une attaque; et on me demande a moi de le faire ... En menaçant de fermer mon serveur ... La bonne blague !