Apache en "open relay"

Support Debian
#1

Salut à tous,

Depuis peu, j’ai plus de connexion internet chez moi donc j’ai mis ma machine directement sur le net (sans pare feu ni rien) chez un ami.
J’ai un problème avec apache2, apparament, il serait en open relay car quelqu’un execute un script pour flooder les forums (japonais) avec des liens de mp3. Pour éviter le problème, j’ai désactivé le site en question dans la conf d’apache, ca s’est arrété, mais comment éviter ce problème ?
C’est une redirection par proxypass qui va taper un tomcat sur le port 8080, dans le fichier “site-enabled”, j’ai mis :

ProxyPass              /  http://xxxxx:8080/
ProxyPassReverse  /  http://xxxxx:8080/

et j’ai rajouté le “xxxxx” dans le host de la machine.
La conf d’apache2 est par défaut, sauf le module proxy qui est activé.
Merci de votre aide :slightly_smiling:

#2

Je ne suis pas spécialiste, mais il me semble que si ton apache2 n’est pas qu’en position d’accèlerateur, que les autres sites passent, et que le problême disparait quand tu désactive juste le site fautif, le problême vient surement d’une faille du code du site lui même et pas d’apache2.
Mais bon, c’est intuitif comme orientation de recherche.

Tu as cherché dans les annonces de sécurité sur le module proxypass ?

#3

J’ai pas regardé dans les failles de sécurité du module proxy pass, par contre, au niveau du site, il n’y a pas de code, il y a simplement des includes pour la banière et le sommaire pour faciliter les modifs.
Merci de ton aide :slightly_smiling:

#4

Que ce soit du html ou des applets java, que ca soit stocké dans des includes ou dans une seule grosse page active compressée cryptée, un site C’EST du code qui s’execute du moment qu’il fait quelquechose.
Alors maintenant, s’il est constitué d’une seule page blanche, c’est sûr que le code a peu de chance de fournir des failles, mais dès que le site fournit la moindre facilité avancée, il peut y avoir des failles.

il faudrait savoir si ça vient du site lui même, de tomcat, ou du proxy.
L’attaque reprend quand tu reactives le site ?
Dans ce cas, renvoies vers un site vide sur un apache non tomcat (si tu peux) pour voir si sans tomcat ni site, l’attaque reprend.
Puis si ça ne reprend pas, vers ton tomcat avec un contenu vide.
Si ça reprend dans le premier cas, ça vient du proxy.
Si ca reprend avec un site vide sous tomcat, c’est une faille de tomcat.
Sinon, c’est une faille du site.

Non ?

#5

Je pari que ton forum est une vieille version de phpbb. Il existe sur les vieille version une faille de sécu, et certains scripts automatisés l’exploitent pour flooder ces forums.

Si c’est phpbb, met le à jour!

#6

C’est un site en jsp, ce n’est pas un forum, simplement un site avec des pages en html et jsp (celle en jsp sont comme les html mais avec un include pour le sommaire et l’entete), il y a que du js comme script pour phpmyvisits.

#7

Oui, ben c’est du code donc faillible, et java est aussi sensible que le php pour ce qui est de la securité.
Tu as pu tester avec ou sans site et avec ou sans tomcat pour savoir d’ou ça venait ?

#8

J’ai laissé tourné apache2 et j’ai commenté un site (en jsp qui tourne sur un tomcat) et depuis, le flood s’est arrété. Par contre, que le tomcat soit démarré ou arrété, c’est la meme chose.
Par contre, dans ce qui est mis en commentaire, il y a simplement les lignes :
ProxyPass et ProxyPassReverse.

#9

[quote=“Chrisnaps”]J’ai laissé tourné apache2 et j’ai commenté un site (en jsp qui tourne sur un tomcat) et depuis, le flood s’est arrété. Par contre, que le tomcat soit démarré ou arrété, c’est la meme chose.
Par contre, dans ce qui est mis en commentaire, il y a simplement les lignes :
ProxyPass et ProxyPassReverse.[/quote]OK. Bon, ça veut dire à priori que ça ne vient pas d’apache, mais ça, on le savait déjà puisque tu avais déja dit qu’en coupant le site l’attaque s’arrètait.
Il reste donc toujours à savoir si ça vient du module proxy, de tomcat, ou du site lui même.
Alors donc comme je te disais mais d’une autre manière au cas ou je me sois mal exprimé la première fois:

  • si ton proxy renvoie vers un site “non tomcat”, une page html blanche par exemple, est ce que l’attaque reprend ?
  • Ensuite, si c’est un site tomcat, mais vierge (pareil, il ne sert qu’une page blenche), qu’est ce que ça donne ?
