[tetaneutral] Comportement étrange: serveur bancaire qui communique avec un serveur en Californie au moment du paiement

[Sylvain]

Salut,

Un petit coup de Google sur l'IP, et on trouve des choses intéressantes :

https://whois.arin.net/rest/nets;q=199.19.249.196?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
https://www.projecthoneypot.org/ip_199.19.249.196
https://www.abuseipdb.com/report-history/199.19.249.196
https://www.reddit.com/r/sysadmin/comments/1ow4gy/
http://surveillance.rsf.org/en/blue-coat-2/

Pour résumer, cette IP est utilisée par la société Blue Coat, qui 
fournit des « services de sécurité » permettant, par exemple, de 
surveiller et filtrer les accès internet en masse.

On peut imaginer qu'ils ont un robot qui crawle tout ce qu'il peut pour 
« catégoriser » les sites, voire « vérifier leur niveau de sécurité »...

Ca serait intéressant de demander à Monetico quelle fonctionnalité ils 
attendent de Blue Coat, vu qu'ils sont au courant de la chose, d'après 
leur réponse.

Sylvain



On 07/04/2016 12:06, Nicolas Toublanc wrote:
> Bonjour,
>
> J'ai observé un comportement étrange pendant la mise en place d'un
> paiement par CB sur un site marchand, et je serais curieux d'avoir
> l'avis de gens plus expérimentés que moi sur le sujet.
>
> Durant la procédure de paiement, le serveur de la banque (Monetico,
> situé en France) envoie une notification vers le site marchand
> (également en France, chez online.net <http://online.net>).
>
> La plage d'IP de Monetico est connue (*145.226.0.0 - 145.226.255.255*)
> donc j'ai mis en place un filtrage par IP au niveau du proxy.
>
> Hors, pendant les tests, j'ai observé a plusieurs reprise une requête
> simultanée vers mon serveur, venant de Californie (requête GET au lieu
> de POST).
>
>
> nginx.1    | *2016/04/01 13:40:04* [error] 33#33: *3992 *access
> forbidden by rule, client: 199.19.249.196*, server:
> mon-site-marchand.com <http://mon-site-marchand.com>, request: "*GET*
> /payment-notification HTTP/1.1", host: "mon-site-marchand.com
> <http://mon-site-marchand.com>"
> nginx.1    | mon-site-marchand.com <http://mon-site-marchand.com>
> *199.19.249.196* - - [01/Apr/2016:13:40:04 +0000] "GET
> /payment-notification HTTP/1.1" *403* 168 "-" "SPM"
>
> nginx.1    | *2016/04/01 13:40:04* [error] 33#33: *3993 upstream
> prematurely closed connection while reading response header from
> upstream, client: *145.226.30.181*, server: mon-site-marchand.com
> <http://mon-site-marchand.com>, request: "*POST* /payment-notification
> HTTP/1.1", upstream: "http://172.17.0.19:8080/payment-notification",
> host: "mon-site-marchand.com <http://mon-site-marchand.com>"
> nginx.1    | mon-site-marchand.com <http://mon-site-marchand.com>
> *145.226.30.181* - - [01/Apr/2016:13:40:04 +0000] "POST
> /payment-notification HTTP/1.1" *200* 172 "-" "SPM"
>
>
> Ce qui signifie que la requête à été soit communiquée par Monetico à un
> autre serveur (volontairement ou non), ou alors repérée par un robot sur
> la route entre la banque et le site marchand.
>
> Je précise que le site marchand est hébergé en HTTP.
>
> Comme je trouvais ça étrange, j'ai contacté par précaution mon hébergeur
> ainsi que Monetico, lequel m'a répondu:
>
>     Suite à l'analyse et au retour de notre assistance technique ce
>     comportement est normal et n'est pas malveillant, cependant il a été
>     désactivé par notre assistance pour pas qu'il se reproduit.
>
> Et ce matin, j'ai refait un essai, et je n'ai plus cette requête, mais à
> la place, venant toujours de *199.19.249.196* une requête vers la page
> d'accueil (css, js et requêtes json montrant que le javascript a été
> interprêté).
>
> J'en déduis donc que Monetico utilise un service tiers qui s'assure que
> le site marchand est UP, ou pour une autre raison.
>
>
> Qu'en pensez-vous?
>
> Avez-vous déjà observé quelque chose de ce genre?
>
>
> --
> Nicolas Toublanc
> @toubiweb <https://twitter.com/Toubiweb>
>
>
> _______________________________________________
> tetaneutral mailing list
> tetaneutral at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/tetaneutral
>