iptables: Drop/Reject IPs - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 06-09-2016 à 08:35:08
Bon visiblement ça fonctionnerait correctement. tcpdump et iftop analysent les paquets à la sortie de la NIC, et donc avant qu'iptables fasse son boulot:
Chain FORWARD (policy ACCEPT 255 packets, 37544 bytes) |
Marsh Posté le 07-09-2016 à 00:36:47
Hello,
Ta conf devrait fonctionner, mais deux petites remarques :
Les regles inscrites dans les chaines INPUT et OUTPUT sont superflues, elles servent juste a empecher tes clients de communiquer avec ta passerelle, pas pour la traverser mais juste communiquer.
Aussi les "best practices" recommendent d'utiliser REJECT en target plutot que DROP. Il y a pas mal d'articles sur le net qui traitent du sujet mais grosso modo, ca emmerde tout le monde le DROP parce qu'on sait pas si c'est le serveur qui est down, ou il y a u probleme sur le reseau ou autre. Avec Reject tu sais direct que le serveur a pas voulu de ton paquet.
Marsh Posté le 07-09-2016 à 07:43:00
Ouaip après quelques tests supplémentaires j'ai noté que les IN/OUT ne servaient à rien.
Mais comme je ne savais pas trop comment iptables se comporte avec le FORWARD pour le traffic "entrant" vers les clients j'avais mis le OUT aussi ... puis le IN tant qu'à faire
Pour le DROP vs REJECT je le note, mais dans mon cas, après avoir mis en place la gateway et surveillé le trafic je me suis aperçu que mes caméras IP ouvraient des connexions non-désirées donc j'ai profité d'avoir la main sur la GW pour les couper définitivement d'internet ...
Marsh Posté le 05-09-2016 à 11:04:58
Bonjour
J'ai un host Debian 8 qui me sert de gateway pour mon réseau local.
Ce host est configuré comme default-router au niveau DHCP et en changeant sa default route localement, je peux passer, suivant les conditions, d'un accès internet via DSL ou via 4G.
Cette partie fonctionne correctement même si ce "bricolage" ajoute un HOP.
Par contre j'aimerai interdire l'accès internet à certaines IPs (tout en les laissant clients DHCP). Comme tout le trafic vers internet transite par ce host, utiliser iptables qui fait déjà le masquerading me semble l'idéal ... Mais ça ne fonctionne pas
Ma table:
root@vmgateway:~# iptables-save
# Generated by iptables-save v1.4.21 on Mon Sep 5 09:04:53 2016
*nat
:PREROUTING ACCEPT [110051:11471685]
:INPUT ACCEPT [19336:4024074]
:OUTPUT ACCEPT [1596:222457]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Sep 5 09:04:53 2016
# Generated by iptables-save v1.4.21 on Mon Sep 5 09:04:53 2016
*filter
:INPUT ACCEPT [72001:16761643]
:FORWARD ACCEPT [2228381:1357921047]
:OUTPUT ACCEPT [11233:1285899]
-A INPUT -s 192.168.1.70/32 -j DROP
-A INPUT -s 192.168.1.69/32 -j DROP
-A INPUT -s 192.168.1.68/32 -j DROP
-A FORWARD -s 192.168.1.70/32 -j DROP
-A FORWARD -s 192.168.1.69/32 -j DROP
-A FORWARD -s 192.168.1.68/32 -j DROP
-A OUTPUT -s 192.168.1.68/32 -j DROP
-A OUTPUT -s 192.168.1.69/32 -j DROP
-A OUTPUT -s 192.168.1.70/32 -j DROP
COMMIT
# Completed on Mon Sep 5 09:04:53 2016
Et pourtant en regardant avec iftop (ou tcpdump) ces trois IPs accèdent toujours à internet:
24.56.178.140 => 192.168.1.69 0b 0b 0b
<= 0b 182b 182b
24.56.178.140 => 192.168.1.70 0b 0b 0b
<= 0b 182b 182b
24.56.178.140 => 192.168.1.68 0b 0b 0b
<= 0b 122b 122b
168.1.83.89 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
23.234.53.61 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
23.234.53.67 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
50.7.44.82 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
50.7.124.48 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
50.7.114.59 => 192.168.1.68 0b 0b 0b
<= 0b 70b 70b
50.7.176.18 => 192.168.1.68 0b 0b 0b
root@vmgateway:~# tcpdump src 192.168.1.68 or src 192.168.1.69 or src 192.168.1.70 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:08:14.974699 IP 192.168.1.69.59918 > 50.7.124.48.10001: UDP, length 60
11:08:14.974748 IP 192.168.1.69.59918 > 23.234.53.67.10001: UDP, length 60
11:08:14.975019 IP 192.168.1.69.59918 > 23.234.53.61.10001: UDP, length 60
11:08:14.975038 IP 192.168.1.69.59918 > 50.7.176.18.10001: UDP, length 60
11:08:14.975046 IP 192.168.1.69.59918 > 50.7.114.59.10001: UDP, length 60
11:08:14.975237 IP 192.168.1.69.59918 > 168.1.83.89.10001: UDP, length 60
11:08:14.975251 IP 192.168.1.69.59918 > 50.7.44.82.10001: UDP, length 60
11:08:19.981930 ARP, Request who-has 192.168.1.254 tell 192.168.1.69, length 46
11:08:23.050132 IP 192.168.1.70.59938 > 168.1.83.89.10001: UDP, length 60
11:08:23.050186 IP 192.168.1.70.59938 > 50.7.44.82.10001: UDP, length 60
11:08:23.050191 IP 192.168.1.70.59938 > 50.7.124.48.10001: UDP, length 60
11:08:23.050276 IP 192.168.1.70.59938 > 23.234.53.67.10001: UDP, length 60
11:08:23.050383 IP 192.168.1.70.59938 > 23.234.53.61.10001: UDP, length 60
11:08:23.050529 IP 192.168.1.70.59938 > 50.7.176.18.10001: UDP, length 60
11:08:23.050538 IP 192.168.1.70.59938 > 50.7.114.59.10001: UDP, length 60
11:08:28.058107 ARP, Request who-has 192.168.1.254 tell 192.168.1.70, length 46
11:08:32.899379 IP 192.168.1.68.59935 > 50.7.124.48.10001: UDP, length 60
11:08:32.899438 IP 192.168.1.68.59935 > 23.234.53.67.10001: UDP, length 60
11:08:32.899550 IP 192.168.1.68.59935 > 23.234.53.61.10001: UDP, length 60
11:08:32.899624 IP 192.168.1.68.59935 > 50.7.176.18.10001: UDP, length 60
11:08:32.899806 IP 192.168.1.68.59935 > 50.7.114.59.10001: UDP, length 60
11:08:32.899821 IP 192.168.1.68.59935 > 168.1.83.89.10001: UDP, length 60
11:08:32.899949 IP 192.168.1.68.59935 > 50.7.44.82.10001: UDP, length 60
11:08:34.047269 IP 192.168.1.68.42347 > 132.163.4.103.123: NTPv3, Client, length 48
Merci d'avance pour les éventuelles infos/idées
Message édité par Deadlock le 05-09-2016 à 11:09:25
---------------
Institutions européennes: Ensemble d'outils dont le but est de transformer une grande quantité d'argent en merde. Cette merde est utilisée pour créer de nouveaux fonctionnaires. L'argent restant payant des externes pour faire leur travail.