#10

Le tomcat était arrété avec le site commenté dans la config d’apache, ca à continué sur un site en html tout basique qui tourne sous apache. Avec le site tomcat vide, c’est la meme chose, l’attaque continuait.

Nous avons quand meme réussi à bloquer le floodage, il se connecte toujours mais il a une erreur de type 403 qui lui est renvoyé (mais il continue toujours d’essayer), donc il y a ip-tables qui a été mis en place et surtout “mod-security” sur apache qui a été mis en place (depuis son installation, il renvoi l’erreur 403).

Par contre, nous n’arrivons pas à trouver le script qu’il utilise ou ce qu’il a pu modifier dans la machine, si vous avez une idée pour chercher, ce n’est pas de refus, car on sèche un peu, j’essaye de regarder un peu partout manuellement, mais …

#11

Si j’ai bien compris, quand tu n’actives aucun proxy et que tu ne déclares qu’un site composé d’une page vierge, ca continue.
L’apache est donc la faille.
Ce que je ne comprends pas par contre c’est que tu disais au tout début qu’il suffisait que tu desactives le site dans apache pour bloquer l’attaque.
Ca veut dire que quand tu n’as aucun “site-enabled”, même pas de page vierge à la racine de /var/www, ça bloque les attaques, et qu’il suffit que tu ajoutes un site pour que ça redémarre ?

Pour la recherche du script, as tu essayé avec un /var/www vide ou vraiment minimaliste ?
Ensuite, tu rajoutes par morceau le contenu actuel et tu vois quand l’attaque se reactive.

Sinon, pour chercher parmi les failles officiellement détectées, ça serait utile de connaitre ta version d’apache et des modules qui sont activés.

#12

[quote=“mattotop”]Si j’ai bien compris, quand tu n’actives aucun proxy et que tu ne déclares qu’un site composé d’une page vierge, ca continue.
L’apache est donc la faille. [/quote]

C’est tout à fait ca :slightly_smiling:

[quote=“mattotop”]Ce que je ne comprends pas par contre c’est que tu disais au tout début qu’il suffisait que tu desactives le site dans apache pour bloquer l’attaque.
Ca veut dire que quand tu n’as aucun “site-enabled”, même pas de page vierge à la racine de /var/www, ça bloque les attaques, et qu’il suffit que tu ajoutes un site pour que ça redémarre ? [/quote]

En fait, j’ai pas enlevé “site-enabled”, j’ai simplement commenté tout les sites qui étaient déclaré dedans. Première chose qu’on a faites, désinstallation apache2 avec un dpkg --purge. Ca n’a rien changé donc on a enlevé tout les sites qui utilisait “ProxyPass” et “ProxyPassReverse” (le premier de la liste en était un). Quelque heures après, nous avons regardé les dates d’écritures des fichiers de log et on s’est apercu qu’apache logué plus dans acces.log, mais dans le fichier : nomDuSite_access.log. (d’où le moment où l’on pensait que l’attaque s’était arrété :frowning: ) et l’attaque se servait du second site qui était mis dans “site-enabled” (donc du www je pense)

Dans le /var/www/ j’ai un dossier avec les fichiers de base d’mrtg, un dossier apache2-default, un dossier qsstats (stat pour qmail) et un dossier vide server-status

Voila quelques lignes que je vois dans le fichier acces.log :

221.226.124.126 - - [06/Jun/2007:12:01:54 +0200] "GET http://135531.com:80/prx.php?p=q1w2e3r4t5y6u7i8o9p0*a-b HTTP/1.1" 403 209 "-" "Mozilla/3.0 (compatible; Indy Library)" 221.226.124.126 - - [06/Jun/2007:12:01:54 +0200] "GET http://searchour.com:80/prx.php?p=q1w2e3r4t5y6u7i8o9p0*a-b HTTP/1.1" 403 209 "-" "Mozilla/3.0 (compatible; Indy Library)" sp34.ipt.ru - - [06/Jun/2007:12:02:03 +0200] "GET http://images.google.com/ HTTP/1.0" 403 202 "-" "-"

Et ce qu’il y a dans error.log

[Wed Jun 06 12:03:00 2007] [error] [client 61.41.234.46] mod_security: Access denied with code 403. Pattern match "^$" at HEADER("USER-AGENT") [severity "EMERGENCY"] [hostname "images.google.com"] [uri "http://images.google.com/"] [Wed Jun 06 12:03:08 2007] [error] [client 62.194.230.232] mod_security: Access denied with code 403. Pattern match "^$" at HEADER("USER-AGENT") [severity "EMERGENCY"] [hostname "www.microsoft.com"] [uri "http://www.microsoft.com/en/us/default.aspx"] [Wed Jun 06 12:03:14 2007] [error] [client 83.19.65.58] mod_security: Access denied with code 403. Pattern match "^$" at HEADER("USER-AGENT") [severity "EMERGENCY"] [hostname "images.google.com"] [uri "http://images.google.com/"]

