Archives pour l'étiquette apache

Certificat letsencrypt installation et renouvellement

Hello,
Suite à ma réinstallation, j’ai pu jouer un peu avec letsencrypt, et les outils de génération, installation et renouvellement de certificats sont tous simplement génial d’un point de vue administrateur système …

Tout est automatisé, on lance une ligne de commande, et l’on a son certificat, ainsi que la possibilité de les renouveller sans même avoir à y penser (plus besoin tout les x ans de renouveller ces certificats, avec le risque de les oublier et de se retrouver devant le fait accompli et de devoir mettre à jour les certificats à l’arrache …).

Continuer la lecture de Certificat letsencrypt installation et renouvellement

Sécurité en Vidéo … le fail du LoupZeur

Plop à tous …

Histoire de passer moins de temps à bloguer (déjà que je n’écrit plus grand chose), je me suis dit que faire des vidéos serait plus facile, on tourne le truc, on upload et basta …
L’idée était de faire un truc assez complet sur « comment sécuriser un site web » avec pas mal d’outils libres/gratuits (iptables, apache, modsecurity, ossec, tomoyo, …).

La vidéo d’intro c’est plutot bien passé, 5 minutes sans coupure, un son pas trop moche, un upload rapide …

La première vidéo parlant de la sécurité apache et modsecurity à été plus laborieuse … 45 minutes de « tournage », le micro branché sur la jack de sortie (donc c’est le micro interne de l’ordi qui a enregistré le son….), énorme décalage son/vidéo, 1 heure d’upload :/, un bon fail de 10 minutes sur une regexp …

J’essaierai de voir comment ça se passe dans les prochaines vidéos mais au final, écrire un article reste plus simple ^^, je suis pas sur de terminer la « série », mais ça reste intéressant de découvrir les difficultés propres à ce domaine, entre l’encodage de la vidéo, de l’audio, la synchro, le conteneur, … j’ai appris pas mal de chose, au pire je tenterai un upload live via rtmp avec ffmpeg sur youtube histoire de rire.

Voilà, amusez vous bien 😉

Améliorer les performances d’apache avec nginx

Plop à tous …

Comme vous l’aurez sûrement remarqué, la quasi-totalité de mes derniers articles sont tirés d’expériences (plutôt foireuses) me poussant souvent à remettre en questions certaines notions que je pensais acquises … cet article n’y coupera pas :s.

Après avoir vénéré les serveurs apache pendant 7 ans, j’ai eu récemment à m’asseoir sur mes convictions et à installer nginx pour avoir des performances convenables …

Note du 2016/02/20 : L’erreur a été d’installer apache en mod_prefork sur un environnement demandant de grosse perf, en utilisant un mpm_event avec un fcgi, ça marche très bien.
Continuer la lecture de Améliorer les performances d’apache avec nginx

Configuration de processus apache au poil …

salut à tous …

Aujourd’hui on va parler configuration de processus apache … J’ai eu l’occasion en 3-4 jours de connaitre des problèmes sur plusieurs serveurs différents liée à une surconsommation de mémoire due à apache et à sa gestion des processus faisant littéralement planter mon blog (ça swap mal un RPS! donc 2 crash de la machine en 24 heures … avec les nouveaux prix des serveurs dédiés de chez online.net … je risque probablement de migrer prochainement ;)).

Note 2016-02-20 : Cet article est à jeter … on NE PEUT PAS UTILISER un mpm_prefork en PROD !!! le prefork c’est pour du debug/dev sur apache, même pour du dev php, il faut préférer un mpm_event avec un fcgi.

je garde néanmoins cet article (histoire de me rappeler que l’on fait tous des erreurs ;)).

Continuer la lecture de Configuration de processus apache au poil …

Partage et ecriture de fichiers sur protocole HTTP

Bijour,

Encore un truc inutile mais assez intéressant ^^. Tout le monde connait le protocole HTTP pour télécharger des pages web, voir des fichiers, mais on peut aussi écrire des fichiers sur le protocole HTTP via webDAV (supporté de base par windows … si c’est pas la classe ^^).

Bon bien sûr, il existe d’autre protocoles pour partager des fichiers (ftp, p2p, smb), mais webDAV a ses avantages :

  • Gestion de la concurrence des accès (plusieurs personnes ne pourront pas modifier le même fichier).
  • Possibilité d’utiliser des certificats SSL pour chiffrer les transferts (super utile!!).
  • Rapide et sécurisé (ça tourne sur un serveur apache) et ça permet d’éviter d’avoir d’autre ports ouvert sur sa machine (genre ftp, …).

