Ik heb enkel ervaring met fail2ban en denyhost Het voordeel van fail2ban vond ik de geoip logging. Maar alles doet ze werk zoals het moet doen. Ik denk dat je moet kijken wat geschikt is voor jou situatie

Ik heb alleen ervaring met SSHGuard, net als bij de Anoniem (10:15) hierboven doet het wat het moet doen.

Waarom probeer je ze niet gewoon en kijk je welke JIJ het prettigst vind?

Ik gebruik fail2ban. Werkt in principe out of the box. Wat meer configureer werkt gaat er inzitten om het ECHT goed te doen...

Misschien moet je hier eens naar kijken
http://www.fail2ban.org/wiki/index.php/HOWTOs

Ik host op een unmanaged dedicated server een social network dat goed beveiligd moet zijn omdat er in korte tijd duizenden mensen zich hebben ingeschreven en ik niet wil dat mijn database of content via een SQL-injectie, brute force of andere methode op straat komen te liggen aangezien dit een soort hype is aan het worden onder hackers en scriptkiddies.

Ik krijg in mijn logs een waslijst van aanvallen zoals:

--------------------- httpd Begin ------------------------

400 Bad Request
/: 6 Time(s)
/w00tw00t.at.ISC.SANS.DFind:): 7 Time(s)
/w00tw00t.at.ISC.SANS.test0:): 4 Time(s)
404 Not Found
//admin/index.php: 1 Time(s)
//admin/phpmyadmin/index.php: 1 Time(s)
//admin/pma/index.php: 1 Time(s)
//db/index.php: 1 Time(s)
//dbadmin/index.php: 1 Time(s)
//index.php: 1 Time(s)
//myadmin/index.php: 1 Time(s)
//mysql/index.php: 1 Time(s)
//mysqladmin/index.php: 1 Time(s)
//php-my-admin/index.php: 2 Time(s)
//phpMyAdmin-2.2.3/index.php: 1 Time(s)

++++ honderden gericht op php en mysql versies....


--------------------- Named Begin ------------------------


**Unmatched Entries**
client XXX.XXX.XXX.XXX query (cache) 'isc.org/ANY/IN' denied: 13 Time(s)

++++ tientallen tot soms honderden....


--------------------- pam_unix Begin ------------------------

proftpd:
Unknown Entries:
authentication failure; logname= uid=0 euid=0 tty=/dev/ftpdXXXX ruser=mysql rhost=XXX.XXX.XXX.XX user=mysql: 1 Time(s)


++++ tientallen tot soms honderden....


sshd:
Authentication Failures:
unknown (XXX.XXX.XX.XX): 935 Time(s)

su-l:
Unknown Entries:
session closed for user popuser: 4 Time(s)

++++ tientallen tot soms honderden....


-------------------- SSHD Begin ------------------------


Failed logins from:
XX.XXX.XX.XX: 18 times
XX.XX.XXX.XX (static-XXX-XX-XX-XX.xxx.net): 10 times


Illegal users from:
XX.XX.XXX.XX (static-XXX-XX-XX-XX.xxx.net): 5 times
XXX.XXX.XX.XX: 935 times

++++ tientallen tot soms honderden....


Received disconnect:
11: Bye Bye : 1066 Time(s)

SFTP subsystem requests: 1 Time(s)

**Unmatched Entries**
pam_succeed_if(sshd:auth): error retrieving information about user tavi : 1 time(s)
reverse mapping checking getaddrinfo for xxx.xxxx-xxxx.xxx.fr failed - POSSIBLE BREAK-IN ATTEMPT! : 1 time(s)

++++ honderden tot soms duizenden...........


-------------------


Ik ben een leek wat betreft security en weet daarom ook niet om welke logs ik me het meest zorgen moet maken en hoe deze het beste te bestrijden omdat ik daar nog niet zo veel ervaring mee heb. Ik zoek daarom een gepaste tool om voor het grootste deel uit de zorgen te zijn en hackers en scriptkiddies buiten de deur houd.

Alle advies is welkom, alvast bedankt!

