# Parefeu dureté maximale

**URL:** <https://www.debian-fr.org/t/parefeu-durete-maximale/76805>\
**Category:** Support Debian\
**Created:** [Mai 27, 2018, 2:47 UTC](https://www.debian-fr.org/t/parefeu-durete-maximale/76805 "2018-05-27T14:47:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![txj](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@txj](https://www.debian-fr.org/u/txj)\
**Post date:** [Mai 27, 2018, 2:47 UTC](https://www.debian-fr.org/t/parefeu-durete-maximale/76805/1 "2018-05-27T14:47:56Z")

</div>

Bonjour j’essais d’approfondir mes connaissances avec iptables et de comprendre plus en profondeur le fonctionnement du parefeu.

Mon objectif : n’autoriser que pour seule connexion sur un serveur le ssh en provenance de mon ip locale, (même pas le apt).

Donc j’ai un script qui ressemble à ca :

```auto
#!/bin/bash

#### INPUT ####
iptables -A INPUT -p tcp -s $IP --dport 22 -j ACCEPT

iptables -P INPUT DROP

#### OUTPUT ####
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -d $IP -p tcp --sport 22 -j ACCEPT

iptables -P OUTPUT DROP

#### FORWARD ####

iptables -P FORWARD DROP

```

première difficulté, la règle en sortie est bien écris? ma connexion finis par lâcher (pas tout de suite) et impossible de me reconnecter avec ce script.

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Mai 28, 2018, 6:49 UTC](https://www.debian-fr.org/t/parefeu-durete-maximale/76805/2 "2018-05-28T06:49:22Z")

</div>

Bonjour,

Personnellement j’utilise les fichiers `host.allow` et `host.deny` pour limiter l’accès au ssh: [https://www.incredigeek.com/home/allow-ssh-access-from-a-specific-host-using-hosts-allow-and-hosts-deny-on-linux/](https://www.incredigeek.com/home/allow-ssh-access-from-a-specific-host-using-hosts-allow-and-hosts-deny-on-linux/)

Je laisse les experts de iptables répondre à tes questions 🙂

---

<div class="post-metadata">

**Author:** ![anon93295908](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@anon93295908](https://www.debian-fr.org/u/anon93295908)\
**Post date:** [Mai 28, 2018, 1:25 UTC](https://www.debian-fr.org/t/parefeu-durete-maximale/76805/3 "2018-05-28T13:25:43Z")

</div>

> [@sk4hrr](#):
>
> host.allow

Il me semble que c’est déprécié désormais.  
sinon perso j’utilise ufw et j’en suis très content.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Mai 28, 2018, 6:05 UTC](https://www.debian-fr.org/t/parefeu-durete-maximale/76805/4 "2018-05-28T18:05:40Z")

</div>

> [@txj](#):
>
> la règle en sortie est bien écris?

Pas besoin de RELATED. Les paquets SSH ne sont jamais dans cet état.

Par contre une connexion TCP ou UDP peut engendrer l’envoi et la réception de paquets ICMP d’erreur dans l’état RELATED. Bloquer ces paquets peut empêcher ces connexions de fonctionner correctement.

```
iptables -A INPUT -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT

```

Et la même chose dans OUTPUT.

Aussi, certains processus locaux utilisent l’interface de loopback pour communiquer entre eux. Il est donc recommandé d’autoriser les paquets en entrée et en sortie sur cette interface.

```
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

```