Il faut bien prendre conscience d'un truc, quand on a un serveur avec de l'ipv6, certains services comme sshd vont écouter en ipv6 et en ipv4
Si vous avez restreint l'acces au port SSH à certaines ips de confiances, il faut aussi faire l'opération avec ip6tables sinon vous êtes à poil en ipv6
Ce sont deux stacks complètement indépendantes
Description du format d'iptables-save
"This contains a few comments starting with a # sign. Each table is marked like <table-name>, for example mangle. Then within each table we have the chain specifications and rules. A chain specification looks like :<chain-name> <chain-policy> [<packet-counter>:<byte-counter>]. The chain-name may be for example PREROUTING, the policy is described previously and can, for example, be ACCEPT. Finally the packet-counter and byte-counters are the same counters as in the output from iptables -L -v. Finally, each table declaration ends in a COMMIT keyword. The COMMIT keyword tells us that at this point we should commit all rules currently in the pipeline to kernel. "
Le schema dans cet article est vraiment clair (ce qui est rare pour un schema iptables)
Quelques tentatives de connexion sur mon serveur. On voit un peu de tout : rdp, vnc, mysql ..
DPT=1433
DPT=22
DPT=23
DPT=3128
DPT=3306
DPT=3389
DPT=37662
DPT=37834
DPT=389
DPT=4899
DPT=5001
DPT=5900
DPT=7071
DPT=7777
DPT=8080
DPT=9200
DPT=992
une rule rsyslog
un logrotate
Franchement pas d'accord avec lui t_t
Bon ya aussi de bons conseil dans l'article, alors je lui pardonne !
"Consider a situation where your INPUT chain contains quite a few rules allowing traffic, and you’ve set the default policy to DROP. Later on, another administrator logs into the server and flushes the rules (which isn’t a good practice, either). I’ve met quite a few good systems administrators who are unaware of the default policy for iptables chains. Your server will be completely inaccessible immediately. All of the packets will be dropped since they match the default policy in the chain."
via arnaudb
Pas simple : "ulogd" un plugin userspace pour iptables va sortir un output en JSON. Logstash récupère derriere et envoie à elasticsearch. Kibana peut afficher.
Au final un dashboard qui résume le trafic.
Via skunnyk
Qu'est ce que le module conntrack et comment il classe les connexions TCP et UDP (NEW, RELATED, ESTABLISHED..)
Très bon article qui explique le fonctionnement d'iptables
TLDR :
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport EXTERNAL_PORT -j DNAT --to INTERNAL_IP:INTERNAL_PORT
Pour permettre aux noeuds du LAN avec des adresses IP privées de communiquer avec les réseaux public externes, configurez le pare-feu pour le masquage d'IP, qui masque les requêtes provenant des noeuds du LAN avec l'adresse IP du périphérique externe du pare-feu (dans ce cas, eth0) :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
La règle utilise la table de correspondance de paquets de NAT (-t nat) et spécifie la chaîne intégrée POSTROUTING pour NAT (-A POSTROUTING) sur le périphérique réseau externe du pare-feu (-o eth0). POSTROUTING permet aux paquets d'être modifiés lorsqu'ils quittent le périphérique externe du pare-feu. La cible -j MASQUERADE est spécifiée pour masquer l'adresse IP privée d'un noeud avec l'adresse IP externe du pare-feu / de la passerelle.
Si vous possédez un serveur sur votre réseau interne que vous souhaitez rendre disponible de manière externe, vous pouvez utiliser la cible -j DNAT de la chaîne PREROUTING dans NAT pour spécifier une adresse IP et un port de destination où les paquets entrants demandant une connexion à votre service interne peuvent être retransmis. Par exemple, si vous souhaitez retransmettre des requêtes HTTP à votre système de Serveur HTTP Apache dédié sur 172.31.0.23, exécutez la commande suivante :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
Cette règle spécifie que la table NAT utilise la chaîne intégrée PREROUTING pour retransmettre les requêtes HTTP entrantes exclusivement à l'adresse IP de destination listée de 172.31.0.23.
Note Remarque
Si vous avez une politique par défaut DROP dans votre chaîne FORWARD, vous devez ajouter une règle autorisant la retransmission de requêtes HTTP entrantes afin que le routage NAT de destination soit possible. Pour ce faire, exécutez la commande suivante :
iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
Cette règle autorise la retransmission de requêtes HTTP entrantes depuis le pare-feu vers la destination souhaitée sur le Serveur HTTP Apache derrière le pare-feu.
iptables -L
iptables -D fail2ban-SSH -s XXX.XXX.XXX.XXX -j DROP