Je vais regarder si je trouve quelque chose :wink:

Merci de ton aide :slightly_smiling:[/code]

#13

Dis donc, j’arrive pas trop à interpreter les requetes je me suis connecté sur 135531.com et searchour.com, c’est chez toi, ou c’est un rebond de l’attaquant ?
dans ce cas, c’est quoi ce prx.php ?

Sinon, tu as vraiment essayé en sortant (un bête mv temporaire) mrtg et qsstats de l’arbo du serveur ? (de toutes facons, ils ne devraient pas etre accessibles de l’exterieur, idealement).
Parceque la faille peut encore venir de là tant que tu as un quelconque contenu actif sur ton serveur. c’est pour ça que je te conseillais de vraiment tout vider.

Un autre moyen de savir si ça vient de ça est de desactiver carrément le php.

Sinon, c’est pas bien de mettre les choses à la main dans httpd.conf, c’est pas pour rien qu’il y a les comandes a2ensite/a2dissite et a2enmod/a2dismod :wink:

#14

[quote=“mattotop”]Dis donc, j’arrive pas trop à interpreter les requetes je me suis connecté sur 135531.com et searchour.com, c’est chez toi, ou c’est un rebond de l’attaquant ?
dans ce cas, c’est quoi ce prx.php ?[/quote]

C’est un rebond de l’attaquant, j’ai qu’un domaine, c’est le meme que mon pseudo :wink:

[quote=“mattotop”]Sinon, tu as vraiment essayé en sortant (un bête mv temporaire) mrtg et qsstats de l’arbo du serveur ? (de toutes facons, ils ne devraient pas etre accessibles de l’exterieur, idealement).
Parceque la faille peut encore venir de là tant que tu as un quelconque contenu actif sur ton serveur. c’est pour ça que je te conseillais de vraiment tout vider.[/quote]

Je viens de le faire, ca continue toujours (en plus, les fichiers ne sont pas utilisés donc je vais les supprimer)

Je l’ai désactiver, mais ca change rien :frowning: (par contre, j’ai simplement enlevé le module php5.load et php5.conf dans mod-enabled.

J’ai rien mis dans le httpd.conf, il est vide, les seules choses que j’ai rajouté à la main sont les sites dans sites-enabled et la conf du “mod-security” dans apache2.conf :wink:

#15

ton cas ce confirme, même s’il n’y a pas de solution:
webmasterworld.com/forum23/4414.htm

#16

Merci pour ton aide, je vais la laisser comme ca, on verra quand je serai de nouveau derrière un routeur si ca s’arrete :wink:

#17

mais dit donc, j’ai lu ça:
httpd.apache.org/docs/2.0/mod/mod_proxy.html
qui m’a mené vers ça:
httpd.apache.org/docs/2.0/mod/mo … tml#access
ou il est dit:

[quote]Strictly limiting access is essential if you are using a forward proxy (using the ProxyRequests directive). Otherwise, your server can be used by any client to access arbitrary hosts while hiding his or her true identity. This is dangerous both for your network and for the Internet at large. When using a reverse proxy (using the ProxyPass directive with ProxyRequests Off), access control is less critical because clients can only contact the hosts that you have specifically configured.[/quote]Tu as cette directive “ProxyRequests Off” ?

Parceque je crois avoir compris, de ce que j’ai pu lire, que les derniers logs que tu m’a montré (ceux en prx.php) sont les traces de tests de detection de proxy ouverts, pas d’une exploit en soit: c’est normal qu’ils continuent.
Les “vraies” traces d’exploit doivent en fait s’arrèter dès que tu as desactivé le mod_proxy, normalement.

#18

[quote=“mattotop”]Tu as cette directive “ProxyRequests Off” ?

Parceque je crois avoir compris, de ce que j’ai pu lire, que les derniers logs que tu m’a montré (ceux en prx.php) sont les traces de tests de detection de proxy ouverts, pas d’une exploit en soit: c’est normal qu’ils continuent.
Les “vraies” traces d’exploit doivent en fait s’arrèter dès que tu as desactivé le mod_proxy, normalement.[/quote]

Elle était deja mise cette directive pourtant.

#19

Bon.

Pas d’autre idée.