Niet in de extreme mate die jij noemt, maar er is altijd al overmatig scanverkeer van zogenaamde "security onderzoekers" die menen dat ze door deze zelfgekozen titel legitiem alles kunnen scannen wat los en vast zit.

Ik zie dit al op webhosts sinds 1998.

Soms enkele honderden, soms duizenden webhits.
Soms webscans, (meerdere per dag) en portscans

En gemiddeld 10.000 ssh connections en 3000 mysql conns per dag.

Heel veel traffic uit de Oekraine (zitten veel scammers)

Dus dit is normaal

Ik doel specifiek op een toename sinds pasen. Normaal zie je inderdaad altijd wel wat verkeer, maar ik heb in de 20 jaar dat ik sites host nooit zoveel 404 / 403 meldingen gezien op echt dagelijkse basis vanuit specifiek Microsoft cloud servers.

Dat is al maanden gaande.

We hebben ook contact met MS hierover gehad als business partner.
Ze zijn er kuch mee bezig. Antwoord was niet totaal niet naar wens dus eigen lijn getrokken.

Onze procedure is eerst single IP block (helpt nooit)
Gaat door over meerdere dan een /24 (1 Class C) block (helpt 50/50)
Gaat het nog steeds door dan een /16 (256 Class C) block

En dan komen we als het om MS Dublin dus uit bij het huidige actieve lijstje met blocks.

13.79.0.0/16 # MS Dublin DC abuse
13.74.0.0/16 # MS Dublin DC abuse
13.94.0.0/16 # MS Dublin DC abuse
23.102.0.0/16 # MS Dublin DC abuse
40.69.0.0/16 # MS Dublin DC abuse
40.113.0.0/16 # MS Dublin DC abuse
52.138.0.0/16 # MS Dublin DC abuse
52.169.0.0/16 # MS Dublin DC abuse
52.178.0.0/16 # MS Dublin DC abuse
52.164.0.0/16 # MS Dublin DC abuse

Die staan er al langere tijd in en geen klachten van klanten aan onze kant dat ze iets niet kunnen, missen.
Doe er mee wat je wilt ik garandeer je dat als ik ze hier uit de deny haal dat het meteen weer mis gaat.

Geen idee wat dit veroorzaakt

Ik weet alleen dat sommige IPs meer gebruikt zijn dan anderen en daarom dus ook meer traffic zien

Misschien een outbreak van een nieuwe worm of virus zou dit kunnen verklaren...als je dat wil weten kun je gewoon eens met tcdump alle traffic loggen op die host, en analyzen. Of installeer eens een van die honeypot scripts die een fake web/ssh/ftp server emuleren en kijken naar het gedrag..

Je hebt in elk geval te maken met automatische scans , de meeste zijn automatisch tegenwoordig
Misschien zit je op het netwerk van iemand die doelwit is maar dit is speculatie

1. Duizenden hits per dag
2. Alles op je wp-admin?


Lijkt me dat ze je wpadmin pass proberen te raden

Dit kun je doen:

1. Wp-admin in andere directory zetten, wpa-admin zelf via htaccess redicten naar 501 of anders gewoon 404 laten

2. Klein wp-admin scriptje maken die de HTML inputs van wpadmin neemt (login,pass) en deze loggen. Dan weet je zeker of je target bent van een bruteforce attack op wpadmin

Wp-admin in de standard dir zetten op je webroot is trouwens bad security practise. Ik delete ook de documentatie en Changelogs en voorbeeld configs uit de dir om "versie detective" tegen te gaan, soms heeft net die ene oude versie een bug die ze kunnen exploiteren

Zinloos dit zijn geen wordpress only probes helaas
Hier voorbeeldje
https://www.abuseipdb.com/check/52.169.1.219

Hier moet je zo min mogelijk tijd en energie in steken als je ziet dat er honderden anderen ook melding hebben gemaakt dan weet je dat het geen gerichte aanval is op je organisatie dan is de kans ook vrijwill nill dat ze het op een andere manier gaan pogen specifiek voor jou dit zijn simpelweg willekeurige aanvallen vanaf geautomatiseerde bots.

Gooi de range in een deny, drop, kill hoe het ook mag heten in je firewall situatie.
Komen er geen klachten uit niet meer verder over nadenken.
Komen er wel klachten uit zet de specifieke IP van de range in een ignore en als dat niet helpt wel dan moet de klant van je maar eens gesprek voeren met hun leverancier.

