Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1814 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

Iptables Openwrt plusieur interface

n°1224969
vith
Vit0
Posté le 24-06-2010 à 22:43:13  profilanswer
 

Reprise du message précédent :
T'appels quoi par connexion invalides ?
 
Et j'ai pas compris quand tu dis : je remplace l'ip local de mes machines par mon ip public ?!

mood
Publicité
Posté le 24-06-2010 à 22:43:13  profilanswer
 

n°1224978
High Plain​s Drifter
Posté le 25-06-2010 à 01:13:25  profilanswer
 

INVALID c'est un état du module de suivi de connexion (mod_conntrack) et là on rentre dans un monde compliqué, je sait que les "TCP ACK" ne se référents pas à une connexions dans la table de suivi sont marqués INVALID, y'a aussi un filtrage sur les IP qui n'ont rien à faire là je crois (genre 127.0.0.1 sur eth0)
 
Remplacer l'IP locale, c'est remplacer l'IP de ta debian (192.168.1.6) par l'IP publique routeur (82.xx.xx.xx) car si ton paquet se balade sur internet avec 192.168.1.6 comme source, tu pourra attendre longtemps la réponse :whistle: Ça permet aussi d'initialiser cette connexion dans la table de suivi (dont je parle plus) comme ça quand la réponse reviendra le routeur saura qu'il faut la rediriger vers 192.168.1.6 (pour ça qu'il n'y a pas besoin de règles supplémentaires pour les paquets entrants)
 
On dit des routeurs et firewalls capables d'effectuer ce suivi de connexion qu'ils sont "stateful", avec iptables ce "stateful" devient le module state avec son option --state et ses fameux paramètres : NEW, ESTABLISHED, RELATED, UNTRACKED, INVALID et vu le nombre de fois qu'on les utilises on imagine facilement à quoi ça revient de s'en passer : beaucoup de lignes de plus et beaucoup moins de possibilités (pas de NAT par exemple)
 
 
 
Au passage j'ai mis en place le filtrage des connexions entrantes sur le routeur à partir du LAN au lieux de tout accepter bêtement, chez moi ça revient à  

                                                                                                                                   
# Règles par défaut, toujours pareil quasi-tout accepter en sortie, uniquement les connexions établies en entrée
iptables -t filter -A OUTPUT -o $V4_LAN_IFACE -s $V4_LAN_IP -d $V4_LAN_NETWORK -m state ! --state INVALID -j ACCEPT
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -m state --state ESTABLISHED,RELATED -j ACCEPT                                                      
                                                                                                                                                                                   
# Pouvoir pinger son routeur c'est bien !
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -p icmp -m icmp --icmp-type echo-request -m state --state NEW -j ACCEPT                              
                                                                                                                                                                                   
# Traceroute aussi c'est bien !
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -p udp -m udp --dport 33434:33523 -m state --state NEW -j REJECT --reject-with icmp-port-unreachable
                                                                                                                                                                                   
# Accepter les requêtes DNS
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT                                              
                                                                                                                                                                                   
# Accepter les requêtes DHCP et leurs réponses, pas d'IP source ou de destination ici car on demande justement à un routeur dont on ne connais pas l'IP de nous en fournir une :D
iptables -t filter -A OUTPUT -o $V4_LAN_IFACE -p udp --sport 67 --dport 68 -j ACCEPT
iptables -t filter -A INPUT -i $V4_LAN_IFACE -p udp --sport 68 --dport 67 -j ACCEPT                                                                                                
                                                                                                                                                                                   
# Accepter SSH sur le port 22
iptables -t filter -A INPUT -i $V4_LAN_IFACE -s $V4_LAN_NETWORK -d $V4_LAN_IP -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT  


Assez simple en IPv4 comme je l'avais dit, maintenant je dois attaquer l'IPv6 et je vais en chier  :fou:


Message édité par High Plains Drifter le 25-06-2010 à 01:38:27

---------------
| < Ceci n'est pas une pipe.
n°1225117
vith
Vit0
Posté le 25-06-2010 à 22:30:46  profilanswer
 

Tu viens de me faire un cours la =D, merci j'ai tout compris =D sauf TCP ACK :) mais je pense j'en suis pas encore la pour comprendre.
 
Merci pour la mise a jour je viens de modifier avec mes variables ^^?
 
On pourrais utiliser iptables comme log de connection ? genre  a chaque fois que j'ai une connection établie ou refuser par mon ssh, sa log dans un fichier ?

n°1225118
High Plain​s Drifter
Posté le 25-06-2010 à 22:50:49  profilanswer
 

vith a écrit :

Tu viens de me faire un cours la =D, merci j'ai tout compris =D sauf TCP ACK :) mais je pense j'en suis pas encore la pour comprendre.


Quand on initialise une connexion TCP on envoi un SYN au serveur (demande de connexion)
- Le serveur répond par un ACK (accusé de réception) + un SYN  (demande de connexion)
- Le client répond par un ACK
Si le serveur reçoit un ACK et qu'il ne trouve pas la connexion correspondante dans sa table de suivi => Paquet invalide
 

