Tentatives de connections incessantes : que faire ?

Support Debian
#1

Bonsoir,
Alors je sais pas si c’est précisément en rapport avec une mauvaise config d’apache, de pure-ftpd, mais j’ai firestart qui me montre des tas de tentatives de connections (qu’il bloque), sur les ports dédiés :

  • Radmin
  • mysql
  • VNC
  • eDonkey

Que faire ? pourquoi toutes ces tentatives de connections ( plusieures par minutes, ça commence à faire ) ? Quels risques ?
Enfin bref, bizarre non ?

#2

Euh… C’est du pause café, ça.
Sinon, pas d’idée.

#3

ah bon ?! :blush:
désolé, mais ça me semble étrange quand même … même ça m’inquiète …

#4

Conseil : virer firestart.
Je l’avais installé, “pour voir” et j’ai eu aussi ce désagréable rslt.
Bien sûr, des tentatives, il y en a mais si ton parefeu est en place et bien configuré, tu ne risques rien donc, évite-toi une crise de parnoïa.

#5

Ouvrir un fil dans pause café en lançant un concours, si tu veux t’amuser, regardes les connexions Samba et les connexions ssh et «keep coll», si ils sont dehors, c’est qu’ils ne sont pas dedans!

#6

[quote=“ricardo”]Conseil : virer firestart.
Je l’avais installé, “pour voir” et j’ai eu aussi ce désagréable rslt.[/quote]
Non non lol, je le laisse, il me suffira alors de clicker droit sur la ligne de la connection blockée et de choisir :

  • désactiver les énénements en provenance de la source
    Comme c’est jamais la même, je vais peut-être opter pour désactiver les événements sur le port (ex: mysql) …
    Donc c’est normal banal … dac.

Je comprend mieux la suggestion de Matt là … Bon, je keep cool :wink:

#7

sinon, pour les services accessibles par mot de passe, il y a un module pam que j’ai cité ailleurs, et qui permet de verrouiller automatiquement des adresses en cas de tentatives echouée répètées, il faudrait juste retrouver le fil.
Et en première protection contre les attaques ssh en “brute force” quand on a activé les mots de passe, c’est fail2ban.

#8
  • Radmin -> Quelqu’un (ou un robot) veut controler ta machine a distance
  • mysql -> Quelqu’un veut probablement tester un exploit ou une injection
  • VNC -> Idem radmin, controle de machine
  • eDonkey -> Si tu utilise edonkey et que tu l’arrete, il y a une remanence, ton ip va rester comme source d’un fichier. Idem si tu reprend une nouvelle IP (si tu es en IP statique et que tu ne fais jamais d’edonkey, c’est pas normal par contre! Sauf si les messieurs en bleus se sont mis à scanner les gens…), tu peux par malchance chopper l’ancienne IP d’un gros downloadeur qui vient de se deconnecter et donc tout le monde frappe à ta porte. Dans ce cas, eteind ton modem 5 minutes et redemarre le jusqu’a enlever ce bruit. Parfois il faut s’y reprendre plusieurs fois et en general ca marche.

Donc c’est des ports “à problèmes”, pas d’inquietude outre mesure. Ce que je ferai:
-> Tu mets reject à la place de drop pour ces ports.
-> Tu attends un peu pour voir si ca se calme.
-> Tu enleve le log sur ces ports.

A priori oui, keep cool :smt033

edit: pour ssh
Au niveau des logs du firewall:

  1. Changer de port et tu previens tes users
  2. N’autorise que leur IP si c’est possible
  3. Utiliser les methodes indiquées par MattOTop (fail2ban)

Au niveau des logs SSH:

  1. Faire un script qui filtre les “Failed password for” des logs ssh avec un effacement periodique des logs ssh.
  2. N’autoriser que une authentification par certificats et non plus par mot de passe.
#9

[quote=“MattOTop”]
Et en première protection contre les attaques ssh en “brute force” quand on a activé les mots de passe, c’est fail2ban.[/quote]

# modprobe ipt_recent
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW  -m recent --set
# iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP

Très efficace… Ça bloque l’IP pendant quelques minutes après 3 connexions en 90 secondes.

#10

fran.b pourquoi tu inseres la deuxiême règle ?

#11

Elle DROP les paquets venant d’IP ayant effectué + de 3 connexions en 90 secondes sur le port ssh. Terminé les tentatives de forces brutes sur ssh.

#12

