Apparemment trop simple, j'ai du le faire moi même.
Les requêtes HTTP depuis des adresses blacklistées par mon firewall sont redirigées vers un port interne, pris en charge par inetd.
Si il y en a que cela intéresse, voici le code :
Un exemple de redirection iptables :
iptables -t nat -A PREROUTING -s 221.232.0.0/14 -p tcp --dport www -j REDIRECT --to-port 1090
La ligne dans inetd :
1090 stream tcp nowait nobody /usr/bin/opws.sh opws.sh
Le fichier /usr/bin/opws.sh :
1 #!/bin/sh
2
3 HTML_FILE=/var/www/blacklisted/index.html
4 ANSWER='HTTP/1.1 403 Forbidden'
5 SERVER=Apache
6
7 DATE=`/bin/date -u -R | /bin/sed 's/+0000/GMT/'`
8 LENGTH=`/bin/ls -l $HTML_FILE | awk '{ print $5 }'`
9
10 echo $ANSWER
11 echo Date : $DATE
12 echo Server : $SERVER
13 echo Content-Type : text/HTML
14 echo Content-Length : $LENGTH
15
16 # blank line to separate header form content
17 echo
18
19 # start to send content
20 /bin/cat $HTML_FILE
Quant au fichier /var/www/blacklisted/index.html, mettez ce que vous voulez...
Il ne me manque plus qu'à rajouter des entrées dans syslog...
Les commentaires sont les bienvenus, il y a certainement des failles ?
# Racisme ?
Posté par rahan . Évalué à 2.
[^] # Re: Racisme ?
Posté par André Rodier . Évalué à 5.
Je reconnais que je casse l'universalité du web, mais le peu de sites que j'héberge sont en français, et n'ont aucun intérêt pour les chinois, les pakistanais, les japonais, les coréens, etc...
Sil il y a des français expatriés, cette redirection les informe que le réseau qu'ils utilisent a été temporairement blacklisté, et qu'ils peuvent utiliser un proxy, voire m'envoyer un mel.
C'est fatiguant à force, les remplissage de logs apache ou sshd, invalid request, invalid user, etc...
Quand on épluche ses logs assez souvent, cela devient difficile de discerner une attaque réelle au milieu de cette inondation de requêtes invalides venue de vers et autres saletés qui inondent ces réseaux.
Couplé à fail2ban, cela me permet de passer moins de temps a lire mes logs, et de me concentrer sur d'autres projets.
C'est plus constructifs que de jouer au chat et a la souris avec des pirates en herbes en train de tester si j'ai bien mis à jour PhpBB ou si j'utilise phpmyadmin...
Vivement ipv6.
Je retourne programmer...
[^] # Re: Racisme ?
Posté par michauko . Évalué à 2.
[^] # Re: Racisme ?
Posté par briaeros007 . Évalué à 3.
# Pourquoi répondre ?
Posté par _alex . Évalué à 6.
iptables -t nat -A PREROUTING -s 221.232.0.0/14 -p tcp --dport www -j DROP
n'irait pas ?
Un petit bout de code C serait plus approprié à mon gout, sans inetd.
But : éviter de créer plein de processus à chaque requête et de faciliter un DOS (sh, `date ..` , `ls ... ` , /bin/cat --> 4 processus)
si je ne me trompe pas ?
[^] # Re: Pourquoi répondre ?
Posté par André Rodier . Évalué à 2.
Je réponds plus Haut.
Je n'ai pas de compilateur C sur mon serveur, mais si quelqu'un connaît un serveur web qui fasse cela, je suis preneur.
[^] # Re: Pourquoi répondre ?
Posté par inico (site web personnel) . Évalué à 2.
Tu peux le modifier pour qu'il reponde 503 Service Unavailable facilement.
[^] # Re: Pourquoi répondre ?
Posté par André Rodier . Évalué à 2.
Bravo pour le travail en tout cas.
[^] # Re: Pourquoi répondre ?
Posté par Yth (Mastodon) . Évalué à 4.
iptables -t nat -A PREROUTING -s 221.232.0.0/14 -p tcp --dport www -j REJECT --reject-with icmp-port-unreachable
Si les paquets sont juste jetés, ils peuvent insister.
Si la réponse est immédiate et dit « ce port n'est pas ouvert » c'est simple et clair, inutile d'aller chercher plus loin.
Utile en cas de nmap sur ta machine pour chercher les failles, et les points d'accès, là c'est simple, c'est fermé, alors que si tu droppes simplement, il y a un doute.
Je me trompe peut-être, je ne suis pas expert en sécurité, loin de là, mais voilà,
Yth.
[^] # Re: Pourquoi répondre ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
# Optimisations:
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 6.
script de la sorte (limite les appels à 2 forks):
[^] # Re: Optimisations:
Posté par andeus . Évalué à 10.
Sinon en PHP, 0 fork:
Ou en C:
[^] # Re: Optimisations:
Posté par André Rodier . Évalué à 1.
Offrir PHP à des adresses blacklistées, n'est-ce pas imprudent ?
Il me semble qu'en PHP nous perdons tout l'intérêt du programme sensé écarter les crackers.
La simple ligne #!/usr/bin/php5 exécute certainement beaucoup de code, analyse POST, GET, initialisations, etc... ouvrant ainsi la porte à autant de failles potentielles.
[^] # Re: Optimisations:
Posté par Fabien Engels . Évalué à 3.
[^] # Re: Optimisations:
Posté par Vador Dark (site web personnel) . Évalué à 4.
Mais bon, je rejoins ce qui a été dit plus haut : autant mettre les en-têtes avec le contenu de la page dans un fichier, et le balancer.
[^] # Re: Optimisations:
Posté par andeus . Évalué à 2.
Mais je crois que l'entête Date est obligatoire, et elle ne peut pas être mise en dur dans le fichier (en fait ça marche très bien sans cette entête du moment qu'on envois pas de cookies/expires, etc...)
[^] # Re: Optimisations:
Posté par Moonz . Évalué à 6.
Pas vraiment, car la RFC2616 autorise les serveurs non datés:
14.18 Date
[...]
Origin servers MUST include a Date header field in all responses, except in these cases:
[...]
3. If the server does not have a clock that can provide a
reasonable approximation of the current time, its responses
MUST NOT include a Date header field. In this case, the rules
in section 14.18.1 MUST be followed.
[...]
14.18.1 Clockless Origin Server Operation
Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last- Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).
(voir http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14(...)
[^] # Re: Optimisations:
Posté par André Rodier . Évalué à 2.
Je sais maintenant que je peux utiliser un simple fichier texte.
Je n'utilise pas de redirections apache pour des raisons de sécurité et de performances.
[^] # Re: Optimisations:
Posté par Vador Dark (site web personnel) . Évalué à 5.
[^] # Re: Optimisations:
Posté par Fabien Engels . Évalué à 3.
# montée en charge ?
Posté par Gniarf . Évalué à 2.
exemple de listes de blocs d'ip ici :
http://blackholes.us/zones/countries/
(parce que après l'asie c'est l'amérique du sud qui commence à bien s'équiper et à être vérolé en permanence)
[^] # Re: montée en charge ?
Posté par André Rodier . Évalué à 3.
Existe-t-il un module noyau couplant iptables à une base de données du style sqlite ?
[^] # Re: montée en charge ?
Posté par André Rodier . Évalué à 2.
[^] # Re: montée en charge ?
Posté par Bruno Michel (site web personnel) . Évalué à 1.
http://ipset.netfilter.org/
# Redirect Apache
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
(Quoique c'est peut-être un peu lourd)
[^] # Re: Redirect Apache
Posté par Gniarf . Évalué à 2.
131.211.183.51 - - [04/Jun/2007:19:12:49 +0200] "GET /phpmyadmin/main.php HTTP/1.0" 404 293
(660 variantes)
131.211.183.51 - - [04/Jun/2007:19:13:28 +0200] "GET /administrator/phpMyAdmin-2.8.3/main.php HTTP/1.0" 404 293
669 en donc moins de 40 secondes, soit plus de 15 à la seconde
répondre vite et bien (un gentil 404, tout de suite) à ce genre de recherches de vulnérabilité n'est pas une bonne idée.
alors entre faire un drop/reject ou ajouter un sleep(10) dans son 404 parce qu'on sait que l'outil en face lance une requete à la fois, peu importe du moment que ça marche et que le site reste utilisable pour les autres usagers
# Apache ?
Posté par Sébastien Koechlin . Évalué à 4.
Je ne comprends pas pourquoi tu ne fais pas traiter ces requêtes par Apache ?
Tu fais écouter Apache sur le port 1090, port sur lequel tu déclares un VirtualHost qui ne contient qu'un document: ta page d'erreur. Non testé:
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.