Putaing, je sais pourquoi j’ai pas fais sysadmin moi, le développement c’est plus simple.
Je comprends toujours pas comment il pourrait laisser passer un IP, mais soit.
Du coup que fait portsentry ? Il effectue le drop à la place de netfilter et bloque l’IP qui viens de tenter la connexion via netfilter cette fois-ci ?
[quote=“MisterFreez”]Putaing, je sais pourquoi j’ai pas fais sysadmin moi, le développement c’est plus simple.[/quote] 
Fail2ban ? Regarde le rapport de bugs. Il arrive que pour des jails multiples (sur plusieurs services - ce qui est le cas de beaucoup de serveurs quand même) fail2ban plante au démarrage, du coup, t’es pas protégé du tout, ou partiellement…
La solution est une bidouille du bin ou l’installation de la version testing de fail2ban. Mais c’est du testing, et pour un serveur, c’est TRèS moyen…
Il fait ce que tu veux.
Une simple alerte dans les logs, un blocage au niveau de hosts.deny, un banissement de route, un drop d’IP dans iptables.
Ou les quatre à la fois! 
Pour le port ouvert sans service à l’écoute, j’ai posé la question à “la liste”, je n’ai pas encore de réponse vraiment concluante (à part installe fail2ban…).
Il fait ce que tu veux.
Une simple alerte dans les logs, un blocage au niveau de hosts.deny, un banissement de route, un drop d’IP dans iptables.
Ou les quatre à la fois!
Pour le port ouvert sans service à l’écoute, j’ai posé la question à “la liste”, je n’ai pas encore de réponse vraiment concluante (à part installe fail2ban…).[/quote]
Ma question c’était surtout de savoir comment il détecte la tentative d’accès.
Il se met à l’écoute sur les ports non utilisés.
Si il y a de l’activité il balance une alerte dans les logs.
Bien sur si iptables bloque (DROP) l’accès à ces ports, portsentry ne détecte rien.
Ok c’est ce que je pensais. Va falloir que je regarde d’un peu plus près notamment pour voir s’ils ont suivi ça : La séparation des privilèges
Cela permettrait de limiter fortement les dégâts en cas de compromission du processus qui écoute les ports (et collé à un LSM ça rend les attaques terriblement complexe, je pense).
Saluts,
[quote=“lol”]Il fait ce que tu veux.
Une simple alerte dans les logs, un blocage au niveau de hosts.deny, un bannissement de route, un drop d’IP dans iptables.
Ou les quatre à la fois! [/quote]
+1 
Concernant porsentry, il ouvre environ 20 ports non utilisés pour tenter de détecter les scans de ports.
Demandes lui ce que tu veux, moi c’est blocage, bannissement, et drop …et un et deux et trois zéro !
pour les log psad s’en charge également, souvenir souvenir …
:~# tail -n 20 /var/lib/portsentry/portsentry.history
1319953636 - 10/30/2011 06:47:16 Host: 209.85.213.53/209.85.213.53 Port: 25 TCP Blocked
1319973664 - 10/30/2011 12:21:04 Host: 209.85.160.181/209.85.160.181 Port: 25 TCP Blocked
1319986636 - 10/30/2011 15:57:16 Host: 82.115.26.185/82.115.26.185 Port: 135 TCP Blocked
1319986992 - 10/30/2011 16:03:12 Host: 78.185.219.171/78.185.219.171 Port: 23 TCP Blocked
1319987591 - 10/30/2011 16:13:11 Host: 84.186.207.55/84.186.207.55 Port: 21 TCP Blocked
1319996541 - 10/30/2011 18:42:21 Host: 119.73.220.66/119.73.220.66 Port: 135 TCP Blocked
1320003684 - 10/30/2011 20:41:24 Host: 97.74.83.187/97.74.83.187 Port: 81 TCP Blocked
1320027323 - 10/31/2011 03:15:23 Host: 80.93.93.144/80.93.93.144 Port: 81 TCP Blocked
1320037547 - 10/31/2011 06:05:47 Host: 114.42.130.108/114.42.130.108 Port: 25 TCP Blocked
1320040662 - 10/31/2011 06:57:42 Host: 62.221.199.160/62.221.199.160 Port: 81 TCP Blocked
1320051045 - 10/31/2011 09:50:45 Host: 87.106.100.144/87.106.100.144 Port: 81 TCP Blocked
:~# tail -n 20 /etc/hosts.deny
ALL: 74.125.82.181 : DENY
ALL: 85.214.109.93 : DENY
ALL: 209.85.220.181 : DENY
ALL: 209.85.161.181 : DENY
ALL: 91.121.80.56 : DENY
ALL: 88.247.169.145 : DENY
ALL: 81.213.152.231 : DENY
ALL: 75.126.16.142 : DENY
ALL: 63.84.52.146 : DENY
ALL: 209.85.213.53 : DENY
ALL: 209.85.160.181 :DENY
ALL: 82.115.26.185 :DENY
ALL: 78.185.219.171 :DENY
ALL: 84.186.207.55 :DENY
ALL: 119.73.220.66
ALL: 80.93.93.144
ALL: 114.42.130.108
ALL: 62.221.199.160
ALL: 87.106.100.144
:~#
Config … (?)
Salut,
Oui, bien sur, je ne me vois pas poster un papier non testé… 
Il peut y avoir des boulettes ou des phrases pas très claires, mais sinon, oui il est opérationnel.
J’ai fait ce papier car tout ce que j’ai trouvé sur le net est vieux, ou copié/collé d’un autre tuto…
C’est très rapide à mettre en place.
Le seul point que je n’ai pas abordé c’est iptables, et il faudrait que j’ajoute quelque chose dessus. Si tu as suivi la discussion, il faut avoir des ports ouverts non occupés par des programmes pour que ce soit fonctionnel.
Mais je n’ose pas encore en parler sur le wiki, car du point de vue de la sécurité, je n’ai pas l’absolue certitude que ce n’est pas dangereux.
Je ne vois pas comment ça pourrait l’être, et personne ici ou sur “la liste” ne m’a traité de fou… 
Donc à mon avis c’est sans soucis.
Oui, je me doutais un peu que le tuto puisque inclut dans le wiki est donc opérationnel mais plus haut, tu dis que ton système ne fonctionnait pas.
Je pensais que le tuto du wiki devait être corrigé…
Voilà…sinon 
Au sujet de ports non protégés, j’ai obtenu cette réponse:
[quote]Le seul danger que je pourrai voir c’est qu’une personne ayant obtenu un
accès utilisateur à ton serveur puisse mettre un service en écoute sur
l’un de ses ports (netcat par exemple). Sauf que les simple utilisateurs
ne sont pas en mesure de mettre un service en écoute sur un port
inférieur à 1024.
$ nc -l 22
nc: Permission denied
Hormis ça, je ne pense pas que ca soit gênant.[/quote]
Donc ça se tient mon histoire, d’autant que tous mes utilisateurs sont dans un jail… 
portsentry n’écoute pas les ports ouverts ? Comment fait-il pour les analyses ? 
Il faut un/des port(s) libre(s) (non occupées par un/des processus) ET ouverts (non bloqués par iptables).
Il faut un/des port(s) libre(s) (non occupées par un/des processus) ET ouverts (non bloqués par iptables).[/quote]
Oui mais il y fait quoi s’il ne les écoute pas ? Mis à part un module noyau qui se grefferais sur la pile IP.
Un petit netstat -tpul lol ?
Avec plaisir +antalgeek!
# netstat -tpul
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 localhost.localdo:10024 *:* LISTEN 3191/amavisd (maste
tcp 0 0 localhost.localdo:10025 *:* LISTEN 31161/master
tcp 0 0 localhost.localdo:mysql *:* LISTEN 10008/mysqld
tcp 0 0 *:pop3 *:* LISTEN 3375/dovecot
tcp 0 0 *:imap2 *:* LISTEN 3375/dovecot
tcp 0 0 *:10999 *:* LISTEN 2890/sshd
tcp 0 0 *:ftp *:* LISTEN 6924/pure-ftpd (SER
tcp 0 0 machine.domaine:domain *:* LISTEN 2882/named
tcp 0 0 localhost.locald:domain *:* LISTEN 2882/named
tcp 0 0 *:smtp *:* LISTEN 18393/smtpd
tcp 0 0 localhost.localdoma:953 *:* LISTEN 2882/named
tcp 0 0 *:imaps *:* LISTEN 3375/dovecot
tcp 0 0 *:pop3s *:* LISTEN 3375/dovecot
tcp6 0 0 [::]:http-alt [::]:* LISTEN 7184/apache2
tcp6 0 0 [::]:www [::]:* LISTEN 7184/apache2
tcp6 0 0 [::]:tproxy [::]:* LISTEN 7184/apache2
tcp6 0 0 [::]:10999 [::]:* LISTEN 2890/sshd
tcp6 0 0 [::]:ftp [::]:* LISTEN 6924/pure-ftpd (SER
tcp6 0 0 [::]:domain [::]:* LISTEN 2882/named
tcp6 0 0 ip6-localhost:953 [::]:* LISTEN 2882/named
tcp6 0 0 [::]:https [::]:* LISTEN 7184/apache2
udp 0 0 machine.domaine:domain *:* 2882/named
udp 0 0 localhost.locald:domain *:* 2882/named
udp6 0 0 [::]:domain [::]:* 2882/named
# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
...
-A INPUT -i eth0 -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 23 -j ACCEPT
...
Les bots de scan se font tous toper sur le port 23:
Oct 31 00:04:10 ns387444 portsentry[17527]: attackalert: TCP SYN/Normal scan from host: 201.230.95.206/201.230.95.206 to TCP port: 23
Nov 1 03:17:13 ns387444 portsentry[17527]: attackalert: TCP SYN/Normal scan from host: 190.233.217.128/190.233.217.128 to TCP port: 23
Nov 1 07:23:01 ns387444 portsentry[17527]: attackalert: TCP SYN/Normal scan from host: 209.112.223.162/209.112.223.162 to TCP port: 23Ben je ne vois personne sur le port 23 là-dedans.
J’y regarderai ce soir.
[quote=“antalgeek”]Ben je ne vois personne sur le port 23 là-dedans.
J’y regarderai ce soir.[/quote]
Vu la réponse que lol a eu il n’écoute pas sur le port, sinon ça empêcherais tout autre processus à écouter sur ce même port.
[quote=“MisterFreez”][quote=“antalgeek”]Ben je ne vois personne sur le port 23 là-dedans.
J’y regarderai ce soir.[/quote]
Vu la réponse que lol a eu il n’écoute pas sur le port, sinon ça empêcherais tout autre processus à écouter sur ce même port.[/quote]
Seul portsentry est lié au port 23, mais il n’est pas listé des les processus qui écoutent sur ce port. Ça ne doit pas fonctionner comme les processus, mais là, je ne suis pas capable de vous en dire plus…
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced mode will monitor first 1024 ports
Oct 30 20:40:51 ns387444 portsentry[17530]: adminalert: PortSentry 1.2 is starting.
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced mode will manually exclude port: 113
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced mode will manually exclude port: 139
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 21
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 25
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 53
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 80
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 110
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 143
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 443
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 953
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 993
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 995
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139
Oct 30 20:40:51 ns387444 portsentry[17527]: adminalert: PortSentry is now active and listening.
Automatiquement il ignore les ports occupés et se “lie” (to bind dans le man) aux ports disponibles.
Tout ce que je sais, c’est que les petits malins qui balancent des scans sont piégés.
[quote=“MisterFreez”][quote=“antalgeek”]Ben je ne vois personne sur le port 23 là-dedans.
J’y regarderai ce soir.[/quote]
Vu la réponse que lol a eu il n’écoute pas sur le port, sinon ça empêcherais tout autre processus à écouter sur ce même port.[/quote]
Il occupe les ports disponibles, il ne risque pas de gêner les autres services.
Avec netstat je voulais savoir s’il se faisait passer pour un processus en service sur un port donné…c’est pas le cas.
Je n’ai plus qu’à potasser la doc.