Het speelt al maanden. Regelmatig veel IPv4 onzin verkeer naar poorten 80
en 443. Dit keer ACK’s. Ca 80 MBps (bytes, geen bits);
Verbinding valt steeds uit en komt dan weer terug. Dit is voor mij voor het eerst dat het zoveel data is, dat het de verbinding onbruikbaar maakt.
Maar weer eens een analyse gemaakt. Net als de vorige keren is het verkeer ook afkomstig van poorten 80 en 443. Het is nogal ongebruikelijk dat web requests van privileged (< 1024) poorten komen. Ik heb dit dan ook dichtgezet in mijn firewall. Met een DROP en zonder logging.
Zou het wat zijn dat Feedom dit kompleet blokkeert?
Dat kunnen we niet doen op individuele basis. Daarvoor hebben de routers onvoldoende mogelijkheden.
We zien al weken DDOS aanvallen op zowel onze infrastructuur als op klant prefixes. Als dat gebeurd routeren we de betreffende prefixes door de NaWas. Dat heeft weer gevolgen voor latency en veroorzaakt in individuele gevallen packet-loss als de scrubber legitiem verkeer toch wegpoetst.
Ik kan me niet voorstellen dat verkeer vanaf privileged poorten naar 80 of 443 legitiem is. Het idee is dan dus ook dit niet individueel te doen.
Eerder kwam alles vanaf ‘Braziliaanse’ IP adressen. Nu is het op een paar na (bv geen 10/8 of 127/8) vanaf elke IPv4 /8.
Het gaat hier niet om het dichtzetten van een bepaalde poort / blokkeren
van een bepaalde dienst. Als mensen bv poort 23 (telnet) open willen hebben, fine.
Heel oude DNS implementaties gaan wel van poort 53 naar poort 53. En misschien zijn er ook andere diensten van lage poort naar lage poort. Maar bij web heb ik het nog nooit gezien. Maar misschien bestaat het wel.
Maar als het echt helemaal niet bestaat zit het dus niets in de weg.
Ik vrees dat je hier met een N=1 blik kijkt en het wmb niet aan Freedom als InternetVrijheid minnende dienst is om generiek bepaalde sourcepoorten dicht te te zetten. En ja source verkeer vanaf < 1024 is doorgaans wat apart maar zeker niet verboden.
In mijn eerste post zit dus een scheeflees foutje. Het is 8 a 14 MBps. Da’s nog knap, want ik heb een 50 Mbps abonnement en dan zou je max 6.25 MBps verwachten. Blijkbaar werkt de snelheidsbegrenzing niet goed voor heel veel hele kleine pakketjes.
Ondertussen denk ik na over wat ik zelf nog kan doen. De ‘volle’ PPP link gaat steeds down omdat ie PPP echo-replies mist. Ik heb nu de lcp-echo-failure verhoogd van 4 (default) naar 10.
En is een snelheidsverhoging wat? Ik heb KPN AON, dus relatief duur, maar de prijzen voor hogere snelheden zijn een stuk minder duur dan vroeger. Voor mij is een snelheidsverdubbeling maar twee euro per maand extra.
Beetje een idee waar met of in welke adres serie/spreiding het vandaan komt ?
Mogelijk dat je iom Freedom dan de veroorzakende partij kunt (laten) aanspreken.
Eventueel, een ander (eigen) IP adres en Freedom dan het ingenomen adres een jaartje of zo kan laten opdrogen.
Ik neem aan dat je omgekeerd al 's een generieke of deep poortscan hebt gedaan op veroorzakende adressen om te bekijken of er/het/wat (niet) reageert.
Mij een ander IP adres geven is een hoop heisa en zeker geen blijvende oplossing. Iedereen kan dit overkomen en niet alleen bij Freedom.
Zoals ik al eerder aangaf, op een paar na is elke IPv4 /8 gebruikt. Dus 1.0.0.0, 1.0.0.1, 1.0.0.2, etc. En dan 2.0.0.0, 2.0.0.1 enzovoorts.
10.0.0.0 t/m 10.255.255.255 is overgeslagen, want RFC1918 private net. Zo ook 127.0.0.0 t/m 127.255.255.255, want localhost. En 224.0.0.0 t/m 239.255.255.255 is ook niet gebruikt. Voor de rest loopt het door tot 255.255.255.255.
Source IP adres spoofing kan gebeuren omdat er aan de bron niet goed gefilterd word. Als je een netwerk 10.0.0.0 t/m 10.0.0.255 hebt, is het niet de bedoeling dat er verkeer met als source IP adres 192.168.1.1 vandaan komt. Dit moet dus bij de bron geblokkeerd worden.
Ik heb een filter voorstel gedaan maar dat is afgeschoten.
Er is nu nog maar een ding dat je nog kan doen:
Net als in oude film waar in elektromechanische telefooncentrales de bron van een telefoongesprek word getraceerd, van knooppunt naar knooppunt naar knooppunt de bron traceren. Het verkeer is redelijk uniek dus dat zou moeten kunnen lijkt me. Is vast wel te automatiseren en misschien er wel een standaard tool voor.
Ondertussen vraag ik me af hoeveel verkeer het eigenlijk is. Zijn er mensen met vergelijkbare ervaringen en een snellere link. Wanneer is de link sneller dan de ddos.
Tot nog toe kan ik aan deze kant dingen redelijk mitigeren, dus dat is het punt niet.
Ik heb met netflow gekeken naar verkeer waarbij source en destination poorten beide kleiner zijn dan 1024.
Maar er lijkt verassend veel legitiem verkeer onder. Ik vermoed VPNs en/of backups want de top 10 is bijna geheel bevolkt door één-op-één verkeer van een “Nederlandse” ASen (lees netwerken) naar één Freedom IPv4-adres.
Het pieken van de top-talkers beginnen allemaal in het midden van de nacht en duren een paar uur. Dat zijn vermoedelijk backups. In totaal komen die pieken niet over de 1,2Gbit/s.
Pas op de 6de plaats komt verkeer van ‘veel sources’ naar ‘veel destinations’ en dat piekt naar kilobits per seconde.
IPv6 komt in de top 10 niet voor.
Kortom de aanname dat dat verkeer niet legitiem kan zijn klopt niet en dus filteren is inderdaad geen goed idee.
Ik heb de netflow data specifiek gefilterd op bovenstaande poort-combinaties:
(SrcPort = 80 AND DstPort = 80) OR (SrcPort = 80 AND DstPort = 443) OR (SrcPort = 443 AND DstPort = 80) OR (SrcPort = 443 AND DstPort = 443)
Dat verkeer komt over de laatste dagen in het algemeen nauwelijks te zien op de externe interfaces.
Met uitzondering van gisteren tussen 08:00 en 11:30. Toen was er en piek. Waarbij source AS ‘veel’, zoals verwacht de top-talker is met 120Mbit/s. Maar ons - Freedom dus - AS op de tweede plaats staat. Dat vind ik dan wel weer verassend.
Wat bedoel je met Freedom op tweede plaats?
Dat er veel verkeer naar Freedom gaat of dat er veel vandaan komt? Als firewalls van Freedom klanten een destination unreachable geven is er dus veel verkeer met Freedom als source.
Ik zie hier al jaren verkeer met (in algemene zin) lage source poorten. Bij mij zie ik dan niet zo zeer dat de source en destination poort gelijk zijn, maar dat de destination port diverse well known ports zijn, een bekende (en oude) truc om te proberen door firewalls heen te komen. Misschien vraag ik er ook wel een beetje om door eigen services, honeypots en tor draaien
Ik heb hier ook een rule gemaakt die SYN’s met een lage source port (<1024) in een blacklist plaatst waardoor ze niets meer bij mij kunnen bereiken, deze heeft afgelopen 17 dagen ca. 2700 keer getriggert. Ze komen uit de blacklist door 24 uur geen enkel verkeer naar mijn adressen te sturen, al sturen ze maar een enkel legitiem packet dan gaat de 24 uur opnieuw lopen. Door de grote dynamiek van IPv4 adressen heeft langer vasthouden toch geen zin.
Dit door een ISP laten filteren zou ik niet willen, alleen als het opt-in of opt-out is, wat xs4all bijvoorbeeld had. Bij gebrek aan keuze wil ik dat m’n ISP alles doorlaat en zorg ik zelf wel voor de beveiliging.
Toen ik nog een 5490 had, heeft het wel eens gespookt.
Of dat met poort 7547 te doen had toen, vraag ik me nog steeds af?
Bij Freedom een basis filter met een aan/uit knopje voor puristen zou ik prettig vinden.
Dat er ook mensen boos worden van het knopje, gaat me te ver.
Destination unreachable is natuurlijk ICMP en natuurlijk geen TCP poort 80 of 443 valt dus niet onder het filter.
Tussen 08:00 en 11:30 komt overeen met het door mij geposte grafiekje.
De source IP adressen zijn hier over the place. En ik zou verwachten dat verkeer van Freedom klanten ook Freedom source IP adressen heeft.
Dus het is me nog steeds niet duidelijk wat je bedoelt.
Waarom zou dat voor wie precies, voor een hoop heisa zijn ?
Ik mag - gelet je technische statuur - je zelf een IP wijziging relatief makkelijk zal kunnen anticiperen. Hooguit dat je dan even offline bent terwijl je DNS daarvan weer bijkomt. Ik doe tal van dingetjes maar kan met koffie drinken in een uurtje - daar gaan we weer, zucht - wel overschakelen.
En ja, iedereen kan jouw “DDOS” overkomen en ook mijn reden dat een ISP daarin flexibel zou moeten (en kunnen ) zijn wanneer het specifieke adressen betreft van gebruikers. Daarbij zullen veel gebruikers functioneel gezien ws helemaal geen permanente behoefte hebben aan een vast eigen IP adres die daarmee ook nog eens hun individuele “identiteit” als/op verbandhoudende ‘locatie’ blootgeeft.
