@Roy ja ik zie allerlei scanning plaatsvinden… soms hele subnetten van /24 waarbij elke systeem elke uur een poort checked na een uur 256 verder etc. tot ze alle poorten gehad hebben… .en dan opnieuw.
Je kan er ook van uitgaan dat NA jouw adressen de volgende onderzocht worden.
Er zijn allelrlei systemen die can adres 0.0.0.0 -. 239.255.255.255 ALL 64K poorten uitproberen.
Denk dan aan:
Wij hebben dan vaste adressen, er zijn ook hele volkstammen die random adressen hebben, dus dat een systeem lang op een adres zou zitten is een beperkt beeld op de wereldwijde werkelijkheid.
Bij Microsoft kun je tenminste nog piepen. Daar krijg ja na het eerste automatische antwoord aandacht van natuurlijke personen. Je moet wel een Microsoft-account aanmaken om bij het juiste formulier te kunnen komen.
Met Google krijg je gewoon geen contact. Die houden zelf ‘de reputatie van IP-adressen’ bij en kennelijk laten ze na een ‘tijdje’ (lees maanden) je e-mail weer door. Bij mijn weten kun je niet eens zien waarom je mailserver geblokkeerd is.
Even kort verder o.t.
Bij Microsoft kun je met wat moeite inderdaad een blokkade ongedaan krijgen. Maar na een maand of zo is 'ie er gewoon weer en kun je opnieuw hetzelfde verzoek doen (aan weer een ander persoon die weer van niets weet en het weer vervelend vindt en weer meeleeft en die het weer “permanent” gaat oplossen).
Vorig jaar nog ging het contact met Google vrij soepel en was het probleem snel en langdurig opgelost. Nu kan het alleen nog maar met een formulier waarvoor je een account nodig hebt en je verplicht bent een mobiel nummer op te geven.
Anyway, mijn prolemen met die twee lijken te maken te hebben met het IP adres / het IP blok, vandaar mijn eerdere uitegesproken hoop.
@arien , als een IP wissel voor mij een oplossing is dan heeft Freedom toch nog steeds “last” van die verstuurde pakketjes? Die blijven nu immers ook komen ondanks dat ze hier gedropt worden. En zo lang als ze komen, snoepen ze bandbreedte. Als deze pakketjes aan hele subnets worden gestuurd dan kan dat oplopen.
@Noci , Ja dat gebeurt mij ook inderdaad. Maar die scans houden vrij kort aan, gelukkig.
Voor zover ik kan zien zijn deze scans 24x7 continue vanuit vele bronnen.
Als je tcpdump/tshark/wireshark aan je link hangt zul je behoorlijk wat verkeer zien.
waaronder een deel gewenst verkeeer en een groot deel waarbij je vraagtekens kan zetten.
Ik wordt hier ook niet echt blij van al het volk wat zich “security researcher” noemt en denkt dat ze daarmee het recht te hebben om alles te scannen en te proberen. Het enige wat in hun voordeel spreekt is dat ze zich vaak duidelijk kenbaar maken, bijvoorbeeld door een opvallende user agent in http requests.
Zo plotseling als het probleem onstaan is, is het weer verdwenen: de afgelopen week precies 0 packets tegengehouden, waar het er eerst miljoenen waren…
Nu heb ik het probleem terug, maar dan op mijn primaire name server, die niet op mijn Freedom aansluiting draait. Nu met enkele duizended requests per minuut voor ferc.gov en het TLD .sl
Aangezien ik daar geen firewall apparaat voor heb staan, rest mij weinig meer te doen dan wat lokale firewall rules op de server zelf aanmaken. Lijkt vooralsnog effectief terwijl functionaliteit intact lijkt te blijven.
Voor de liefhebber:
Het source adres van je packets zijn FEITELIJK de targets die ge-DDOS-ed worden.
(UDP heeft geen sessies dus een random systeeem kan jou een pakket sturen voor een reuzen query met als “afzender” het aan te vallen doel en jij stuurt dan het antwoord naar dat doel…)
1e verdediging: antwoord UITSLUITEND op queries voor jouw adres… (Geen recursive resolution)…
Als je recursive resolution nodig hebt, zet een allow / deny ruleset op zodat uitsluitend de adressen/adres blokken waar jij antwoord wil geven dat ook krijgen.
2e verdediging: fail2ban opzetten zodat de logs van je name server met query adres gelogged worden en als er te veel / te snel aanvragen “van” een bepaald adres afkomen dan ook het adres geheel blokkeren voor ALLE verkeer.
Fail2ban kan de blokades voor je managen, 24x7 …
3e verdediging: ratelimit dns queries naar je DNS server op IP/UDP niveau.
Dan verwacht ik een query naar TXT records, die vaak het grootst zijn, met dnssec. Gek genoeg gaat het vooral om ANY queries. Deze worden sowieso gweigerd. Los van dat het hinderlijk is, snap ik niet wat nu het doel van deze “attack” is.
@Noci , het source adres is iedere query anders, steeds uit een grote reeks met iedere keer een ophoging van één of twee. Dus 12.23.34.1 , 12.23.34.2 , 12.23.34.3 etc. Lijkt me heel onlogisch dat het source adres het werkelijke target is (of het hele subnet moet het target zijn). Dit maakt fail2ban ook nutteloos, of ik moet na één hit het hele subnet blokkeren.
De name servers zijn niet recursive, uitsluitend authoritatief; recursive queries worden refused.
Het probleem is ook niet groot voor mij; deze vreemde attack is effectief te filteren door inspectie van de UDP pakketjes m.b.v. IPtables (rules heb ik hierboven als voorbeeld geplaatst zodat iemand anders er misschien zijn voordeel mee kan doen). Daarnaast wil ik dat (ook al is het antwoord “refused”) de server geen enkel antwoord geeft op deze requests.
idd. NXDOMAIN / REFUSED is ook een antwoord.
iptables kan het idd makkelijk filteren, het wordt een ander verhaal met NFT die heeft geen string filter meer, of met een andere firewalls (pf).
Dan filteren:
Het kan een poll poging zijn door een DOSS farm om te zien of er effect is… in dat geval is een block poging geen probleem.
Het kan een poll farm zijn om open resolvers te vinden, ook dan is een block geen probleem…
Het zou (heel kleine kans) een legitieme vraag kunnen zijn… maar dan is het enkelvoud, eenmalig. dus bij herhaald vragen is de kans dat het legitiem is best klein.
)