Mon firewall est-il correct ?

Salut,

Pouvez-vous me dire si j'ai bien configuré iptable pour verrouiller mon
serveur ?

Voyons ça. Serveur de quoi ?

# /sbin/iptables -L

C'est mieux avec l'option -v (verbose) en plus. Ou, encore mieux, lister
les règles avec 'iptables-save' au lieu de 'iptables -L'. Là, on ne voit
pas les interfaces notamment.

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)

La politique par défaut devrait être DROP par sécurité.

target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

J'ajouterais state NEW et --syn à cette règle.

REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

A mon avis c'est mieux de rejeter les paquets TCP avec tcp-reset. A mon
avis toujours, un serveur devrait aussi répondre au ping (ICMP echo).

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

C'est moyennement "verrouillé" de tout autoriser en sortie.

J'aurais bien aimé essayer ca :
INPUT -i eth0 -p tcp --dport 22 --source domaine.dyndns.org -j ACCEPT

Où domaine.dyndns.org est relié à mon IP dynamique. Est-ce possible ? J'ai
pas envie de "tester".

Et tu as raison, parce que le nom de domaine serait résolu en adresse IP
une fois pour toutes au moment de la création de la règle.

On Sat Jul 01 2006 at 23:09, Mike Hanigan wrote:

J'aurais bien aimé essayer ca :
INPUT -i eth0 -p tcp --dport 22 --source domaine.dyndns.org -j ACCEPT
Où domaine.dyndns.org est relié à mon IP dynamique. Est-ce possible ?

C'est possible, mais ça prendra l'IP à l'instant où la commande est
entrée; quand l'IP dynamique changera, la règle netfilter ne sera pas
mise à jour.

Pascal Hambourg le lundi 3 juillet 2006 09:11 sur fr.comp.securite

Salut,

Salut et merci

Pouvez-vous me dire si j'ai bien configuré iptable pour verrouiller mon
serveur ?

Voyons ça. Serveur de quoi ?

Serveur est mal choisis comme terme. Un butineur rsnapshot si je puis dire.

# /sbin/iptables -L

C'est mieux avec l'option -v (verbose) en plus. Ou, encore mieux, lister
les règles avec 'iptables-save' au lieu de 'iptables -L'. Là, on ne voit
pas les interfaces notamment.

# Generated by iptables-save v1.3.0 on Tue Jul 4 12:20:10 2006
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [11637:56513595]
:OUTPUT ACCEPT [42070233:5617080871]
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Tue Jul 4 12:20:10 2006

Pas de lo. c'est grave ?

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)

La politique par défaut devrait être DROP par sécurité.

Pardonnez ma lenteur mais hier, suite à votre message j'ai fais ma
boulette... Sans trop réfléchir j'ai collé INPUT, FORWARD et OUTPUT à DROP
en debut de script. C'est devenu immédiatement gênant.

-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP

C'est ce que j'ai mis hier, mais sans la règle OUTPUT plus bas.

je met permet de faire une copie de mon script version corrigée pour la
soumettre à avis :)

IPT=/sbin/iptables

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A INPUT -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i eth0 -p tcp --dport 22 --syn -j ACCEPT
$IPT -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j
ACCEPT
#$IPT -A INPUT -i eth0 -j REJECT

question subsidiaire.. Je peux utiliser, dans ce cas là, indifférament sport
et dport ?
merci

Pardonnez ma lenteur mais hier, suite à votre message j'ai fais ma
boulette... Sans trop réfléchir j'ai collé INPUT, FORWARD et OUTPUT à DROP
en debut de script. C'est devenu immédiatement gênant.

-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP

C'est ce que j'ai mis hier, mais sans la règle OUTPUT plus bas.

je met permet de faire une copie de mon script version corrigée pour la
soumettre à avis :)

IPT=/sbin/iptables

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A INPUT -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i eth0 -p tcp --dport 22 --syn -j ACCEPT
$IPT -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j
ACCEPT
#$IPT -A INPUT -i eth0 -j REJECT

question subsidiaire.. Je peux utiliser, dans ce cas là, indifférament sport
et dport ?
merci
Bonjour,

Pour faire du SSH (serveur), il faut autoriser le port 22 en
destination (--dport) seulement pour la chaîne INPUT. --sport
correspondra au port source (port "haut") sur la machine cliente,
typiquement un numéro de port choisi par l'OS >= 1024. D'ailleurs, si
vous voulez, vous pouvez d'ailleurs ajouter la contrainte pour vérifier
que le client se connecte bien avec un tel port, ce qui devrait toujours
être le cas, par exemple:

