[FEDORA] Configuration de vsFTPd [Résolu]

nicolou · 10/08/2006, 15h16

Bonjour,

j'ai installé et configuré sur mon serveur Fedora Core 4 le serveur FTP vsFTPd.

Si je désactive le pare-feu, je peux me connecter sans problème à celui-ci, mais dès que je l'active, je n'arrive plus à me connecter et le serveur me renvoie une erreur 530 permission denied si je me connecte ainsi : ftp://ip_serveur/
et une erreur 425 failed to establish connexion ici : ftp://user@ip_serveur.

Je rappelle que si le pare-feu es désactivé, je n'ai aucun problème!

Pour info, voici mes règles iptables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [4:720]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [40:5925]
:OUTPUT ACCEPT [44:37728]
:POSTROUTING ACCEPT [44:37728]
:PREROUTING ACCEPT [40:5925]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A FORWARD -i eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_IN:
-A OUTPUT -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9321 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9331 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9441 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9442 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Fri Jul  7 12:49:18 2006

et mon fichier vsftpd.conf (même si je n'ai pas l'impression que çà vienne de là...):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
 
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO
 
listen_port=21
 
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=NO
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
 
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
 
# You may override where the log file goes if you like. The default is shown
# below.
xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
 
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that turning on ascii_download_enable enables malicious remote parties
# to consume your I/O resources, by issuing the command "SIZE /big/file" in
# ASCII mode.
# These ASCII options are split into upload and download because you may wish
# to enable ASCII uploads (to prevent uploaded scripts etc. from breaking),
# without the DoS risk of SIZE and ASCII downloads. ASCII mangling should be
# on the client anyway..
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
ftpd_banner=Welcome to blah FTP service.
#
 
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd/chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
ls_recurse_enable=YES
 
pam_service_name=vsftpd
userlist_enable=YES
#enable for standalone mode
listen=YES
tcp_wrappers=YES

Voilà, si vous voyez quelquechose qui vous choque ou un début de piste, merci de me sortir de ce cul-de-sac.

Nicolas

nicolou · 11/08/2006, 15h20

Salut,
J'ai modifié mon iptables comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [4:720]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [40:5925]
:OUTPUT ACCEPT [44:37728]
:POSTROUTING ACCEPT [44:37728]
:PREROUTING ACCEPT [40:5925]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A FORWARD -i eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_IN:
-A OUTPUT -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp --sport 20 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9321 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9331 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9441 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9442 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Fri Jul  7 12:49:18 2006

mon serveur n'est pas derrière un routeur (pas que je sache, mais c'est une dedibox, alors je sais pas trop...),

et mon poste client se trouve su un vpn derrière une freebox.

Chose étrange, avec la configuration que j'ai cité ci-dessus, si j'essaye de me connecter au ftp via mon pc qui a comme adresse 192.168.0.3 (sur mon vpn), j'ai le problème que je vous ai exposé plus haut.
Mais si je me connecte à partir de mon pda qui est relié par wifi à mon réseau (192.168.0.4), tout fonctionne correctement.

Mon but était d'arriver à çà : acces à mon ftp à partir du pda.
Mais j'avoue ne pas comprendre pourquoi je ne peux pas me connecter d'un poste classique alors qu'il est sur le même réseau que mon pda... bizarre.

Est-ce que quelqu'un a une idée du pourquoi du cmment ?

Nico

ripat · 12/08/2006, 08h45

Les policy par défaut de tes tables FILTER sont toutes sur ACCEPT et tes règles en aval aussi. Ce qui est pratiqué habituellement est de tout interdire (DROP) pour n'ouvrir que ce qui est strictement nécessaire.

Est-ce voulu?

Les règles iptables sont, comme les brosses à dents, très personnelles. Mais voici un truc passe-partout dont tu pourrais t'inspirer (plein d'autres exemples sur le net).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Initialisation
  iptables -F
  iptables -X
 
# Règles par défault
  iptables -t filter -P INPUT DROP
  iptables -t filter -P FORWARD DROP
  iptables -t filter -P OUTPUT ACCEPT
 
# ouverture des ports
  # Autorisation de loopback
    iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
  # Autorisation des connections déjà établies
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  # ssh
    iptables -A INPUT -p tcp --dport 22 -j ACCEPT
  # ftp
    iptables -A INPUT -p tcp --dport 20 -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -j ACCEPT
 
# filet LOG
  iptables -A INPUT -j LOG --log-prefix '[MonIpLog]'

Pour déboguer, la règle "filet" journalisera tout ce qui n'est pas accepté par les règles ACCEPT. Voir dans syslog.

Tu pourras ensuite resserrer les règles en ajoutant les ip source et destination (-s et -d). D'autres protocoles etc...

Iptables est un "full state" firewall, car l'état connexions établies sont stockées (en général dans le fichier /proc/net/ip_conntrack). Si tu n'y vois pas les connexions ftp, vérifie si le module ip_conntrack_ftp est bien chargé (lsmod)