Het probleem van deze probes is niet dat ze slagen (tenzij je de boel niet op orde hebt) het punt is dat all die open connecties CPU vreten en accounts richting hun limiet duwen als je een afgeschermde container opzet gebruikt zoals CageFS of erger als je dat niet doet dat je beveiliging zichzelf dus de nek omdraait door dat het de requests constant een timeout moet geven op een rule trigger of script omdat het tegen een hardlimit aanloopt van de webserver.

Het enige wat je doet door een script er tussen te hangen om te onderzoeken is extra belasting op de server realiseren.


TLDR;
Reputatie check doen bij hoge confidence level blocken op range.
Resultaat afwachten en bijstellen indien nodig bij klachten.

Elk verzoek levert een 404 op. Er staat niet eens wordpress op de server.

Er zijn heel veel verschillende bestanden die worden geraakt (allemaal 404). Lijkt haast wel of bijvoorbeeld 'nikto' herhaaldelijk zit te draaien. Je vraagt je echt af wat het voor zin heeft dat vaker dan 1x te doen, behalve dan om vooral tegen fail2ban aan te lopen en weer een AbuseIPDB melding erbij te zien komen.


Duidelijk, ze zijn dus aan het slapen daar in Dublin.

Duidelijk, ze zijn dus aan het slapen daar in Dublin.[/quote]Nee.
Het is gewoon omzet voor M$. Alleen een rechterlijk bevel of inbeslagname zal helpen.
Het melden van abuse bij een hoster heeft totaal geen zin is mijn ervaring.

Met het blokkeren van complete /16 ranges van cloud providers loop je aanzienlijk kans, dat je ook legitiem verkeer blokkeert. Bij de whois gegevens kan je vaak de customer subnets identificeren, binnen de /16 - daarmee kan je veel gerichter blokkeren.

Wat is hier nieuw aan, gebeurt elk moment van de dag, door miljoenen (vaak geinfecteerde) hosts op het internet.

Implementeer een IDS dienst zoals CrowdSec of Cloudflare en je houdt de meeste ellende al direct tegen.
Het is nooit 100% maar zo te horen heb je nu helemaal niets draaien?

Klopt dat kan en het is ook goed aanvullende informatie.


Ik deel hier uiteraard niet wat de hele onderzoek procedure is geweest en hoeveel meldingen we wel niet hebben gevonden in ons systeem van die Class C's alsmede de impact analyse maar ik kan je zeggen aanzienlijk veel ellende. Ter vergelijking we hebben twee /24 block van MS India 1 van MS Australia en 1 van MS Singapore. De rest van Microsoft is enkel en puur MS Dublin en mix van /24 en /16 met losse uitzonderingen die we al voor de meldingen hadden genoteerd hadden.

Sterker nog bijna alles in die categorie is Microsoft. Ik heb er vier actieve van Digital Ocean in en die naam zal niet veel mensen verbazen als het op onruststokers aan komt. De rest zijn allemaal individuele tijdelijke of permanente IP blocks. maar MS Dublin die spant de kroon al maanden en klaarblijkelijk is er geen verbetering nog dus bij ons blijven die ranges lekker op de lijst.


Zoals aangegeven als er klachten zijn dan kun je exceptions neer zetten je kan ook zoals je aangeeft later de range verkleinen op je gemak maar moment dat je duizenden aanvallen krijgt richting jou ongericht dan is het zaak de boel eerst tot rust te brengen en dan gericht vrij te geven waar nodig.

Doe je dat andersom dan loop je kans dat er veel meer meldingen uitkomen omdat mensen gaan klagen over traagheid of mischien wel uitval van functies of sites. Afterall webservers die hun limiet bereikt hebben die gaat niet rustig onderscheid maken tussen de onruststokers en legitieme gebruikers die dropt gewoon de connectie die over het limiet op dat moment gaat of als je CloudFlare hebt van die irritante captcha's en connection throtling. En het is helaas een utopie te denken dat je firewall, IDS en andere beveiliging alles kan opvangen alle tijden.


Dit vak blijft hoe dan ook gewoon zelf nadenken en situaties inschatten. Klakkeloos ook onze ranges overnemen is niet geadviseerd en ook zeker niet als advies bedoeld naar enig persoon. Het dient puur als bevestiging van de vermoedens en extra informatie wat er gerelateerd aan gaande is gezien van een ander in het vak en kan worden gebruikt om te zien of er ook aanverwante bijzonderheden op je eigen infra zijn met die ranges. Hoe je vervolgens je eigen infra regelt en de afwikkelingen van issues dat is niet aan mij.