Niveau configuration, y’a pas grand chose à faire, il suffit de mettre les lignes suivantes dans un fichier de conf d’apache :

    Alias /kikoosfiles /dossier/a/partager/
    
            Dav On
            AuthType Basic
            AuthName "Restricted Files"
            AuthUserFile /etc/apache2/paccess.htpasswd
            Require valid-user
   

Il faut juste créer le htpasswd :

htpasswd -c /etc/apache2/paccess.htpasswd votreLogin

On peut ensuite tester l’accès :

Sous linux :

webdavSous windows, il suffit d’ouvrir l’url comme dossier web (Alt+O) en donnant l’url.

Bien sûr, si vous avez le modsecurity, vos logs vont se remplir de pas mal de chose, il faut donc désactiver certaines vérifications faites par le modsecurity, ce qui donne la configuration suivante :

    Alias /kikoosfiles /dossier/a/partager/
    
            Dav On
            AuthType Basic
            AuthName "Restricted Files"
            AuthUserFile /etc/apache2/paccess.htpasswd
            Require valid-user
            SecRuleRemoveByMsg "Invalid HTTP Request Line"
            SecRuleRemoveByMsg "Method is not allowed by policy"
            SecRuleRemoveByMsg "Request Missing an Accept Header"
            SecRuleRemoveByMsg "HTTP header is restricted by policy"
   

Si vous avez un certificat ssl, vous saurez facilement comment le mettre en place pour chiffrer la connexion. Et hop, une connexion chiffrée sur http :

dav-ssl

Open-Source : Réseau d’entreprise sécurisé … ou pas

Bijour …

Alors voilà, maintenant que la présentation de notre projet pour ma licence pro CDED est terminée, je peux montrer l’architecture de notre réseau sans avoir peur d’être plagié par des concurrents ^^.

Donc le but de notre réseau est d’avoir :

  • Une sécurité assez élevée sans pour autant compromettre l’utilisation du réseau par les utilisateurs (le problème de tout admin …).
  • Un coût très faible autant niveau architecture logicielle que matérielle
  • Une maintenance aisée du réseau (ajout/suppression de postes/utilisateurs)

Le contexte de notre projet :

Une petite entreprise veut revoir son réseau et ses logiciels/sites web pour plus de productivité, avec pas mal d’intéractions avec l’extérieur (Obligation d’utiliser une base de données extérieur au réseau, plusieurs site web publié avec utilisation de certificats pour le chiffrement (pour l’authentification ça aurait été un peu trop :p), …).

Ce qui a donné le réseau suivant pour notre groupe :

Network-Skipify-final-cipher

L’architecture est plus ou moins classique, on sépare les serveurs des utilisateurs, côté chiffrement :

  • Toute communication est chiffrée entre les serveurs (3DES en phase 1 et AES en phase 2) on a poussé le vice jusqu’à chiffrer les communication avec les clients Linux du réseau (bien sûr toute communication non chiffrée sur le réseau des serveurs est automatiquement rejetée).
  • Les communications vers la base de données sont chiffrés par un tunnel (ssh avec une simple redirection de ports).
  • Les communications depuis les internautes sont chiffrés par un certificat valide en AES

Coté architecture matérielle :

  • 4 serveurs sous debian 5.0 patché avec GrSecurity pour les ACL et le W^X (ma licence étant spé développement, on a pas pu pousser la chose très loin … dommage, ce patch me semble très prometteur, et devrait devenir une norme dans le domaine de l’hébergement).
  • 1 client XP ajouté au domaine NT (utilisation du remote announce de samba pour l’utilisation du PDC hors du réseau sécurisé des serveurs), ainsi qu’un client linux avec authentification direct à l’annuaire LDAP

Coté architecture logicielle :

  • Sur le reverse proxy / Firewall :
    • Apache2 avec modsecurity couplé avec l’IDS, modevasive (pour les bruteforces et DoS de faible ampleur), mod proxy pour la mise en place d’un reverse proxy pour protéger le serveur web
    • IDS Prelude couplé avec Snort
    • Utilisation d’arpwatch pour les attaques en interne (un script kidy qui réussit à pirater le wifi, la connexion d’un employé au réseau local via son IPhone ;), ….)
    • Fail2Ban pour les bruteforces sur le service SSH
    • IPTable comme firewall
  • Sur le serveur WWW et d’appli : apache2 avec le mod rails pour les applis web en ruby (déploiement et màj des applis simplifié par capistrano …)
  • sur le PDC un serveur Samba avec OpenLDAP

Et hop … on obtient un réseau pas mal sécurisé et gratuit (faut juste payer l’informaticien ;)).