Elle DROP les paquets venant d’IP ayant effectué + de 3 connexions en 90 secondes sur le port ssh. Terminé les tentatives de forces brutes sur ssh.[/quote]Bon, j’avais compris, même si ton hack ne fait pas la différence entre les bonnes et les mauvaises connections (mais c’est vrai qu’on a pas forcément besoin de se connecter toutes les trentes secondes).
Ma question est : pourquoi tu fais ta règle en -I plutot qu’en -A comme la première (et je connais la signification de -I et -A, là n’est pas la question). Pourquoi ne pas les mettre toutes les deux en -A dans l’ordre inverse ? Il y a une raison ?

#13

sur le conseil d’avision il faut blacklister les ports souvent solicités dans firestarter, le parfeu fait sont boulot et ne te met pas une tartine de tentatives de connections.

va faloir que jme mette à iptables moi. :confused:

#14

Pas d’accord pour blacklister. Si un méchant essaye de se connecter sur ta machine et que tu ne lui dit pas que le port est fermé mais seulement que tu ne lui répond pas, il va re-essayer. Alors que si tu lui dit: cherche pas c’est fermé ben il va voir ailleurs. C’est carrement le cas pour emule par exemple, le test est vite fait.
Enfin chacun ses methodes… :wink:

#15

[quote=“BorisTheButcher”]Pas d’accord pour blacklister. Si un méchant essaye de se connecter sur ta machine et que tu ne lui dit pas que le port est fermé mais seulement que tu ne lui répond pas, il va re-essayer. Alors que si tu lui dit: cherche pas c’est fermé ben il va voir ailleurs. C’est carrement le cas pour emule par exemple, le test est vite fait.
Enfin chacun ses methodes… :wink:[/quote]Je ne crois pas que le_petit_chat_noir parlait de la différence entre DROP et REJECT, si ?

#16

[quote=“BorisTheButcher”]… si tu es en IP statique et que tu ne fais jamais d’edonkey, c’est pas normal par contre![/quote]Justement, je n’utilise jamais eDonkey, j’ai jamais utilisé la mule … mais mon ip est dynamique, mon eth0 static par contre. Ok je vais voir, il y a quand même un truc pas clair, même si c’est pas alarmant … ça le fait pas depuis longtemps, mais depuis plusieurs jours à certaines heures …
Pour Radmin et VNC, ça ne m’étonne pas (le parano parles en moi là), faut que je tire ça au clair…

#17

[quote=“MattOTop”][quote=“BorisTheButcher”]Pas d’accord pour blacklister. Si un méchant essaye de se connecter sur ta machine et que tu ne lui dit pas que le port est fermé mais seulement que tu ne lui répond pas, il va re-essayer. Alors que si tu lui dit: cherche pas c’est fermé ben il va voir ailleurs. C’est carrement le cas pour emule par exemple, le test est vite fait.
Enfin chacun ses methodes… :wink:[/quote]Je ne crois pas que le_petit_chat_noir parlait de la différence entre DROP et REJECT, si ?[/quote]
Ah ptet bien… je croyais que blacklister c’etait drop. J’ai ptet repondu trop vite alors :slightly_smiling:
Pour preciser ma pensée:
Si la machine n’est pas serveur alors on peu tout droper (on veut rester invisible)
Si la machine a un port d’ouvert (serveur donc) alors on est plus invisible donc autant etre “standard TCP” et repondre par la négative, ca evitera de nouvelles tentatives.
Dans les deux cas, pas besoin de logger les requetes, c’etait ptet ca blacklister…

#18

C’est biensur l’ip “visible” qui compte, celle du tunnel pppoe (visible sur ton pc) ou si tu es en pppoa, celle de ton modem/routeur.

Ben eteind ta connexion au minimum 5mn et re-essaye jusqu’a plus avoir d’emule. Si ca revient c’est ptet qu’il y a un ver ou bot qui utilise Emule pour se propager, faudrait regarder les niouzes…

#19

euh… blacklister ca doit pas être ca?
ben ja du me gourrer ou mal m’exprimer.
en fait je parlait juste de faire en sorte à ce que les tentatives n’apparaissent pas sur l’interface firestter et ne figurent pas non plus dans les logs…
pour pas avoir des logs ennorme quoi… :confused:
alors? drop ou reject?

#20

Boris t’a répondu: dans ton cas, c’est drop, à moins que tu n’aies un service inet sur ta machine.