$IPT -A INPUT -i eth0 -p tcp --sport 1024: --dport 22 --syn -j ACCEPT

Par contre, la règle OUTPUT (SSH) me paraît étrange:

1. Si cette règle est destinée à autoriser SSH sur le serveur (donc
indissociable de la règle INPUT SSH), elle ne fonctionnera pas car le
port destination du paquet "réponse" ne sera pas 22 mais le port dont
j'ai parlé plus haut car on veut laisser passer la réponse du serveur au
client. Donc, si on veut ajouter le port pour être plus fin, il faut
mettre --sport 22 et non pas --dport 22 pour cette règle. De plus,
--state *NEW* ne devrait pas être là.

2. Si cette règle est destinée à autoriser le SSH depuis ce poste (en
client), c'est bon mais il manque dans ce cas le cas 1.

Vous pouvez éventuellement laisser une règle REJECT pour la chaine
OUTPUT à la fin, pour permettre au serveur d'être "informé" du rejet en
sortant au lieu de subir un timeout à chaque "refus" de paquet.

Enfin, voici deux règles supplémentaires que j'utilise et qui pourraient
vous intéresser; celles-ci permettent d'éliminer d'autres paquets mal
formés qui pourraient cependant passer dans votre règle SSH en INPUT.
Vous pouvez donc les ajouter avant "$IPT -A INPUT -i eth0 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT":

$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option ! 2 -j DROP


Alex.

Un plaisantin modifie régulièrement ma home-page pour y ajouter des
<iframes> et des pop-ups qui pointent vers des sites commerciaux : j'ai du
laisser traîner une autorisation foireuse quelque part... Il faut dire que
je ne connais vraiment rien en sécurité et je le paie, donc. Quelqu'un
peut-il me dire ce que je dois chercher sur mon serveur pour combler le trou
de sécurité ? Il s'agit d'un site situé chez un hébergeur commercial a
priori sérieux (ils me disent, en tout cas, que je suis le seul à qui ça
arrive). Les logs FTP (auxquels l'hébergeur a accès, mais pas moi) sont
apparemment effacés par le pirate ! Bref très casse-pied, donc si quelqu'un
a un conseil, une idée, je prends !
jn

Le Tue, 11 Jul 2006 18:22:03 +0000, Jean-noel Lafargue a écrit :

Il s'agit d'un site situé chez un
hébergeur commercial a priori sérieux (ils me disent, en tout cas, que
je suis le seul à qui ça arrive). Les logs FTP (auxquels l'hébergeur a
accès, mais pas moi) sont apparemment effacés par le pirate ! Bref très
casse-pied, donc si quelqu'un a un conseil, une idée, je prends !

Qu'est-ce qui te permet de dire que les logs ftp sont effacés?
Est-ce la seule manière d'uploader des pages sur ton site? (pas de
webdav, ssh...?)

Ton site est-il statique ou dynamique? Dans le deuxième cas as-tu
vérifié qu'il n'est pas possible d'appeler des appli externe (include
foireux, possibilité de mettre une url en paramètre etc).

Si tu es *certain* que ça ne vient pas de ton côté et que les logs ftp
sont effacés alors le problème vient de ton hébergeur (même si tu as
laisser trainer le password du compte ftp les logs ne devraient pas
pouvoir être effacé).

Sans précision de ta part on ne pourra pas trop t'aider (en plus si
vraiment ton site est à l'état de passoire c'est délicat de demander
son adresse ici! :) ).

Eric.

Enfin, voici deux règles supplémentaires que j'utilise et qui pourraient
vous intéresser; celles-ci permettent d'éliminer d'autres paquets mal
formés qui pourraient cependant passer dans votre règle SSH en INPUT.
Vous pouvez donc les ajouter avant "$IPT -A INPUT -i eth0 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT":

$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option ! 2 -j DROP

Tiens, j'écrivais l'autre jour dans une liste de diffusion que je
trouvais que ce n'était pas une bonne pratique de faire précéder une
règle ACCEPT trop permissive par une ou plusieurs règles DROP en
comptant sur ces dernières pour bloquer les paquets indésirables que la
règle ACCEPT aurait acceptés sinon. En effet si une règle DROP n'est pas
chargée pour une raison quelconque (manque de mémoire, erreur de
syntaxe, module manquant...), le résultat est plus permissif que prévu.
En poussant le raisonnement à l'extrême, on devrait pouvoir retirer
toutes les règles DROP d'un jeu de règles bien écrit sans en altérer la
sécurité.

