Bekijk Volledige Versie : Tendens: Vertienvoudiging aan Brute Force inlogpogingen
dreamhost_nl
10/03/14, 20:07
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.
dennis0162
10/03/14, 22:22
Hier stond ook al wat: http://www.webhostingtalk.nl/dedicated-en-vps-unmanaged-hosting/183777-spammer-op-server-help-alsjeblieft-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.
systemdeveloper
11/03/14, 00:10
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:
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.
dennis0162
11/03/14, 09:40
touch /etc/virtual/smtp_whitelist
touch /etc/virtual/whitelist_domains_ac
Ergens boven aan:
hostlist smtp_whitelist = net-iplsearch;/etc/virtual/smtp_whitelist
domainlist whitelist_domains_ac = lsearch;/etc/virtual/whitelist_domains_ac
ACL voor acl_check_recipient:
# 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.
systemdeveloper
11/03/14, 10:04
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).
dennis0162
11/03/14, 10:08
Het nadeel is dat op ZEN vrijwel alle internet providers staan met hun DHCP Pools.
SBL.spamhaus.org staan geen dynamic IP's op.
systemdeveloper
11/03/14, 10:13
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.
dennis0162
11/03/14, 10:16
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?).
systemdeveloper
11/03/14, 10:30
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.
TotallyHosted
11/03/14, 14:51
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!*
En CSF is leuk maar soms krijg je er grijze haren van..
Zie momenteel op een WHM Server continu attacks van een ip 10.244.x.y op FTP
Ip komt van CHina dus ik steek CN mee in de CC_DENY ports, herstart csf , ip blijft binnenkomen met failed ftp logins.. bon dan maar 10.244.0.0/12 in de deny ips.. herstart csf en LFD maar dat Ip blijft er gewoon doorkomen...
:@
dennis0162
11/03/14, 22:41
Mwah heb liever zo weinig mogelijk default opties mee geïnstalleerd door DirectAdmin.
bibawa
Je zou even moeten kijken of de types wel door iptables worden gebruikt (iptables -L).
CSF en LFD werkt hier altijd zonder problemen. Maar het is gewoon een makkelijke schil om Iptables heen.
Sent from my HTC One using webhostingtalk mobile app
Patrick_st
12/03/14, 08:20
bon dan maar 10.244.0.0/12 in de deny ips.. herstart csf en LFD maar dat Ip blijft er gewoon doorkomen...
:@
Een 10.0.0.0 adres zou niet op je externe interface binnen moeten komen. Vaak is er een $HOME_NET waar 10.0.0.0 onder valt wat niet geblokkeerd wordt.
Als je intern geen 10.0.0.0 gebruikt zou je met het commando: iptables -I INPUT -s 10.0.0.0/8 -j DROP
hier altijd vanaf moeten zijn.
Ik denk dat bibawa eerder 110.244.0.0/12 bedoeld, want dat is effectief een range van een chinees telecom bedrijf ;).
Mwah heb liever zo weinig mogelijk default opties mee geïnstalleerd door DirectAdmin.
bibawa
Je zou even moeten kijken of de types wel door iptables worden gebruikt (iptables -L).
CSF en LFD werkt hier altijd zonder problemen. Maar het is gewoon een makkelijke schil om Iptables heen.
Sent from my HTC One using webhostingtalk mobile app
Moet voor mij niet default zijn, maar iets zoals CSF en LFD : je kan het gewoon apart installeren. Of reeds preinstalled, maar je moet het nog "aan zetten" (vinkje oid).
TotallyHosted
12/03/14, 11:45
Wij zijn inmiddels een globale lijst aan het opstellen. Een x aantal invalide logins (op mail danwel ftp) betekent geen toegang meer op onze shared hosting servers voor 24 uur, via de firewall. En dat dan binnen het uur syncen naar de andere servers.
SSH staat al volledig afgeschermd dus nemen we hier niet in mee.
Wij zijn inmiddels een globale lijst aan het opstellen. Een x aantal invalide logins (op mail danwel ftp) betekent geen toegang meer op onze shared hosting servers voor 24 uur, via de firewall. En dat dan binnen het uur syncen naar de andere servers.
SSH staat al volledig afgeschermd dus nemen we hier niet in mee.
Voor mei verwacht ik dat wij ook zoiets hebben (maar dan op basis van sync binnen 5 minuten). Het eens per uur syncen is helaas maar beperkt zinvol.
TotallyHosted
12/03/14, 14:10
Daar zit mogelijk wel wat in ja. Maar een cronjob wijzigen van hourly naar */5 is natuurlijk ook een kleine aanpassing.
Ik hou het nu sinds 24 uur bij op 1 server, en zit al op 222 unieke IP's op alleen qmail en proftpd ... Ik ben erg benieuwd of dat heel veel meer wordt als we meer servers gaan toevoegen, of dat het gewoon 1 serie rotte appels (appels met IP's vergelijken?!?:)) is.
dennis0162
12/03/14, 15:05
Nog even een ACL geknutseld die bijhoudt hoeveel e-mails per dag vanuit het buitenland zijn verzonden.
Het limiet kan je totaal en per user instellen.
Let wel dat je de lists al hebt die hierboven ergens staan:
/etc/virtual/smtp_whitelist
/etc/virtual/whitelist_domains_ac
/etc/exim_count.sh :
#!/bin/bash
# Maximale Limiet voor buitenlandse verzendende MAIL.
Setmaxlimit="25"
# Indien leeg yes terug geven anders wordt de mail niet verzonden
if [ -z "$1" ]
then
echo -n yes
exit 0
fi
if [ -z "$2" ]
then
echo -n yes
exit 0
fi
mailusr=$1
# MAIL LIMIET OPHALEN
if [ -f /etc/exim_count_limit/$mailusr ]; then
maxlimit=`cat /etc/exim_count_limit/$mailusr`
else
maxlimit=$Setmaxlimit
fi
# 0 = onbeperkt mails versturen
if [ "$maxlimit" = "0" ]; then
echo -n yes
exit 0
fi
# Counter
if [ -f /etc/exim_count/$mailusr ]; then
countje=`wc -c < /etc/exim_count/$mailusr`
if [ "$countje" -ge "$maxlimit" ]; then
echo -n yes
else
COUNTER="0"
while [ $COUNTER -lt $2 ]; do
echo -n "1" >> /etc/exim_count/$mailusr
let COUNTER=COUNTER+1
done
echo -n no
fi
else
COUNTER="0"
while [ $COUNTER -lt $2 ]; do
echo -n "1" >> /etc/exim_count/$mailusr
let COUNTER=COUNTER+1
done
echo -n no
fi
exit 0
mkdir /etc/exim_count
mkdir /etc/exim_count_limit/
chown mail:root /etc/exim_count
chown mail:root /etc/exim_count_limit
chown mail:root /etc/exim_count.sh
Exim.conf:
Na check_recipient:
# Buitenland Counter (het zou iets van de PVV kunnen zijn)
drop hosts = !+smtp_whitelist : !127.0.0.1
sender_domains = !+whitelist_domains_ac
message = Too many messages sent from outside NL or BE, possibly outgoing spam
log_message = Counter outside NL/BE HIT
condition = ${run{/etc/exim_count.sh $sender_host_address $rcpt_count}}
- Exim restarten
Cronjob:
0 0 * * * root rm -rf /etc/exim_count/*
In de map /etc/exim_count_limit/ kan je per domeinnaam een max. limiet aangeven (0 is onbeperkt)
Voorbeeld 50 uitgaande mails vanaf het buitenland: echo 50 > /etc/exim_count_limit/domeinnnaam.nl
Patrick_st
12/03/14, 20:46
Ik denk dat bibawa eerder 110.244.0.0/12 bedoeld, want dat is effectief een range van een chinees telecom bedrijf ;).
Goed punt :) Ik kon vanmorgen de link al niet leggen met 10.244 en een range uit China. Maar dan nog moet je er vanaf zijn als je 10.0.0.0/8 vervangt door 10.244.0.0/12. Het gaat me vooral om de iptables -I optie, in veel tutorials zie je dat iptables -A gebruikt wordt. Dan kan prima werken maar als er al een regel is wat er voor zorgt dat het adres wordt toegelaten, dan kan het anders uitpakken dan verwacht.
TotallyHosted
13/03/14, 13:40
De herkomst van de bruteforces van de afgelopen 30 uur, zie bijlage :)
- HELO/EHLO naam geblokkeerd van een bekend botnet.
Hoe doe je dat? Want dat zag ik er niet zo snel bij staan. Mag evt. ook per pm als men het publiekelijk wat onveilig vindt om dat te vermelden.
Hier ook al zeker vier weken in toenemende mate op alle servers van die bruteforces, het zijn er vele honderden per dag.
Volgens mij hebben de bruteforces toch wel te maken met dat virus wat die wachtwoorden jat van windows pc's.
Toevallig hadden we eergisteren op een server een spam flood, die ik vrij snel kon killen en het wachtwoord van betreffende email adres wijzigen en exim queue leeg kiepen voor dat email adres.
Gelijk gekeken wat er ging gebeuren en nog geen 5 minuten later kwamen er de nodige bruteforces specifiek op dat email adres waarvan zojuist het wachtwoord gewijzigd was. Zelfde op een Cpanel server van een kennis. Daar ook 1 account misbruikt, gelijk dicht gezet, wachtwoord gewijzigd, weer geactiveerd en ook daar meteen de nodige bruteforces op.
dennis0162
13/03/14, 20:59
Hoe doe je dat? Want dat zag ik er niet zo snel bij staan. Mag evt. ook per pm als men het publiekelijk wat onveilig vindt om dat te vermelden.
Hier ook al zeker vier weken in toenemende mate op alle servers van die bruteforces, het zijn er vele honderden per dag.
Volgens mij hebben de bruteforces toch wel te maken met dat virus wat die wachtwoorden jat van windows pc's.
Toevallig hadden we eergisteren op een server een spam flood, die ik vrij snel kon killen en het wachtwoord van betreffende email adres wijzigen en exim queue leeg kiepen voor dat email adres.
Gelijk gekeken wat er ging gebeuren en nog geen 5 minuten later kwamen er de nodige bruteforces specifiek op dat email adres waarvan zojuist het wachtwoord gewijzigd was. Zelfde op een Cpanel server van een kennis. Daar ook 1 account misbruikt, gelijk dicht gezet, wachtwoord gewijzigd, weer geactiveerd en ook daar meteen de nodige bruteforces op.
Zie: http://www.webhostingtalk.nl/beveiliging/183880-tendens-vertienvoudiging-aan-brute-force-inlogpogingen.html#post1281851
Vandaag toevallig 1 gehackt account verder al 1 á 2 weken niks :thumbup:
Ja ik zie daar die country blocks en max. aantal blocks per country etc. maar ik zie geen specifieke naam van een botnet, dat bedoelde ik.;)
dennis0162
13/03/14, 21:23
Staat er wel bij hoor. Kan het zo niet even selecteren via m'n telefoon. "mycomputer" is de helo name. Even ctrl-f op die pagina doen naar mycomputer
Sent from my HTC One using webhostingtalk mobile app
Ah, da's dit stukje:
# 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}}
Gevonden, thanks!
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.
Klopt heb dit ook reeds een poos gezien op een directadmin server van me. Interessante is wel is dat die server geen klanten host, dus ben ik vrij goed op de hoogte wat er draait en wat er aan mail e.d. wordt gebruikt aangezien ik zelf de enige gebruiker ben :)
Wat ik vooral zie is brute force pogingen op proftpd met als username <domain>@<domain>.<tld> waarbij de domeinen inderdaad door die server worden gehost.
Zat een poosje te zoeken naar hoe ze die accounts redelijk correct weten te gokken (de username noem ik meestal anders).
Blijkt na wat logfile spellen dat ze dit ook 1x hebben geprobeerd via een domein waar ik niet eens een hostingaccount voor had aangemaakt, alleen een DNS record.
Ofwel het lijkt er verdacht veel op dat ze deze informatie via DNS servers weten te ontfutselen, de volgende stap is zien uit te vinden hoe dan. Ik gebruik zowel bind alsook via een andere server DNS met powerdns. Omdat het geen productieserver is heb ik de powerdns server offline gehaald, nog geen pogingen gezien sinds toen.
Maar het zegt nu ook weer niet zoveel omdat deze pas een paar dagen offline is.
dennis0162
14/03/14, 09:30
Gebruikersnamen achterhalen via een DNS server???
Lijkt mij heel sterk / of gewoon onmogelijk.
Domeinnamen achterhalen en gebruikersnamen gokken is het meer.
Support@domain
Admin@domain
Username@domain
Domain@domain
Etc.
Al dit soort dingen zie je voorbij komen.
Hier ook rare pogingen op subdomeinen trouwens. Krijg je ineens een bruteforce op support@subdomain.domain ofzoiets.
systemdeveloper
14/03/14, 11:29
Domeinen komen gewoon van crawlers. Wij zien het ook op subdomeinen die vanwege de wildcard dns nergens op een dnsserver genoemd zijn.
Gebruikersnamen achterhalen via een DNS server???
Lijkt mij heel sterk / of gewoon onmogelijk.Nee dat bedoelde ik niet, domeinnamen kloppen, de gebruikersnamen worden gegokt. Als ik me niet vergis is bij directadmin de domein zelf ook de default username en dat is wat wordt geprobeerd.
Mijn powerdns server is nog steeds down en daarnet werd er toch weer een poging ondernomen, dus die hypothese begint ook al minder sterk te worden.
Nee dat bedoelde ik niet, domeinnamen kloppen, de gebruikersnamen worden gegokt. Als ik me niet vergis is bij directadmin de domein zelf ook de default username en dat is wat wordt geprobeerd.
Mijn powerdns server is nog steeds down en daarnet werd er toch weer een poging ondernomen, dus die hypothese begint ook al minder sterk te worden.
De oorzaak zal niet in een bepaalde naamserver zitten. De domeinnaam niet in de DNS zetten helpt mogelijk op termijn iets.
Bij DirectAdmin staat de domeinnaam voor extra FTP accounts na het @-teken.
Het ligt in elk geval niet aan Powerdns lijkt me, want ze bruteforcen ook gewoon op servers die geen Powerdns gebruiken.
Toch ben ik benieuwd hoe ze aan de info komen, misschien toch van malware van pc's of zoiets. Laatst ook diverse bruteforces gezien op een domeinnaam waar alleen wat informatie op stond. In DA stond een email adres wat niet gebruikt werd.
Dat email adres werd specifiek gebruteforced, terwijl ik van dat domein geen andere bruteforce pogingen in de log tegen kwam.
Daardoor begin ik een beetje te twijfelen of het wel random pogingen zijn. De meesten zijn echter wel op info@domeinnaam.tld van wat ik in de gauwigheid zag. Dat is natuurlijk wel een veel voorkomend email adres, dus misschien toch random pogingen op info adressen.
Vandaag was het voor de eerste keer even wat rustiger, maarja er staan er dan ook enkele honderden in de firewall geblokkeerd momenteel.
Misschien via robtex.com?
Je kan daar een IP ingeven en dan zien welke domeinnamen er nog op die server staan.
bvb
https://www.robtex.com/advisory/dns/eu/it2go/be/s01/v01/?deep=1#shared
Oh, maar ik heb zie hier ook al op admin@server1.hostname.nl en dergelijke gezien.. Geen idee hoe ze daar aan komen want daar ben ik toch al zeker niet mee aan het adverteren.
Misschien dat ze ook gewoon kijken op sites als robtex.com welke domeinen naar hetzelfde ip resolven of zoiets dergelijks.
Edit: Kris was me voor :)
Zomaar een dagje op een DA server die geen email adressen heeft geconfigureerd:
domain@ account@ accountin@ accounting@ root@ admin@
van 5 van de 30 domeinen. Geen van deze domeinen heeft de MX records naar deze server staan.
Pas een nieuwe DA server geinstalleerd, tot nu toe met 1 domein en system email account.
Deze staat momenteel 2 dagen te draaien. Maar sinds 14-3 is het erg rustig op alle servers. Wel af en toe nog een paar naar wat vDong ook al noemt, dat zijn de vrij standaard bruteforces, die zie je altijd wel.
Maar tot nu toe niet meer van die mass bruteforce aanvallen gezien van honderden per dag. Hopelijk is de rust weergekeerd.
TotallyHosted
18/03/14, 13:36
Momenteel 'slechts' < 150 geblokkeerde IP's over 24 uur gemeten. Dat was vorige week af en toe 600+. Dus redelijk rustig nu!
Ik ben benieuwd of dit artikel op Tweakers het over dezelfde aanval heeft:
http://tweakers.net/nieuws/94901/aanvallers-kraakten-25000-servers-en-kernel-punt-org-om-spam-te-versturen.html
Ziet er wel naar uit.
Ik heb trouwens die snippet eens gedraait op alle servers.
En wat blijkt? Op de pas nieuw geinstalleerde DA server blijkt deze infected aan te geven, terwijl er nog niets op draait behalve DA en CSF firewall:
ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
Ziet er naar uit dat we die dus opnieuw moeten gaan installeren. :(
Maar wat is nu precies geinfecteerd vraag ik me dan af....
Never mind... ik dacht al... openssh clients was niet eens geinstalleerd, daar gaf het script geen fout op maar gaf gewoon aan system infected.
Leek me al stug bij een pas nieuw geinstalleerd systeem. Nu geeft ie clean aan.:)
Blacky : bedankt om er mij op te wijzen.
All systems are clean...
Graag gedaan IT-works. Ik dacht ik meld het maar even voordat anderen zich ook een hoedje verschrikken terwijl er niets aan de hand is. ;)
Het botnetje lijkt weer te zijn opgestart, tenminste, ik zie weer een redelijk aantal BF's staan.
Het botnetje lijkt weer te zijn opgestart, tenminste, ik zie weer een redelijk aantal BF's staan
Dit wilde ik ook net melden, er komen weer veel dovecot_login authenticator failed meldingen binnen
Mwah valt mee hier. Als het klopt wat Tweakers zegt en dat er vn de 25000 nog 10000 over zijn dan is dat nog genoeg over, dat is geen opnieuw starten.
Er is wel weer een verhoging te zien, maar op de servers in ons beheer tot nu toe slechts een kleine 30 per server, geen honderden per dag zoals voorheen.
Heb hier op 1 server vanaf +/- 12.00 al rond de 80 om mijn oren gekregen. Dit terwijl ik direct op veel landen een block heb gezet.
Het zijn allemaal
dovecot_login authenticator failed for ([192.168.2.33]) [202.60.70.120]:51912: 535 Incorrect authentication data (set_id=oracle)
dreamhost_nl
21/03/14, 20:04
Ik begrijp niet echt wat ze er mee opschieten eerlijk gezegd. Nu komt er weer de hele tijd de gebruikersnaam "test" voorbij v.a. verschillende wereldwijde IP-adressen. Hinderlijk is het in ieder geval zeer zeker! :angry:
sinds vanmiddag zie ik idd weer een stijging, maar zeker minder dan voorheen
4service: Lijkt me dan een ander botnetje, het eerdere waren echt bruteforces op naam@domein.nl etc. en die wat jij nu hebt (en ik ook alleen niet zoveel momenteel) zijn er inderdaad met alleen set_id=oracle en ook andere id's zoals webmaster, postmaster, scanner, test.
Die zie je normaliter ook al altijd, alleen niet in deze mate. Ik vraag me net als Dreamhost eerlijk gezegd af wat ze daaraan hebben, want in de meeste gevallen heb je toch echt een naam@domeinnaam.tld nodig als usernaam om in te loggen, enkele uitzonderingen (zoals zonnet) daargelaten. Dus dat verbaast me wel een beetje.
Vannacht kwam botnet Joomla / Wordpress brute force ook weer eens langs.
TotallyHosted
24/03/14, 11:06
Wij hadden vrijdag meer dan 1100 IP's op de blacklist, dat was wel een record. Let wel, dat wij slechts voor 24 uur blokkeren, dus het is echt een stevige aanval!
Op dit moment zijn het er 'slechts' nog 283.
dreamhost_nl
25/03/14, 12:39
Is er eigenlijk al iemand die een bepaalde IP-range of mogelijk zelfs een volledig land heeft geblokkeerd naar aanleiding hiervan?
Sommige netwerkbeheerders lijken weinig te doen met de aan hen verstuurde Brute Force meldingen.
TotallyHosted
25/03/14, 14:36
Gezien de verdeling van IP's die wij tegenkomen, is het blokkeren van ranges echt niet aan de orde. De verdeling naar land wijzigt ook nogal, al scoren China, India en Thailand wel hoog.
Opmerkelijk overigens ook dat (bij ons) de verdeling op service als volgt is:
- FTP: Circa 76%
- Mail: 13%
(- SSH: 1% neem ik voor het gemak even niet mee aangezien we dat op vrijwel elke server op IP-basis whitelisten)
Inderdaad opmerkelijk. Bij ons is het vrijwel uitsluitend smtp auth. Ftp momenteel juist opvallend weinig. Maar ook hier afkomstig uit vele landen dus ranges blokkeren heeft geen zin.
Dit zijn zo de landen die tijdelijk block als er weer veel activiteiten op FTP en SMTP zijn.
EG,IN,IR,TH,PK,VN,MY,KR,TW,TR,UA,BG,TN,RU,MX,KZ,PH ,EC,LV,ZA,AM,RO,BY,CL,IQ,CN,CO,AR,DZ,LT,RS,MA,SA,T T,BR,VE,CZ,AE,ID,SK,PE,HT,NG.
Van deze landen komt zo'n 80% weg
De ene keer is er meer ftp en dan weer SMTP.
Nu gelukkig rustig.
TotallyHosted
26/03/14, 11:04
Bij ons is de afgelopen 24 uur juist weer een record geweest, meer dan 1200 verschillende IP's op de blacklist... (gaat wel om tientallen servers)
Tientallen servers? Dan valt het toch mee? Als je al 20 pakt is het 1200/20=60 per server. :)
TotallyHosted
26/03/14, 15:28
Vind ik toch nogal wat. De laatste tijd is dat enorm toegenomen. En 60 per server is misschien niet zo veel, omdat die alle 60 alle servers aflopen ... het zijn daadwerkelijk 1200+ unieke IP's die we blokkeren.
Ja vergeleken met normaal is het wel veel ja. Maar in de context van deze aanvallen valt het mee bedoelde ik.
In het begin hadden we hier zeker een 500 verschillende ip's per server. Dan valt 60 per server mee. Wij hadden er 115 over 3 servers tussen 02.30 vannacht en 14.00 vanmiddag.
Apart is wel dat er bij 2 stuks de smtp het meest waren en bij de andere server de ftp het meest was.