Discussion :

[Blo0d4x3]

Bonjour,

Lorsque je consulte mes logs, je me demande si un type a pas tenté de me hacker cette nuit, et j'aimerai savoir si quelqu'un connait un type de failles au vu de ces messages:

Dans auth.log

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
 
May  9 16:36:21 Etch sshd[1969]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 16:53:43 Etch sshd[2597]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 16:58:13 Etch sshd[2792]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 17:00:01 Etch CRON[2890]: (pam_unix) session opened for user root by (uid=0)
May  9 17:00:01 Etch CRON[2890]: (pam_unix) session closed for user root
May  9 17:02:01 Etch CRON[3071]: (pam_unix) session opened for user logcheck by (uid=0)
May  9 17:02:05 Etch CRON[3071]: (pam_unix) session closed for user logcheck
May  9 17:11:13 Etch sshd[3741]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 17:17:01 Etch CRON[4010]: (pam_unix) session opened for user root by (uid=0)
May  9 17:17:01 Etch CRON[4010]: (pam_unix) session closed for user root
May  9 17:19:59 Etch sshd[4121]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 17:30:01 Etch CRON[4542]: (pam_unix) session opened for user root by (uid=0)
May  9 17:30:10 Etch CRON[4542]: (pam_unix) session closed for user root
May  9 17:37:15 Etch sshd[4945]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 17:46:02 Etch sshd[5268]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN
May  9 17:58:41 Etch sshd[5793]: Bad protocol version identification '\200F\001\003\001' from UNKNOWN

Dans les logs d'ulog:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
May  9 17:19:45 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=80.8.242.18 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=115 ID=37563 CE DF PROTO=TCP SPT=4867
DPT=443 SEQ=375534364 ACK=0 WINDOW=65535 SYN URGP=0
May  9 17:37:05 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=80.8.242.18 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=115 ID=41016 CE DF PROTO=TCP SPT=1910
DPT=443 SEQ=3885584519 ACK=0 WINDOW=65535 SYN URGP=0
May  9 17:45:48 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=80.8.242.18 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=115 ID=42706 CE DF PROTO=TCP SPT=2416
DPT=443 SEQ=1390587404 ACK=0 WINDOW=65535 SYN URGP=0
May  9 17:58:30 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=80.8.242.18 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=115 ID=44508 CE DF PROTO=TCP SPT=2915
DPT=443 SEQ=4284133435 ACK=0 WINDOW=65535 SYN URGP=0
May  9 18:05:36 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=62.48.228.149 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=112 ID=38975 CE DF PROTO=TCP SPT=1860 DPT=443 SEQ=3186776466 ACK=0 WINDOW=65535 SYN URGP=0
May  9 18:40:14 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=193.147.185.18 DST=192.168.1.11 LEN=60 TOS=00 PREC=0x00 TTL=46 ID=2089 DF PROTO=TCP SPT=45696 DPT=443 SEQ=3181036818 ACK=0 WINDOW=5840 SYN URGP=0

Merci de votre aide

[frp31]

a premiere vue comme ca je pense plus a un sniffer ou un truc comme ca... mais bon jamais facile de savoir.

[gandalfar]

Code :

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

1
2
 
\200F\001\003\001

ca ressemble mechaments a des shellcode

et le

Code :

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

1
2
3
 
May  9 17:00:01 Etch CRON[2890]: (pam_unix) session opened for user root by (uid=0)
May  9 17:00:01 Etch CRON[2890]: (pam_unix) session closed for user root

montrerais qu aparement il sont rentré

[Michaël]

pour cron, c'est normal qu'il se logge en root sinon comment il peut faire tourner les logs ?

le reste sont des tentatives foireuses sur ssh. ceci dit, tu as parlé de cette nuit mais la log montre 17h ton serveur est à une heure décalée volontairement ?

[Blo0d4x3]

Non j'ai mis qu'une partie des logs, mais ca a commence vers 00h40 a raison de 4 7 tentative de connexion au serveur par heures. Et l'ip change souvent, parfois vient de taiwan, france, chine, corée, je pense a des machine relais (zombies). Donc impossible de trouver qui est le trouduc qui fait ca .

En effet ca ressemble a un shellcode, mais je trouve rien traitant d'un exploit de ce type sur ssh.

Et ce qui est encore plus bizarre:

Code :

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

1
2
 
May  9 01:16:43 Etch TRAFFIC_ACCEPT_SSH IN= OUT=ath0 MAC= SRC=192.168.1.11 DST=80.8.244.143 LEN=40 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=1352 SEQ=687655433 ACK=0 WINDOW=0 RST URGP=0

Ma propre machine envoi des paquet sur le port SSH a 80.8.244.143. Ca m'inquiete, mais j'ai pas l'impression que quelqu'un est rentré quand même.

[gandalfar]

les whois des differents accept ssh donnent une adresse a issy
les moulineaux la deuxieme une adresse portugaise et la derniere
en espagne

[frp31]

tu peux tjrs changer tes clef ssh et assurer un alias à root de sorte que root n'existe pas sur la machine.

ça calme déja beaucoup de choses puisque toute intrusion à pour but d'utiliser root.

[reggae]

Moi je pencherai plutôt pour une attaque antérieure qui se manifeste, très certainement grâce à un rootkit système:

May 9 17:00:01 Etch CRON[2890]: (pam_unix) session opened for user root by (uid=0)

Représente une planification système. Les attaquants doivent très certainement avoir compromis le compte root et y avoir installé des portes dérobées...

Je te conseille d'analyser ta machine à l'aide de chkrootkit.

Tu peux également scanner tous les ports réseaux à l'aide de Wireshack (ex-Ethereal) et d'observer l'évolution liée au logs générés.

Tu peux également tenté un redémarrage, écrasant ainsi une éventuelle zone mémoire hostile, mais inefficace en cas de contamination du secteur BIOS ou de l'utilisation via un driver...

[panthere noire]

il suffi aussi de fermer l'aces a l'exterieur a root grace aux module ower de iptable c'est a dire a l'utilisateur 0 sauf le port 53 qui est parfoit utiliser.

petit exemple:

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -p TCP --dport 22 -m owner --uid-owner 0 -j drop

évidament a vous d'adapter la règle

De ce fait seul l'user peut répondre et sa complique pas mal la tache a celui qui veux faire mumuse avec root puisque pour ce loguer en root il doit obligatoirement obtenir la réponse de root.

voila

[gnto]

bonjour,

J'aime particulierement cette ligne

May 9 18:05:36 Etch TRAFFIC_ACCEPT_SSH IN=ath0 OUT= MAC= SRC=62.48.228.149 DST=192.168.1.11 LEN=48 TOS=00 PREC=0x00 TTL=112 ID=38975 CE DF PROTO=TCP SPT=1860 DPT=443 SEQ=3186776466 ACK=0 WINDOW=65535 SYN URGP=0

une fenêtre de 65535 ca pue l'attaque

[onet]

Tu as pensé a installer fail2ban ?

Onet

[Blo0d4x3]

Oui c'est fait. Mais, j'ai pas eu de nouveau types d'attaques comme celle-ci depuis.

[herzleid]

Tu peux aussi (et vivement conseillé) interdire à ssh toute connexion en root. Ainsi seul la connexion par compte normaux est autorisé. Le root est accessible uniquement aux user, via su, membre du compte wheel.

[ggnore]

Tu peux aussi (et vivement conseillé) interdire à ssh toute connexion en root. Ainsi seul la connexion par compte normaux est autorisé. Le root est accessible uniquement aux user, via su, membre du compte wheel.

+9999

Le compte root est présent sous toutes les distributions.
Ton compte avec ton nom est déjà nettement moins fréquent.

Ubuntu a choisi de ne pas mettre de mot de passe par défaut pour root. Elle encourage l'utilisation de sudo, c'est en partie à cause de cela.

[Blo0d4x3]

Oui, j'avais déjà interdit tous accès au compte root par ssh. :-)

[onet]

un fail2ban + un mot de passe root composé de chiffre, lettre minuscules, lettres majuscules et caractères spéciaux est déja une très bonne sécurité. Perso, j'ai plusieurs dédiés qui tourne comme ca, et ca ne pose pas de souci

Onet

[herzleid]

Sur mon serveur en plus de fail2ban qui bloque une adresse ip à partir de 3 connexions j'ai ces regles iptables qui bloques à 4 (on ne sait jamais fail2ban pourrait planter ) :

Code :

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

1
2
3
4
# Bannissement d une adresse IP apres 4 tentavies ko
iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
iptables -A INPUT -p tcp --dport ssh -m recent --set --name SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

[CoolCubiX]

Et ce qui est encore plus bizarre:

Code :

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

1
2
 
May  9 01:16:43 Etch TRAFFIC_ACCEPT_SSH IN= OUT=ath0 MAC= SRC=192.168.1.11 DST=80.8.244.143 LEN=40 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=1352 SEQ=687655433 ACK=0 WINDOW=0 RST URGP=0

Ma propre machine envoi des paquet sur le port SSH a 80.8.244.143. Ca m'inquiete, mais j'ai pas l'impression que quelqu'un est rentré quand même.

Note le RST.
Rien d'inquiétant, ta machine renvoie juste un paquet pour dire au poste distant 80.8.244.143 "vous venez d'envoyer une requête TCP de manière non appropriée, je vous informe que je n'en tiendrai pas compte", ce que le pirate peut comprendre comme "l'attaque vient d'échouer[, try again]".

[is_null]

Pour les buffers overflow, il existe une parade : PaX et ses amis
Personnelement je pense que c'est le minimum sur un serveur. Sinon, je garde un oeil sur glsa.gentoo.org (entre autres)...