iptables pour bloquer les sites Web https

9

Je souhaite bloquer quelques sites Web qui fonctionnent également sur https, comme Facebook, Twitter et Gmail, dans mon organisation. Squid n'est pas censé être utilisé ici selon les ordres de la haute direction. Nous pouvons utiliser Untangle Lite Package et iptables.

Y a-t-il une option autre que Squid pour ce faire? Une iptablesrègle pour bloquer ce type de trafic serait également très utile.

j'ai trouvé ça

iptables -t filter -I INPUT -m string --string facebook.com -j LOG --algo bm
iptables -t filter -I INPUT -m string --string facebook.com -j REJECT --algo bm

mais https fonctionne toujours sur les machines à l'exception de la machine locale.

iptables filter

— Dharmit
source

2

vous devez expliquer à votre entreprise qu'éviter https pour un compte personnel n'est pas une bonne idée car cela pourrait conduire à des vols d'identité au sein de l'entreprise, déployer un certificat sur toutes les machines et agir comme un homme au milieu serait une bien meilleure façon de vérifier qui est connexion à facebook. aussi je ne suis pas sûr, mais je pense qu'il n'est plus possible de se connecter à gmail sans https.

— Kiwy

Puis-je savoir comment vous avez obtenu toutes ces adresses IP?

— Jagadeesh

12

Au lieu de faire une correspondance en fonction de l'URL, essayez de faire une correspondance en fonction du contenu du certificat.

iptables -t nat -I INPUT --sport 443 -m string \
                 --string www.facebook.com --algo bm -j REJECT

Vous pouvez également établir une correspondance sur l'empreinte digitale, mais si la destination modifie ou met à jour son certificat, cela invalidera votre règle.

— pr0f3550r
source

cela peut-il bloquer tout ce qui correspond à www.facebook.com même dans le corps html, mais c'est légitime comme ça dans la zone de commentaire. Il peut être bloqué au niveau de l'URL, mais qu'en est-il de l'adresse IP?

— Nikhil Mulley

@NikhilMulley: Non, il ne correspondra qu'au certificat SSL servi par Facebook. Tout le reste est crypté et ne peut pas être vu.

— bahamat

2

Seul le premier paquet d'une connexion entre dans la nattable (et il n'y a pas de chaîne INPUT dans la table nat), je pense que vous vouliez dire filterlà. De plus, il y a une chance (très) éloignée que cela corresponde aux paquets où 443 est le port client

— Stéphane Chazelas

Quelqu'un at-il utilisé cette solution? En dehors de l'absence de -p tcprègle, cela ne semble pas être quelque chose d'utile ..

— ivanleoncz

10

Le pare-feu ne peut pas contrôler les URL HTTPS auxquelles le client tente d'accéder, car l'URL est chiffrée. Le pare-feu ne peut contrôler que les sites auxquels le client se connecte, en utilisant des adresses IP, mais cela n'aide pas si les versions HTTP et HTTPS du site sont à la même URL (et même si elles ne le sont pas, vous auriez pour maintenir une énorme liste d'adresses IP).

La seule façon réaliste de bloquer HTTPS est de le bloquer complètement. Insistez sur le fait que toutes les connexions doivent être HTTP valides (c'est-à-dire que le client commence par envoyer une HTTPligne, etc.). Cela ne peut pas être fait avec seulement IPtables, vous avez besoin d'un proxy réel prenant en charge le protocole tel que Squid. (Je ne sais pas de quoi Untangle Lite est capable.)

Vous pouvez bloquer la plupart du trafic HTTPS en bloquant le trafic sortant vers le port 443, car presque tous les serveurs HTTPS sont sur ce port. Ou, suivant une approche de liste blanche, autorisez uniquement le trafic sortant vers le port 80 (le port HTTP normal).

Une approche différente serait de proxy toutes les connexions HTTP et HTTPS. Ensuite, vous pouvez faire correspondre les URL. Cela nécessite de mener une attaque d'homme au milieu sur les clients. Vous pouvez le faire si vous déployez votre propre autorité de certification sur toutes les machines clientes et que vous l'enregistrez en tant que racine de confiance. Cela peut être considéré comme contraire à l'éthique.

Peu importe ce que vous faites, les utilisateurs déterminés configureront un proxy en dehors de votre environnement et exécuteront IP sur HTTP ou quelque chose comme ça.

Vous semblez soit essayer de résoudre un problème social avec des moyens techniques, qui ne fonctionne presque jamais, soit faire de votre mieux pour mettre en œuvre une exigence idiote de la part de la direction (dans ce cas, je choisirais de bloquer le port 443, peut-être uniquement pour certaines adresses IP, qui vous permettraient de signaler que vous avez fait votre travail, peu importe leur utilité).

— Gilles 'SO- arrête d'être méchant'
source

1

un pare-feu professionnel comme Checkpoint permet le filtrage https sans déployer de certificat client dans la dernière version, je ne sais pas comment ils y parviennent, mais cela fonctionne.

— Kiwy

4

Je connais une option.

Si vous avez des serveurs DNS internes à utiliser, mettez simplement des références statiques dans vos données de zone TLD qui résolvent les domaines (que vous ne souhaitez pas établir les connexions externes) à 127.0.0.1. De cette façon, tous les hôtes utilisant le DNS central de votre réseau résoudront les domaines (facebook.com/twitter.com en soi) en adresse de bouclage, ce qui ne mènera nulle part.

Cela fonctionnera si vous avez un contrôle total sur la configuration du résolveur des ordinateurs clients de votre réseau. Si les postes de travail / clients sont autorisés à modifier / modifier / etc / hosts ou /etc/resolv.conf, ils peuvent contourner cette option.

— Nikhil Mulley
source

+1 pour cela. Cela peut être fait en insérant ces références dans le /etc/hostsfichier. Par exemple:127.0.0.1 www.facebook.com

2

Ou, pour une solution plus civilisée, définissez les enregistrements DNS A (ou les entrées hosts / hosts.txt) pour faire référence à un hôte intranet avec un serveur Web qui explique exactement pourquoi l'utilisateur n'a pas été envoyé sur Facebook, etc. Veuillez noter que cela rompt HTTPS car le nom d'hôte prévu (par exemple www.facebook.com) ne correspondra pas au certificat CN.

— Alexios

@Alexios: OpenDNS est une excellente solution pour cela.

— Kevin M

@KevinM: merci, c'est utile de savoir. Je garderai cela à l'esprit (bien que nous ayons notre propre petite ferme DNS au travail)

— Alexios

2

Une option consiste à blackhole les routes vers les blocs réseau: (La liste est pour FB)

ip route add blackhole 69.171.224.0/19
ip route add blackhole 74.119.76.0/22 
ip route add blackhole 204.15.20.0/22
ip route add blackhole 66.220.144.0/20
ip route add blackhole 69.63.176.0/20
ip route add blackhole 173.252.64.0/18

— soi
source

1

non ce n'est pas le cas, il est trop compliqué de maintenir une liste d'ip pour facebook twitter ou même google qui ne communique plus ses propres plages de plage ip.

— Kiwy

1

Le filtre de contenu simple ne peut pas bloquer le site SSL.

Utilisez des outils de protection contre les intrusions comme snort / suricata.

Exemple de règle IPS : pour bloquer les URL ssl pour une adresse IP spécifique.

drop ip any 443 -> 192.168.3.30 any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".fbcdn.net"; msg:"Simplewall Ssl block for User30 : Urls => .fbcdn.net " ;sid:11469443;rev:1;)

drop ip any 443 -> 192.168.3.30 any (content:".youtube.com"; msg:"Simplewall Ssl block for User30 : Urls => .youtube.com " ;sid:13989722;rev:1;)

Télécharger Simplewall : dans les règles de politique de simplewall partagées par Squid + Suricata IPS.

— Chetan Muneshwar
source

0

Vous devriez mettre cela sur la chaîne FORWARD, par exemple

iptables -I FORWARD  -m string --string "facebook.com" \
                     --algo bm --from 1 --to 600 -j REJECT

Cela affectera les autres systèmes du réseau, à l'exception du pare-feu.

— Senthamil
source