[phil]

A chacun a ses préférences

[jibouh]

Il faut que je regarde plus en détail ConnTrack car ça semble utile mais je n'ai pas eu le temps de le tester...

Oui j'ai vu, sans fail2ban et une politique stricte, il y a quelques serveurs qui tentent leur chance en permanence...

Concernant ma politique de filtrage, je préfère tout bloquer et accepter uniquement des execptions. Cela implique plus de risque lors de la configuration mais un peu moins sur le long terme.

Pour l'instant je reste sur le port 22, cela me permet de faire un mini "hony-pot" sans me prendre la tête... Les IP sont banni une semaine et en cas de récidive je banni 1 mois. Il y a toujours moyen pour l'admin de trouver une autre IP et netoyer le fichier de log en cas d'erreur ^^

[phil]

Hello

Content que ça remarche.

2- Je dirai qu'il est beaucoup plus important de maîtriser les applis que tu fais tourner sur ton serveur :-)

3- Si je ne dis pas de bêtises, conntrack est le module qui permet à une règle comme "/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT" en gros, il surveille les connexions et ouvre les port au retour.

4- en fait, UFW s'appuie sur iptables. Son avantage majeur est qu'il simplifie la configuration d'iptables, exemple:

philippe@hostname:~$ sudo apt-get install ufw
[...]
philippe@hostname:~$ sudo ufw status
Status: inactive
philippe@hostname:~$ sudo ufw allow 22/tcp
Rules updated
Rules updated (v6)
philippe@hostname:~$ sudo ufw enable
Firewall is active and enabled on system startup
philippe@hostname:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 22/tcp                     ALLOW IN    Anywhere (v6)

philippe@hostname:~$ sudo ufw delete 2
Deleting:
 allow 22/tcp
Proceed with operation (y|n)? y
Rule deleted (v6)
philippe@hostname:~$

J'ai fait ça depuis le shell de mon PC sous ubuntu, mais cela marche pareil sur ton serveur dédié sous débian, avec le warning quand tu passes en "enable" . En fait, par derrière, ufw génère les règles iptables pour toi (constate avec un iptables -L). Si tu as besoin de règles plus subtiles, typiquement du NAT ou le filtrage du trafic en forwarding, tu as les fichiers /etc/ufw/*.rules dans lesquels tu peux insérer ta propre syntaxe iptable.
On aime ou on n'aime pas, perso, je trouve que c'est rapide et m'évite de me gaufrer bêtement dans les règles.

6- oui mais toujours un risque d'erreur humaine, et je parle d'expérience ! Aveux, j'ai planté une fois mon serveur en rajoutant une 2ème IP FO. Au moins, ça m'a fait découvrir le mode rescue d'OVH.

8- c'est mon point de vue qui n'engage que moi
Je ne filtre pas le trafic ayant pour source les IPs d'OVH officielles (monitoring etc.).
Je rajoute la commande "Port 40022" dans le fichier de conf /etc/ssh/sshd_config (ou choisi un autre port) et je ferme le trafic entrant sur le port 22 sauf depuis certaines IP sources statiques. Regarde tes logs, je te garanti que tu dois avoir une 100aine de tentatives de connexion sur le compte root en SSH. Au moins, sur un port exotique tu es plus tranquille.
Je ne filtre pas l'icmp

a- c'est bien pratique de savoir si la machine et up ou down à défaut du service
b- les script qui scannent aléatoirement les IPs ne perdent pas de temps à faire un ping et tapent directement les ports pour tester des vulnérabilités (apache/php:80 etc.)
c- si quelqu'un a décidé de hacker ta machine spécifiquement, ne pas répondre au ping ne vas pas changer grand chose

++

Philippe

[jibouh]

Le soucis était double:
- J'avais mal configuré le retour du monitoring :
/sbin/iptables -A INPUT -i eth0 -p icmp --source MON.I.P.250 -j ACCEPT # IP = aaa.bbb.ccc obtenue selon la règle precedente
/sbin/iptables -A INPUT -i eth0 -p icmp --source MON.I.P.251 -j ACCEPT # IP pour system de monitoring

- Petit soucis de configuration du switch .

[jibouh]

Salut,


Merci pour ton message

1. Oui c'est vrai mais je croyais avoir testé ma config après un reboot...

2. Quitte à filtrer autant tout filtrer et on est jamais à l'abris (même sous linux) d'une application trop bavarde.

3. Je ne connaissait pas conntrack et ne savais encore moins que c'était installé par défaut. Je vais creuser un peu cette fonctionnalité qui semble intéressante.

4. UFW, je connaissait pas non plus mais en quoi c'est plus performant que iptables ? la syntaxe est juste plus simple ? Ou il y a autre chose ?

5. Oui

6. Oui mais ce script fonctionne sur un serveur OVH...

"7. ", pour le monitoring je ne bloque pas le port SSH afin que "OVH-SYS" puisse faire son affaire. l'ICMP, si je ne dis pas de c....ie, c'est plus pour l'administration du réseau que de la machine mais SYS peut toujours se connecter en SSH.