Heb je geheel gelijk in. Wat ik verder merkte bij die customer ranges, is dat het afhankelijk is hoe je het opvraagt, of je de /16 krijgt, of specifieker (whois query op linux geeft beste resultaat bij mij).

Mijn server returned altijd een HTTP 200 response met een speciale zipbomb. Als je met de browser naar het IP adres navigeert crashed de browser na een minuut omdat de zipbbomb het geheugen laat vol lopen (in firefox, duurt wel even; in chrome crashed alleen de tab).
All mijn prive selfhosted websites zitten onder een niet publiekelijk vindbaar subdomein "raadmaar.example.ltd" onder een wildcard certificaat "*.example.ltd". Bezoek je mijn server zonder een van deze domeinen dan krijg je de zipbomb. Dit is natuurlijk "security by obsecurity" en niet echt een vorm van beveiliging. Maar het werkt wel en zorgt ervoor dat bots in iedergeval niet in mijn normale logs zitten.
Als ik in de logs kijk van de zipbomb zie ik zoon 200+ requests per dag, veel van deze bots kunnen de zipbomb niet eens openen omdat het niet echte browsers zijn.

Nee dat is geen security by obscurity het is de wet overtreden.

Je brengt bewust schade aan een andermans systeem en data die verloren gaat is op jou te verhalen.
En je internet provider, colocation, carrierhotel zou je direct eruit trappen als ze het doorhadden.
Je bent niet gemachtigd om offensive security uit te voeren zonder enige vrijwaring van alle betrokkene.

Ik zou ook het liefste bot servers letterlijk verbranden zodra ze iets doen maar ik heb me aan de wet te houden zoals ieder ander en de weg is zoek als men zelf actie gaat ondernemen. Laat staan dat je de gevolgen werkelijk overziet omdat er hoeft ook maar iets mis te gaan met je script of er komt een bezoek van een onschuldige die er melding van maakt en je bent de lul.

Echt niet verstandig.

@15:26, Ik vind uw mening over het legale aspect een goede toevoeging, wel zou ik u willen vragen om de bijbehorende wet te noemen om uw claim te versterken.

Daarnaast is het crashen van een process na het scannen van mijn IP meer een irritatie en kan er nouwelijks van schade gesproken worden omdat de verbinding door hun zelf is geinitieerd. Ook geeft elke normale browser een veiligheidswaarschuwing voordat de zipbomb actief is, omdat de zipbomb achter een niet valide certificaat zit om het echte domein niet kenbaar te maken. (Het is altijd via DNS te vinden, maar veel partijen gebruiken de DNS data niet.)

Voor mij is gewoon leuk om mee te spelen. Het idee dat de scanner van een groot bedrijf op mijn zipbomb stuit is gewoon grappig en ik denk dat de techneuten de uniekheid van mijn implementatie kunnen waarderen. Het is niet een zip file die ik van het internet geplukt heb maar ik heb het zelf moeite gedaan om het te implementeren. Ik snap ook dat er op dit forum mensen zijn met een veel strictere form van integriteit, wat ook leuk is om te zien.

Het is inderdaad belangrijk dat je een goed detectie systeem hebt draaien. En monitoring. Je kunt een detectie systeem opzetten middels bijvoorbeeld https://github.com/stamparm/maltrail Je hebt wel Linux kennis nodig. (maltrail detecteerd alleen) Vervolgens kan je deze informatie dynamisch middels rules importeren in een firewall welke dit ondersteund.
Dan worden de gedetecteerde Host automatisch geblokkeerd.

Je hebt hier wel voldoende netwerk kennis voor nodig. Of in combinatie met een intrusion Prevention System (IPS) bijvoorbeeld https://www.snort.org

Ik heb meerdere Linux server draaien welke alleen als beveiliging dienen en het verkeer filteren en door routeren naar verschillende systemen. Het is niet verstandig om servers te verbinden zonder enige beveiliging of detectie. Dan vraag je om problemen. Zeker met A.I. is dit gewoon not done. Weet waar je aan begint.

DDoS aanval met beperkte impact** (art. 138b Sr)
Het voorhanden hebben van malware (art. 139d lid 2 sub a en b SR)
Verwijderen / ontoegankelijk maken van gegevens/ toevoegen van gegevens (art. 350a Sr / 138ab Sr)