Pourquoi ne pas simplement mettre toutes les conditions d'acceptation
nécessaires dans les règles ACCEPT ? Et si on souhaite "factoriser" des
conditions communes à plusieurs règles, on peut regrouper ces règles
dans une chaîne utilisateur.

"Eric Razny" <news_01@razny.net> a écrit

Qu'est-ce qui te permet de dire que les logs ftp sont effacés?
Est-ce la seule manière d'uploader des pages sur ton site? (pas de
webdav, ssh...?)

Je n'ai pas accès aux logs FTP, et quand je les ai demandés à mon hébergeur,
celui-ci m'a juste dit "c'est bizarre, vos logs FTP commencent à telle
date..." (la date du piratage que je venais de constater) et, je cite : "Ce
qui signifie peut être que cette personne à utilisé un script pour effacer
vos dossiers qui avaient des permissions supérieures à 755 (pareil pour les
fichiers)."

Ton site est-il statique ou dynamique? Dans le deuxième cas as-tu
vérifié qu'il n'est pas possible d'appeler des appli externe (include
foireux, possibilité de mettre une url en paramètre etc).

il y a pas mal de pages dynamiques, en général elles interdisent de passer
le ";" en argument, il me semblait que ça suffisait à se prémunir des
attaques par url... Mais en même temps je ne suis pas un dieu de PHP et des
erreurs sont possibles.
typiquement, la home page en question se voit rajouter des iframes comme
<iframe src="http://hebforum.free.fr/" width="0" height="0"></iframe>
(j'ai contacté hebforum.free.fr ... pas de réponse), soit dans le corps de
la page, soit dans un fichier extérieur appelé par include.

Si tu es *certain* que ça ne vient pas de ton côté et que les logs ftp
sont effacés alors le problème vient de ton hébergeur (même si tu as
laisser trainer le password du compte ftp les logs ne devraient pas
pouvoir être effacé).

Comme je n'ai pas accès à ces logs en plus, je n'y comprends pas grand
chose.

Sans précision de ta part on ne pourra pas trop t'aider (en plus si
vraiment ton site est à l'état de passoire c'est délicat de demander
son adresse ici! :) ).

ah mais je le donne sans problème car il faut que je comprenne :
http://www.hyperbate.com
... Et si les problèmes persistent, j'effacerais la totalité du site.
Si il se trouve ici un hacker (gentil) capable d'identifier le trou de
sécurité, il me fera un grand plaisir ! (ne pas hésiter à me contacter à
n'importe quoi @hyperbate.com)

Ce qui m'étonne c'est que :
- je connais tous les php du site, les ayant écrits moi-même
- je sais parfaitement que mes identifiants/mots de passe ne trainent pas
n'importe où, étant finalement assez parano.

On Tue, 11 Jul 2006 18:22:03 +0000, Jean-noel Lafargue wrote:

Un plaisantin modifie régulièrement ma home-page pour y ajouter des
<iframes> et des pop-ups qui pointent vers des sites commerciaux

Par expérience, je penserais à une compromission du compte FTP, via un
keylogger ou un extracteur de base de registre (et donc une compromission
d'un des postes utilisés pour la mise à jour).


Nicob

Le Wed, 12 Jul 2006 20:20:37 +0000, Nicob a écrit :

On Tue, 11 Jul 2006 18:22:03 +0000, Jean-noel Lafargue wrote:

Un plaisantin modifie régulièrement ma home-page pour y ajouter des
<iframes> et des pop-ups qui pointent vers des sites commerciaux

Par expérience, je penserais à une compromission du compte FTP, via un
keylogger ou un extracteur de base de registre (et donc une compromission
d'un des postes utilisés pour la mise à jour).

Salut
Question con:

chez moi si je donne un login/password d'un compte ftp,
sauf s'il y a une faille sur le serveur ftp (le soft ou la conf) ou
éventuellement dans le noyau, je ne vois pas trop comment tu efface les
logs. (sauf si l'herbergeur est assez <biiip :) > pour les laisser dans
l'espace accessible par ftp ou via des scripts lancés ensuite en http)

Pour la partie concernant la modif du site il y a pas mal de
possibilités, mais pour les logs c'est moins facile.

Une idée?

Eric.