On pourrais utiliser iptables comme log de connection ? genre  a chaque fois que j'ai une connection établie ou refuser par mon ssh, sa log dans un fichier ?


Iptables ne sait si la connexion ssh a réussi (bon mot de passe) ou pas, vaut mieux utiliser les logs d'iptables dans ce cas.


Message édité par High Plains Drifter le 25-06-2010 à 22:51:16

---------------
| < Ceci n'est pas une pipe.
n°1225119
vith
Vit0
Posté le 25-06-2010 à 23:01:39  profilanswer
 

les logs d'iptables ne sont pas lié a iptables ? donc il sais ?

n°1225120
High Plain​s Drifter
Posté le 25-06-2010 à 23:08:10  profilanswer
 

Je voulais dire les logs de SSH  :pt1cable:
 
En fait le """problème""" avec SSH c'est qu'il ouvre un canal sécurisé pour la saisie des mots de passes, donc impossible de différencier le connexions réussies ou refusées en analysant la connexion ou en faisant du deep packet inspection.


Message édité par High Plains Drifter le 25-06-2010 à 23:11:08

---------------
| < Ceci n'est pas une pipe.
n°1225122
vith
Vit0
Posté le 25-06-2010 à 23:12:29  profilanswer
 

J'ai trouvé ce script qui donne un log via iptables pour le SSH :
 

Code :
  1. # bounce to port 22
  2. iptables -t nat -A prerouting_wan -p tcp --dport 443 -j DNAT --to :22
  3. # set restrictions on port 22
  4. iptables        -A input_wan      -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 --name ATTACKER_SSH --rsource -j DROP
  5. iptables        -A input_wan      -p tcp --dport 22 -m state --state NEW -m recent --set --name ATTACKER_SSH --rsource -j ACCEPT


 
Ou :
 

Code :
  1. # Brute Force Protection (BFP) adapted from http://forum.openwrt.org/viewtopic [...] 522#p34522
  2. # For "-m recent" in Kamikaze 8.0.9 the packages "iptables-mod-conntrack-extra" and "kmod-ipt-conntrack-extra" are needed (files: libxt_recent.so & xt_recent.ko)
  3. # As target REJECT is not allowed in nat/prerouting, redirect to an unused port and reject it in filter/input and filter/forwarding
  4. echo ' ...establishing reject rules for prerouting'
  5. BFP_REJECTPORT=55555
  6. # nat chain that redirects to reject port
  7. iptables -t nat -N prerouting_REJECT
  8. iptables -t nat -A prerouting_REJECT -p tcp -j DNAT --to :${BFP_REJECTPORT}
  9. iptables -t nat -A prerouting_REJECT -p udp -j DNAT --to :${BFP_REJECTPORT}
  10. # filter rules that will finally reject
  11. iptables -A input_wan      -p tcp  --dport ${BFP_REJECTPORT} -j reject
  12. iptables -A forwarding_wan -p tcp  --dport ${BFP_REJECTPORT} -j reject
  13. iptables -A input_wan      -p udp  --dport ${BFP_REJECTPORT} -j reject
  14. iptables -A forwarding_wan -p udp  --dport ${BFP_REJECTPORT} -j reject
  15. ### SSH/Dropbear (TCP-22)
  16. SERVICE=SSH
  17. PROTO=tcp
  18. PORT=22
  19. BFP_START=6
  20. echo " ...establishing ${SERVICE} rules for ${PROTO}-${PORT}"
  21. ## nat chain that updates connections and rejects
  22. iptables -t nat -N prerouting_wan_BFP_${PROTO}${PORT}
  23. iptables -t nat -A prerouting_wan_BFP_${PROTO}${PORT} -p ${PROTO} --dport ${PORT}  -m recent --name ATTACKER_${PROTO}${PORT} --rsource --update                                      -j prerouting_REJECT
  24. ## nat/prerouting
  25. # immediately jumps to update+reject chain if remote source already in BFP mode (avoids multiple bruteforce log entries)
  26. iptables -t nat -A prerouting_wan -p ${PROTO} --dport ${PORT} -m state --state NEW -m recent --name ATTACKER_${PROTO}${PORT} --rsource --rcheck --seconds 60 --hitcount ${BFP_START} -j prerouting_wan_BFP_${PROTO}${PORT}
  27. # adds/updates remote source in list
  28. iptables -t nat -A prerouting_wan -p ${PROTO} --dport ${PORT} -m state --state NEW -m recent --name ATTACKER_${PROTO}${PORT} --rsource --set
  29. # check if BFP mode for remote source applies, if so log bruteforce and reject
  30. iptables -t nat -A prerouting_wan -p ${PROTO} --dport ${PORT} -m state --state NEW -m recent --name ATTACKER_${PROTO}${PORT} --rsource --update --seconds 60 --hitcount ${BFP_START} -j LOG --log-level warn --log-prefix "BRUTEFORCE-${SERVICE} "
  31. iptables -t nat -A prerouting_wan -p ${PROTO} --dport ${PORT} -m state --state NEW -m recent --name ATTACKER_${PROTO}${PORT} --rsource --rcheck --seconds 60 --hitcount ${BFP_START} -j prerouting_wan_BFP_${PROTO}${PORT}
  32. ## filter/input
  33. iptables        -A input_wan      -p ${PROTO} --dport ${PORT} -m state --state NEW -j LOG --log-level info --log-prefix "${SERVICE} "
  34. iptables        -A input_wan      -p ${PROTO} --dport ${PORT} -m state --state NEW -j ACCEPT


 
 