Het hangt er een beetje vanaf welke en hoeveel mensen er toegang moeten hebben via SSH. Voor enkel toegang voor een klein aantal gebruikers/beheerders zou je hieronder ideeën kunnen opdoen.

Wat ik zelf altijd doe, is het inloggen met wachtwoorden verbieden. Inloggen kan uitsluitend met een keyfile en inloggen als root heb ik ook uitgeschakeld. Als er toch beheertaken uitgevoerd moeten worden, dan met su of sudo. Dan hoef je je in principe over de SSH-aanvalsvector geen zorgen meer te maken, behalve dan natuurlijk je SSH daemon up-to-date houden. Om je logbestanden schoon te houden (en dus serieuze issues sneller te ontdekken) kun je de SSH daemon op een andere poort draaien en alle verkeer naar poort 22 door de firewall laten blokkeren of op je firewall instellen dat er alleen verbinding gemaakt mag worden op poort 22 door een aantal opgegeven IP-adressen.

FTP zou ik sowieso uitschakelen omdat dat onversleuteld is. Als je openSSH hebt draaien, kun je prima gebruik maken van de SFTP server die meegeleverd is. In een fatsoenlijke (S)FTP client (zoals FileZilla) moet dat geen probleem opleveren. Dan kun je dus inloggen met dezelfde combinatie van gebruikersnaam/keyfile als voor SSH.

Als je mysql databse lokaal draait (dus op dezelfde server als je webserver), dan hoeft die alleen maar te luisteren op 127.0.0.1 of een socket. Remote inloggen wordt dan onmogelijk. Draait je webserver op een andere machine, dan alleen de IP-adressen van de webserver(s) toegang bieden op poort 3306 (standaard mysql poort). Het liefst zitten al je webserver/database servers dan op hetzelfde interne netwerk, zodat anderen het verkeer niet kunnen onderscheppen. Als dat niet het geval is, zou ik een SSL laagje eroverheen leggen (bijvoorbeeld met stunnel) of een VPN maken (OpenVPN is wel lastig te configureren vind ik).

En voor wat betreft die httpd logs: zorg dat de toegangsrechten goed staan en dat je code veilig is (als in: geen SQL-injectie en XSS mogelijk). Voor tools als phpMyAdmin zou ik willen adviseren om die op een vhost te draaien die luistert op een andere poort en weer in je firewall alleen die IP-adressen toegang geven die dat ook echt nodig hebben. Is dat niet mogelijk, dan kun je bijvoorbeeld basis-authenticatie gebruiken met een sterk wachtwoord. Uiteraard alleen beschikbaar via SSL (kan prima met een zelf gegenereerd certificaat, hoeft niets te kosten).

Er zijn meerdere prima wrappers rond de firewall iptables/ip6tables beschikbaar. Voor debian-gebaseerde systemen gebruik ik eigenlijk meestal arno-iptables-firewall, standaard beschikbaar in de repositories.

Hoop dat je er wat aan hebt.

[edit]
Ik weet niet of het alleen hobby is en dus weinig mag kosten of dat je er een paar centen voor over hebt (gezien je een eigen dedicated server hebt, gok ik eigenlijk het laatste). In het laatste geval is het wellicht raadzaam om iemand met wat ervaring op dit gebied e.e.a. te laten instellen, omdat je zelf geen ervaring hebt zo lees ik uit de post hierboven.

Waarom zou je met dit soort ingewikkelde tooltjes willen werken?

Je kunt toch veel beter in de packetfilter aangeven welke ip's er toegang mogen hebben tot sshd.

Ik weet van te voren niet vanaf welk IP adres ik een connectie maak.

Daar heb ik een ingewikkelde procedure (duurt 5 minuten) voor om alsnog het ip in de packetfilter krijgen.

Alle andere zaken zijn gewoon internet 'ruis' maar bij deze zou ik me toch ernstig zorgen gaan maken. Klaarblijkelijk probeert het 'popuser' account su uit te voeren. Hoewel het mislukt betekent dit wel dat er iemand toegang tot dat account heeft want normaliter hoort deze gebruiker NOOIT een su te doen.