Vous n'êtes pas identifié(e).
Pages : 1
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
comment puis-je identifier exactement ce que cette adresse cherche à faire ?
En regardant les logs du serveur web.
Il vaut mieux montrer que raconter.
Hors ligne
C'est quelqu'un qui tente de craquer la base de données ?
Je peux bloquer cette IP, mais ça fait pas une semaine qu'il est installé, j'espère ne pas devoir vérifier ce qui se passe tous les jours...
Aussi, suivant le cas, il y a écrit "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36" ou "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0", pour la même IP. Dur de savoir ce que c'est comme machine...
Ceci dit, ces 2 IPs (celle du premier message et cette dernière) ont disparu de iftop maintnenant. Peut-être en ont-ils eu marre de se casser les dents si c'était des hackers.
Ou était-ce des services de Debian qui ont tout simplement terminé leur travail ? Peut-être que je m'inquiètes pour rien quoi.
Dernière modification par Anard (28-10-2019 16:42:22)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
Dernière modification par raleur (28-10-2019 17:45:54)
Il vaut mieux montrer que raconter.
Hors ligne
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
Dernière modification par infothema (30-10-2019 02:36:53)
Association libriste infothema située dans les Côtes d'Armor (Bretagne)
Blog : https://www.infothema.fr / Forum : https://www.infothema.fr/forum
Twitter : https://twitter.com/asso_infothema / Compte Mastodon : https://framapiaf.org/@infothema / PeerTube : https://infothema.net
Hors ligne
$
Mais ça semble fonctionner, en revanche uniquement pour apache.
J'ai donc suivi ton conseil et installé également fail2ban mais activé uniquement pour sshd et vsftpd. En effet, pour apache, il me renvoie une erreur, il semble ne pas trouver le fichier /etc/fail2ban/filter.d/apache
$
Enfin idem que précédemment, j'ai l'impression que les tutos ne sont plus tout à fait adaptés à Buster.
Ceci dit, c'est très bien, ça me permet de sécuriser un peu les connexions par SSH ou FTP, Apache étant géré en interne.
Aussi, j'ai cru comprendre que ça ne servait pas à grand chose d'ajouter des règles persistantes dans iptables.
En effet, il est fort probable que ces attaques passent par des VPN, auquel cas 1/2h plus tard, l'IP en question sera probablement affectée à une autre personne.
Donc en effet, un bannissement pour 10 minutes voire un peu plus doit être largement suffisante pour faire fuir les robots.
Ceci dit, en suivant les logs d'apache, j'ai l'impression que les attaques se sont bien calmées, avant même de se faire bannir par les modules apache…
Edit à toto : Mis les BBCode du forum au propre en séparant la commande de son retour.
Pour le principe, voir le tuto qu'il est bô, là :
Oh, quel beau BB …code où comment mettre en forme vos messages dans le fofo
Dernière modification par Anard (30-10-2019 13:20:05)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
Debian testing, nvidia 980 gtx sli, cm asurock 16 gb ram cpu i7 4,2 ghz
Hors ligne
mais si c'est des bons casse burne, ils changent l'ip régulièrement
dans apache
regarde La directive MaxRequestWorkers et La directive RequestReadTimeout
l'une qui permet de fixer le nombre maximum de requêtes pouvant être traitées simultanément
l'autre limiter le temps que met le client pour envoyer sa requête.
perso, je les ai pas encore mises..
je ferai peut-être aussi une petite config nftables sur le serveur, mais sans illusions.
tu peux aussi en savoir un tout petit peu plus sur les ip
Dernière modification par lagrenouille (01-11-2019 08:33:12)
site de mon association 1901
https://le-caillou.le-pic.org
Hors ligne
EDIT : @toto : Merci pour la mise en forme, j'essaierai de faire plus attention...
Dernière modification par Anard (01-11-2019 10:01:30)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
Si j'ai bien compris, le module security renvoie une erreur 403 à certaines requêtes en fonction de différents shémas, enregistrés dans /usr/share/modsecurity-crs/rules/ . Il en bloque en effet certaines requêtes, par exemple en cas de tentative d'injection de code.
Le module evasive ne bloque que les requêtes qui cherche à mettre le serveur en DoS, en demandant le même page avec insistance. Ca fonctionne en effet, mais uniquement en faisant plusieurs fois la même requête.
J'ai installé également fail2ban, qui lui apparemment, ne se base que sur les fichiers de log pour interdire une IP si la même trame dans les logs est trouvée plusieurs fois de suite (par exemple dans le cas ou le module security d'apache bloque plusieurs requêtes à la suite).
Dans l'idéal, j'aimerais qu'il bloque simplement un IP qui reçoit plus de 5 erreurs 404 en 5s par exemple, mais je ne vois pas trop comment lui écrire cette règle sans risquer trop de faux positifs.
En effet, hier soir en lisant les accès au serveur, une même IP a essayé une page inexistante par seconde pendant plus de 20 minutes sans être inquiétée, si ce n'est une dizaine de blocages par le module security.
Serait-ce une erreur de configuration ou est-ce que des erreurs 404 répétées ne déclenche aucune alerte si les pages demandées sont différentes ?
Merci pour votre aide.
Dernière modification par Anard (04-11-2019 10:36:13)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
iftop est pas mal non plus pour surveiller le réseau
'
multitail te donne les logs en directe
tu as des outils d'audit réseau comme netdata qui sont intéressant
j'en parle ici:
https://chezlagrenouille.fr/spip.php?article164
Dernière modification par lagrenouille (04-11-2019 13:07:47)
site de mon association 1901
https://le-caillou.le-pic.org
Hors ligne
, même après avoir redirigé correctement le port 19999 du routeur.
Mais ça ne répond pas tout à fait à ma question :
Dans l'idéal, j'aimerais [que fail2ban] bloque simplement un IP qui reçoit plus de 5 erreurs 404 en [10s] par exemple, mais je ne vois pas trop comment lui écrire cette règle sans risquer trop de faux positifs.
Dernière modification par Anard (04-11-2019 13:54:01)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
En faisant des essais, fail2ban se déclenche bien :
L'entrée est bien apparue dans iptables :
J'ai écrit "mon-ip-a -l-envers" car au lieu de 109.190.xxx.yyy, il est écrit yyy-xxx-190-109.dsl.ovh.fr
Pour le reste, je ne comprends pas bien ce qui est écrit mais la configuration par défaut de fail2ban
Pourtant, je peux toujours aller charger une adresse existante :
On voit bien que j'ai pu charger une page à 11:07:44, après le bannissement survenu à 11:07:38
Qu'est-ce que j'ai oublié ?
Merci beaucoup pour votre aide.
[EDIT]
Comme je disais, fail2ban lance également un script à moi qui enregistre l'IP concernant dans un base de données.
Si l'IP concernée est retrouvée plus d'un certain nombre de fois en un certain temps, je rajoute une règle dans iptables et dans /etc/iptables/rules.v4 pour la bannir définitivement...
Cette méthode fonctionne très bien elle. Tellement bien... que je me suis banni et ne peux plus accéder au serveur, même pas en ssh !
Il faudrait peu-être que je trouve la bonne syntaxe pour interdire l'IP sauf sur le port SSH
Je suis en train de télécharger Tails pour me connecter depuis une fausse IP, je n'arrive pas à trouver de fournisseur de VPN gratuit…
REGLE : merci homebrewvpn
En tout cas, ça confirme que les directives iptables inscrites naturellement par fail2ban ne fonctionnent pas.
Pourquoi ? Ça reste un mystère… Peut-être ne faut-il pas utiliser iptables-mutiport comme action de bannissement mais autre chose ?
[EDIT2]
Bien j'ai pu régler mon problème : il fallait écrire dans /etc/fail2ban/jail.d/default-debian.conf :
Je n'ai pas bien compris le différence, mais il se trouve que ça fonctionne avec allports...
Dernière modification par Anard (05-11-2019 17:12:39)
"iMack" : GA-H97M-D3H, Intel i5 4460, 16Go RAM / Bootloader Clover - macOS Mojave / Gentoo-Xfce
"Serveur" : Dell Optiplex 360, Intel Q8200, 2Go RAM / Debian Bullseye
"Portable" : Asus E502NA, Intel N4200, 8Go RAM / DebianFacile Bullseye
Hors ligne
Pages : 1