Onderwerp: Tendens: Vertienvoudiging aan Brute Force inlogpogingen

Beste concullegae,

We ervaren de laatste paar dagen minimaal een vertienvoudiging in het aantal Brute Force inlogpogingen, waarbij ook vaak simultaan dezelfde gebruikersnaam wordt geprobeerd v.a. diverse IP-adressen wereldwijd. Is dit een nieuwe tendens of zijn we de enigen die hierdoor worden getroffen?

Vroeger zag je slechts enkele malen per dag wat (domme) pogingen op standaard gebruikersnamen, maar nu zie je ook echt pogingen op (soms) correcte gebruikersnamen van daadwerkelijke cliënten.

Voor de volledigheid: Alle IP-adressen worden uiteraard standaard geblokkeerd na een X aantal foute inlogpogingen en onze cliënten worden verplicht om een sterk wachtwoord te gebruiken, maar het blijft vervelend.

Er lijkt zo wel een nieuw botnet actief.

Ik kan rustig zeggen al een hele maand.
Wereld wijd dat klopt. De meeste op de SMTP en host account login.
Meeste landen geblocked die van geen belang zijn voor de klanten.

Inderdaad hier ook, zelfs bij nieuwe servers die net geinstalleerd zijn. Ze proberen inderdaad ook met bestaande accounts, hoe ze eraan geraken is me een raadsel.
Ook ontzettend veel last van DNS Ddoss attacks (dns servers antwoorden gewoon niet maar toch sturen ze random domeinen om te laten resolven..)

Binnen DA kan je inderdaad vrij eenvoudig met CSF werken om het eea te blokkeren, wij hebben hier nogal veel Plesk servers draaien en daar werkt dat niet goed op.. (of toch niet zo deftig geintegreerd..) Als iemand iets weet voor plesk hoor ik dat graag..

Het zelfde verhaal hier sinds enkele weken inderdaad.
Heb het aantal mogelijke foute inlogpogingen gelimiteerd tot 2 waarna een permanent block komt. CSF lijkt tot nu toe nog goed z'n taak te volbrengen.
Had onlangs wel een 'breach' in een ongebruikt en vergeten email-account onder een aktief domein, wat daarna direct spam ging versturen. Gelukkig gebeurde het overdag waardoor ik het aantal verstuurde emails nog redelijk wist te beperken tot zo'n 'slechts' 4000 stuks.
De csf-blocklist met (nu nog) max. 200 ip's wordt door het grote aantal bruteforce-pogingen alsnog regelmatig 'ververst', dus tijdelijke of permanente blocks instellen maakt vooralsnog weinig verschil.

Hier stond ook al wat: http://www.webhostingtalk.nl/dedicat...eblieft-2.html

Ook de laatste paar weken hebben we er last van. Er lijkt een botnet actief te zijn wat wachtwoorden van Windows pc's afvist.

Sinds een week of twee hebben we de volgende ACL's voor Exim in gebruik:

