
Suite à de nombreuses attaques sur les applications web, voici résumé dans cet article des pistes possibles.
Suite à de nombreuses attaques sur les applications web, voici résumé dans cet article des pistes possibles pour s’en protéger.
L’architecture typique d’une application web est la suivante:

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.
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.
Configuration pour l’installation du CAS jasig sur un serveur JBoss 7. Problème de loggeur, log4j et hibernate dialect
Découvrez la planche #24 !
Mettre à jour sa stack applicative, c'est assurer la stabilité et la sécurité de ses applications. Il est donc important de faire le suivi des mises à jour pour ne pas se retrouver bloqué à cause de l'accumulation de la dette technique. Sur Symfony, les versions majeures (X.0.0) sont programmées tous les 2 ans, et les versions mineures (1.X.0) sont programmées tous les 6 mois, en mai et en novembre. Chaque version arrive avec son lot de nouveautés qu'il est important de prendre en compte. Les dates de mises à jour étant connues, l'intégration à des Roadmap est alors simplifiée. Mais à quoi faut-il penser lors de ces migrations ?