Bekijk Volledige Versie : 300 miljoen hackpogingen per dag!
Hebben jullie wel eens geteld hoeveel 'hackpogingen' er dagelijks zijn gemiddeld per server die je beheert? Heel irritant die oude Joomla, Wordpress en andere exotische CMS installaties, om niet te spreken van de simpele wachtwoorden die klanten gebruiken voor hun aangemaakte email adressen (spam!). Gelukkig vrij eenvoudig op te vangen met de juiste tools en de gebruikers te dwingen moeilijke wachtwoorden in te stellen.
Hoe gaan jullie eigenlijk te werk tegen deze geautomatiseerde scans en brute force aanvallen?
Voor onze shared hosting servers (cPanel, VMWare) eigenlijk alleen maar cPHulk (https://documentation.cpanel.net/display/ALD/cPHulk+Brute+Force+Protection) (cPanel) en CSF (http://www.configserver.com/cp/csf.html) voor de brute force aanvallen en Patchman (http://patchman.co/), CXS (http://www.configserver.com/cp/cxs.html) en Maldet (https://www.rfxn.com/projects/linux-malware-detect/) voor exploits en malware detectie.
Kunnen we dit nog aanvullen met bepaalde tools en services? Ik hoor graag van jullie.
En om alles even in het juiste perspectief te plaatsen, de datacenters van de NSA hebben er dagelijks meer dan 300 miljoen. :stuart: bron: http://thehackernews.com/2016/02/nsa-utah-data-center.html (wht.to/1WLeNKy)
Hier eigenllijk net dezelfde stack: CSF, Maldet en Patchman op 1 server ook CXS.. Daarnaast ook op alle servers nog Cloudlinux maar daar de afgelopen dagen wel wat miserie mee gehad met hun kernel bug :-)
eigenwebsite
26/02/16, 00:18
Heb je al gedacht aan je firewall instellingen en zo ja, hoe heb je deze geconfigureerd?
Hier eigenllijk net dezelfde stack: CSF, Maldet en Patchman op 1 server ook CXS.. Daarnaast ook op alle servers nog Cloudlinux maar daar de afgelopen dagen wel wat miserie mee gehad met hun kernel bug :-)
Hier ook een paar servers draaien met CloudLinux maar gelukkig geen last gehad van deze bug.
We are sorry to inform you that together with the latest stable CL kernel update (version 2.6.32-673.8.1.lve1.4.3) a bug has been revealed. Only few installations are affected so far, however it is recommended to update kmod-lve (version 1.4-3.1), which is available from our production repository. Details below.
Heb je al gedacht aan je firewall instellingen en zo ja, hoe heb je deze geconfigureerd?
Nu ben ik wel benieuwd wat je in gedachte had. Poort 25 en 80 blokkeren is nogal onhandig. ;)
Hier ook een paar servers draaien met CloudLinux maar gelukkig geen last gehad van deze bug.
Hier 3 servers die de raarste gekke toeren deden.. 500 Internal server errors memory dat niet meer vrijkwam.. Servers die super sloom waren.. Blij dat het verholpen is :-)
eigenwebsite
27/02/16, 02:40
Nu ben ik wel benieuwd wat je in gedachte had. Poort 25 en 80 blokkeren is nogal onhandig. ;)
Misschien ligt het aan mij, maar wat hebben "hackpogingen" te maken met je genoemde (mail)poorten? Bedoel je met hackpogingen dat er ook mail vanuit jouw server verstuurd wordt?
Als je niet weet waar men het over heeft zwijg dan eens ipv onzin reacties te posten, vroeger zou ik nog denken dat het was om aan je 100 posts te geraken nu weet ik het niet...
Misschien ligt het aan mij, maar wat hebben "hackpogingen" te maken met je genoemde (mail)poorten? Bedoel je met hackpogingen dat er ook mail vanuit jouw server verstuurd wordt?
Is niet als grap bedoeld maar het ging me juist om de manieren waarop hackers binnen komen en dat is onder andere via de generieke poorten die open moeten blijven om bepaalde services te laten werken. De web en mailserver om eens een aantal vectoren te noemen.
Maar goed, niemand die nog wat anders kan noemen?
Kunnen we dit nog aanvullen met bepaalde tools en services? Ik hoor graag van jullie.
Patrick_st
27/02/16, 19:01
Wij gebruiken Fail2Ban en Psad op een aantal servers maar ik denk dat CSF vergelijkbaar/beter is.
Een aantal hosters "vangt" de inlogpogingen op de bekende CMS systemen op met een infopagina: "klik hier om door te gaan naar het inlogscherm". Daarmee wordt de kans op succes met geautomatiseerde bruteforce scripts behoorlijk beperkt. Een bijkomstig voordeel is dat de server minder wordt belast door dit soort aanvallen, omdat een eenvoudige info-pagina sneller laadt dan het gemiddelde inlogscherm.
We hebben eerder al eens wat mogelijkheden besproken hier volgens mij. Ik weet niet of er misschien een uitbreiding voor cPhulk voor bestaat? Misschien is het daarmee te integreren.
systemdeveloper
27/02/16, 23:18
Bij beveiliging komt toch wel meer kijken dan alleen de riedel standaard tooltjes installeren.
Iemand met verstand van zaken (en dan bedoel ik niet die kinderachtige redhat certificaten en zo), met een over-the-top paranoid-level en de ballen om gebruikersgemak op te offeren voor veiligheid, is iets dat je echt nodig hebt.
Wij vallen gebruikers zelfs lastig als ze met hun website errors in de apache logs hebben en verzoeken hun om het op lossen. Of wel pushen ze vriendelijk om verouderde versies van cmsjes te upgraden (met de kanttekening dat we het anders zelf forceren als ze het niet binnen x dagen doen).
Ook moeten we een aantal keer per maand klanten uit de firewall vissen omdat ze 5 keer fout hebben ingelogd.
Zodra we weer een attack hebben van een partij zoals leaseweb (die per definitie geen drol doen als je ze hierop attendeert) dan knallen we die hele netwerken/subnetten een paar maanden in de firewall.
Wat de tooltjes betreft hebben bovenstaande plus o.a. mod_security nog. En wat zelf geschreven scriptjes. Daarnaast nog aparte syslogservers zodat we eenvoudig wat grepjes kunnen doen (denk aan versies van services, segfaults etc.)
Het houdt je van de straat, iig ;)
eigenwebsite
28/02/16, 02:05
Hiërarchisch gezien zou je (gezien de hackpogingen veelal uit China, Rusland, Afrika, etc. komen) series van IP ranges (landen) kunnen uitschakelen.
Dit is mogelijk door alle IP ranges van de betreffende landen via een script aan iptables toe te voegen. (via b.v. Directadmin, Cpanel, SSH)
Bij beveiliging komt toch wel meer kijken dan alleen de riedel standaard tooltjes installeren.
Wat de tooltjes betreft hebben bovenstaande plus o.a. mod_security nog. En wat zelf geschreven scriptjes. Daarnaast nog aparte syslogservers zodat we eenvoudig wat grepjes kunnen doen (denk aan versies van services, segfaults etc.)
Hier uiteraard ook mod_security in gebruik, samen met de standaar vendor (OWASP ModSecurity Core Rule Set) die je via cPanel kunt installeren.
Nu zijn er meer venors die je kunt gebruiken, Comodo heeft ook een gratis ruleset. Zie https://waf.comodo.com/
Verder heb je wel een punt natuurlijk en in mijn ogen is het ook vooral het zoeken naar een balans. Alles dicht timmeren kunnen we allemaal wel maar het moet ook bruikbaar blijven voor de klanten. En met shared hosting heb je ook te maken met meer beperkingen natuurlijk maar ook hier is het een en ander goed te beveiligen. De zwakste plunten blijven naast de zero day exploits toch vooral de gebruikers zelf. Mits er geen luie admin in het spel is die regelmatig vergeet het een en ander te updaten...
Sinds 1998 is er nog geen enkel server van ons gehackt maar als we het over user accounts gaan hebben is dat een heel ander verhaal. ;)
Hiërarchisch gezien zou je (gezien de hackpogingen veelal uit China, Rusland, Afrika, etc. komen) series van IP ranges (landen) kunnen uitschakelen.
Dit is mogelijk door alle IP ranges van de betreffende landen via een script aan iptables toe te voegen. (via b.v. Directadmin, Cpanel, SSH)
Ja dat kan maar wij hebben ook klanten uit die contreien dus daar ga je al. Eigenlijk hebben we nog nooit hele landen afgesloten omdat ik denk dat dit niet echt helpt.
Een aantal hosters "vangt" de inlogpogingen op de bekende CMS systemen op met een infopagina: "klik hier om door te gaan naar het inlogscherm". Daarmee wordt de kans op succes met geautomatiseerde bruteforce scripts behoorlijk beperkt. Een bijkomstig voordeel is dat de server minder wordt belast door dit soort aanvallen, omdat een eenvoudige info-pagina sneller laadt dan het gemiddelde inlogscherm.
Wij hebben ook een rate limit staan op de bekende cms login pagina's en dat scheelt ook al een hele boel. En dan heb je ook nog Varnish en zo om de load te verlichten en zo kunnen we wel nog even doorgaan.
het ging mij in eerste instantie om wat tools om brute force aanvallen tegen te gaan. :)
systemdeveloper
04/03/16, 23:14
Een brute-force aanval 'tegengaan' kan vrijwel niet. Je moet hem tenslotte eerst krijgen om hem vervolgens te kunnen detecteren en dan is het een kwestie van snel blokken. Dingen zoals fail2ban, csf/lfd zijn er redelijk effectief in. Met name de 'domme' brute forces kun je daar gemakkelijk mee counteren.
Een slimme brute-force (denk aan 1-2-3 tries per remote ipadres) is wat lastiger omdat die onder de radar blijven vaak. 1 van de grootste problemen (als je dit soort brute-forces hebt op loginpagina's van websites) is dat je dit lastig kunt detecteren. Het zou bv handig zijn als een standaard 'soft-error' code zou worden teruggegeven bij een foute login op een website, maar dat gebeurd maar zelden. (dus geen 403/404 oid maar bv en 450 of iets niet-httpd gerelateerd).
Voor dit soort dingen zul je vaak naar tools zoals splunk moeten uitwijken en je meer richten op anomalies in je netwerk traffic. Zeker als je een cache front-end hebt zoals vanish of iets custommades zoals een bridged firewall, dan kun je op basis van die anomalies besluiten om (net zoals cloudflare doet) er op bepaalde momenten een captcha page tussen te gooien of verkeer extra te filteren/blokken.
Dan kun je besluiten om login-traffic te blokkeren en normale requests naar de site door te laten. (om maar een voorbeeld te noemen).
Voor services zoals sshd kun je eventueel nog eens kijken naar portknocking. Dat is ook redelijk effectief, maar simpelweg je ssh poortnummer wijzigen heeft vaak al meer effect. Dan weet je tenminste zeker dat foute logins op sshd in 99 van de 100 keer komen van iemand die op zoek is gegaan naar het poort nummer én door de portscan is gekomen zonder geblocked te worden.
En als je een hardware firewall hebt dan kun je vaak nog de beurs trekken en er een ids/ips licentie voor pakken. Maar dat is vaak duurder dan het profijt dat je er van hebt. (En zeker met servers waar veel bezoek op komt en je dus erg veel connecties moet aankunnen, kom je er vaak niet met 5-10k euro)
eigenwebsite
05/03/16, 01:28
Ja dat kan maar wij hebben ook klanten uit die contreien dus daar ga je al. Eigenlijk hebben we nog nooit hele landen afgesloten omdat ik denk dat dit niet echt helpt.
Waarom zou dit niet echt helpen? Heb je een gedegen website-bezoeker doelgroep analyse gemaakt via b.v. Google Analytics? Dit om specifiek in kaart te brengen uit welke landen je bezoekers precies komen?
Waarom zou dit niet echt helpen? Heb je een gedegen website-bezoeker doelgroep analyse gemaakt via b.v. Google Analytics? Dit om specifiek in kaart te brengen uit welke landen je bezoekers precies komen?
Het gaat niet om of het helpt. Security is een spel met gebruiksvriendelijkheid. Domenico zegt niet voor niets dat we misschien maar poort 80 en 25 moeten sluiten. Iedereen snapt dat dit het probleem op lost maar dat het ten koste gaat van bereikbaar zijn. Hetzelfde geldt voor het blokkeren van China of Rusland. Misschien heb je zelf geen klanten uit die regio, maar de klanten van je klanten wel.
Zo zijn er nog tal van redenen waarom het blokkeren van landen of regio's geen goed idee is zonder dat je daar een doelgroep analyse voor hoeft te maken.
eigenwebsite
11/03/16, 00:10
Nationaal sowieso, wanneer je idd internationaal werkt ligt het weer een stuk gecompliceerder. Denk dat de basis iig ligt bij een goede VPS of dedicated server provider:)