- HELO/EHLO naam geblokkeerd van een bekend botnet.
- Limiet voor buitenlandse IP-adressen van max. 10 recipients (in 1 mailtje) ingesteld.
- RBL lists voor de uitgaande SMTP mail gebruiken (geen mail meer te verzenden vanuit IP's die geblacklist zijn). * Alleen RBL's die geen Dynamic IP ranges geblokt hebben.

Alle Nederlandse en Belgische IP-adressen zijn gewhitelist zodat deze geen last hebben van bovenstaande.
We kunnen ook per domeinnaam whitelisten voor buitenlandse klanten.

Ik ben nog bezig om een soort counter te maken voor alleen buitenlandse IP-adressen.
Als het aantal verzonden mailtjes vanuit het buitenland ineens heel hoog is voor een account wat niet op de whitelist staat dat hij de uitgaande mail dan niet door laat.

Maar dat is wat lastiger dan het maken van ACL's voor Exim.

Sinds bovenstaande ACL's is het misbruik van gehackte (SMTP) accounts heel erg afgenomen.

Als iemand anders nog goede ideeën heeft hoor ik het graag, dan kan ik het wellicht omtoveren tot een ACL.

Ik heb niet het idee dat het een botnet die passwords heeft is hier. Ik zie erg veel bruteforce pogingen, die na blocken na een tijdje terug komen met nieuwe ips.
Nu wordt er hier automatisch geblokkeerd en is de lijst geduldig aan het groeien, echter helpt dat niet in het minder worden van het aantal pogingen.

Oorspronkelijk geplaatst door dennis0162

Sinds een week of twee hebben we de volgende ACL's voor Exim in gebruik:

- HELO/EHLO naam geblokkeerd van een bekend botnet.
- Limiet voor buitenlandse IP-adressen van max. 10 recipients (in 1 mailtje) ingesteld.
- RBL lists voor de uitgaande SMTP mail gebruiken (geen mail meer te verzenden vanuit IP's die geblacklist zijn). * Alleen RBL's die geen Dynamic IP ranges geblokt hebben.

Gooi ze online? Wellicht kunnen anderen ze dan aanvullen of er ook hun voordeel mee doen.

Zelf heb ik nog een acl_smtp_connect check:

Code:

acl_smtp_connect  = check_host

MYACL_DENY = SELECT acl_deny('${quote_mysql:$sender_host_address}')

begin acl

check_host:
   deny   condition = ${lookup mysql{MYACL_DENY}}
           message   = Connection not accepted
   accept

Hiervoor heb ik wel exim gecompileerd met mysql lookups. In mysql heb ik een udf gemaakt die een ip adres checked tegen mijn eigen rbl.
Mijn rbl vul ik aan de hand van de logs met de smtp auth errors vanaf de servers.
Verder heb ik dan nog een relatief eenvoudige webpage waarop iemand zijn ip weer kan vrijgeven.

touch /etc/virtual/smtp_whitelist
touch /etc/virtual/whitelist_domains_ac

Ergens boven aan:

Code:

hostlist smtp_whitelist = net-iplsearch;/etc/virtual/smtp_whitelist
domainlist whitelist_domains_ac = lsearch;/etc/virtual/whitelist_domains_ac

ACL voor acl_check_recipient:

Code:

# BLOCK SMTP senders die op de RBL staan
deny    hosts   = !+smtp_whitelist : !127.0.0.1
                sender_domains = !+whitelist_domains_ac
                message      = $sender_host_address is listed by $dnslist_domain
        log_message  = Remote host $sender_host_address is listed by $dnslist_domain ###002
        dnslists     = b.barracudacentral.org : \
                                                                bl.spamcop.net : \
                                                                spam.spamrats.com : \
                                                                sbl.spamhaus.org : \
                                                                bl.mailspike.net

# BLOCK meer als 10 RECIPENTS buiten NL EN BE (IPs in smtp_whitelist)
drop    hosts     = !+smtp_whitelist : !127.0.0.1
        sender_domains = !+whitelist_domains_ac
                message   = I don't take more than 10 RCPTs outside NL or BE
        condition = ${if > {$rcpt_count}{10}}

# BLOCK mycomputer als helo name buiten NL EN BE (IPs in smtp_whitelist)
drop    hosts     = !+smtp_whitelist : !127.0.0.1
        sender_domains = !+whitelist_domains_ac
        message = Gave HELO/EHLO as "error"
    log_message = HELO/EHLO error
        condition = ${if eq {$sender_helo_name}{mycomputer} {yes}{no}}

/etc/virtual/smtp_whitelist moet je vullen met IP-ranges (CIDR notatie) uit de landen die je standaard wil toe laten.
Kan je hier vandaan halen: https://www.countryipblocks.net/country_selection.php

In /etc/virtual/whitelist_domains_ac kan je domeinnamen zetten die wil whitelisten, bijvoorbeeld buitenlandse klanten.


De counter voor vanaf het buitenland verzonden mails ben ik nog mee bezig, het wil nog niet echt werken.
Het liefst doe ik het zonder MySQL database.

Ja, mysql vond ik ook wel jammer, maar die had ik toch al nodig voor de greylist.

Je kunt ook eens kijken naar zen.spamhaus.org. Dit is nog wat strikter dan alleen de sbl. (Misschien een beetje té, maar dat moet je zelf even zien).

Het nadeel is dat op ZEN vrijwel alle internet providers staan met hun DHCP Pools.
SBL.spamhaus.org staan geen dynamic IP's op.

Oorspronkelijk geplaatst door dennis0162

Het nadeel is dat op ZEN vrijwel alle internet providers staan met hun DHCP Pools.
SBL.spamhaus.org staan geen dynamic IP's op.

Dat klopt, maar in 99-100 gevallen hoeft iemand vanaf zijn dynamisch adres ook niet mailserver te gaan spelen.

De ACL is voor uitgaande mail verzonden vanaf een mail account via bijvoorbeeld Outlook (dus niet de inkomende SMTP mail).

zen.spamhaus.org gebruiken we wel voor inkomende SMTP mail (heeft dat nog een naam?).

Ah ja, natuurlijk.

Bij mij werkt het net iets anders omdat (vanaf de firewall gezien) alles inkomend is. Die maakt alleen een uitzondering als het smtp_auth is en laat hem dan door.
Aan de exim kant op de server zelf gooi ik de verzender dan eventueel nog in een greylist of stuur ik hem fietsen als ie op de naugthy list staat.

Deze tendens is hier ook sterk merkbaar. We hebben al diverse klanten waarbij het fout is gegaan onder onze Plesk-servers. Inmiddels een paar mooie fail2ban installaties gemaakt, en we zijn aan het overwegen om alles maar op andere poorten te gaan draaien (mail en ftp), maar kijken nog een beetje op tegen het aantal extra telefoontjes dat dat op zal gaan leveren.

Plesk 12 gaat fail2ban standaard aan boord hebben.. *Eindelijk!*