Mais lui il est plutôt bruteforce et bla bla avec log =D
Sa fait appel a des " modules ? " externe j'ai l'impression


Message édité par vith le 25-06-2010 à 23:14:23
n°1225124
High Plain​s Drifter
Posté le 25-06-2010 à 23:33:23  profilanswer
 

En fait je fait déjà un peu la même chose (sans logging) :

Citation :

# SSH on frost with bruteforce protection
ip6tables -t filter -A FORWARD -i $V6_WAN_IFACE -o $V6_LAN_IFACE -s $V6_WAN_NETWORK -d $V6_FROST_IP -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
ip6tables -t filter -A FORWARD -i $V6_WAN_IFACE -o $V6_LAN_IFACE -s $V6_WAN_NETWORK -d $V6_FROST_IP -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 2 --name SSH --rsource --rttl -j DROP
ip6tables -t filter -A FORWARD -i $V6_WAN_IFACE -o $V6_LAN_IFACE -s $V6_WAN_NETWORK -d $V6_FROST_IP -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT


 
Ça utilise le module recent mais avec iptable tout ou presque est un module (-m tcp, -m state, -m recent...)
 
recent permet de logger les connexions et de détecter les connexions identiques (même IP, même TTL...) car comme le dirait un de nos cher ministre "quand il y a une connexion ça va, c'est quand il y en a beaucoup qu'il y a des problèmes".
 
Là avec l'option "--hitcount 2" je permet en fait à une IP de se connecter qu'une fois à mon ssh et avec l'option "--seconds 180"  je précise que s'il dépasse l'IP est bannie pour 3 minutes.
 
Comme mon SSH permet 3 tentatives de mot de passe ça laisse à un attaquant 3 tentatives toutes les 3 minutes, trop lent pour faire du bruteforce.
 
Par contre ça ne différencie pas le connexions réussies (je me suis loggé en SSH) ou refusés (j'ai tapé trois mauvais mots de passes), donc si j'ouvre une session ssh, je lance une commande et je referme de suite la session ben je suis bon pour poiroter 3 minutes si je veut me reconnecter à la même machine...
 
C'est pour ça qu'il y as des scripts qui fonctionnent à plus haut niveau (fail2ban), mais la mise en place se fait plus facilement sur la machine qui fait tourner SSH qu'au niveau du routeur.


---------------
| < Ceci n'est pas une pipe.
n°1225128
vith
Vit0
Posté le 25-06-2010 à 23:52:41  profilanswer
 

A oui c'est pas top par contre ...
Si jamais j'ai eu des petites coupure je suis fichue =)
 
Les log d'iptables se loge dans quoi ?
 
Fail2ban existe pas sous openwrt ... je pense que je vais acheter un mini itx pour faire tourner un debian dessus =/


Message édité par vith le 25-06-2010 à 23:52:59
n°1225130
High Plain​s Drifter
Posté le 26-06-2010 à 00:18:16  profilanswer
 

Perso ce que j'ai fait c'est que j'ai rendu le SSH de ma Fonera accessible uniquement à partir du LAN.
 
Si je veut accéder à ma Fonera de l'extérieur je me connecte sur un des PC du LAN (qui fait tourner fail2ban) puis à partir de ce PC je me connecte à ma Fonera.
 
C'est de toute façon une bonne sécurité de ne pas laisser des services ouverts de l'extérieur sur un routeur !


---------------
| < Ceci n'est pas une pipe.
mood
Publicité
Posté le 26-06-2010 à 00:18:16  profilanswer
 

n°1225131
vith
Vit0
Posté le 26-06-2010 à 00:24:36  profilanswer
 

Pas bête ! certe, si le pc lache bah plus d'accès ... =/

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[OpenWRT] fonctionnement et problémesiptables: FORWARD forward bizarrement
IPTables versus modsecurityQuel carte son avec interface s/pdif interne ?
[Résolu] IPtables bloque tout seul les scan ?Interface de gestion de serveurs : OpenQRM : cherche retour d'expéri
[FreeNas] Interface Web [résolut]Probléme avec marquage des paquets avec iptables
Un serveur de chat via interface web légerFiltrage iptables (netfilter) qui ne fonctionne pas (???)
Plus de sujets relatifs à : Iptables Openwrt plusieur interface


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR