Attaque avec adresse IP forgée
EPiKoiEncore
J'ai une petite machine sous linux Suse 10.3 avec SuFirewall2
Je subis depuis plus de 24 heures des tentatives de connexion en ssh.
Visiblement l'attaquant se cache derri�re des IP forg�es.
Il y a un essai toutes les 2 � 3 minutes avec un login diff�rent � chaque
fois mais dont le nom cro�t en ordre alphab�tique.
Normalement je bannis pour une heure les IP qui ont plus de trois connexions
infructeuses mais dans ce cas, cela ne marche pas.
Y aurait-il un moyen de d�tecter l'IP r�elle de l'attaquant ???
Merci par avance
Alain
JKB
Attaque avec adresse IP forgée,
EPiKoiEncore ?crivait dans fr.comp.securite :
> Bonjour à tous
Bonjour,
> J'ai une petite machine sous linux Suse 10.3 avec SuFirewall2
> Je subis depuis plus de 24 heures des tentatives de connexion en ssh.
> Visiblement l'attaquant se cache derrière des IP forgées.
> Il y a un essai toutes les 2 à 3 minutes avec un login différent à chaque
> fois mais dont le nom croît en ordre alphabétique.
>
> Normalement je bannis pour une heure les IP qui ont plus de trois connexions
> infructeuses mais dans ce cas, cela ne marche pas.
>
> Y aurait-il un moyen de détecter l'IP réelle de l'attaquant ???
>
> Merci par avance
Est-ce que sont des vraies IP forgées ou un réseau ? Peut-on avoir
un extrait des logs ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Xavier Roche
> Visiblement l'attaquant se cache derri�re des IP forg�es.
Forg�es ou IP de proxy ouverts ? Je n'ai jamais vu de ma vie une seule
attaque avec une "IP forg�e" (l'IP spoofing est plus du domaine de la
l�gende urbaine que de la r�alit�, mis � part quelques curiosit�s
d'attaques par UDP ou ICMP)
Mateusz Viste
> Visiblement l'attaquant se cache derri�re des IP forg�es.
Si les IP étaient réellement "forgées", le connexion n'aboutirait jamais
(la poignée de main TCP ne s'établirait même pas).
> Y aurait-il un moyen de d�tecter l'IP r�elle de l'attaquant ???
Sans avoir la main sur les proxies utilisées? Non.
Solution: ne jamais laisser un accès SSH avec authentification par mot de
passe ouvert sur internet.
Cordialement,
Mateusz Viste
P.S. La chose te servant de lecteur de news est mal configurée... ;-)
EPiKoiEncore
"Mateusz Viste" <mat...@no-spam.please> a �crit dans le message de news:
93h4v6-...@datacenter.viste-family.net...
> On Wednesday 09 December 2009 12:30, EPiKoiEncore wrote:
>
> Si les IP �taient r�ellement "forg�es", le connexion n'aboutirait jamais
> (la poign�e de main TCP ne s'�tablirait m�me pas).
>
>> Y aurait-il un moyen de dtecter l'IP relle de l'attaquant ???
>
> Sans avoir la main sur les proxies utilis�es? Non.
>
> Solution: ne jamais laisser un acc�s SSH avec authentification par mot de
> passe ouvert sur internet.
>
Merci de votre r�ponse.
Mais comment faites-vous pour vous connecter de n'importe o� sur une
machine.?
En dehors du ssh, je ne vois pas trop ?!
> Cordialement,
> Mateusz Viste
>
> P.S. La chose te servant de lecteur de news est mal configur�e... ;-)
Oui mais pour mes mails, c'est Thunderbird ;-)
EPiKoiEncore
Amicalement
Voici un petit bout des logs (il y en a beaucoup plus!) :
/************/
Dec 9 11:11:43 pitchou sshd[30469]: Invalid user export from 189.53.181.13
Dec 9 11:11:44 pitchou sshd[30469]: error: PAM: User not known to the
underlying authentication module for illegal user export from 189.53.181.13
Dec 9 11:11:44 pitchou sshd[30469]: Failed keyboard-interactive/pam for
invalid user export from 189.53.181.13 port 39272 ssh2
Dec 9 11:17:16 pitchou sshd[30500]: Invalid user extra from 113.105.82.13
Dec 9 11:17:16 pitchou sshd[30500]: error: PAM: User not known to the
underlying authentication module for illegal user extra from 113.105.82.13
Dec 9 11:17:16 pitchou sshd[30500]: Failed keyboard-interactive/pam for
invalid user extra from 113.105.82.13 port 8283 ssh2
Dec 9 11:25:56 pitchou sshd[30514]: Invalid user fabios from
211.115.234.143
Dec 9 11:25:56 pitchou sshd[30514]: error: PAM: User not known to the
underlying authentication module for illegal user fabios from
211.115.234.143
Dec 9 11:25:56 pitchou sshd[30514]: Failed keyboard-interactive/pam for
invalid user fabios from 211.115.234.143 port 60846 ssh2
Dec 9 11:37:33 pitchou sshd[30551]: Invalid user fax from 79.190.233.42
Dec 9 11:37:33 pitchou sshd[30551]: error: PAM: User not known to the
underlying authentication module for illegal user fax from
ita42.internetdsl.tpnet.pl
Dec 9 11:37:33 pitchou sshd[30551]: Failed keyboard-interactive/pam for
invalid user fax from 79.190.233.42 port 60563 ssh2
Dec 9 11:40:25 pitchou smartd[3370]: Device: /dev/sda, SMART Prefailure
Attribute: 1 Raw_Read_Error_Rate changed from 55 to 54
Dec 9 11:40:25 pitchou smartd[3370]: Device: /dev/sda, SMART Usage
Attribute: 195 Hardware_ECC_Recovered changed from 55 to 54
Dec 9 11:42:37 pitchou sshd[30573]: Invalid user acct from 168.20.197.63
Dec 9 11:42:37 pitchou sshd[30573]: error: PAM: User not known to the
underlying authentication module for illegal user acct from
sun.savannahstate.edu
Dec 9 11:42:37 pitchou sshd[30573]: Failed keyboard-interactive/pam for
invalid user acct from 168.20.197.63 port 34273 ssh2
Dec 9 11:45:26 pitchou syslog-ng[1868]: STATS: dropped 0
Dec 9 11:51:37 pitchou sshd[30609]: Invalid user felipe from 121.52.215.180
Dec 9 11:51:38 pitchou sshd[30609]: error: PAM: User not known to the
underlying authentication module for illegal user felipe from 121.52.215.180
Dec 9 11:51:38 pitchou sshd[30609]: Failed keyboard-interactive/pam for
invalid user felipe from 121.52.215.180 port 49957 ssh2
Dec 9 11:54:29 pitchou sshd[30618]: Address 125.40.69.208 maps to
hn.kd.ny.adsl, but this does not map back to the address - POSSIBLE BREAK-IN
ATTEMPT!
Dec 9 11:54:29 pitchou sshd[30618]: Invalid user felix from 125.40.69.208
Dec 9 11:54:29 pitchou sshd[30618]: error: PAM: User not known to the
underlying authentication module for illegal user felix from 125.40.69.208
Dec 9 11:54:29 pitchou sshd[30618]: Failed keyboard-interactive/pam for
invalid user felix from 125.40.69.208 port 45688 ssh2
Dec 9 11:57:25 pitchou sshd[30625]: Invalid user felix from 113.105.82.13
Dec 9 11:57:26 pitchou sshd[30625]: error: PAM: User not known to the
underlying authentication module for illegal user felix from 113.105.82.13
Dec 9 11:57:26 pitchou sshd[30625]: Failed keyboard-interactive/pam for
invalid user felix from 113.105.82.13 port 12295 ssh2
Dec 9 12:00:08 pitchou sshd[30652]: Invalid user felix from 78.43.82.153
Dec 9 12:00:09 pitchou sshd[30652]: error: PAM: User not known to the
underlying authentication module for illegal user felix from
hsi-kbw-078-043-082-153.hsi4.kabel-badenwuerttemberg.de
Dec 9 12:00:09 pitchou sshd[30652]: Failed keyboard-interactive/pam for
invalid user felix from 78.43.82.153 port 55045 ssh2
Dec 9 12:05:59 pitchou sshd[30663]: Invalid user fernanda from
190.144.133.214
Dec 9 12:06:00 pitchou sshd[30663]: error: PAM: User not known to the
underlying authentication module for illegal user fernanda from
190.144.133.214
Dec 9 12:06:00 pitchou sshd[30663]: Failed keyboard-interactive/pam for
invalid user fernanda from 190.144.133.214 port 59256 ssh2
Dec 9 12:08:51 pitchou sshd[30672]: Invalid user fernando from 212.243.41.9
Dec 9 12:08:51 pitchou sshd[30672]: error: PAM: User not known to the
underlying authentication module for illegal user fernando from 212.243.41.9
Dec 9 12:08:51 pitchou sshd[30672]: Failed keyboard-interactive/pam for
invalid user fernando from 212.243.41.9 port 4068 ssh2
Dec 9 12:10:25 pitchou smartd[3370]: Device: /dev/sda, SMART Usage
Attribute: 194 Temperature_Celsius changed from 32 to 31
Dec 9 12:14:40 pitchou sshd[30683]: Invalid user f from 41.206.41.90
Dec 9 12:14:41 pitchou sshd[30683]: error: PAM: User not known to the
underlying authentication module for illegal user f from
mail.consumeroptions.co.ke
Dec 9 12:14:41 pitchou sshd[30683]: Failed keyboard-interactive/pam for
invalid user f from 41.206.41.90 port 41493 ssh2
Dec 9 12:35:04 pitchou sshd[30750]: Address 190.25.136.132 maps to
corporat190-025136132.sta.etb.net.co, but this does not map back to the
address - POSSIBLE BREAK-IN ATTEMPT!
Dec 9 12:35:04 pitchou sshd[30750]: Invalid user finaid from 190.25.136.132
Dec 9 12:35:04 pitchou sshd[30750]: error: PAM: User not known to the
underlying authentication module for illegal user finaid from 190.25.136.132
Dec 9 12:35:04 pitchou sshd[30750]: Failed keyboard-interactive/pam for
invalid user finaid from 190.25.136.132 port 15064 ssh2
Dec 9 12:43:58 pitchou sshd[30764]: Invalid user finanzas from
66.201.160.200
Dec 9 12:43:58 pitchou sshd[30764]: error: PAM: User not known to the
underlying authentication module for illegal user finanzas from
mail.cuscatlan.net
Dec 9 12:43:58 pitchou sshd[30764]: Failed keyboard-interactive/pam for
invalid user finanzas from 66.201.160.200 port 55807 ssh2
Dec 9 12:45:27 pitchou syslog-ng[1868]: STATS: dropped 0
/************/
"JKB" <knat...@koenigsberg.fr> a �crit dans le message de news:
slrnhhv2mo.4...@rayleigh.systella.fr...
> Le 09-12-2009, ? propos de
> Attaque avec adresse IP forg�e,
> EPiKoiEncore ?crivait dans fr.comp.securite :
>> Bonjour � tous
>
> Bonjour,
>
>> J'ai une petite machine sous linux Suse 10.3 avec SuFirewall2
>> Je subis depuis plus de 24 heures des tentatives de connexion en ssh.
>> Visiblement l'attaquant se cache derri�re des IP forg�es.
>> Il y a un essai toutes les 2 � 3 minutes avec un login diff�rent � chaque
>> fois mais dont le nom cro�t en ordre alphab�tique.
>>
>> Normalement je bannis pour une heure les IP qui ont plus de trois
>> connexions
>> infructeuses mais dans ce cas, cela ne marche pas.
>>
>> Y aurait-il un moyen de d�tecter l'IP r�elle de l'attaquant ???
>>
>> Merci par avance
>
> Est-ce que sont des vraies IP forg�es ou un r�seau ? Peut-on avoir
> un extrait des logs ?
>
> JKB
>
> --
> Le cerveau, c'est un v�ritable scandale �cologique. Il repr�sente 2% de
> notre
> masse corporelle, mais disperse � lui seul 25% de l'�nergie que nous
> consommons tous les jours.
Stephane Catteau
> Solution: ne jamais laisser un accï¿œs SSH avec authentification par mot de
> passe ouvert sur internet.
C'est tout sauf une solution ￜ la problￜmatique posￜe ici. Le monsieur
ne dit pas "au secours on veut casser mon SSH", mais "y a un con qui me
gonfle". De mï¿œme qu'il ne parle pas d'une attaque dictionnaire sur le
mot de passe, mais sur le nom du compte utilisateur.
Stephane Catteau
> Voici un petit bout des logs (il y en a beaucoup plus!) :
[snip]
Une recherche rapide permet d'aboutir entre autre ￜ ￜa :
<http://datanethost.net/logs/dos.txt>
<http://charles.the-haleys.org/ssh_dico_attack_hdeny_format.php/hostsdeny.txt>
Et il y en a d'autres, donc tu es pour l'instant la cible d'un gus qui
cherche ￜ ￜtendre son botnet, et il y a fort ￜ parier que c'est ￜ partir
du botnet lui-mï¿œme qu'il le fait. Rien de bien grave si tu es sï¿œr de
ton SSH, mais il n'y a pas grand chose que tu puisses faire pour tes
logs, sauf ￜ bloquer les adresses IP fournis par la seconde URI pour
limiter un peu les domage en attendant.
Mateusz Viste
> C'est tout sauf une solution à la problématique posée ici. Le monsieur
> ne dit pas "au secours on veut casser mon SSH", mais "y a un con qui me
> mot de passe, mais sur le nom du compte utilisateur.
Bah justement - le con, il aura vite fait d'arrêter lorsqu'il s'apercevra
qu'il est incapable de tester ne serait-ce qu'un seul couple login/mot de
passe. :)
Cordialement,
Mateusz Viste
Eric Masson
'Lut,
> Mais comment faites-vous pour vous connecter de n'importe oￜ sur une
> machine.?
Toujours en ssh mais en dï¿œsactivant tout accï¿œs autre que celui par clï¿œs.
--
NC> Ben quoi ? C'est dￜshonorant le GCU ? (Si oui, lￜ, je prendrais
des risques inconsidï¿œrï¿œs...)
Pas ce que j'ai dit Mais passer du GCU au GNU....
-+- HP in: <http://www.le-gnu.net> - Grandeur et dï¿œcadence -+-
Mateusz Viste
> Mais comment faites-vous pour vous connecter de n'importe o� sur une
> machine.?
> En dehors du ssh, je ne vois pas trop ?!
Attention, je ne dis pas d'arrêter SSH.
SSH, c'est BIEN. En revanche, une authentification par login/mot de passe,
c'est MAL. :-)
SSH propose deux mécanismes d'authentificaion: par login/mot de passe
(méthode simple, mais vulnérable aux attaques brute-force), et
authentification par clef.
Pour des accès distants, je préconise de n'autoriser que cette dernière.
Cordialement,
Mateusz Viste
Fabien LE LEZ
<a.ferrio...@free.inutile.fr.com>:
>Je subis depuis plus de 24 heures des tentatives de connexion en ssh.
A priori, mes machines en subissent aussi. Rien de bien grave, tant
que tu as des mots de passe s�rieux.
Je n'ai connu qu'un seul cas o� un serveur (pas encore en production,
heureusement) est tomb�[*] � cause de �a : un guignol avait cr�� un
compte temporaire avec un mot de passe trop facile � deviner.
L'identit� du guignol en question ? Un employ� de l'h�bergeur. Grrr...
(Il s'agissait d'un serveur "managed" (infog�r� ?))
[*] Comprendre : un script-kiddie a r�ussi � se connecter, donc on
consid�re que la machine est compromise, et il faut r�installer le
syst�me � partir d'un backup ant�rieur.
Fabien LE LEZ
>En revanche, une authentification par login/mot de passe,
>c'est MAL.
Pourquoi ?
>par login/mot de passe
>(m�thode simple, mais vuln�rable aux attaques brute-force),
Combien de temps faut-il pour trouver un mot de passe de style
Z9PQiQ7N ?
EPiKoiEncore
C'est � peu pr�s les mots de passe que j'utilise.
Mais pourquoi avoir diffus� mon mot de passe root ci-dessous ????
:-)
Je clos donc le sujet puisque le risque semble faible.
Merci encore pour vos conseils
Cordialement
Alain
"Fabien LE LEZ" <gram...@gramster.com> a �crit dans le message de news:
66bvh5di5e1q634hn...@4ax.com...
Stephane Catteau
> Bah justement - le con, il aura vite fait d'arrï¿œter lorsqu'il s'apercevra
> qu'il est incapable de tester ne serait-ce qu'un seul couple login/mot de
> passe. :)
Le con est un botnet qui agit visiblement sur ordre mais sans
controle. Du coup il est parfaitement capable de dï¿œrouler l'ensemble de
son dictionnaire mￜme si ￜa ne sert strictement ￜ rien.
Stephane Catteau
> En revanche, une authentification par login/mot de passe, c'est MAL. :-)
Pas si c'est vers un compte utilisateur correctement configurￜ, ￜ
savoir sans possibilitￜ d'escalade normale[1], limitￜ ￜ trois process,
limitￜ ￜ une connexion et on peut aussi jouer sur la limitation
processeur et mￜmoire pour eviter qu'il puisse servir ￜ un DoS en
interne. Avec ï¿œa il peut faire une connexion scp[2], mais mï¿œme un man
ferait beugler le systï¿œme. Idï¿œal pour un bot, pas plus dangeureux que
ï¿œa (mais plus que pas d'accï¿œs du tout ï¿œvidement) et tellement reposant
pour l'admin qui regarde son petit monde bosser pour lui :D
Il y a aussi la possibilitￜ, pour les plus programmeurs, d'utiliser un
shell dￜdiￜ ce qui limiterait d'autant plus les possibilitￜs d'action
d'une personne qui arriverait ￜ casser le mot de passe.
[1]
Une "possibilitￜ d'escalade normale" ￜtant ici d'avoir le droit de
faire un p'tit su vers un autre utilisateur ou, pire, root, et de
pouvoir utiliser sudo.
[2]
Dommage qu'il ait besoin d'un shell.
Fabien LE LEZ
>et � part faire gonfler mes
>fichiers hosts.denyssh, �a m'en touche une sans remuer l'autre (c)
Ben justement, s'il s'agit du serveur SSH de l'ordinateur portable qui
se trouve sur tes genoux, toutes ces attaques le font chauffer un peu
plus, et donc chauffer un peu plus tes testicules. Remarque, c'est une
m�thode contraceptive comme une autre...
Thierry
news:mn.4bda7d9c9...@sc4x.org...
> Le con est un botnet qui agit visiblement sur ordre mais sans
> controle. Du coup il est parfaitement capable de dï¿œrouler l'ensemble de
> son dictionnaire mￜme si ￜa ne sert strictement ￜ rien.
Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon courage
deja rien que pour trouver le username.
Jean-Marc Desperrier
>> Le con est un botnet [...]
>
> Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon
> courage deja rien que pour trouver le username.
Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne
sert ￜ rien.
Un blacklistage de quelques minutes valable pour toutes les ip serait
peut-ï¿œtre une solution (avec si besoin des plages spï¿œcifiques en
white-list).
Stephane Catteau
>> Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon
>> courage deja rien que pour trouver le username.
>
> Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne
> sert ￜ rien.
D'aprï¿œs les logs que l'on peut trouver sur le net en recherchant
certaines des IP indiquï¿œes, non seulement il dispose d'un bon parc
d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
> Un blacklistage de quelques minutes valable pour toutes les ip serait
> peut-ï¿œtre une solution (avec si besoin des plages spï¿œcifiques en
> white-list).
Dans l'un de mes messages prￜcￜdent j'ai pointￜ un fichier
denyssh.host qui contient entre autres un bon nombre[1] des adresses IP
de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois
jours serait encore plus efficace.
[1]
Je ne suis pas non plus allￜ les comparer une ￜ une hein.
EPiKoiEncore
Je me permets de m'immiscer dans votre discussion car je me demandais s'il
�tait possible de s'abonner (au niveau du serveur ssh) � des listes d'ip
blacklist�es un peu comme dans postfix avec les rbl spamcop ou mail-abuse
Les hosts.deny me semblent un peu fig�s face � la volatilit� des IP.
P.S.
Pour le blacklistage, j'ai mis 86400 secondes, cela devrait calmer ;-)
Mais je suis loin d'�tre un expert en s�curit� comme vous tous, quand je
vois ce que vous �crivez ...
Merci
Alain
"Stephane Catteau" <steph....@sc4x.net> a �crit dans le message de news:
mn.53227d9c7...@sc4x.org...
> Jean-Marc Desperrier n'�tait pas loin de dire :
>
>>> Avec un blacklistage d'1 heure pour chaque IP ayant 3 echecs, bon
>>> courage deja rien que pour trouver le username.
>>
>> Sauf que si le botnet dispose de suffisament d'ip, le blacklistage ne
>> sert � rien.
>
> D'apr�s les logs que l'on peut trouver sur le net en recherchant
> certaines des IP indiqu�es, non seulement il dispose d'un bon parc
> d'adresses IP, mais en plus il ne va pas jusqu'au trois tentatives.
>
>
>> Un blacklistage de quelques minutes valable pour toutes les ip serait
>> peut-�tre une solution (avec si besoin des plages sp�cifiques en
>> white-list).
>
> Dans l'un de mes messages pr�c�dent j'ai point� un fichier
> denyssh.host qui contient entre autres un bon nombre[1] des adresses IP
> de ce botnet. Bloquer toutes ces adresses au moins pour deux ou trois
> jours serait encore plus efficace.
>
>
> [1]
> Je ne suis pas non plus all� les comparer une � une hein.
>
>
"fx [François-Xavier Peretmere]"
> Bonjour ￜ tous
>
> Je me permets de m'immiscer dans votre discussion car je me demandais s'il
> blacklistï¿œes un peu comme dans postfix avec les rbl spamcop ou mail-abuse
> Les hosts.deny me semblent un peu figￜs face ￜ la volatilitￜ des IP.
http://denyhosts.sourceforge.net/ ?
Ps : merci de rï¿œpondre en dessous du message original.
--
Fx
Jean-Marc Desperrier
> Un blacklistage de quelques minutes valable pour toutes les ip serait
> peut-ï¿œtre une solution (avec si besoin des plages spï¿œcifiques en
> white-list).
En fait, ï¿œa ne marche pas du tout ce genre de solution.
Le bot, s'il est obstinￜ et attaque en force, dￜrobe systￜmatiquement le
"slot" de connexion ￜ l'utilisateur lￜgitime car il rebloque
instantanï¿œment le systï¿œme pour plusieurs minutes dï¿œs qu'il se dï¿œbloque
et le systￜme apparaￜt donc comme constamment bloquￜ.
Une autre mï¿œthode efficace serait peut-ï¿œtre d'utiliser 2 ports :
- On drop tout par dï¿œfaut.
- L'utilisateur lￜgitime se connecte ￜ un port secret, qui est lui aussi
droppￜ
- Mais cela a ouvert pour son ip une fenￜtre de 30 secondes oￜ il peut
se connecter sans drop au port lï¿œgitime et envoyer ses identifiants
- si l'ip se connecte ￜ un autre port que le bon pendant les 30
secondes, cela ferme la fenï¿œtre
- il faut voir les numￜros des deux ports juste comme un prￜ-filtrage
qui ï¿œvite d'encombrer les log et le CPU en gï¿œrant trop de tentatives de
connexions rejetï¿œes.
Stephane Catteau
> Une autre mï¿œthode efficace serait peut-ï¿œtre d'utiliser 2 ports :
> - On drop tout par dï¿œfaut.
> - L'utilisateur lￜgitime se connecte ￜ un port secret, qui est lui aussi
> droppￜ
> - Mais cela a ouvert pour son ip une fenￜtre de 30 secondes oￜ il peut
> se connecter sans drop au port lï¿œgitime et envoyer ses identifiants
Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
voulant absolument rentrer sur la machine fera un scan de port
systï¿œmatique avec analyse du service qui rï¿œpond, or une telle personne
finirait de toute faï¿œon par comprendre ton mï¿œcanisme d'ouverture de
fenï¿œtre.
Du coup, autant demander directement ￜ SSH d'ￜcouter sur cet autre
port (2222 par exemple) et le problￜme est rￜglￜ. Si c'est un bot il
croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
pirate bah ï¿œa ne changera de toute faï¿œon pas grand chose aux donnï¿œes du
problï¿œme. Par contre ï¿œa limitera les risques d'effets de bord nï¿œgatif.
EPiKoiEncore
""fx [Fran�ois-Xavier Peretmere]"" <f...@terra.fr> a �crit dans le message de
news: 4b21492a$1...@ac-versailles.fr...
>> Les hosts.deny me semblent un peu fig�s face � la volatilit� des IP.
>
> http://denyhosts.sourceforge.net/ ?
Ha que merci que j'y vais de ce pas !!
>
> Ps : merci de r�pondre en dessous du message original.
>
Oups !
Serais-je devenu un gougnafier ?
Je vous l'dis mon bon Monsieur : tout fout l'camp ;-)
D�sol� et merci de cette petite claque sur mes fesses plus tr�s roses
Netsurfeur
> Jean-Marc Desperrier wrote:
> Une autre mï¿œthode efficace serait peut-ï¿œtre d'utiliser 2 ports :
> - On drop tout par dï¿œfaut.
> - L'utilisateur lￜgitime se connecte ￜ un port secret, qui est lui aussi
> droppￜ
> - Mais cela a ouvert pour son ip une fenￜtre de 30 secondes oￜ il peut
> se connecter sans drop au port lï¿œgitime et envoyer ses identifiants
> - si l'ip se connecte ￜ un autre port que le bon pendant les 30
> secondes, cela ferme la fenï¿œtre
> - il faut voir les numￜros des deux ports juste comme un prￜ-filtrage
> qui ï¿œvite d'encombrer les log et le CPU en gï¿œrant trop de tentatives de
> connexions rejetï¿œes.
>
La technique existe, c'est le "port knocking"
(http://fr.wikipedia.org/wiki/Port_knocking).
En utilisant une sï¿œquence de plusieurs ports, ï¿œa rï¿œsiste bien au simple
scan. Une description pour Ubuntu (mais pouvant ï¿œtre adaptï¿œe pour
d'autres Linux) : http://doc.ubuntu-fr.org/port-knocking
--
Netsurfeur
Eric Razny
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
> Jean-Marc Desperrier n'était pas loin de dire :
>
>> Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On
>> drop tout par défaut.
>> - L'utilisateur légitime se connecte à un port secret, qui est lui
>> aussi droppé
>> - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
>> se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de
plusieurs port dans un ordre précis (le même port pouvant être utilisé
plusieurs fois ;)
>
> Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
> voulant absolument rentrer sur la machine fera un scan de port
> systématique avec analyse du service qui répond, or une telle personne
> finirait de toute façon par comprendre ton mécanisme d'ouverture de
> fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
> Du coup, autant demander directement à SSH d'écouter sur cet autre
> port (2222 par exemple) et le problème est réglé. Si c'est un bot il
> croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
> pirate bah ça ne changera de toute façon pas grand chose aux données du
> problème. Par contre ça limitera les risques d'effets de bord négatif.
pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement
mieux. Par contre les deux solutions présentées ici ont le même défaut
qui peut être rédhibitoire : en "extérieur" certains opérateurs ne
laissent passer que certains ports, assez souvent 22 à ma grande joie
d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le
changement de port n'est pas la panacée en ce cas.
Eric
Eric Razny
Le Fri, 11 Dec 2009 11:38:57 +0100, Stephane Catteau a écrit :
> Jean-Marc Desperrier n'était pas loin de dire :
>
>> Une autre méthode efficace serait peut-être d'utiliser 2 ports : - On
>> drop tout par défaut.
>> - L'utilisateur légitime se connecte à un port secret, qui est lui
>> aussi droppé
>> - Mais cela a ouvert pour son ip une fenêtre de 30 secondes où il peut
>> se connecter sans drop au port légitime et envoyer ses identifiants
le port knocking fonctionne bien mais il vaut mieux une succession de
plusieurs port dans un ordre précis (le même port pouvant être utilisé
plusieurs fois ;)
>
> Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
> voulant absolument rentrer sur la machine fera un scan de port
> systématique avec analyse du service qui répond, or une telle personne
> finirait de toute façon par comprendre ton mécanisme d'ouverture de
> fenêtre.
Si tu paramètre correctement ton port-knocking j'en doute!
> Du coup, autant demander directement à SSH d'écouter sur cet autre
> port (2222 par exemple) et le problème est réglé. Si c'est un bot il
> croira qu'il n'y a pas de service SSH disponible, et si c'est un vrai
bruno.tregui...@nullepart.invalid
> EPiKoiEncore a �crit :
>> Visiblement l'attaquant se cache derri�re des IP forg�es.
>
> attaque avec une "IP forg�e" (l'IP spoofing est plus du domaine de la
> l�gende urbaine que de la r�alit�, mis � part quelques curiosit�s
> d'attaques par UDP ou ICMP)
Bonjour,
L'IP spoofing est tout sauf une l�gende urbaine, c'est d'ailleurs cette
technique (entre autres) qui a �t� utilis�e par Kevin Mitnick lors de sa
c�l�bre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation
IP + SYN flooding + pr�diction des num�ros de s�quence TCP). Elle a m�me
�t� plus ou moins automatis�e par la suite (par d'autres, Mitnick ayant
�t� arr�t� entre-temps).
Cela dit, outre le fait que d�j�, � l'�poque (fin 1994), tr�s peu de
gens �taient capables de mettre en oeuvre une telle attaque (et encore
moins de la comprendre ;-) ), de nombreuses am�liorations ont depuis �t�
apport�es aux piles TCP/IP, (meilleure randomisation des num�ros de
s�quence TCP et impl�mentation des SYN cookies, notamment), ce qui la
rend encore plus difficile � mener d�sormais.
Aujourd'hui, l'usurpation IP est donc effectivement, � mon avis, plut�t
une attaque "�pouvantail" qu'autre chose (dans la mesure o� la
dangerosit� per�ue en est tr�s exag�r�e, �tant donn� le nombre de
pr�-requis qu'elle impose) mais elle a bel et bien �t� r�alis�e.
Par ailleurs, il n'est pas totalement exclu que la d�couverte d'une ou
plusieurs autre(s) faille(s) protocolaire(s) la remette "en selle" un de
ces jours, m�me si cela reste actuellement du domaine du tr�s improbable.
Bruno
Stephane Catteau
comme ceci :
> L'IP spoofing est tout sauf une lï¿œgende urbaine, c'est d'ailleurs cette
> technique (entre autres) qui a ￜtￜ utilisￜe par Kevin Mitnick lors de sa
> cï¿œlï¿œbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP +
> SYN flooding + prï¿œdiction des numï¿œros de sï¿œquence TCP).
Sauf que ce que tu dￜcris lￜ n'est pas une attaque ￜ proprement parler
mais un scan de port. S'il y a un service TCP en ï¿œcoute sur le port, il
essayera de rￜpondre ￜ la poignￜ de main. La machine dont l'adresse IP
a ￜtￜ usurpￜe n'ayant aucune trace d'une tentative de connexion en cour
rï¿œpondra d'un RST ce qui incrï¿œmentera le numï¿œro de sï¿œquence TCP. Si la
pile IP n'a pas une forte randomisation du numï¿œro de sï¿œquence TCP il
suffit donc (faï¿œon de parler puisqu'il faut aussi prï¿œdire le numï¿œro de
sￜquence) d'interroger le port de l'hￜte usurpￜ, avant et aprￜs le
scan. Si le numￜro de sￜquence a ￜtￜ incrￜmentￜ deux fois, c'est que le
RST a effectivement ￜtￜ envoyￜ et donc que le port est ouvert.
Par contre j'ai d'ￜnormes doutes concernant la paternitￜ de Mitnick,
vue que ce scan n'a ￜtￜ intￜgrￜ ￜ nmap qu'au environ de 2002 si ma
mï¿œmoire est bonne.
Dans le cadre d'une vï¿œritable attaque, l'IP spoofing nï¿œcessite d'avoir
le controle sur, au choix, le routeur situￜ avant la cible ou celui
situￜ avant la machine dont l'adresse IP est usurpￜe. Autrement les
paquets arriveront fort logiquement sur la machine usurpï¿œe et
l'usurpation ne servirait ￜ rien. C'est cela qui rend l'IP spoofing
anecdotique, d'autant plus de nos jours oￜ le premier pirate venu peut
disposer d'un botnet de quelques centaines de machines ou plus.
Stephane Catteau
>> Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
>> voulant absolument rentrer sur la machine fera un scan de port
>> systï¿œmatique avec analyse du service qui rï¿œpond, or une telle personne
>> finirait de toute faï¿œon par comprendre ton mï¿œcanisme d'ouverture de
>> fenï¿œtre.
>
> Si tu paramï¿œtre correctement ton port-knocking j'en doute!
Bof. A l'ï¿œpoque des botnets les donnï¿œes ne sont plus les mï¿œmes. Si
chaque (sￜquence de) port est testￜ par une machine tirￜe au hasard et
que le port lui-mï¿œme, ou la sï¿œquence de port, est aussi tirï¿œe au
hasard. Si tu laisses un dï¿œlais de 2 minutes entre chaque test, que tu
places un prï¿œrequis disant qu'une mï¿œme machine ne peut pas intervenir
deux fois de suite et que deux (sï¿œquences de) ports qui se suivent ne
peuvent pas ￜtre faites l'une aprￜs l'autre, le tout couplￜ avec un
tableau de flags pour ï¿œtre sï¿œr de faire tous les tests et de ne pas les
faire deux fois, non seulement ce n'est qu'une question de temps mais
en plus bon courage ￜ l'IDS pour arriver ￜ dￜtecter le scan.
La seule chose que montreront les logs, c'est qu'un paquet de machines
font toc toc au hasard, ce qu'il faudra dï¿œbrouiller du bruit de fond
fait par tous les kiddies qui trainent sur le rï¿œseau. Le seul handicap
c'est le temps nￜcessaire pour le scan, mais lￜ encore les botnets ont
changￜ la donne, tu lances ton script et ensuite tu fais ta vie en
attendant d'avoir un rï¿œsultat.
Le port knocking reste un plus, mais le considï¿œrer comme sï¿œr est une
faille en soit, il protï¿œge encore des kiddies, mais d'eux seuls.
[snip]
> pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement
> mieux. Par contre les deux solutions prï¿œsentï¿œes ici ont le mï¿œme dï¿œfaut
> qui peut ï¿œtre rï¿œdhibitoire : en "extï¿œrieur" certains opï¿œrateurs ne
> laissent passer que certains ports, assez souvent 22 ￜ ma grande joie
> d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le
> changement de port n'est pas la panacï¿œe en ce cas.
En tout ￜtat de cause, l'obscuritￜ n'a jamais ￜtￜ un rￜel plus en
matiￜre de sￜcuritￜ. Un SSH bien configurￜ et les patchs de sￜcuritￜ
appliquï¿œs en temps et en heure restent la dï¿œfense la plus efficace, le
reste n'ï¿œtant qu'une question de confort personnel.
bruno.tregui...@nullepart.invalid
> bruno.tregui...@nullepart.invalid devait dire quelque chose
> comme ceci :
>
>> L'IP spoofing est tout sauf une lï¿œgende urbaine, c'est d'ailleurs cette
>> technique (entre autres) qui a ￜtￜ utilisￜe par Kevin Mitnick lors de sa
>> cï¿œlï¿œbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP +
>> SYN flooding + prï¿œdiction des numï¿œros de sï¿œquence TCP).
>
> Sauf que ce que tu dￜcris lￜ n'est pas une attaque ￜ proprement parler
> mais un scan de port. S'il y a un service TCP en ï¿œcoute sur le port, il
> essayera de rￜpondre ￜ la poignￜ de main. La machine dont l'adresse IP
> a ￜtￜ usurpￜe n'ayant aucune trace d'une tentative de connexion en cour
> rï¿œpondra d'un RST ce qui incrï¿œmentera le numï¿œro de sï¿œquence TCP.
Bonjour Stï¿œphane,
Renseigne-toi sur l'attaque en question, c'ï¿œtait trï¿œs loin de n'ï¿œtre
qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
prￜalables ￜ l'attaque de Mitnick consistait justement ￜ faire taire la
machine lï¿œgitime (et ainsi l'empï¿œcher de rï¿œpondre par un RST) en
l'inondant de paquets SYN et saturer les buffers prï¿œvus pour les
nouvelles connexions (ce qui est maintenant contournￜ par les SYN cookies).
> Si la
> pile IP n'a pas une forte randomisation du numï¿œro de sï¿œquence TCP il
> suffit donc (faï¿œon de parler puisqu'il faut aussi prï¿œdire le numï¿œro de
> sￜquence) d'interroger le port de l'hￜte usurpￜ, avant et aprￜs le
> scan. Si le numￜro de sￜquence a ￜtￜ incrￜmentￜ deux fois, c'est que le
> RST a effectivement ￜtￜ envoyￜ et donc que le port est ouvert.
Hmmm. Je pense que tu es en train de confondre avec le "dumb scan", lￜ,
qui utilise effectivement une technique utilisant non pas les numï¿œros de
sï¿œquence TCP, mais un champ IP qu'on appelle habituellement "IP ID" et
qui s'incrï¿œmente de faï¿œon simple sur beaucoup d'implï¿œmentation de piles
IP. Cette technique permet ￜ un pirate de scanner des ports sans rￜvￜler
son adresse IP.
> Par contre j'ai d'ￜnormes doutes concernant la paternitￜ de Mitnick,
> vue que ce scan n'a ￜtￜ intￜgrￜ ￜ nmap qu'au environ de 2002 si ma
> mï¿œmoire est bonne.
Ce n'est pas parce que ￜa n'a ￜtￜ intￜgrￜ qu'en 2002 ￜ nmap que ￜa
n'existait pas avant ! :-) Mais lￜ on ne parle pas de la mￜme chose de
toute faï¿œon...
> Dans le cadre d'une vï¿œritable attaque, l'IP spoofing nï¿œcessite d'avoir
> le controle sur, au choix, le routeur situￜ avant la cible ou celui
> situￜ avant la machine dont l'adresse IP est usurpￜe. Autrement les
> paquets arriveront fort logiquement sur la machine usurpï¿œe et
> l'usurpation ne servirait ￜ rien.
Ce que tu dￜcris lￜ est une attaque "man in the middle", rien ￜ voir
avec l'IP spoofing, ￜ mon avis...
Bonne fin de journï¿œe,
Cordialement,
Bruno
Stephane Catteau
comme ceci :
> Renseigne-toi sur l'attaque en question, c'ï¿œtait trï¿œs loin de n'ï¿œtre
> qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
> prￜalables ￜ l'attaque de Mitnick consistait justement ￜ faire taire la
> machine lï¿œgitime (et ainsi l'empï¿œcher de rï¿œpondre par un RST) en
> l'inondant de paquets SYN et saturer les buffers prï¿œvus pour les
> nouvelles connexions (ce qui est maintenant contournￜ par les SYN cookies).
Ce qui n'est qu'un DoS et ne permet toujours pas ￜ Mitnick de rentrer.
[snip]
> Hmmm. Je pense que tu es en train de confondre avec le "dumb scan",
Possible.
>> Par contre j'ai d'ￜnormes doutes concernant la paternitￜ de Mitnick,
>> vue que ce scan n'a ￜtￜ intￜgrￜ ￜ nmap qu'au environ de 2002 si ma
>> mï¿œmoire est bonne.
>
> Ce n'est pas parce que ￜa n'a ￜtￜ intￜgrￜ qu'en 2002 ￜ nmap que ￜa
> n'existait pas avant ! :-)
Ca avait ￜtￜ intￜgrￜ suite ￜ la publication de la mￜthode. Tsutomu
Shimomura s'y connait suffisement pour comprendre ce qui lui ï¿œtait
arrivￜ et a l'ￜgo qui va avec sa profession, il n'aurait pas gardￜ ￜa
pour lui ;)
> Mais lￜ on ne parle pas de la mￜme chose de toute faￜon...
vi.
>> Dans le cadre d'une vï¿œritable attaque, l'IP spoofing nï¿œcessite d'avoir
>> le controle sur, au choix, le routeur situￜ avant la cible ou celui
>> situￜ avant la machine dont l'adresse IP est usurpￜe. Autrement les
>> paquets arriveront fort logiquement sur la machine usurpï¿œe et
>> l'usurpation ne servirait ￜ rien.
>
> Ce que tu dￜcris lￜ est une attaque "man in the middle", rien ￜ voir
> avec l'IP spoofing, ￜ mon avis...
Non. Un man in the middle est destinￜ ￜ intercepter une connexion
lï¿œgitime, je parle bien d'IP spoofing. Dans le cadre d'une connexion
TCP, ￜ moins d'un simple DoS il faut d'abord passer la poignￜe de main
et donc une discussion bilatï¿œrale. Or la machine usurpï¿œe n'acceptera
jamais de donner suite ￜ une poignￜe de main qu'elle n'a pas initiￜe,
il faut donc que les paquets soit routï¿œe vers la machine de
l'attaquant, ce qui ne peut se faire qu'en ayant la main sur l'un des
deux routeurs terminaux. La seule exception c'est lorsque l'usurpation
se passe au sein d'un LAN, parce que c'est le seul cas oￜ l'on a la
garantie d'ￜtre derriￜre le mￜme routeur que la machine usurpￜe. Lￜ
oui, si on attribue son adresse IP ￜ notre machine et que l'on arrive ￜ
DoSer la machine usurpï¿œe, on prendra sa place dans le rï¿œseau. Mais dans
le cadre d'une attaque in the wild, il n'y a quasiment aucune chance
d'y arriver si on ne place pas un tunnel Ip entre un routeur et notre
machine ; mï¿œme si la machine usurpï¿œe est sur le mï¿œme netbloc que la
notre il n'y a aucune garantie que le plan de routage du FAI
permettrait de prendre sa place autrement.
Cela dit, on en revient ￜ ce que je rￜpondais ￜ Eric, l'heure est aux
botnets, ce qui change la donne. De nos jours l'IP spoofing n'a de sens
que pour contourner un filtrage par adresse IP. Dans tous les autres
cas de figure cacher l'adresse IP source est une complication inutile,
perdre une machine du botnet ï¿œtant au final sans grande importance.
Cela d'autant plus que l'agonie massive des services abuses fait qu'en
gï¿œnï¿œral on ne perd mï¿œme pas la machine utilisï¿œe.
bruno.tregui...@nullepart.invalid
Le 21/12/2009 ￜ 16:27, Stephane Catteau a ￜcrit :
> bruno.tregui...@nullepart.invalid devait dire quelque chose
> comme ceci :
>
>> Renseigne-toi sur l'attaque en question, c'ï¿œtait trï¿œs loin de n'ï¿œtre
>> qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
>> prￜalables ￜ l'attaque de Mitnick consistait justement ￜ faire taire la
>> machine lï¿œgitime (et ainsi l'empï¿œcher de rï¿œpondre par un RST) en
>> l'inondant de paquets SYN et saturer les buffers prï¿œvus pour les
>> nouvelles connexions (ce qui est maintenant contournￜ par les SYN cookies).
>
> Ce qui n'est qu'un DoS et ne permet toujours pas ￜ Mitnick de rentrer.
Mais si, ce DoS est justement destinￜ a bￜillonner la machine usurpￜe !
Plus bas dans ton message, tu dis que jamais une machine usurpï¿œe
n'acceptera de donner suite ￜ un 3-way-handshake dont elle n'est pas ￜ
l'origine: je suis tout ￜ fait d'accord. Pour ￜviter qu'elle ne rￜagisse
violemment ￜ l'attaque en aveugle menￜe par Mitnick en balaￜant des RST
ￜ tout va, il fallait donc la faire taire, c'est prￜcisￜment ￜ cela que
ce DoS ￜ base de SYN flooding sert.
Ensuite, Mitnick a exploitￜ une relation de confiance prￜexistante entre
la machine usurpï¿œe (localisï¿œe chez Shimomura) et un serveur de l'UCSD
sur lequel celui-ci avait un compte.
Au final, Mitnick est bel et bien rentrￜ sur la machine de Shimomura,
avec les droits root, qui plus est.
> [snip]
>> Hmmm. Je pense que tu es en train de confondre avec le "dumb scan",
>
> Possible.
Certain. ;-)
>> Ce que tu dￜcris lￜ est une attaque "man in the middle", rien ￜ voir
>> avec l'IP spoofing, ￜ mon avis...
>
> Non. Un man in the middle est destinￜ ￜ intercepter une connexion
> lï¿œgitime, je parle bien d'IP spoofing. Dans le cadre d'une connexion
> TCP, ￜ moins d'un simple DoS il faut d'abord passer la poignￜe de main
> et donc une discussion bilatï¿œrale. Or la machine usurpï¿œe n'acceptera
> jamais de donner suite ￜ une poignￜe de main qu'elle n'a pas initiￜe,
> il faut donc que les paquets soit routï¿œe vers la machine de
> l'attaquant, ce qui ne peut se faire qu'en ayant la main sur l'un des
> deux routeurs terminaux.
Non, voir ci-dessus. ;-)
> La seule exception c'est lorsque l'usurpation
> se passe au sein d'un LAN, parce que c'est le seul cas oￜ l'on a la
> garantie d'ￜtre derriￜre le mￜme routeur que la machine usurpￜe. Lￜ
> oui, si on attribue son adresse IP ￜ notre machine et que l'on arrive ￜ
> DoSer la machine usurpï¿œe, on prendra sa place dans le rï¿œseau. Mais dans
> le cadre d'une attaque in the wild, il n'y a quasiment aucune chance
> d'y arriver si on ne place pas un tunnel Ip entre un routeur et notre
> machine ; mï¿œme si la machine usurpï¿œe est sur le mï¿œme netbloc que la
> notre il n'y a aucune garantie que le plan de routage du FAI
> permettrait de prendre sa place autrement.
Sur un LAN les choses sont effectivement beaucoup plus simples, mais via
des liaisons WAN, avec des routeurs qu'on ne maï¿œtrise pas, le seul moyen
d'usurper une machine est de la faire taire avant... D'oￜ le DoS.
Pour plus d'infos, voir ici le post de Shimomura lui-mï¿œme, expliquant
comment il s'ￜtait fait avoir (ce qui a dￜ lui en coￜter, vu l'ego du
bonhomme, comme tu le disais):
http://www.cs.berkeley.edu/~daw/security/shimo-post.txt
> Cela dit, on en revient ￜ ce que je rￜpondais ￜ Eric, l'heure est aux
> botnets, ce qui change la donne. De nos jours l'IP spoofing n'a de sens
> que pour contourner un filtrage par adresse IP. Dans tous les autres
> cas de figure cacher l'adresse IP source est une complication inutile,
> perdre une machine du botnet ï¿œtant au final sans grande importance.
> Cela d'autant plus que l'agonie massive des services abuses fait qu'en
> gï¿œnï¿œral on ne perd mï¿œme pas la machine utilisï¿œe.
Tout ￜ fait d'accord avec cette derniￜre partie.
Cordialement,
Bruno