Bekijk Volledige Versie : Possible Break-in Attempt!
Hi,
Elke nacht om 04:00 krijg ik van Logwatch een overzicht van de belangrijste logs van wat er op mijn server is gebeurt.
Vanmorgen stond deze erbij:
Address 216.40.236.242 maps to ev1s-216-40-236-242.ev1servers.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 594 time(s)
Kan iemand mij vertellen wat diegene hier doet en wat ik er tegen kan doen?
Thanks!
Gewoon een server die gehacked is en aanvallen op andere servers aan het doen is.
Gewoon even een abuse mailtje sturen..
http://whois.domaintools.com/216.40.236.242
Indeed, precies zoals TCM vertelde...
Ik zou me er niet te druk om gaan zitten maken in ieder geval... Shit happens alot, damn script kiddies :P
De melding zelf houd in:
IP 216.40.236.242 heeft reverse DNS naar ev1s-216-40-236-242.ev1servers.net
Maar ev1s-216-40-236-242.ev1servers.net is geen A record voor 216.40.236.242
(oftewel: A wijst naar B, maar B wijst niet naar A, wat wel zou moeten).
Als dat het enige is zou ik me er niet druk om maken :).
De server is niet gehacked. Deze melding geeft alleen aan dat de reverse-DNS entry van het IP naar een hostname verwijst, die andersom niet terug naar het IP verwijst.
Waar in je logwatch-mail stond het?
Het stond in het laatste gedeelte:
**Unmatched Entries**
pam_succeed_if(sshd:auth): error retrieving information about user raul : 2 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user wolfgang : 1 time(s)
pam_succeed_if(sshd:auth): error retrieving information about user baiat : 2 time(s)
... etc. etc. ....
Dus ik neem aan dat hij probeerde in te loggen met SSH ?
* Bedankt voor jullie reacties :-)
Het stond in het laatste gedeelte:
Dus ik neem aan dat hij probeerde in te loggen met SSH ?
* Bedankt voor jullie reacties :-)
Een geautomatiseerd script wat een lijst met namen afwerkt.. niks om je druk om te maken, gebeurd dagelijks. Wil je het voorkomen dan moet je SSH via een andere poort dan 22 gaan draaien (ik ben toendertijd van 15.000 login attempts naar 0 gezakt ;))
Een geautomatiseerd script wat een lijst met namen afwerkt.. niks om je druk om te maken, gebeurd dagelijks. Wil je het voorkomen dan moet je SSH via een andere poort dan 22 gaan draaien (ik ben toendertijd van 15.000 login attempts naar 0 gezakt ;))
He, he, je maakt zelf nooit een tikfoutje? :)
Een geautomatiseerd script wat een lijst met namen afwerkt.. niks om je druk om te maken, gebeurd dagelijks. Wil je het voorkomen dan moet je SSH via een andere poort dan 22 gaan draaien (ik ben toendertijd van 15.000 login attempts naar 0 gezakt ;))
Even offtopic (ietsiepietsie dieper in gaan op de stof ;)):
Hoewel dit het aantal login attempts omlaag gooit, maakt het de server in de meeste gevallen nauwelijks veiliger oid. In principe zou je server goed genoeg beveiligd moeten zijn om eventuele 'hacks' (eerder bruteforcen...) te kunnen weerstaan. De vele login attempts op poort 22 heb je dus geen last van (wellicht een theoretisch performance verlies).
Het draaien van je SSH op een andere poort zorgt ervoor dat je de login attempts niet meer binnen krijgt (poort 22 zit nu dicht), maar een echte hacker kan die poort vaak zonder problemen achterhalen (port scan) en daarmee alsnog toegang tot je server krijgen (als er iets mankeert aan je beveiliging).
Veranderen van SSH poort is een vorm van security through obscurity.
systemdeveloper
26/04/08, 09:44
Even offtopic (ietsiepietsie dieper in gaan op de stof ;)):
Veranderen van SSH poort is een vorm van security through obscurity.
100% true. Vaak is het zelfs onveiliger omdat gebruikers 'denken' dan minder hoeven te beveiligen.
Aan de andere kant schoont het wel je logfiles op en kun je meer aandacht geven aan de scripts / personen die zich wél de moeite nemen om je nieuwe ssh-poortnummer te vinden.
Het is een beetje het kaf van het koren scheiden, dus wijzigen van de ssh poort doe ik in principe altijd.
crazycoder
26/04/08, 10:05
Het draaien van je SSH op een andere poort zorgt ervoor dat je de login attempts niet meer binnen krijgt (poort 22 zit nu dicht), maar een echte hacker kan die poort vaak zonder problemen achterhalen (port scan)
Lees: echte hacker en een ieder die nmap of een soortgelijke tool weet te starten. Dus iets wat iedereen met het diploma schoenstrikken kan :)
100% true. Vaak is het zelfs onveiliger omdat gebruikers 'denken' dan minder hoeven te beveiligen.
Aan de andere kant schoont het wel je logfiles op en kun je meer aandacht geven aan de scripts / personen die zich wél de moeite nemen om je nieuwe ssh-poortnummer te vinden.
Het is een beetje het kaf van het koren scheiden, dus wijzigen van de ssh poort doe ik in principe altijd.
Verspilde moeite firewall ervoor en klaar ermee, vergeet niet ervoor te zorgen dat je zelf wel via ssh in kan loggen.. scheelt je weer een ritje naar het dc :)
Je moet vanzelfsprekend nog wel alles redelijk up to date houden maar het verminderd de mogelijkheden om aan te vallen.
Als je toch bezig bent, sluit dan alle poorten behalve wat er nodig is en maak zinvolle regels in je firewall voor de poorten die wel open moeten staan.
systemdeveloper
26/04/08, 10:32
Lees: echte hacker en een ieder die nmap of een soortgelijke tool weet te starten. Dus iets wat iedereen met het diploma schoenstrikken kan :)
Verspilde moeite firewall ervoor en klaar ermee, vergeet niet ervoor te zorgen dat je zelf wel via ssh in kan loggen.. scheelt je weer een ritje naar het dc :)
Je moet vanzelfsprekend nog wel alles redelijk up to date houden maar het verminderd de mogelijkheden om aan te vallen.
Als je toch bezig bent, sluit dan alle poorten behalve wat er nodig is en maak zinvolle regels in je firewall voor de poorten die wel open moeten staan.
Verspilde moeite? Hoe kom je daar bij?
Met enkele toetsaanslagen ...
# vi /etc/sshd/sshd_config
/22[ENTER]cw<nieuwe poort>[ESC]:w![ENTER]:q[ENTER]
/etc/rc.d/sshd restart[ENTER]
bespaar je een veelvoud aan traffic, diskspace van je logfiles en psychische stress...
Lijkt me wel de moeite waard :D
crazycoder
26/04/08, 10:53
Verspilde moeite? Hoe kom je daar bij?
Met enkele toetsaanslagen ...
# vi /etc/sshd/sshd_config
/22[ENTER]cw<nieuwe poort>[ESC]:w![ENTER]:q[ENTER]
/etc/rc.d/sshd restart[ENTER]
bespaar je een veelvoud aan traffic, diskspace van je logfiles en psychische stress...
Lijkt me wel de moeite waard :D
Mij niet :)
Als je het via de firewall blokkeer bespaar je extra doordat de poortscannende figuurtjes ook geen pogingen naar een andere poort gaan doen.
systemdeveloper
26/04/08, 11:19
Mij niet :)
Als je het via de firewall blokkeer bespaar je extra doordat de poortscannende figuurtjes ook geen pogingen naar een andere poort gaan doen.
Waarom zeg je dan 'Mij niet'? Het bespaart je zelfs nog meer ;)
Maar niet elke gebruiker kan zelf zijn firewall op zijn dedi onderhouden en bij een managed dedi/firewall zul je het zelf moeten doen. Dus dat is imho minder efficient.
Firewall is wel veiliger natuurlijk, maar dan kun je ook aan vlans, kerobos, locale beveiliging, auditing, ids, monitoring, apache modules, whitelists etc... gaan denken. Dit zal allemaal bijdragen tot een uiterst veilige server, maar efficient of prettig om mee te werken e.d. zal die server niet worden :)
Veranderen van SSH poort is een vorm van security through obscurity.
Goed goed goed, ik geef toe, mijn reactie was iets te kortzichtig... het voorkomt dat geautomatiseerde scripts je lastig vallen, maar het heeft verder inderdaad niks met security zelf te maken.
crazycoder
27/04/08, 15:01
Waarom zeg je dan 'Mij niet'? Het bespaart je zelfs nog meer ;)
Om eerlijk te zijn vind ik de schijfruimte niet echt interessant. Toegang tot een bepaalde service totaal blokkeren is altijd veiliger dan op een andere poort draaien.
Maar niet elke gebruiker kan zelf zijn firewall op zijn dedi onderhouden en bij een managed dedi/firewall zul je het zelf moeten doen. Dus dat is imho minder efficient.
Als iemand een server colocate moet je zorgen voor voldoende kennis. Heb je die niet, huur het dan in. Snap niet zo waarom iemand met 0.0 kennis zo nodig een eigen colocated server moet hebben. Vallen vrouwen daarvoor ofzo? Indien ja dan moet ik dat voortaan zeker gebruiken :)
Als je meerdere servers colocate of managed dedicated hebt staan kan je het altijd nog op een externe firewall regelen. Zeker met managed producten vraag ik mezelf af of een klant toegang tot ssh moet hebben.
Het spreekt voor zich dat je dit soort zaken ook zou kunnen automatiseren.
Firewall is wel veiliger natuurlijk, maar dan kun je ook aan vlans, kerobos, locale beveiliging, auditing, ids, monitoring, apache modules, whitelists etc... gaan denken. Dit zal allemaal bijdragen tot een uiterst veilige server, maar efficient of prettig om mee te werken e.d. zal die server niet worden :)
Wat apache modules met ssh te maken heeft weet ik niet maar je heb wel gelijk dat je in het geval het streven naar een veilige server doorschiet er niets meer mee gedaan kan worden. Toch denk ik dat je een optimaal punt moet proberen te bereiken waar beveiliging en gebruikersvriendelijkheid in balans zijn. Een service op een andere poort zetten heeft niets met veiligheid te maken, bedenk dat de meeste password raad tooltjes toch niet zoveel kans maken tegen sterke wachtwoorden..
Gebruik CSF met LFD, dan komt het helemaal goed ;)
Wel goed configureren uiteraard.
http://www.configserver.com/cp/csf.html
fail2ban werkt erg goed om ge-automatiseerd ips (tijdelijk) te blokkeren als een bepaald aantal pogingen om in te breken wordt overschreden.
heb inmiddels op mijn eigen server een lijst van ongeveer 600 ips (voornamelijk russisch, amerikaans en chinees) geblokkeerd op deze manier.
Afhankelijk vna je eigen iptables kennis kun je deze volledig danwel voor bepaalde services blokkeren of ene omleiding instellen naar een abuse pagina oid.