Bonjour, je cherche à configurer correctement blockhosts pour empecher
les tentatives d'intrusion à répétition et banir temporairement les
adresses IP sources.
J'aurais voulu essayer fail2ban mais il requiert une version de Python
non encore dispo sur ma distribution (CentOS 4.5)
Le problème est que depuis que j'utilise blockhosts je n'arrive plus à
me connecter en FTP sur le serveur.
Ce que je ne comprends pas c'est que blockhosts.py n'est exécuté qu'une
fois pas heure, et que dans l'intervalle il n'apparait pas dans ps - Al
Pourtant quand je tente de me connecter avec un client ftp, j'obtiens
ceci dans /var/log/messages
blockhosts: echo tag: 192.168.1.1-vsftpd@192.168.1.11
Je ne comprends pas comment blockhosts peut s'exécuter sur demande,
d'ailleurs iptables --list retourne ceci :
Chain INPUT (policy ACCEPT)
target prot opt source destination
blockhosts all -- anywhere anywhere
Que fait cette target 'blockhosts' ici, à quoi correspond elle ? Est-ce
que ça signifie que blockhosts.py est exécuté par iptables ? Comme un
filtre ? Mais où est-ce que c'est déclaré ce genre de comportement ?
Voila, si vous avez un peu d'aide à me fournir ça serait sympa !
/etc/blockhosts.cfg (ne comportant que les sections que j'ai modifié)
#-----------------------------------------------------------------------
[common]
# common section is variables that may be used by main program, mail, etc
#HOSTS_BLOCKFILE = "/etc/hosts.allow"
# the name of the block-file on your computer - usually hosts.allow or
# hosts.deny, see "man 5 hosts_access" for details on these files.
# default is hosts.allow
#HOST_BLOCKLINE = ["ALL: ", " : deny"]
# the line to output, with Host Ip Address in between the strings above,
# to turn on blocking of that IP address
#VERBOSE = Log.MESSAGE_LEVEL_ERROR #-> error (same as --quiet option)
VERBOSE = Log.MESSAGE_LEVEL_WARNING #-> warning (default)
#VERBOSE = Log.MESSAGE_LEVEL_INFO #-> info (same as --verbose option)
#VERBOSE = Log.MESSAGE_LEVEL_DEBUG #-> debug (same as --debug option)
# logging message levels - each level includes all levels above it
#-----------------------------------------------------------------------
[filters]
# filters section defines configuration for filtering watched hosts
# into the blocked hosts list
COUNT_THRESHOLD = 7
# number of invalid attempts after which host is blocked
# note that actual denial make take one or more attempts - depends on the
# timing of when LOGFILES are updated by the system, and when this script
# gets to run
#AGE_THRESHOLD = 12
# number of hours after which host entry is discarded from hosts.deny
# 24 -> one day, 168 -> one week, 720 -> 30 days, integer values only
# most attackers go away after they are blocked, so to keep hosts.deny
# file size small, no reason to make this any more than, say, half-a-day
WHITELIST = [ "127.0.0.1", "192.168.1.1", "194.146.224.129"]
#WHITELIST = []
#WHITELIST = [ "127.0.0.1", "10\.0\.0\..*", ]
# A list of IP (IPv4) addresses or regular expressions that represent
# a IP (IPv4) address - this is the list of white-listed IP addresses.
# When considering IPs to block, if a IP address maches any item in this
# list, then it will be removed from the block list - so won't be blocked.
#BLACKLIST = []
#BLACKLIST = [ "192.168.10.1", "10\..*", ]
# A list of IP (IPv4) addresses or regular expressions that represent
# a IP (IPv4) address - this is the list of black-listed IP addresses.
# When considering IPs to block, if a IP address maches any item in this
# list, then it will be immediately added to the block list, even if
# COUNT_THRESHOLD may not have been reached.
# IP addresses directly specified in this list without a regular expression
# will be immediately added to the blocked list.
# WHITELIST takes precedence over BLACKLIST - so a match in both will mean
# it is white-listed.
#-----------------------------------------------------------------------
[blockhosts]
# blockhosts section defines the log files to scan and patterns to look for
#LOGFILES = [ "/var/log/secure", ]
#LOGFILES = [ "/var/log/auth.log", ]
LOGFILES = [ "/var/log/secure", "/var/log/xferlog", ]
# default list of logs to process, comma separated, can follow Python
# syntax, should be a sequence (list or tuple) of strings representing
# filenames: 1 or more files, default is single file: /var/log/secure
#LOCKFILE = "/tmp/blockhosts.lock"
# need create/write access to this file, used to make sure only one
# instance of blockhosts.py script writes the HOSTS_BLOCKFILE at one time
# note that the mail/iptables/iproute parts of the program do not serialize
#-----------------------------------------------------------------------
[ipblock]
# ipblock section for enabling protection using TCP/IP level blocking -
# by using null routes, or iptables filtering, all network communication
# is stopped from a particular IP address
#IPBLOCK = ""
#IPBLOCK = "iproute"
IPBLOCK = "iptables"
# "iproute": Do TCP/IP blocking using route commands to setup null-routes.
# ip route add <ip-addr> via 127.0.0.1
# "iptable": Do TCP/IP blocking, using iptables packet filtering.
# iptables --append blockhosts --source <ip-addr> -j DROP
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Pas avec la correspondance "limit", mais avec la correspondance "recent" oui. Le déni de service reste néanmoins possible en spoofant l'adresse source, et la mémoire de "recent" n'est pas illimitée (100 adresses par défaut) : il est possible de se faire oublier en émettant un grand nombre de demandes de connexion avec des adresses sources différentes (spoofées évidemment).
Luc Habert wrote in message <ff4rfm$4u0$1@nef.ens.fr>:
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Pas avec la correspondance "limit", mais avec la correspondance "recent"
oui. Le déni de service reste néanmoins possible en spoofant l'adresse
source, et la mémoire de "recent" n'est pas illimitée (100 adresses par
défaut) : il est possible de se faire oublier en émettant un grand
nombre de demandes de connexion avec des adresses sources différentes
(spoofées évidemment).
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Pas avec la correspondance "limit", mais avec la correspondance "recent" oui. Le déni de service reste néanmoins possible en spoofant l'adresse source, et la mémoire de "recent" n'est pas illimitée (100 adresses par défaut) : il est possible de se faire oublier en émettant un grand nombre de demandes de connexion avec des adresses sources différentes (spoofées évidemment).
Nina Popravka
On 17 Oct 2007 11:09:02 GMT, (Lolotte) wrote:
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à 65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et adresses de bécanes + les login et pass qui vont avec, je vais aussi me trimballer les numéros de port custom.... Non mais ça va pas ??? Y a des normes en ce domaine, je refuse de m'en écarter. Pas plus que je ne décide de mettre ma porte d'entrée sur le toit et de monter sur une échelle pour rentrer chez moi. De toute manière, si qqn est fermement décidé à me cambrioler, il trouvera bien que la porte est sur le toit. Bref : 'portnawak... Sécurité, obscurité, toussa. -- Nina
On 17 Oct 2007 11:09:02 GMT, newsreader@pasdespamdansmongrenier.com
(Lolotte) wrote:
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à
65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et
adresses de bécanes + les login et pass qui vont avec, je vais aussi
me trimballer les numéros de port custom.... Non mais ça va pas ???
Y a des normes en ce domaine, je refuse de m'en écarter.
Pas plus que je ne décide de mettre ma porte d'entrée sur le toit et
de monter sur une échelle pour rentrer chez moi. De toute manière, si
qqn est fermement décidé à me cambrioler, il trouvera bien que la
porte est sur le toit.
Bref : 'portnawak... Sécurité, obscurité, toussa.
--
Nina
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à 65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et adresses de bécanes + les login et pass qui vont avec, je vais aussi me trimballer les numéros de port custom.... Non mais ça va pas ??? Y a des normes en ce domaine, je refuse de m'en écarter. Pas plus que je ne décide de mettre ma porte d'entrée sur le toit et de monter sur une échelle pour rentrer chez moi. De toute manière, si qqn est fermement décidé à me cambrioler, il trouvera bien que la porte est sur le toit. Bref : 'portnawak... Sécurité, obscurité, toussa. -- Nina
Nicolas KOWALSKI
Nicolas George <nicolas$ wrote:
Luc Habert wrote in message <ff4rfm$4u0$:
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
-- Nicolas
Nicolas George <nicolas$george@salle-s.org> wrote:
Luc Habert wrote in message <ff4rfm$4u0$1@nef.ens.fr>:
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh
# first: mark new connections to ssh in the "SSH" list
iptables -A INPUT -p tcp --dport ssh
-m state --state NEW
-m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH
# list with this new connection attempt (sliding window), and reject
# the connection
iptables -A INPUT -p tcp --dport ssh
-m recent --update --seconds 60 --hitcount 3 --rttl --name SSH
-j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui
ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000
tentatives d'intrusion par jour (c'était vraiment le pire), je suis
passé à moins d'une dizaine.
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
-- Nicolas
Zouplaz
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Nicolas George <nicolas$ wrote:
Luc Habert wrote in message <ff4rfm$4u0$:
Peut-être est-ce deux connexions par minute depuis une même adresse? Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
Pour ce qui est du nombre, moi c'est fréquemment plus de 30 000 par jour d'après les logs. Mais pas tous les jours...
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Nicolas George <nicolas$george@salle-s.org> wrote:
Luc Habert wrote in message <ff4rfm$4u0$1@nef.ens.fr>:
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh
# first: mark new connections to ssh in the "SSH" list
iptables -A INPUT -p tcp --dport ssh
-m state --state NEW
-m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH
# list with this new connection attempt (sliding window), and reject
# the connection
iptables -A INPUT -p tcp --dport ssh
-m recent --update --seconds 60 --hitcount 3 --rttl --name SSH
-j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui
ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000
tentatives d'intrusion par jour (c'était vraiment le pire), je suis
passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou
avantage par rapport à une solution type fail2ban ou blockhosts ?
Pour ce qui est du nombre, moi c'est fréquemment plus de 30 000 par jour
d'après les logs. Mais pas tous les jours...
Peut-être est-ce deux connexions par minute depuis une même adresse? Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
Pour ce qui est du nombre, moi c'est fréquemment plus de 30 000 par jour d'après les logs. Mais pas tous les jours...
Pascal Hambourg
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Comme l'écrit Pascal, avec le module "recent":
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
L'inconvénient, je l'ai expliqué dans mon message précédent : c'est très sensible au spoofing IP car c'est basé sur les paquets de demande de connexion (SYN) et non sur l'établissement effectif des connexions TCP. Par conséquent, un attaquant déterminé peut relativement facilement aussi bien faire bloquer l'adresse IP d'un utilisateur légitime que se soustraire au filtrage en jouant sur la profondeur limitée de la mémoire de "recent". L'option --rttl qui fait prendre en compte le TTL des paquets comme élément de différenciation des sources permet néanmoins de limiter le risque de déni de service.
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Comme l'écrit Pascal, avec le module "recent":
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou
avantage par rapport à une solution type fail2ban ou blockhosts ?
L'inconvénient, je l'ai expliqué dans mon message précédent : c'est très
sensible au spoofing IP car c'est basé sur les paquets de demande de
connexion (SYN) et non sur l'établissement effectif des connexions TCP.
Par conséquent, un attaquant déterminé peut relativement facilement
aussi bien faire bloquer l'adresse IP d'un utilisateur légitime que se
soustraire au filtrage en jouant sur la profondeur limitée de la mémoire
de "recent". L'option --rttl qui fait prendre en compte le TTL des
paquets comme élément de différenciation des sources permet néanmoins de
limiter le risque de déni de service.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
L'inconvénient, je l'ai expliqué dans mon message précédent : c'est très sensible au spoofing IP car c'est basé sur les paquets de demande de connexion (SYN) et non sur l'établissement effectif des connexions TCP. Par conséquent, un attaquant déterminé peut relativement facilement aussi bien faire bloquer l'adresse IP d'un utilisateur légitime que se soustraire au filtrage en jouant sur la profondeur limitée de la mémoire de "recent". L'option --rttl qui fait prendre en compte le TTL des paquets comme élément de différenciation des sources permet néanmoins de limiter le risque de déni de service.
Pascal Hambourg
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à 65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et adresses de bécanes + les login et pass qui vont avec, je vais aussi me trimballer les numéros de port custom.... Non mais ça va pas ???
Bof, SSH n'est pas un service "public" comme peuvent l'être des serveurs web, DNS ou SMTP. On peut donc plus facilement se permettre d'utiliser un port non standard.
De toute manière, si qqn est fermement décidé à me cambrioler, il trouvera bien que la porte est sur le toit. Bref : 'portnawak... Sécurité, obscurité, toussa.
Personne ne conteste que l'efficacité est très limitée contre un attaquant déterminé. Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé.
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à
65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et
adresses de bécanes + les login et pass qui vont avec, je vais aussi
me trimballer les numéros de port custom.... Non mais ça va pas ???
Bof, SSH n'est pas un service "public" comme peuvent l'être des serveurs
web, DNS ou SMTP. On peut donc plus facilement se permettre d'utiliser
un port non standard.
De toute manière, si
qqn est fermement décidé à me cambrioler, il trouvera bien que la
porte est sur le toit.
Bref : 'portnawak... Sécurité, obscurité, toussa.
Personne ne conteste que l'efficacité est très limitée contre un
attaquant déterminé. Par contre c'est très efficace contre les attaques
automatisées des vers, ça soulage bien les journaux - et donc les vraies
attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas
être inutile en cas de 0-day non ciblé.
- j'ai changé le port du serveur SSH à une valeur haute (y a jusqu'à 65535) non encore utilisée sur mon serveur
Enfin bon à ce compte, en plus de me trimballer des listes de noms et adresses de bécanes + les login et pass qui vont avec, je vais aussi me trimballer les numéros de port custom.... Non mais ça va pas ???
Bof, SSH n'est pas un service "public" comme peuvent l'être des serveurs web, DNS ou SMTP. On peut donc plus facilement se permettre d'utiliser un port non standard.
De toute manière, si qqn est fermement décidé à me cambrioler, il trouvera bien que la porte est sur le toit. Bref : 'portnawak... Sécurité, obscurité, toussa.
Personne ne conteste que l'efficacité est très limitée contre un attaquant déterminé. Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé.
Nicolas KOWALSKI
Zouplaz wrote:
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Nicolas George <nicolas$ wrote:
Luc Habert wrote in message <ff4rfm$4u0$:
Peut-être est-ce deux connexions par minute depuis une même adresse? Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
Je n'utilise pas actuellement ces deux outils, donc il m'est difficile de juger objectivement. La seule fois où j'avais utilisé fail2ban, je m'étais "retrouvé dehors" ; j'avais certainement raté quelquechose dans la conf, mais ça m'avait un peu échaudé.
La solution iptables ci-dessus a l'avantage de ne dépendre que d'elle-même ; elle est aussi diaboliquement simple. :-)
-- Nicolas
Zouplaz <user@domain.invalid> wrote:
le 17/10/2007 14:30, Nicolas KOWALSKI nous a dit:
Nicolas George <nicolas$george@salle-s.org> wrote:
Luc Habert wrote in message <ff4rfm$4u0$1@nef.ens.fr>:
Peut-être est-ce deux connexions par minute depuis une même adresse?
Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh
# first: mark new connections to ssh in the "SSH" list
iptables -A INPUT -p tcp --dport ssh
-m state --state NEW
-m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH
# list with this new connection attempt (sliding window), and reject
# the connection
iptables -A INPUT -p tcp --dport ssh
-m recent --update --seconds 60 --hitcount 3 --rttl --name SSH
-j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui
ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000
tentatives d'intrusion par jour (c'était vraiment le pire), je suis
passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou
avantage par rapport à une solution type fail2ban ou blockhosts ?
Je n'utilise pas actuellement ces deux outils, donc il m'est difficile
de juger objectivement. La seule fois où j'avais utilisé fail2ban, je
m'étais "retrouvé dehors" ; j'avais certainement raté quelquechose dans
la conf, mais ça m'avait un peu échaudé.
La solution iptables ci-dessus a l'avantage de ne dépendre que
d'elle-même ; elle est aussi diaboliquement simple. :-)
Peut-être est-ce deux connexions par minute depuis une même adresse? Je ne crois pas qu'iptables sache faire ça.
Comme l'écrit Pascal, avec le module "recent":
# rate limit ssh # first: mark new connections to ssh in the "SSH" list iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --set --name SSH
# second: if more than 3 connection arrived in 60 seconds, update the SSH # list with this new connection attempt (sliding window), and reject # the connection iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
Et puis pour la complétion de rsync ou scp, ce serait pénible...
Tu peux aussi définir avant cette règle une whitelist des machines qui ne seront jamais bloquées.
Je trouve l'utilisation de ces deux règles très efficace. De ~5000 tentatives d'intrusion par jour (c'était vraiment le pire), je suis passé à moins d'une dizaine.
J'ignorais totalement qu'iptables sache faire ça. Quel inconvénient ou avantage par rapport à une solution type fail2ban ou blockhosts ?
Je n'utilise pas actuellement ces deux outils, donc il m'est difficile de juger objectivement. La seule fois où j'avais utilisé fail2ban, je m'étais "retrouvé dehors" ; j'avais certainement raté quelquechose dans la conf, mais ça m'avait un peu échaudé.
La solution iptables ci-dessus a l'avantage de ne dépendre que d'elle-même ; elle est aussi diaboliquement simple. :-)
-- Nicolas
Nina Popravka
On Wed, 17 Oct 2007 15:25:27 +0200, Pascal Hambourg wrote:
Personne ne conteste que l'efficacité est très limitée contre un attaquant déterminé. Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé.
Je suis parfaitement étanche à ce genre d'arguments. Des ports très sollicités et soumis à des 0-day non ciblés, je connais très bien (135, 139, et 445 au hasard), on vit parfaitement bien avec sans se planquer au fond du couloir, bref démerdez-vous :-) -- Nina
On Wed, 17 Oct 2007 15:25:27 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:
Personne ne conteste que l'efficacité est très limitée contre un
attaquant déterminé. Par contre c'est très efficace contre les attaques
automatisées des vers, ça soulage bien les journaux - et donc les vraies
attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas
être inutile en cas de 0-day non ciblé.
Je suis parfaitement étanche à ce genre d'arguments.
Des ports très sollicités et soumis à des 0-day non ciblés, je connais
très bien (135, 139, et 445 au hasard), on vit parfaitement bien avec
sans se planquer au fond du couloir, bref démerdez-vous :-)
--
Nina
On Wed, 17 Oct 2007 15:25:27 +0200, Pascal Hambourg wrote:
Personne ne conteste que l'efficacité est très limitée contre un attaquant déterminé. Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé.
Je suis parfaitement étanche à ce genre d'arguments. Des ports très sollicités et soumis à des 0-day non ciblés, je connais très bien (135, 139, et 445 au hasard), on vit parfaitement bien avec sans se planquer au fond du couloir, bref démerdez-vous :-) -- Nina
Mihamina Rakotomandimby
Nina Popravka wrote:
Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé. Je suis parfaitement étanche à ce genre d'arguments.
Je ne comprends pas... ce sont pourtant bien des "petits bouts de sécurité" mis les uns apres les autres qui font qu'un système est sûr uo pas! La parade ultime n'existant pas, je ne vois pas pourquoi "trop petit, passera pas"...
Nina Popravka wrote:
Par contre c'est très efficace contre les attaques
automatisées des vers, ça soulage bien les journaux - et donc les vraies
attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas
être inutile en cas de 0-day non ciblé.
Je suis parfaitement étanche à ce genre d'arguments.
Je ne comprends pas... ce sont pourtant bien des "petits bouts de
sécurité" mis les uns apres les autres qui font qu'un système est sûr uo
pas! La parade ultime n'existant pas, je ne vois pas pourquoi "trop
petit, passera pas"...
Par contre c'est très efficace contre les attaques automatisées des vers, ça soulage bien les journaux - et donc les vraies attaques sont plus faciles à voir - et je soupçonne que ça puisse ne pas être inutile en cas de 0-day non ciblé. Je suis parfaitement étanche à ce genre d'arguments.
Je ne comprends pas... ce sont pourtant bien des "petits bouts de sécurité" mis les uns apres les autres qui font qu'un système est sûr uo pas! La parade ultime n'existant pas, je ne vois pas pourquoi "trop petit, passera pas"...
Nicolas George
Mihamina Rakotomandimby wrote in message <ff565o$30tj$:
La parade ultime n'existant pas
Qu'est-ce qui te fait dire ça ?
Mihamina Rakotomandimby wrote in message
<ff565o$30tj$1@cabale.usenet-fr.net>:
