Durée d’exécution de la dernière commande en PowerShell

Durée d'exécution de la dernière commande en PowerShell

Salut à tous, aujourd’hui je vous propose une brève sur la durée d’exécution de la dernière commande en PowerShell. C’est pas violent, mais pas plus tard que cette semaine je me suis retrouvé avec un vieux bout de script PowerShell « un peu moisi » à faire marcher en production et qui mettait plus de 12h à s’exécuter… quelques optimisations évidentes effectuées, j’en était toujours à plus de 8h (i.e ça débordait de mon temps de présence sur place) et j’ai oublié d’inclure dans les logs le temps de début et la fin d’exécution, ce qui fait que quand j’ai fini par réussir avec avoir une exécution qui se terminait en allant au bout, je ne savais pas combien de temps ça avait pris…^^

Il s’avère que PowerShell est toujours aussi sympa et vous conserve pour vous l’historique d’exécution, accessible via la commande Get-History, avec toutes les propriétés liées à l’exécution de chaque commande :

Du coup il m’a suffit de saisir la commande suivante pour récupérer la durée d’exécution de la dernière commande en PowerShell :

(Get-History)[-1].EndExecutionTime - (Get-History)[-1].StartExecutionTime 

Et voir que mon script prenait encore 10h pour s’exécuter. Pour le coup cela me suffisait puisqu’on m’en demandait … Lire la suite

Support TLS 1.3 pour nginx sous Debian 9

TLS 1.3 pour nginx sous Debian 9

Salut à tous, aujourd’hui on va prendre 15 minutes pour ajouter le support de TLS 1.3 pour nginx sous Debian 9 pour geekeries.org. En effet, la nouvelle version de TLS sortie en sortie en aout 2018 commence à faire son chemin et ajouter son support à geekeries.org est parfaitement inutile, pour l’instant, il est donc totalement indispensable de le faire.

TLS1.3 pourquoi ?

TLS1.3 est une nouvelle version du protocole de chiffrement des communications HTTPS. Il s’agit du dernier rejeton de la famille SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3 (par ordre d’apparition). Comme toute nouvelle version d’un logiciel, TLS1.3 apporte des gains de performances, de sécurité et de fonctionnalité (plus de détails ici).

TLS1.3 et nginx

Alors la bonne nouvelle c’est que nginx supporte TLS1.3 depuis sa version 1.13. Il nous suffit donc, en théorie, de rajouter la directive ci-dessous dans le fichier de configuration /etc/nginx/nginx.conf, si vous avez une version ultérieure (et de mettre à jour sinon) :

ssl_protocols TLSv1.3 TLSv1.2;

Pourtant, quand je test cette configuration chez Qualys, on s’aperçoit que le support de TLS 1.3 n’est pas actif. Mais pourquoi donc me direz-vous ?

Simplement parce que nginx n’implémente … Lire la suite

Fail2ban, xmlrpc et nginx – Créer sa règle fail2ban maison

Fail2ban xmlrpc et nginx

Salut à tous, je vous propose un nouveau TP sur fail2ban, xmlrpc & nginx. Ceux qui n’ont pas suivi ou qui débutent avec fail2ban sur WordPress devraient commencer par lire cet article qui fait parfaitement le boulot contre 99% des attaques. Néanmoins, ma supervision Splunk m’a permis de repérer une IP qui arrivait à contourner mes protections en créant des codes d’erreurs 499 sur le serveur web via des requêtes foireuses.

Vu que la fonctionnalité XMLRPC est désactivée sur le site, il y a peu de chance que celui-ci arrive à faire quoi que ce soit. Ce n’est pas une raison pour le laisser faire en saturant le serveur de requêtes inutiles…

Pour ceux qui ont lu mon article sur Splunk et Nginx, la requête Splunk qui m’a permis de générer le graphique pour cet article est la suivante :

index=nginx xmlrpc  | timechart count by src

Fail2ban, xmlrpc et nginx

Pour votre culture, les protections en place ne fonctionnaient pas puisque la requête HTTP en code 499 n’arrivait jamais jusqu’à WordPress qui n’avait donc pas la chance d’écrire une ligne de log sur le sujet. Seul le serveur Web traitait la requête, pour rien donc.

Alors j’aurai pu … Lire la suite

USB Phoning Home : la clé USB qui vole les données

Attaques par clés USB

Salut à tous, bon cela fait un moment que je suis sur ce sujet. Aujourd’hui on va travailler avec l’USBArmory pour créer une clé USB qui vole les données que l’on place dessus à un serveur externe. Bref, une clé USB qui vole vos données. Ce TP illustre bien qu’il est risqué de connecter des clés USB non contrôlées sur un SI d’entreprise, a fortiori, si celui ci est sensible… Ça devrait vous donner des idées sur comment on peut pourrir un SI en piégeant du matériel et contourner une bonne partie des mécanismes de sécurité du réseau au passage.

Il n’existe pas de périphériques “inoffensifs”, et c’est d’autant plus d’actualités avec les Raspberry Pi et les PC USB.

Dans ce TP je vais vous montrer comment implémenter l’USB Devices Phoning home proposé par Willnix en 2016 (papier que je vous recommande le lire avant d’attaquer ce TP). Cette technique est un peu surclassée depuis par le PoisonTap mais elle reste intéressante à réaliser comme TP hardware piégé.

USB Phoning Home : la clé USB qui vole les données que l'on place dessus

Principe

Le principe est celui d’une “attaque hardware” ou un méchant laisse traîner une clé USB(Armory) sur le parking ou bien distribue des clé USB vérolées lors d’une conférence ou d’un … Lire la suite