En fait, ce qu'il me manque c'est ce genre de document : http://guides.ovh.com/FireWall ainsi qu'un http://travaux.ovh.net/
mais adapté pour SYS

[phil]

Bonjour

Je ne sais pas très bien comment tu t'y es pris pour charger ton script iptables et ça fait longtemps que je n'ai pas pongé dedans, mais quelques remarques:

1- passer des règles iptables ne fait pas systématiquement sauter les connexions existantes. Autrement dit, as-tu testé hier soir une nouvelle connexion ssh après avoir chargé ta config?

2- pourquoi filtres-tu le trafic sortant ?

3- une idée comme ça. J'ai eu il a longtemps un problème avec le noyau customisé OVH qui ne chargeait pas le module conntrack. Ceci dit, le comportement a peut-être changé depuis. lsmod ?

4- je te conseille d'utiliser ufw (qui vient avec debian). C'est un front-end sympa et assez simple pour iptables et ça évite de galérer à chaque fois qu'on doit modifier ses règles iptables. Et il est toujours possible de passer "à la main" des règles iptables customisées dans les fichiers de conf.

5- je crois qu'effectivement tu vas devoir passer par la case netboot/rescue

6- c'est toujours une bonne idée de saisir les règles iptables d'abord à la ligne de commande sans les inscrire en dur via un script ou autre. Comme ça en cas de cata, un petit reboot tranquille et tout repart.

Pour connaitre les IP de monitoring d'OVH pour ton serveur, regarde dans /root/.ssh/authorized_keys2 ou les logs des connexions.
En tous cas, c'est là pour mon kimsuffi. Mais effectivement, cela ne devrait pas bloquer ta machine. Et je ne suis pas sûr que le monitoring OVH se limite à de l'icmp.

Bon courage

Philippe

[jibouh]

Bonjour à tous,

Je vous écris car j'ai configuré hier soir mon firewall (basé sur iptables) sur un serveur dédié SYS. Depuis je n'arrive plus à me connecter sur le serveur. Je pense que le soucis vient de la configuration de celui-ci même si je n'ai pas remarqué le soucis hier après l'avoir configuré...

J'ai donc plusieurs questions:
- Y a t'il une maintenance sur les serveurs SYS qui pourrait provoquer l'indisponibilité du serveur ?
- Sous entendu, y a t'il une interface, comme pour OVH, afin de voir si notre serveur est en maintenance ou indisponibilité identifié par SYS.

- Ai je fait une erreur dans la configuration de mon firewall alors que celui-ci fonctionne sur un serveur dédié OVH ?
- Est ce que les IP des serveur de monitoring SYS sont les mêmes que pour OVH ? (voir dans la configuration ci-dessous) A mon avis non, mais cela ne devrait pas rendre ma machine indisponible ?
- Quelles sont les IP SYS dédiées au monitoring du parc de serveurs SYS ?

Dans tous les cas, je pense devoir faire un petit netboot lundi pour modifier mon firewall si c'est celui-ci qui pose problème.

# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Firewall de fou
### END INIT INFO

# Vider les tables actuelles
/sbin/iptables -t filter -F

# Vider les règles personnelles
/sbin/iptables -t filter -X

# Interdire toute connexion entrante et sortante
/sbin/iptables -t filter -P INPUT DROP
/sbin/iptables -t filter -P FORWARD DROP
/sbin/iptables -t filter -P OUTPUT DROP

# ---

# Ne pas casser les connexions etablies
/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Autoriser loopback
/sbin/iptables -t filter -A INPUT -i lo -j ACCEPT
/sbin/iptables -t filter -A OUTPUT -o lo -j ACCEPT

# ICMP (Ping)
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.p19.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.rbx.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.sbg.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source proxy.bhs.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source ping.ovh.net -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --source 94.23.218.250 -j ACCEPT # IP = aaa.bbb.ccc obtenue selon la règle precedente
/sbin/iptables -A INPUT -i eth0 -p icmp --source 94.23.218.249 -j ACCEPT # temporaire, seulement pour serveurs HG
/sbin/iptables -A INPUT -i eth0 -p icmp --source 94.23.218.251 -j ACCEPT # IP pour system de monitoring

# MOI
/sbin/iptables -A INPUT -i eth0 -p icmp --source X.X.X.X -j ACCEPT

#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 24441 -j ACCEPT



# ---
# Subversion In
#/sbin/iptables -t filter -A INPUT -p tcp --dport 3690 -j ACCEPT

# Subversion Out
#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 3690 -j ACCEPT


# SSH In
/sbin/iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT



# SSH Out
/sbin/iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

# DNS In/Out
/sbin/iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
/sbin/iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
/sbin/iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
/sbin/iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

# NTP Out
/sbin/iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT

# HTTP + HTTPS Out
#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

# HTTP + HTTPS In
#/sbin/iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

# Mail SMTP:25
/sbin/iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
/sbin/iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT

# Mail POP3:110
#/sbin/iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT

# Mail IMAP:143
#/sbin/iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT

# Mail POP3S:995
#/sbin/iptables -t filter -A INPUT -p tcp --dport 995 -j ACCEPT
#/sbin/iptables -t filter -A OUTPUT -p tcp --dport 995 -j ACCEPT