Attention! prudence si tu travailles à distance en ssh! Tu risques de tout planter! Si tu as un accès physique au serveur, pas de souçis

nicolou · 13/08/2006, 11h15

Citation:

Envoyé par ripat

Les policy par défaut de tes tables FILTER sont toutes sur ACCEPT et tes règles en aval aussi. Ce qui est pratiqué habituellement est de tout interdire (DROP) pour n'ouvrir que ce qui est strictement nécessaire.

Est-ce voulu?

Salut,
Mettre le drop en premier j'ai essayé, mais apparament çà marche à l'envers vu que les règles que je mettais après le drop n'étaient pas prises en compte.

Citation:

Envoyé par ripat

Les règles iptables sont, comme les brosses à dents, très personnelles. Mais voici un truc passe-partout dont tu pourrais t'inspirer (plein d'autres exemples sur le net).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Initialisation
  iptables -F
  iptables -X
 
# Règles par défault
  iptables -t filter -P INPUT DROP
  iptables -t filter -P FORWARD DROP
  iptables -t filter -P OUTPUT ACCEPT
 
# ouverture des ports
  # Autorisation de loopback
    iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
  # Autorisation des connections déjà établies
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  # ssh
    iptables -A INPUT -p tcp --dport 22 -j ACCEPT
  # ftp
    iptables -A INPUT -p tcp --dport 20 -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -j ACCEPT
 
# filet LOG
  iptables -A INPUT -j LOG --log-prefix '[MonIpLog]'

Pour déboguer, la règle "filet" journalisera tout ce qui n'est pas accepté par les règles ACCEPT. Voir dans syslog.

Tu pourras ensuite resserrer les règles en ajoutant les ip source et destination (-s et -d). D'autres protocoles etc...

Iptables est un "full state" firewall, car l'état connexions établies sont stockées (en général dans le fichier /proc/net/ip_conntrack). Si tu n'y vois pas les connexions ftp, vérifie si le module ip_conntrack_ftp est bien chargé (lsmod)

Attention! prudence si tu travailles à distance en ssh! Tu risques de tout planter! Si tu as un accès physique au serveur, pas de souçis

Pour ce qui est de ces points là, ip_conntrack, ip_conntrack_ftp et ip_nat_ftp sont bien chargés, et je vais essayer de mettre en place la règle "filet" pour pouvoir regarder plus précisément les logs.