Par contre, en discutant avec les profs après déploiement de l’architecture sur 8 machines virtuelles (vmware … le proprio saymal mais bon), on s’est rendu compte de quelques problèmes (et ouai … je suis encore un élève ;)) :

  • Comme un noob j’avais laissé la configuration IPv6, toute la partie IPsec que j’avais déployée etait alors totalement inutile puisque centré sur l’IPv4 seulement, heureusement, j’avais fait des bind explicite sur les adresses IPv4, seul les serveurs http et dns était accessible en IPv6.
  • Sinon, le problème propre au déploiement sur machines virtuelles (comme un noob encore une fois), déploiement de toutes les machines en bridge sur le réseau de l’IUT (l’admin réseau ne m’a pas vu … mais un autre groupe s’est fait gaulé ^^). N’importe qui aurait pu se connecter sur notre réseau en connaissant nos ip. A ma décharge je dirais deux choses : je savais pas qu’en host-only c’est pas seulement l’hote et la mv, mais l’hote et toutes les mv qui peuvent discuter ensemble, ce qui ne corrige en rien le problème des connexions direct sur notre réseau depuis d’autre machines virtuelles, puisque tout les groupes ont montés leurs réseau sur la même machine

Donc voilà … un petit retour sur l’utilisation de l’open-source pour la sécurité et le déploiement d’un réseau entièrement gratuit, qui se rapproche plus d’une multi-national (bien qu’encore très très très loin) que du réseau familial … qui malheureusement est encore présent dans beaucoups d’entreprises en france (et même des grosses boites … pour qui la sécurité consiste à placer des filtres extrèmement lourd sur leurs proxy et mettre à jour des AV …).

Quelques Dénis de services Sympa ou pas

Bijour à vous en ce dimanche ensoleillé (en Alsace ^^).

Petite note : Vous seul êtes responsable de vos actes (de toutes façon, la plupart de ces commandes exécutées par une seule machine ne peuvent plus venir à bout d’un serveur (ou d’une machine quoique …) … donc n’imaginez pas pouvoir planter le serveur de votre petite copine avec les commandes fournit dans l’article … mieux vaut la corriger autrement …)

Voilà mon premier article un peu orienté attaque de l’année (après plein de truc inutile sur comment fortifier son serveur sauce juvamine), ça fait suite à l’attaque qu’a subit korben, et je suis tombé (par hasard!! ça arrive si si je vous jure) sur un vieux numéro de MISC (le numéro 19 de mai-juin 2005 qui était très intéressant … leurs articles sont toujours très intéressant d’ailleurs), qui analysait diverses méthodes de dénis de services.