Ja, technisch gezien zou het aanbieden van een ZIP bomb illegaal (kunnen?) zijn.
Echter, als het tot een rechtszaak komt, zal het volgende worden meegenomen in de overweging:
1. Het is een passieve of reactieve handeling, je bent niet actief bezig met aanvallen.
2. Je gebruikt het als middel om je systeem te verdedigen, dit kan worden gezien als digitale zelfverdediging.
3. Een ZIP bomb is passieve data, er zit geen actief kwaadaardig component in.

En de kans dat hier iemand om word aangeklaagd door de hackers is echter extreem klein.
Gebeurt dat wel, dan heb je ook meteen de identiteit van de aanvallers te pakken en kan je ze terug aanklagen.
Ik vraag me dan af wat de straffen zijn voor het actief aanvallen van andermans servers?

1.Nee want de gebruiker heeft *zelf* een script gemaakt met doel tot uitval van diensten van systemen die verbinding maken naar publiekelijk toegankelijke data. Dat is geen bijeffect dat was de intentie. We hebben het daarnaast niet over een achter slot en grendel omgeving en dan nog mag het niet. Er zijn zeer weinig in de sector die uitgezonderd zijn daarvoor zoals functie bekleders in defensie binnen de IT binnen specifieke teams of bij volledige vrijwaring van alle betrokkenen voor een pentest. Beide is niet van toepassing hier.

2. Nee dat kan het niet. Legitieme verdediging is het droppen van verbindingen, toegang ontzeggen en leveranciers, mensen waarschuwen tot actie bewegen. Er bestaat geen enkele situatie waar het in de Nederlandse wet is toegestaan een offensief er tegen te voeren als regulier ITer met effect op de andere omgeving. Daarom hebben we abuse adressen bij providers om melding te maken en sluiten we niet zelf de boel af.

En leg maar eens uit aan een rechter hoe het enkel connectie maken naar een resource als legitiem wordt gezien tot uitvoeren van een tegenaanval. We hebben het niet eens over een ruletrigger met een anomaly score we hebben het over alleen al een ping, verbinding maken over een publiekelijk gehost data zover het verhaal nu is uitgelegd.

Dat je die resources niet in de zoekmachines etc adverteert doet niet af aan het feit dat het niet afgeschermd is. Als ik mijn site niet indexeer en er komt een bezoeker op kan ik niet boos worden dat ze data inzien, bandbreedte verbruiken. Ik heb alle middelen om het achter een inlog te zetten maar instead vertrouw ik erop dat men de ingang niet ziet omdat ik er geen bordje ingang boven heb hangen. Net als dat als ik mijn voordeur open laat ik iemand kan verzoeken weg te gaan maar als deze vervolgens weigert ik toch echt de politie inschakel en niet zelf eruit gooi en een linkse geef.


3. Wat dacht je dat een DoS, DDoS is? die packets hoeven ook niet persé kwaadaardig component in zitten maar als je vervolgens paar miljoen packets stuurt ervan dan is de intentie en uitwerking wel kwaadaardig. En een decompressie bom valt onder malware in de categorie van data amplificatie. https://cwe.mitre.org/data/definitions/409.html


Is de kans op aanklacht groot, nee tuurlijk niet en voor zelfde is dit puur stoere praat en bestaat die beveiliging helemaal niet. Ik heb mijn ernstige twijfels over het hele veraal omdat zowat alle modernde software beveiliging heeft tegen decompressie bommen maar of het wel of niet echt is dit is beyond slippery slope en iets hoeft niet waar te zijn om schade te veroorzaken.

Ik wil niet dat andere ook maar een seconde denken van de dit een goed idee is om zelf te implementeren. Je gaat ook niet op een autoforum verkondigen dat het een goed idee is om door rood te rijden omdat je geen tegenliggers ziet. In de zelfde zin kunnen we niet suggereren dat er verzachtende omstandigheden zijn die zijn er wettelijk niet.


Informatie verder verkregen op illegale manier voor het vormen van een tegenaanklacht is toelaatbaar maar levert je mogelijk meer ellende op dus ja je kan terug aanklagen maar is dat ook heel erg realitisch? Weet je echt wie er achter zit? Wat als het een zombie is van hive botnet. Wat als het systeem dat verbinding maakte simpelweg kwetsbaar was en is misbruikt en de eigenaar helemaal niks er mee te maken heeft, wou hebben. Zijn we vergeten dat het vinden van digitale criminelen in de praktijk uitermate lastig is omdat ze vaak juist niet in beeld komen in het hele proces?


