Dans cet article


Offres d'emploi

Tags

Sécuriser votre application web contre les attaques dans un cloud

Sécuriser votre application web contre les attaques dans un cloud

Suite à de nombreuses attaques sur les applications web, voici résumé dans cet article des pistes possibles pour s’en protéger.

 

Présentation de l’architecture typique d’une application web

L’architecture typique d’une application web est la suivante:

schéma d'architecture JEE

Un front Apache (ou IIS) qui joue le rôle de point d’entrée unique de l’application. Généralement, il fait office de proxy vers votre application web. Et souvent même  de load balancer. L’application étant généralement développée en JAVA (ou .Net). Pour des raisons de performance, un cluster de serveur d’applications répond aux requêtes proxiées de votre front. De plus, vous laissez le front répondre aux fichiers statiques et ainsi gérer les méta informations de vos images et scripts etc… Enfin vos instances de serveur d’applications sont connectés à la base de données. Le plus souvent Oracle. Suite aux compagnes de performances, vous avez établi le  bon dimensionnement de vos environnements.

Enfin vous décidez de sécuriser votre solution. Vous installez un firewall, disons Iptables et vous rentrez les règles habituelles.

Pour l’exemple nous supposerons que chaque logiciel, front apache, serveurs d’applications, base de données s’exécutent tous sur des serveurs différents (ce qui est la plupart du temps le cas). Vous avez donc défini des règles dans vos firewall autorisant que les bonnes machines  à communiquer entre elles.

Tout est donc ok pour la mise production. Vous ouvrez les ports de votre front. Tous se passent bien pendant une semaine, et d’un coup sans prendre garde, vous êtes alerté par une centaine de mail de votre solution de monitoring (par exemple VMware) vous signalant une activité anormale de votre carte réseau. Un petit tour sur l’application vous fait vous apercevoir que votre application ne réponds plus ou très lentement. Branle-bas de combats avec votre équipe d’infra, et vous vous rendez compte, souvent en regardant dans les logs de votre apache que vous avez des Go de log qui s’empilent. Un rapide coup d’oeil sur vos serveurs d’applications et vous vous rendez comptes qu’ils ne sont pas inquiétés.

Flooding

Le diagnostique tombe. Vous êtes floodé de milliers de requêtes qui empêchent à votre front de traiter les requêtes. Que faire? Voici donc une liste de points qui pourront peut-être vous aider. Aucune de ces pistes ne suffit mais toutes ensemble permettent de limiter le problème.

  • Sécuriser votre apache pour qu’il ne soit plus ouvert en tant que proxy
  • Si l’attaque ne s’effectue que sur certaine url, vous pouvez directement les bloquer depuis votre firewall avec des règles ad-hoc.
  • 90% du temps, ce type d’attaque s’effectue sur le port 80. Si vous avez la possibilité de passer votre solution en https vous réglerez le problème. Faites en sorte que votre apache n’écoute plus sur le port 80 et vous stoppez net les attaques.
  • Activer le mod security d’Apache (Efficacité limitée pour des grosses attaques)
  • Optez pour un vrai firewall de préférence physique ou à défaut logiciel type pfsense (votre iptables ne suffira pas)
  • Changer d’adresse IP votre machine et faites oubliez l’ancienne adresse en ne l’utilisant pas pendant un certain temps.
  • Désactiver la réponse au ping de votre machine
  • Désactiver la réponse d’état de votre apache de sorte que l’assaillant ne connaisse pas votre version
  • Si bien sur vous pouvez filtrer les adresses ip de votre client directement dans le firewall, ceci est encore plus efficace.
  • Mettre en place un VPN avec les clients de l’application si possible (rarement le cas)
  • Vérifier que votre machine n’est pas vérolée par un rootkit et dans le doute réinstaller votre front à partir d’une distribution à jour et propre.
Voici donc une liste de point qui peuvent servir de piste lors que l’on ne sait plus quoi faire pour ce genre d’attaques bien gênantes.

 

 

L'équipe AXOPEN

Voir aussi les articles suivants

JBOSS 7 et Message Driven Architecture (MDA)

JBOSS 7 et Message Driven Architecture (MDA)

Le 08/08/2012 par Pierre Liseron

Configuration pour l’envoi et la réception et message JMS avec Jboss 7 Dans la configuration Full de Jboss 7, un broker de messagerie est intégré. (HornetQ) Pour l’activer, il suffit de lancer son Jboss avec la configuration full (-c=standalone-full.xml). Configuration de Jboss 7 messaging La configuration des queues et topics se fait dans le subsystem urn:jboss:domain:messaging. true 102400 2
Lire l'article

JBoss 7 et java.lang.IllegalArgumentException: null source
En développement un écran très complexe dans une de nos applications, nous avons reçu ce type d’erreur, qui nous ont – au début – parues aléatoire. Après de nombreuses recherches, surtout afin de créer un cas de test satisfaisant, nous nous sommes aperçu que le problème se posait à cause d’un trop grand nombre de paramètres POST. Voici l’anomalie qui se produit: java.lang.IllegalArgumentException: null source at java.util.EventObject.<init>(Unknown Source) at javax.faces.event.SystemEvent.<init>(SystemEvent.java:71) at javax.
Lire l'article

Clustering TOMCAT et MULTICAST

Clustering TOMCAT et MULTICAST

Le 11/04/2012 par Pierre Liseron

Prérequis La première chose a faire pour réaliser un clustering TOMCAT est bien sur de posséder deux instances de TOMCAT. Deux cas sont possibles. Vos deux instances sont sur la même machine (ou VM), auquel cas, il faut bien changer les ports d’écoute de vos TOMCAT. (Rappel ceci sont situés dans le fichier server.xml) Si vous avez deux machines (ou VM) bien distincte, il n’est pas nécessaire de changer le ports d’écoute.
Lire l'article