Verrouillage de mon server Ubuntu avec UFW

J'utilise Ubuntu 12.04 sur une instance Amazon EC2 et nouveau sur le côté sysadmin des choses. Je travaille sur un petit projet et je commence à être ciblé par des robots (au less j'espère qu'ils sont bots).

J'utilise PHP et dans mes journaux d'erreurs, j'ai remarqué w00tw00t romanian anti-sec et /w00tw00t.at.blackhats.romanian.anti-sec: J'ai googlé et j'ai trouvé plusieurs résultats comme celui- ci et ce qui indique que c'est très probablement juste quelques bots. Ils cherchaient des variations de PHPMyAdmin, PMA, MyAdmin. D'après ce que je peux dire, ils n'ont rien trouvé et n'ont eu que 404 erreurs. En ce qui concerne PHPMyAdmin, j'utilise un alias et j'ai access limité à quelques adresses IP.

Actuellement, je gère UFW et j'ai ces règles

 To Action From -- ------ ---- 80 ALLOW Anywhere 443 ALLOW Anywhere 22 ALLOW MY.IP.ADDRESS1 22 ALLOW MY.IP.ADDRESS2 22 ALLOW MY.IP.ADDRESS3 80 ALLOW Anywhere (v6) 443 ALLOW Anywhere (v6) 

Tous les tutoriels que j'ai vus sur UFW indiquent comment le configurer, pas des suggestions sur la configuration elle-même. Fondamentalement, j'utilise SFTP et SSH (avec une paire de keys) pour fonctionner sur mon server. Y a-t-il des règles qui doivent être nécessaires?

Je ne vois pas comment utiliser éventuellement UFW pour éviter ces types d'attaques.

Si tout sauf 80/443 est refusé à l'access public et que vous n'avez spécifié que quelques adresses IP spécifiques pour l'access ssh, le problème réside dans votre application et non sur la configuration du réseau.

Ne touchez même pas les règles de pare-feu dans cette instance.

Vous devez vous protéger contre:

  • Mots de passe faibles
  • Des liens généraux "Admin", c'est-àdire. website.com/admin, website.com/phpmyadmin
  • Mots de passe incorporés dans votre code
  • Les injections SQL et d'autres vulnérabilités de code Web / database différentes.

Pour améliorer la security de votre server, vous pouvez faire exécuter Apache chroot'ed, de sorte qu'il soit séparé du système central par une couche virtuelle.

Vous pouvez également implémenter FIM (gestion de l'intégrité du file) pour vous assurer que les files qui ne sont pas destinés à changer ne changent pas (exemple: la configuration apache / php)

ou vous pouvez écrire un script pour save toutes les commands exécutées par root / apache et les envoyer par courrier électronique périodiquement.

Des choses comme celles-ci sont ce que vous devriez regarder une fois que vous avez configuré votre pare-feu (ce que vous avez fait)

Probablement, la meilleure façon de vous protéger contre la numérisation du panneau de command est de ne pas exécuter un panneau de contrôle Web. Si vous pouvez éviter de faire cela, vous pouvez totalement ignorer ces attaques.

Une autre chose que vous pouvez faire pour vous protéger contre les attaques courantes est de configurer un VPN et de restreindre l'access aux services administratifs (SSH, panneaux de contrôle, etc.) aux adresses IP sur ce VPN. Utilisez votre pare-feu pour vous assurer que ce trafic provient réellement du VPN et n'est pas falsifié (p. Ex., Le trafic de décount lié à l'interface VPN du WAN).

Si vous utilisez des passwords forts, maintenez vos applications à jour, utilisez les users les less privilégiés pour les démons et suivez les pratiques exemplaires comme celles-ci, vous n'avez rien à craindre de ces types d'attaques automatisées.

Gardez à l'esprit qu'il n'y a pas de règles magiques de pare-feu, et un pare-feu ne peut pas vous protéger de beaucoup de choses. Ils ont été conçus pour garder les services «internes» inaccessibles à la WAN publique (voir mon point sur le VPN), et vous pouvez les utiliser pour éliminer certains types de trafic qui autrement enfreindraient une limite de security, mais ils ne fonctionnent pas couche d'application et vous ne pouvez pas l'utiliser pour sécuriser vos applications Web.

Tout le trafic w00tw00t qui se trouve dans vos journaux signifie exactement ce que vous voyez: vous êtes amené à être sondé par un script d'une sorte quelconque. Je ne ferais pas une grosse affaire, mais si vous êtes vraiment concerné, utiliser iptables & ufw ne vous aidera pas vraiment.

Comme il semble que vous utilisez un server Web, je vous recommand d'utiliser ModSecurity à la place.

Ubuntu dispose d'un package dans le repos pour ModSecurity, mais son core setet (CRS) est obsolète. Je recommand donc de le download ici .

Ce qui nous conduit vers un trou de lapin: ModSecurity n'est pas si facile à configurer pour les novices. Je l'ai fait plusieurs fois, mais même lorsqu'il fonctionne, il y a des problèmes dont vous devez être conscient. Comme le fait que, depuis ModSecurity, fonctionne de manière heuristique et surveille le trafic Web, les comportements parfois attendus sur votre server web seront bloqués en raison d'un "faux positif".

Ce qui est tout à dire, vous pourriez être dans un scénario où vous n'avez vraiment pas à vous soucier de rien. Les servers Web – et tous les servers – sont scannés en permanence. En fonction de ce que vous faites avec ce server, la meilleure et la plus grande security est de vous assurer que vos applications frontales sont sécurisées. Et si vous codiez votre propre base de code PHP, vous pouvez être très sûr que vous êtes en security.

Si vous utilisez un logiciel gratuit comme WordPress ou Joomla !, mon meilleur conseil est de le faire: Placez simplement les passwords d'autorisation Web d'Apache sur les URL et les paths d'access de l'administration pour votre CMS. Sérieusement, c'est l'une des meilleures mesures de security. Les scripts qui sondent les sites searchnt généralement des défauts dans le encoding (PHP, Perl, Ruby, etc …) mais en plaçant un mot de passe d'autorisation web Apacce en place, vous avez à peu près bloqué un bon morceau de scripts. Le point négatif de cette approche est que vous devez vous callbacker votre mot de passe pour le CMS ainsi que le mot de passe Apache, mais c'est un inconvénient sortingvial par rapport à votre système compromis.