De straffen worden verder bepaald aan de hand van de wetboek artikelen, de motivatie de schade, was het opzet, hoelang het heeft geduurd, berouw, medewerking aan onderzoek etc. De genoemde wetsartikelen hebben basis casus om op terug te vallen.

https://www.om.nl/onderwerpen/beleidsregels/richtlijnen-voor-strafvordering-resultaten/richtlijn-voor-strafvordering-cybercrime-2018r001

DDoS aanval met beperkte impact** (art. 138b Sr) first offender taakstraf 60 uur
Het voorhanden hebben van malware (art. 139d lid 2 sub a en b SR) first offender Gevangenis straf 1 maand
Verwijderen / ontoegankelijk maken van gegevens/ toevoegen van gegevens (art. 350a Sr / 138ab Sr) Taak straf 20 tot 120 uur.

Daar kan vanaf geweken dus worden maar dat is de basis casus.


Ik snap de frustratie van enig persoon die ooit een server beheerd heeft, dat je het liefst ze permanent van het internet af wilt halen en koekje eigen deeg wilt geven. Ik werk er dagelijks mee zoals wel meer mensen hier en het is bloed irritant maar we kunnen niet simpelweg voor eigen rechter gaan spelen. En ja dat betekend dat we altijd in het nadeel zijn tegenover criminelen dat is onderdeel van het vak.

Verliezen we de grenzen uit het oog dan worden we al heel gauw onderdeel van het probleem.

Beste Anoniem, WAT DAN?
Ja, je kan een 403 terug geven of een IP adresje blokkeren.
Maar dat lost niks op, de aanvaller gaat gewoon ergens anders verder en een nieuwe komt in de plaats.

Als ik niet rechter mag spelen, wie doet dat dan? Waar rapporteer ik dan de aanvallen op mijn machine?
Ga ik dan elke week met de logs naar politiekantoor toe? Anders wel per email, geautomatiseerd misschien?
Ik laat het aanpakken daarvan graag aan iemand anders over, maar dan moet die dat wel doen.

Bij wie behoor ik met de logs aan te kloppen om mijn digitale belagers achter tralies te krijgen?

Het is niet aan jou om de aanvaller te stoppen enkel aan jou om je systemen er tegen te beschermen.
Als je de veaagstelling aan begin hebt gevolgd dan weet je ook dat je aanvallen kan rapporteren naar de industrie lijsten als AbuseIPDB zijn algemeen bekekend en worden ook gebruikt voor onderzoek. Je kan je provider inlichten via een speciaal formulier, mailadres die de meeste hebben. Je kan je datacenter inlichten via SOC of NOC afhankelijk van je relatie met hun.
Ik coordineer met onze DC's bijvoorbeeld en deel aanval informatie zodat ze die hogerop ook in de infra kunnen zetten na controle. Als jij betrouwbare, makkelijk over te nemen data inlevert dan zijn heel veel providers geneigd er wel wat mee te doen zolang je zakelijke klant bent.

Je kan tevens de provider van de aanvallende partij inlichten en je kan ook naar politie of andere opsporing dienst ermee al heeft dat zelden enig effect tenzij je als provider optreedt en melding maakt van een zeer grote aanval.

Zaken tegen DDoS aanbieders, bots kunnen jaren duren maar dat wil niet zeggen dat rapporteren geen effect heeft dat is simpelweg meer bewijsmateriaal voor eventuele vervolging waarschuwen van andere en rijkwiijdte van een aanval verkleinen.

Onze taak is aanvallen afslaan en rapporteren that is it. Je kan rapportering automatiseren met iets als fail2ban zodat je er weinig omkijken naar hebt. Je kan je ook inschrijven voor fetch, pull push van waarschuwing lijsten.

Is het perfect nee maar het is wat we mogen doen

als mensen nu nog niet weten dat wp niet veilig is weet ik het ook niet meer.

Ik fake gewoon veel zodat ik de intenties kan bekijken mijn syteem kan ongeveer een 1000pages per seconde zeker aan dus gewoon meekijken en rotsen met fake data. Je leert het meest erdoor . De top calls dat ik kon verwerken was 12.000 / in 1h injecties in afwisseling van https calls ... nu te bedenken dat als ik mijn http bekijk deze amper worden gescant en dan is https veiliger ???? niet dus

ps bekijk ook eens de domeinen *.2.2 rare lijkend op ip domeinen die aardig systemen benaderen soms met success