Bonjour,
J’ai un serveur “source” S qui en scrute un autre “cible” C en permanence pour détecter la chutte éventuelle d’un site. Cela se fait par un wget du serveur S sur les sites du serveur C
Depuis que j’ai installé portsentry sur le serveur C, S n’a plus accès à C ni sur le port 80 ni sur le 22, même en stoppant le firewall et portsentry:
sur C:
root@ns1:/etc/portsentry# /etc/init.d/firewall stop
[firewall désactivé]
root@ns1:/etc/portsentry# /etc/init.d/portsentry stop
Stopping anti portscan daemon: portsentry.
root@ns1:/etc/portsentry# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@ns1:/etc/portsentry# cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8)
# for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
root@ns1:/etc/portsentry#Sur S:
vm293 ~ > wget http://www.unsite.com
--2016-01-11 11:12:39-- http://www.unsite.com/
Résolution de www.unsite.com (www.unsite.com)... ip.du.serveur.C
Connexion vers www.unsite.com (www.unsite.com)|ip.du.serveur.C|:80... échec: Connexion terminée par expiration du délai d'attente.
vm293 ~ >Je précise que unsite.com/ est accessible depuis un autre poste, bien sûr.
Y-a-t-il d’autres sources de blockage possible que iptables ou hosts.deny ?
Peut-il y avoir des règles blocantes invisibles par iptables -L ?
Merci pour votre support