Conseils pour une configuration iptables sécurisée pour se défendre contre les attaques. (côté client!)

Je me rends compte qu'il y a des opinions différentes, mais une attitude majeure des personnes qui connaissent vraiment le réseau et la sécurité est que la plupart de ces règles iptables/sysctl sont redondantes, voire dommageables pour vous et le réseau. Certains vous reprocheront agressivement de rompre avec un comportement standard sans raison. Quelques exemples :

Le comportement TCP/IP standard est de REJETER afin que l'homologue obtienne un indice sur ce qui se passe. Peut-être que quelqu'un a mal tapé une URL ou que votre administrateur compte les hôtes ou que quelqu'un veut se connecter à votre serveur de jeu mais a tapé le mauvais port. Avec DROP, ils n'obtiennent que des délais d'attente obscurs et ennuyeux.
Il n'est pas nécessaire de supprimer des paquets invalides ou malformés, toutes ces attaques datent d'une décennie. Les développeurs du noyau Linux sont beaucoup plus à jour que vous concernant les types de paquets valides et ceux qui ne le sont pas. "Qu'en est-il des défauts futurs", pourraient dire certains. Eh bien, comment savez-vous que la future faille se trouvera dans le gestionnaire TCP et non dans l'analyseur TCP iptables ?
La plupart des paramètres sysctl sont par défaut. S'ils ne le sont pas, il y a généralement une raison. Par exemple, pourquoi désactiver l'envoi de redirections ? Je trouve très utile d'être informé par un pair que mon routage est mauvais, même si je ne réagirais jamais("accept_redirects", default=0) automatiquement.
Avec vos log_martians et d'autres règles de journalisation, j'espère que vous avez également un quota sur /var/log, ou ce sera très amusant de remplir votre disque à distance, ce qui tuera généralement vos services/applications. De plus, vous devez utiliser une limite de débit pour la journalisation ou quelqu'un pourrait remplir le quota pour vous empêcher de voir les tentatives de force brute de mot de passe SSH dans auth.log, ou d'autres choses. Lisez-vous réellement ces journaux sur un ordinateur de bureau ? Je recommande logcheck.
Vous semblez bloquer ICMP. Outre le problème DHCP mentionné, cela empêche également la découverte PMTU. Sans PMTUD, vous obtiendrez un comportement étrange lorsque vous utiliserez le système dans des endroits avec une connexion DSL ou d'autres paramètres réseau. Certains paquets seront simplement abandonnés et personne ne vous dira pourquoi.
Le filtrage des paquets sortants est un peu obscur. Vous ne vous faites pas confiance ? Vous ne devez généralement pas exécuter de programmes auxquels vous ne pouvez pas faire confiance. Les systèmes d'exploitation de base sont pour la plupart incapables d'isoler ces programmes des écoutes clandestines ou même de manipuler les données d'autres programmes (par exemple, les attaques de synchronisation du cache)
Vous avez besoin de NOUVEAUX paquets pour avoir SYN. Cela s'arrêtera si une connexion TCP est poursuivie après que l'état respectif dans iptables a déjà expiré. Je ne sais pas quels sont les délais d'attente par défaut, mais un gars de netfilter l'a averti.

Alors, quand un ordinateur de bureau doit-il avoir un pare-feu ?

S'il y a une attaque spécifique dans les actualités à laquelle votre système d'exploitation ou vos serveurs actuels sont vulnérables, et l'une des solutions rapides recommandées est une règle de pare-feu.
Vous devez exécuter certains services qui ne permettent pas une configuration sécurisée. La plupart le font, et le reste est mieux remplacé par des alternatives sécurisées.
Vous avez des réseaux plus complexes avec plusieurs VM et/ou interfaces sur votre bureau.

Le premier outil pour la sécurité de votre réseau est la mise à jour du système. Deuxièmement, il y a netstat et nmap, que vous devez utiliser pour rechercher et confirmer les services que vous exécutez. Ensuite, désactivez simplement ceux dont vous n'avez pas besoin ou limitez-les à 127.0.0.1.

Bonus si vous lisez jusqu'ici :les paquets sont soit ÉTABLIS, CONNEXES ou NOUVEAUX, tout le reste que vous laissez tomber. Vous supprimez également NEW sauf si seul SYN est défini. Étant donné que ESTABLISHED,RELATED semble vérifier les drapeaux, cela rend toutes les règles --tcp-flags ainsi que la règle -f redondantes. Idem pour OUTPUT, mais comme aucun paquet n'est accepté pour OUTPUT de toute façon, cela n'a probablement pas d'importance.

Je serais prudent en les intégrant dans le même ensemble de règles pour les appareils à l'intérieur d'un réseau de confiance et ceux d'une DMZ. En utilisant les règles que vous y avez définies, vous n'allez pas répondre à un serveur DHCP demandant (écho ICMP) si votre adresse IP est utilisée. Cela pourrait conduire à une situation d'adresse en double.

Je créerais deux ensembles de règles différents à appliquer à chaque scénario, quelque chose comme ce qui est répertorié ci-dessus est une bonne base pour une machine DMZ, mais crée des défis sur un LAN typique.

De plus, je recommanderais certainement d'ajouter la journalisation aux martiens, aux pertes sortantes, aux connexions entrantes interrompues, etc. Cela peut être crucial pour le dépannage et peut être des données plus utiles pour votre SIEM.

Pour un PC client, connecté directement à Internet via ppp, l'ensemble de règles suivant est un bon début :

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT

Il autorise tout sur l'interface locale interne.
Il autorise tout paquet qui est une réponse pour un paquet que vous envoyez. Cela inclut les paquets au sein d'une connexion TCP, les réponses aux paquets UDP telles que les petites requêtes DNS. Pour l'ancien protocole FTP non chiffré, cela inclut la connexion de données, en supposant que ip_conntrack_ftp est chargé
Rejeter toutes les tentatives d'ouverture de connexion TCP depuis l'extérieur
Rejeter tous les paquets udp initiaux (sans réponse).

Vous pouvez également utiliser -j DROP dans les deux dernières règles. Pour une discussion sur ce sujet, voir Rejeter les paquets IP avec une erreur ICMP, ou simplement les supprimer ?