Donc voici le petit résumé des commandes sympa du mag en question : (Oui dites-le, je ne suis qu’un copieur … et alors ?! J’ai aussi rajouté quelques trucs trouvés sur le net histoire de me faire pardonner ou pas)

  • SynFloods :
    • L’une des attaques les plus simpliste : on balance un paquet TCP avec un syn et on arrête là (donc pas de syn-ack a réceptionner et donc de ack a envoyer, le serveur attendra une réponse qui ne viendra jamais), ce qui peut à termes bouffer pas mal de ressource côté serveur
    • La commande en mode « normal » : hping3 –syn -M 123456 -L 0 -p 80 <ip> –flood
    • Paquets générés : syn-flood-normal On remarque que les paquets ont tous la même tronche (même adresse source et destination) sympa pour se faire choper ^^
    • La commande en random source : hping3 –syn -M 123456 -L 0 -p 80 <ip> –flood –rand-source
    • Paquets générés : syn-flood-randomOn remarque que les ips sources changent … comme c’est direct écrit dans le paquet tcp, y’a de grande chance de ne pas se faire choper … à part si le FAI le détecte ^^.
  • Syn-Ack Floods
    • Un autre type d’attaque sympa, on balance un syn-ack au serveur, le serveur n’ayant pas de ack associé va renvoyer un rst et là … owned, on peut donc par exemple, flooder un serveur en lui envoyant les syn-ack avec comme ip source un autre serveur, et c’est le premier serveur qui enverra les rst au second serveur … on attaque une machine et ce sont deux machines qui trinquent !! Par contre ici, la consommation de mémoire est moindre à cause de l’envoi du rst. A noter que sur une attaque de grande ampleur, en randomisant/incrémentant les numéros de séquence on peut (peut-être) couper des connexions existante (faut soit avoir du bol, soit avoir pas mal de machines sous la main ;))
    • La commande : hping3 -SA -M 123456 -L 0 -p 80 –flood –rand-source
    • Paquets générés : syn-ackOn remarque le flag syn/ack, et toujours l’ip source spoofé (l’ip de destination est mon serveur … et je m’autorise à me flooder ^^)
  • Le sapin de noël TCP
    • Ici, un envoi de paquets avec un numéro de séquence nul
    • La commande : sudo hping3 -SAFRU -M 0 -L 0 -p 80 –flood
    • Paquets générés : safru-modeOn remarque les flags FIN/SYN/RST/ACK/URG qui sont set … j’ai oublié de prendre le numéro de séquence en screen, mais bon …
  • Le trou noir de niveau 2!! (ARP)
    • Ici, c’est l’attaque d’un sous-réseaux, l’attaque parfaitement inutile … on balance ettercap pour détourner les paquets en local vers sa machine … et on oubli comme un noob le forwarding des paquets … et plus d’accès au net … cela dit, faire passer sa machine pour la passerelle et rediriger le traffic pour choper des pass semble plus intelligent …
    • La commande : cf. l’un de mes articles sur ettercap en omettant le forwarding
  • Le trou noir de niveau 3 (IP)
    • Ici ba c’est pareil que le niveau 2 … aussi naze, sauf que c’est au niveau au-dessus, au lieu de rediriger vers une MAC qui bloque le traffic on envoi le traffic sur une ip inexistante ou non-configuré comme gateway
    • La commande : sing -red -S <ip gateway> -gw <ip nouveau gateway> -dest 0.0.0.0 (le net quoi) -x net <ip victime>
    • Exemple avec captures du paquet : sing -red -S 192.168.0.1 -gw 192.168.0.13 -dest 0.0.0.0 -x net 192.168.0.11
      192.168.0.1 est ma passerelle de base, 192.168.0.13 est la machine qui va servir de nouvelle passerelle qui prendra le traffic à destination de 0.0.0.0 (le net quoi) -x net 192.168.0.11 qui est ma machine « victime »
      icmp-redirectA noter qu’encore une fois … le paquet est entièrement forgé, donc si vous ne mettez pas votre ip dedans … ben elle y sera pas ^^, donc on remarque les différents champs du paquet ICMP source/destination et adresse du nouveau gateway, …
    • On peut aussi faire cette attaque sur un DHCP (genre on le descend avec maraveDHCP encore un DoS!! … un DoS pour faire un autre DoS futé :p) puis on utilise irdp de façon similaire à la commande précédente : irdp -i eth0 -S 192.168.0.13 -D 192.168.0.11 (quand même plus court que l’autre commande ^^).
  • Les attaques sur les sessions
    • Ici, le but est d’ouvrir une session sans la fermer, donc on suit le cheminement SYN/SYN-ACK/ACK et plus rien, sachant que la config par défaut des serveurs est d’avoir genre 150-200 clients simultannés au maximum, ouvrir autant de session rendra le serveur aphone ou le fera pas mal lagguer
    • La commande pour un service apache : webdevil <ip-serveur> 80 <nb session> (je l’ai fait sur localhost cette fois … j’ai pas envie de tester sur mon serveur ^^)flood-apache
      On voit les paquets syn, syn-ack et ack … et plus rien (j’ai pas pris la suite dans le screen parce que y’avait plein de dup … allez savoir pourquoi ;))
    • A noter que webdevil est vraiment orienté bad … l’auteur a même prévu un ensemble d’outil pour lancer des attaques distribuées (suffit de remplir le fichier slaveservers.txt encore un truc de SM … de lancer le webdevild sur les machines esclaves et le devilmaster sur le maitre^^ si c’est pas méchant)
  • Flood sur le service DNS
    • Encore une attaque sympa avec un outils sympa … toujours et encore sur packetstorms … qui permet de flooder un serveur DNS … encore mieux ^^
    • La commande : dnsflood <ip serveur> (j’ai pas fait de capture … too lazy)
  • Flooder un routeur Wifi avec mdk3

Je rajouterai encore des trucs prochainement … ou pas (si j’arrive à déchiffrer le PDF plus bas :p), si ça vous a intéressé, lisez donc le numéro 19 de MISC (vous serez surement surpris de voir le nombre de truc que j’ai pas encore copié de l’article en question 😉 j’ai quand même pris des screenshots :p c’est du boulot, bon je m’enfonce j’arrête là … bon apétit).

Quelques liens :

  • Une doc, (j’ai pas réussi à le lire … probleme de police sa TimeNewsRoman est planté, j’ai juste réussi à lire les titres ^^) sur les attaques DOS, moi qui pensait avoir honteusement pompé sur MISC (ce PDF parle d’autre attaque DoS en plus de ceux présenté ici … faut dire, y’a pas mal de technique possible avec d’autre logiciels et d’autre config), sinon, le site de l’auteur est sympa.
  • Sinon, y’a google qui donne toujours de très bon liens 😉