Interception/déchiffrement du TLS 1.3

Posté le de — 4 commentaires ↓

Bonjour à tous, Il n’y a pas longtemps, on m’a demandé pourquoi faire de l’interception/déchiffrement du TLS 1.3, ça pouvait être « compliqué » comme je le disais. J’avais en tête le truc dans les grandes lignes avec en particulier le fait que le SNI passait désormais dans le handdshake chiffré par TLS, rendant plus compliqué l’interception des clés des certificats associés à la communication.

C’était un peu léger comme explication, je me basais surtout sur mes expériences avec TLS la lecture de ce papier de Symantec/Broacom sur le sujet. Néanmoins c’était une vue très bas niveau du sujet. Puis en commençant mes recherches pour vous écrire un article sur le sujet, je suis tombé sur cet article de Vladimir Kolla :

TLS 1.3, ESNI, DoH, interception… ce n’est pas si compliqué 😉

https://greenlock.ghost.io/tls-1-3/

Et puis je me suis dis qu’il y avait pas grand chose à dire de plus en fait là…

Son article est juste nickel, s’il était en Creative Commons, je vous l’aurais bien remis « as-it » sur mon blog mais bon tant pis, je me contenterai de la ref. Du coup son post fait aussi référence au No Limit Secu sur TLS 1.3, qui … Lire la suite

The percentage of small buckets… – Splunk

Posté le de — 2 commentaires ↓

Bonjour à tous, aujourd’hui je vous partage un bug que j’ai rencontré avec un instance Splunk il y a quelques temps de ça. L’erreur en question était celle-ci : « The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index« . J’ai mis un moment à la détricoter.

The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Après quelques recherches (ici, là), j’ai fini par identifier la root-cause : des logs sui arriveraient avec « trop de retard » par rapport à leur date réelle d’émission. Ce délai forcait Splunk, qui range les données dans les Bucket de manière temporellement ordonnée, à recréer des bucket pour ces évènements car ceux correspondant à cette plage temporelle avaient été fermés.

A la recherche des logs pétés

A partir de mon erreur, je me lance donc dans le SPL ci-dessous et effectivement j’ai bien une des sources de logs qui arrivent avec des latences pas normales.

index=<monindex>
| eval latency=_indextime-_time
| stats min(latency),
max(latency),
avg(latency),
median(latency)
by index sourcetype host
| sort - "avg(latency)"
The percentage of small buckets (40%) created over the last hour is high and exceeded the yellow thresholds (30%) for index

Du coup j’ai gratté un peu sur l’hôte en question et il s’avère qu’on a régulièrement des grosses latence à l’indexation, à … Lire la suite

Application Compatibility – Forensgeek

Posté le de — Aucun commentaire ↓
Forensics

Bonjour à tous, pour changer on continue la série sur la forensics. Aujourd’hui je vais vous parler du ShimCache (dit aussi AppCompatCache, c’est la même chose), mais aussi du RecentFileCache et l’AMcache. Que l’on regroupe sous l’appelation Application Compatibility.

C’est quoi l’Application Compatibility de Windows ?

Alors l’Application Compatibility Cache, comme son nom l’indique, s’occupe d’assurer la rétrocompatibilité des applications prévus pour d’anciennes versions de Windows avec le système courant. Finalement, on y regroupe plusieurs éléments quand on parle forensics.

Le ShimCache (ou AppCompatCache)

D’abord de ShimCache, c’est un vieux truc qui date de Windows 95 ! Et dont le but initiale est surtout d’aider au débug pour les dev. Dedans, vous allez trouver plein d’informations relatives aux exécutions des programmes et qui peuvent varier un peu selon les versions de Windows. Vous trouverez notamment dans ce cache :

  • Le chemin complet de l’exécutable ;
  • La taille du fichier ;
  • Les date de dernière modification et d’exécution.
  • Si le programme a effectivement a lancé (mais pas trop loin hein).

RecentFileCache et AMcache

Le RecentFileCache est apparu avec Windows 2003 SP1 et le service « Windows Application Expérience Service Lookup ». Ce dernier a pour but de … Lire la suite

Rsyslog too many open files

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui je voulais vous partager une erreur que j’ai rencontrée récemment avec une infra Splunk, plus exactement avec la couche de collecte Rsyslog (vous savez celle que je recommande dans mon podcast sur les 10 commandements du SIEM). Cette erreur qu’on a fini par identifier dans les journaux avec le message suivant « rsyslog too many open files » et plus précisément la ligne suivante :

May 06 05:47:13 myserver rsyslogd[6896]: file '/splunk-inputs/PROXY/myproxyhost/2022-05-06T03+02-PROD-PROXY.log': open error: Too many open files [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2433 ]

Le log d’erreur arrive dans /var/log/message à priori. Néanmoins, de mon côté on ne l’a vu que depuis la commande journalctl, quelques exemples qui m’ont permis de la mettre en avant :

journalctl --no-pager | tail -f
journalctl -u rsyslog
journalctl --no-pager > /tmp/rsyslogtmp.log

Par défaut, la limite pour rsyslog était à 1024 fichiers ouverts simultanément sur notre système. Pas bien clair sur le pourquoi car les limites systèmes (cf. fichier /etc/security/limits.conf) été bien à 64000 :

ulimit -Sn
64000

Pour autant notre processus rsyslog plafonné à 1024 fichiers. Ce qui causait une erreur bien zarb où on perdait 15min de log au début de chaque heure. Du coup, avec l’aide … Lire la suite