Sinon, c'est un serveur distant que j'ai, mais il a un système de secours qui me permet d'accéder à l'arborescence en cas de plantage (mauvaises règles iptables par exemple

Merci de ta réponse en tout cas.

Nico

nicolou · 16/08/2006, 10h47

Salut,
j'ai essayé de monitorer l'interface eth0 avec iptraf, mais comme j'avais en même temps une session ssh et une avec webmin, j'ai du faire le tri dans le fichier log.
Voilà ce que je pense avoir un rapport avec ma tentative de connexion au ftp.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
Wed Aug 16 10:42:26 2006; TCP; eth0; 60 bytes; from 88.191.254.20:37507 to 88.191.12.190:21; first packet (SYN)
Wed Aug 16 10:42:26 2006; TCP; eth0; 60 bytes; from 88.191.12.190:21 to 88.191.254.20:37507; first packet (SYN)
Wed Aug 16 10:42:26 2006; TCP; eth0; 52 bytes; from 88.191.254.20:37507 to 88.191.12.190:21; FIN sent; 5 packets, 274 bytes, avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:26 2006; TCP; eth0; 52 bytes; from 88.191.12.190:21 to 88.191.254.20:37507; FIN acknowleged
Wed Aug 16 10:42:26 2006; TCP; eth0; 52 bytes; from 88.191.12.190:21 to 88.191.254.20:37507; FIN sent; 5 packets, 316 bytes, avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:26 2006; TCP; eth0; 52 bytes; from 88.191.254.20:37507 to 88.191.12.190:21; FIN acknowleged
Wed Aug 16 10:42:26 2006; TCP; eth0; 60 bytes; from 88.191.254.20:44602 to 88.191.12.190:80; first packet (SYN)
Wed Aug 16 10:42:26 2006; TCP; eth0; 60 bytes; from 88.191.254.20:36140 to 88.191.12.190:25; first packet (SYN)
Wed Aug 16 10:42:26 2006; ICMP; eth0; 84 bytes; from 88.191.254.20 to 88.191.12.190; echo req
Wed Aug 16 10:42:27 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:27 2006; ICMP; eth0; 84 bytes; from 88.191.254.20 to 88.191.12.190; echo req
Wed Aug 16 10:42:28 2006; ICMP; eth0; 84 bytes; from 88.191.254.20 to 88.191.12.190; echo req
Wed Aug 16 10:42:29 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:31 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:33 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:35 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:37 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:39 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:41 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:43 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:45 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:47 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:48 2006; UDP; eth0; 266 bytes; from 88.191.12.170:138 to 88.191.12.255:138
Wed Aug 16 10:42:48 2006; UDP; eth0; 236 bytes; from 88.191.12.170:138 to 88.191.12.255:138
Wed Aug 16 10:42:48 2006; UDP; eth0; 256 bytes; from 88.191.12.156:138 to 88.191.12.255:138
Wed Aug 16 10:42:48 2006; UDP; eth0; 233 bytes; from 88.191.12.156:138 to 88.191.12.255:138
Wed Aug 16 10:42:49 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:51 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:53 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:55 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694
Wed Aug 16 10:42:57 2006; TCP; eth0; 46 bytes; from 82.250.20.202:4374 to 88.191.12.190:21; FIN sent; 22 packets, 1039 bytes, avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:57 2006; TCP; eth0; 50 bytes; from 88.191.12.190:21 to 82.250.20.202:4374; FIN acknowleged
Wed Aug 16 10:42:57 2006; TCP; eth0; 94 bytes; from 88.191.12.190:21 to 82.250.20.202:4374; FIN sent; 26 packets, 1674 bytes, avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:57 2006; TCP; eth0; 46 bytes; from 82.250.20.202:4374 to 88.191.12.190:21; FIN acknowleged
Wed Aug 16 10:42:57 2006; TCP; eth0; 46 bytes; from 82.250.20.202:4374 to 88.191.12.190:21; Connection reset; 23 packets, 1085 bytes, avg flow rate 0,00 kbits/s; opposite direction 26 packets, 1674 bytes; avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:57 2006; TCP; eth0; 46 bytes; from 82.250.20.202:4374 to 88.191.12.190:21; Connection reset; 1 packets, 46 bytes, avg flow rate 0,00 kbits/s; opposite direction 0 packets, 0 bytes; avg flow rate 0,00 kbits/s
Wed Aug 16 10:42:57 2006; UDP; eth0; 147 bytes; from 88.191.12.30:39012 to 88.191.12.255:694

Y'a-t-il quelque chose qui vous interpelle là-dedans?

Nico

nicolou · 16/08/2006, 16h36

Bon, finalement j'ai modifié mon fichier iptable comme suit, et j'ai accès à mon ftp à partir de mon pda et de mon fixe...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [4:720]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [40:5925]
:OUTPUT ACCEPT [44:37728]
:POSTROUTING ACCEPT [44:37728]
:PREROUTING ACCEPT [40:5925]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A FORWARD -i eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_IN:
-A OUTPUT -o eth0 -j LOG  --log-level 7 --log-prefix BANDWIDTH_OUT:
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9321 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9331 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9441 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9442 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Fri Jul  7 12:49:18 2006

Je suis maintenant parti pour l'optimiser... Vous voyez quelquechose qui vous saute aux yeux?

Merci

Nico

ripat · 18/08/2006, 21h13

Oui. Ton système n'est pas du tout protégé.

Comme je l'ai suggéré plus haut, les "POLICY" par défaut des tes filtres INPUT, OUTPUT et FORWARD sont tous en ACCEPT.

Tout passera donc.

Fais un nmap, ou tout autre pen test, sur l'ip de ton serveur et tu verras.

nicolou · 19/08/2006, 14h20

Salut,
j'ai modifié mon fichier iptables comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [4:720]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [40:5925]
:OUTPUT ACCEPT [44:37728]
:POSTROUTING ACCEPT [44:37728]
:PREROUTING ACCEPT [40:5925]
COMMIT
# Completed on Fri Jul  7 12:49:18 2006
# Generated by iptables-save v1.3.0 on Fri Jul  7 12:49:18 2006
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9321 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9331 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9441 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9442 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9600 -j ACCEPT
-A FORWARD -j LOG  --log-level 7 --log-prefix FORWARD:
-A OUTPUT  -j LOG  --log-level 7 --log-prefix OUTPUT:
-A INPUT -j LOG  --log-level 7 --log-prefix INPUT:
COMMIT
# Completed on Fri Jul  7 12:49:18 2006

En faisant un nmap mon_ip, j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2006-08-19 14:24 CEST
Interesting ports on sd-XXX.dedibox.fr (XX.XXX.XX.XXX):
(The 1669 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
111/tcp open  rpcbind
443/tcp open  https
974/tcp open  unknown
 
Nmap finished: 1 IP address (1 host up) scanned in 1.093 seconds

çà a l'air bon, non ?

Nico

18/08/2006, 21h13	#7
ripat Membre émérite Inscription : mai 2004 Messages : 709 Détails du profil Informations personnelles : Localisation : Belgique Informations forums : Inscription : mai 2004 Messages : 709 Points : 852 Points : 852	Oui. Ton système n'est pas du tout protégé. Comme je l'ai suggéré plus haut, les "POLICY" par défaut des tes filtres INPUT, OUTPUT et FORWARD sont tous en ACCEPT. Tout passera donc. Fais un nmap, ou tout autre pen test, sur l'ip de ton serveur et tu verras. __________________ :q :q! :wq :w :w! :wq! :quit :quit! :help help helpquit quit quithelp :quitplease :quitnow :leave :shit ^X^C ^C ^D ^Z ^Q QUITDAMMIT Jabber: ripat at im.apinc.org
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email