16 maart 2006

Passwords voor zeus gaan verlopen

De password voor zeus gaan verlopen. Ik weet zo snel niet meer hoe ik een langere geldigheid moet instellen dus ik weet alleen nog hoe je ze moet wijzigen (op de server) via putty inloggen met je naam op zeus en dan 

smbpasswd
.

Posted by marko at 01:51 am | Comments (0)

06 maart 2006

Persistente ssh port forwarding tunnel

Als de verbinding tussen bytemark en zeus wegvalt dan moet er altijd handwerk aan te pas komen om de systemen weer up te krijgen. in vtunnel heb je een handige persistent optie, maar ik wil geen vtunnel gebruiken. Ik ga niet een hele host in mijn netwerk opnemen voor alleen MySQL toegang. ssh kent die optie niet. Dus ik heb een wrapper /root/pTunnel3306 geschreven die nu op bytemark (www) automatisch gestart zou moeten worden in /etc/rc.local.



[root@www root]# cat /root/pTunnel3306.sh

#!/bin/sh



while [ 1 ]

do

    ssh -nNTR 3306:localhost:3306 bytemark@zeus.brains4all.com

done

Zoals je ziet nogal bruut, maar netwerk timeouts zullen hopelijk zorgen dat het niet de mist in loopt hoop ik. Let op met killen, want als je nu ssh killed wordt hij meteen weer gestart. Eerst pTunnel3306 killen op www.
Deze tunnel is een Remote variant in dat hij van de remote host, dus de ontvangende host wordt gestart ssh -R en hij owrdt dus gestart vanaf bytemark, terwijl de oude tunnels vanaf zeus gestart werden. Reden hiervoor is simpelweg omdat authenticatie al was ingericht op (www). The simplest thing that could possibly work.

Posted by marko at 12:04 am | Comments (0)

31 mei 2005

Logwatch voor www.brains4all.com

Om ongewenste elementen buiten de deur te houden op onze www-server bij Bytemark, draait daar vanaf nu een Swatch (Simple WATCHdog) scriptje. Het script houdt in de gaten of er mensen proberen in te loggen via SSH met vreemde loginnamen of ongeldige wachtwoorden.
Als zo'n inbraak poging ontdekt wordt, dan wordt het ip adres geblocked door de firewall en kunnen ze het dus niet nogmaals proberen.

De volgende ip adressen staan op de safelist (om ervoor te zorgen dat we onszelf niet buitensluiten):
127.0.0.1 (localhost)
80.68.89.8 (www.brains4all.com)
212.115.196.129 (zeus.brains4all.com)
212.92.75.67 (bart @ home)
82.176.64.17 (marko @ home)

De script-, config- en logfiles zijn te vinden in /root/logwatch/.
Het aan- en uizetscript staat in /etc/rc.d/init.d/swatchrc.
Als de server opstart, dan wordt het swatchscript gestart (vanuit /etc/rc.local) en de nieuwste iptables file wordt geladen (na elke blokkering wordt deze weggeschreven in /root/logwatch/iptables.saved).
Bij een blokkering wordt er een mailtje gestuurd naar sysop@brains4all.com.

Voor de geinteresseerden: een soortgelijk scriptje draaide al langer op zeus.brains4all.com (en bij Marko en Bart thuis :-)

Posted by bart at 11:34 am | Comments (0)

05 april 2005

More security

Goh, wat moet je toch goed nadenken over de beveiliging van je systemen. Zo vaak als er aan de deur geklopt wordt op de server, dat had ik niet verwacht. Er draait dus nu een minimaal aantal services aan de externe kant van de server, en dat willen we graag zo houden. Daarom zullen we in veel gevallen moeten kiezen voor tunneling over ssh. Des te belangrijker wordt de beveiliging van ssh. Maar ook de beveiliging van je data zelf. Denk dus ff heel goed na als je van plan bent om een bestandje de rechten 777 of 666 te geven, dat is zelden nodig.
We moeten ook gaan kijken naar de beveiliging van onze andere systemen zoals onze PCs op het werk, maar ook thuis, en de server bij Bytemark.

Posted by marko at 12:50 am | Comments (0)

01 april 2005

Als de server gereboot wordt

Gisteren moest voor de inrichting van de patchkast de server even down. Daarna draaide alles natuurlijk niet meer zoals het deed. Ik heb wel alle services opnieuw ingericht met chkconfig, ook de swatchrc init.d script heb ik hieraan toegevoegd (chkconfig --add ...)
Wat ik natuurlijk vergeten was, dat boefjes wiens ip geblocked werd door de firewall nadat ze zicht misdragen hadden, uit de firewall verdwenen waren nadat de server restart. Ik moet dus op een scriptje schrijven wat de regels ook aan de default firewall configuration toevoegd /etc/sysconfig/iptables of ik moet de redhat iptables-save scripts aanroepen nadat ik een ullie gebanned heb.

Posted by marko at 12:26 am | Comments (0)

31 maart 2005

Swatch trouble

Vandaag heb ik flink wat ellende gehad met swatch. http://swatch.sourceforge.net/ De zogenaamde logwatcher die ook acties kan ondernemen op bepaalde events in de logfiles, zoals brute-force password attacks. Eergisteren hadden we er zo eentje. Meer dan 1200 keer werd er geprobeert op onze server in te loggen van hetzelfde ip-adres. Tegenhouden kun je het niet, of je moet alle toegang blokkeren en alleen vertrouwede ip-adressen toelaten. Dan is echter het concept "on-line" wel ver te zoeken. Als je eens ergens anders bent dan thuis, kun je niet bij de server.
De oplossing die ik zocht is er één die het midden houd tussen beiden, na 1 keer verkeerd inloggen vanaf een vreemd ip wordt de "boef" direct geblokkeerd in de firewall met een DROP regel. Dat vertraagd ook nog een beetje. In ieder geval mer dan een DENY, want dan heeft je attacker meteen door dat wij hem in de gaten hebben.
Na wat nachtwerk staat er nu dus een rhel4 swatch package op met een swatchrc script in /etc/init.d/swatchrc (start|stop|restart|enz), er draait een cronjob om het roteren van de logfiles op te vangen (swatch werkt met tail), en er is een beta test scriptje in /root/banner.pl die door swatch aangeroepen wordt als er iemand verkeerd inlogd. In /root/banfile.conf staan de tot nu toe gebande ip adressen, in /root/safe.conf staan de ip adressen die we vertrouwen en die er dus wel altijd doormogen. Deze worden dus niet gedropped.
Probleem met swatch is dus dat de documentatie en dus ook de man page absoluut niet overeenkomen met de werkelijke werking van het script. De enige manier om achter de werking te komen is door echt naar het script te kijken.

TODO

- Werking controleren en in versiebeheer en productie nemen
- Dekking uitbreiden van sshd.* in /var/log/messages naar andere vunzigheden
- IPtable-rules statefull maken
- Script ook thuis deployen... :)

Posted by marko at 03:54 am | Comments (0)