Beste mede tweakers,
Ik ben bezig met het scripten van een aantal security-checks die regelmatig uitgevoerd moeten worden. Een daarvan is controleren of de kernel gebruik maakt van de Execute Disable of Never Execute functies van de CPU.
Er zijn 1001 websites/fora, inclusief die van Red Hat waar men doodleuk aanraad om een grep als 'protection: active' uit te voeren op de uitvoer van journalctl en/of dmesg of op de messages file. Dat werkt natuurlijk op de meeste machines. . . . . . . . tot de logging geroteerd wordt.
Op mijn CentOS-VM met een uptime van 2 dagen was die melding al uit de journalctl gerold. Ik kon hem nog wel vinden in de messages file en via dmesg. Maar helaas kan ik daar ook niet op vertrouwen aangezien op onze productiesystemen de messages-files maar 3 dagen op het systeem blijven. Bovendien kun je de resultaten van meerdere reboots in die files terug vinden, wat het weer extra complex maakt. Blijft dmesg over... maar ja, eenmaal dmesg --clear uitvoeren en ook die optie is weg.
Dus elke optie die via logging gaat is uitgesloten.
Ook zijn er zat mensen die op internet roepen dat je moet kijken of de NX flag aanwezig is in /proc/cpuinfo. Klinkt mooi aangezien je via /proc rechtstreeks met de kernel communiceert, toch? Maar nee, /proc/cpuinfo is slechts wat de CPU rapporteert. Boot je systeem eens met noexec=off en de NX flag staat daar nog steeds ondanks dat de kernel de NX-functies links laat liggen.
Gezien dit punt bij verschillende hardening-documenten wordt genoemd kan ik mij niet voorstellen dat er geen betere methode is dan de bovenstaande. En ik vraag mij dus af of er een mede-tweaker er in is geslaagd om een waterdichte methode te vinden en hoe die er uit ziet.
Avast bedankt!
Ik ben bezig met het scripten van een aantal security-checks die regelmatig uitgevoerd moeten worden. Een daarvan is controleren of de kernel gebruik maakt van de Execute Disable of Never Execute functies van de CPU.
Er zijn 1001 websites/fora, inclusief die van Red Hat waar men doodleuk aanraad om een grep als 'protection: active' uit te voeren op de uitvoer van journalctl en/of dmesg of op de messages file. Dat werkt natuurlijk op de meeste machines. . . . . . . . tot de logging geroteerd wordt.
Op mijn CentOS-VM met een uptime van 2 dagen was die melding al uit de journalctl gerold. Ik kon hem nog wel vinden in de messages file en via dmesg. Maar helaas kan ik daar ook niet op vertrouwen aangezien op onze productiesystemen de messages-files maar 3 dagen op het systeem blijven. Bovendien kun je de resultaten van meerdere reboots in die files terug vinden, wat het weer extra complex maakt. Blijft dmesg over... maar ja, eenmaal dmesg --clear uitvoeren en ook die optie is weg.
Dus elke optie die via logging gaat is uitgesloten.
Ook zijn er zat mensen die op internet roepen dat je moet kijken of de NX flag aanwezig is in /proc/cpuinfo. Klinkt mooi aangezien je via /proc rechtstreeks met de kernel communiceert, toch? Maar nee, /proc/cpuinfo is slechts wat de CPU rapporteert. Boot je systeem eens met noexec=off en de NX flag staat daar nog steeds ondanks dat de kernel de NX-functies links laat liggen.
Gezien dit punt bij verschillende hardening-documenten wordt genoemd kan ik mij niet voorstellen dat er geen betere methode is dan de bovenstaande. En ik vraag mij dus af of er een mede-tweaker er in is geslaagd om een waterdichte methode te vinden en hoe die er uit ziet.
Avast bedankt!