HomeErvaringVaardighedenProjectenBlogContact
Alle artikelen

Meer grip op je server

Als je lang genoeg met servers werkt, ga je vanzelf tooling verzamelen die het leven makkelijker maakt. Voor mij waren dat jarenlang Webmin en Virtualmin. Niet omdat het niet anders kon, maar omdat het gewoon efficiënt is: minder nadenken over randzaken en meer focus op wat je daadwerkelijk wilt draaien.

Toch zit daar ook een keerzijde aan. Hoe meer er voor je geregeld wordt, hoe minder je nog ziet van wat er daadwerkelijk gebeurt. En ergens begon dat te wringen. Niet omdat het niet werkte, maar juist omdat het te soepel ging.

Dus deze keer besloot ik het anders te doen. Gewoon weer zelf. Configuraties schrijven, keuzes maken, dingen stuk maken en daarna uitzoeken waarom.

De basis blijft de basis ​

Zoals altijd begin je met de bekende dingen: SSH dichtzetten, keys gebruiken en Fail2Ban installeren. Dat is niet spannend, maar wel nodig. Een simpele jail voor SSH ziet er bijvoorbeeld zo uit:

ini
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600

Daar kijk je daarna eigenlijk niet meer naar om. Tot je je logs opent.

Wat er echt gebeurt ​

Op een gegeven moment ging ik wat beter naar mijn Apache logs kijken, gewoon uit interesse. Dan zie je ineens hoeveel rommel er langskomt. Requests naar /phpmyadmin, /wp-login.php, .env files en oude exploits. Het is niet gericht en niet bijzonder slim, maar het stopt ook niet.

Het lastige is dat er technisch niets mis is met die requests. Het zijn gewoon geldige HTTP calls, dus Fail2Ban doet hier niets mee. En dat is het punt waarop je je realiseert dat "het werkt" niet hetzelfde is als "het is oké".

ModSecurity ertussen ​

Daarom ben ik ModSecurity gaan gebruiken, niet als vervanging maar als extra laag. In Apache is de basis vrij simpel:

apache
<IfModule security2_module>
    SecRuleEngine On
    SecRequestBodyAccess On

    SecAuditEngine RelevantOnly
    SecAuditLog /var/log/apache2/modsec_audit.log

    IncludeOptional /etc/modsecurity/crs/crs-setup.conf
    IncludeOptional /etc/modsecurity/crs/rules/*.conf
</IfModule>

Met de OWASP ruleset erbij begint het meteen iets te doen. Requests die eerst gewoon door Apache heen gingen en een 404 kregen, worden nu tegengehouden. Denk aan SQL injection pogingen, rare headers en bekende paden die misbruikt worden. Je applicatie ziet ze niet eens meer, en je logs worden een stuk duidelijker.

De standaard rules zijn wel vrij streng. Dat merk je vooral als je zelf iets bouwt of een API hebt. Soms moet je iets uitschakelen:

apache
SecRuleRemoveById 941100

Of alleen voor een specifiek pad:

apache
<Location "/api/">
    SecRuleRemoveById 942100
</Location>

Niet ingewikkeld, maar wel iets om rekening mee te houden.

En als er toch iets doorheen komt ​

Tot hier zit alles aan de voorkant en probeer je slechte requests buiten te houden. Dat werkt goed, maar zegt niets over wat er gebeurt als iets wel lukt of via een andere weg binnenkomt. Daarom heb ik AIDE toegevoegd.

AIDE ​

AIDE kijkt niet naar verkeer, maar naar je systeem zelf. Het maakt een snapshot en vergelijkt die later. Eerst initialiseren:

bash
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Daarna kun je controleren:

bash
aide --check

In de config geef je aan wat belangrijk is:

text
/bin    NORMAL
/sbin   NORMAL
/etc    NORMAL

Het is vrij saai spul, tot er iets verandert wat je niet verwacht.

Alles bij elkaar ​

Wat je uiteindelijk hebt is geen enkele oplossing, maar een combinatie. Fail2Ban pakt duidelijk misbruik aan, ModSecurity filtert requests voordat ze iets doen en AIDE controleert of je systeem nog klopt. Op zichzelf stelt het weinig voor, maar samen geeft het gewoon meer grip.

Tot slot ​

Het grootste verschil zit niet eens in de tools, maar in wat je ziet. Zodra je je logs serieus neemt, verandert je beeld vanzelf. Meestal is dat ook het moment waarop je net wat meer gaat doen dan alleen denken dat het wel goed zit.