[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] Syn flood, comment s'en débarrasser ?



Le 20 juin 2015 à 13:04, Samuel <debian-user-french-2010@ingescom.com> a écrit :

> Le 20/06/2015 12:31, Samuel a écrit :
>> Le 20/06/2015 12:02, Philippe Gras a écrit :
>>>  
>>> J’ai modifié le script qui établit les règles un peu tous les jours pour essayer de résoudre ce problème, alors
>>> il est possible que je me sois mélangé les pinceaux.
>>> 
>>> Je vous l’ai mis sous la même url pour que vous puissiez deviner la chronologie des versions, parce que j’ai
>>> commenté les versions précédentes et ne les ai pas écrasées.
>> 
>> En regardant vite fait :
>> 
>> iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73 -j DROP
>> iptables -A INPUT -p tcp --dport 80 -s 162.158.68.167 -j REJECT --reject-with icmp-port-unreachable
>> 
>> Comme discuté ici-même je crois, faut regrouper (pour la lisibilité) et rester sur du REJECT, pas DROP :
>> 
>> iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT

La lisibilité n’est en effet pas très bonne pour autrui, mais ce n’était de toute façon pas mon objectif au départ…

Il s’agit d’IP qui envoient du spamco sur mes sites, je les ai d’abord mises en DROP, puis j’ai découvert l’intérêt
du REJECT pour ce type de requêtes (qui ne sont pas envoyées de façon massive).

Pour boucler sur ma première déclaration, c’est une connerie de ma part de mettre ces règles dans le script.

Je ferais mieux de les balancer au coup le coup en console, ça irait plus vite, serait plus pratique et enfin serait
plus lisible y compris pour moi. D’autant plus que ces mecs ne reviennent plus après s’être fait rejeter quelques
fois dans le mois. Idem pour ce que j’ai ajouté sur le port du SMTP.
>> 
>> ----------
>> 
>> iptables -A INPUT -d 5.135.191.38 -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.' -j DROP
>> 
>> Ce genre de test sur du contenu, je le mettrais plutôt une fois que tout le reste marche.
>> 
>> -----------
>> iptables -t filter -A INPUT -p icmp -j ACCEPT
>> iptables -t filter -A OUTPUT -p icmp -j ACCEPT
>> 
>> C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur une chaine FORWARD à compléter selon besoins ):
>> 
>> iptables -A FORWARD -i $lan -o $fai -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state ESTABLISHED -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type destination-unreachable -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type time-exceeded -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type parameter-problem -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type fragmentation-needed -j ACCEPT
>> iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED --icmp-type source-quench -j ACCEPT

Merci pour cette suggestion qui me semble très intéressante… Je vais creuser ce qu’est le ICMP et le LAN avant,
parce que je n’ai pas encore bien compris de quoi il s’agissait.

>> 
>> --------------
>> 
>> As-tu vraiment un DNS public ? :
>> 
>> iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
>> iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
>> iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
>> iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
>> 
>> Je n'ai pas regardé en détail, juste vite fait.

Il ne me semble pas, et l’avoir fermé après avoir eu plein d’erreurs avec le serveur DNS. Je n’ai plus d’erreurs,
mais je n’ai pas pensé à toucher à cette partie de la configuration d’iptables qui est restée d’origine.
>> 
>> Il faut reprendre à zéro ça sera plus simple en fonction de tes besoins et réécrire chaque règle en suivant la règle :

Oui, je suis d’accord :-) C’est sans doute le moment de refaire un truc, mais bien carré cette fois.

J’ai récupéré plein d’informations depuis, mais je manque encore de compétences sur Netfilter ;-)

>> 
>> 1) politique par défaut en DROP
>> 2) on ACCEPT au cas par cas en sécurisant au maximum
>> 3) On REJECT tout le reste avec éventuellement des logs.
> 
> Il ne faut pas oublier de glisser en 1bis) les règles pour bloquer les ennuyeux (sur des ports ouverts) comme j'ai pu le voir :
> 
> 1) politique par défaut en DROP
> 1bis) iptables -A INPUT -p tcp --dport 80 -s 54.77.203.73,162.158.68.167 -j REJECT
> 2) on ACCEPT au cas par cas en sécurisant au maximum
> 3) On REJECT tout le reste avec éventuellement des logs. 
> 
> Samuel.


Reply to: