DoS angreb imod spammere

Jeg kom til at kigge lidt på min mailserver log. Det fik mig til at tænke, at det ville da være rart om man kunne gøre livet surt for et par spammere.

Jeg overvejer derfor hvad jeg bedst kan gøre for at udføre et DoS angreb imod spammerne. Selvfølgelig vil jeg holde mig til etiske metoder, og derfor vil jeg holde mig til at alle de pakker jeg sender er en del af den TCP forbindelse spammeren selv åbner til min mailserver. Hvis de holder op med at sende TCP pakker til mig, så sender jeg heller ingen pakker til dem.

Jeg overvejer så, hvad er det mest effektive man kan gøre imod dem, når jeg vil holde mig indenfor de begrænsninger.

En af de idéer jeg har overvejet er noget i retning af LaBrea. LaBrea er oprindeligt lavet som et DoS angreb imod orme, som spreder sig vha. buffer overflows over TCP. Det tvinger ormen til at sende sit buffer overflow en enkelt byte ad gangen med ganske lang tid mellem pakkerne for på den måde at holde en tråd optaget i ormen, som den ellers kunne have brugt på andet.

En anden idé jeg overvejer går i den modsatte retning og går ud på at presse spammeren til at sende pakker med stor hastighed ved at modarbejde TCPs styring af båndbredden. Under normale omstændigheder lader TCP i første omgang hastigheden vokse eksponentielt indtil den rammer grænsen og tilpasser sig så til den tilgængelige båndbredde. Men hvis jeg som modtager sender passende svar kan jeg få afsenderen til at blive ved med at sætte hastigheden op eksponentielt, indtil de laver et DoS angreb på sig selv.

Desværre er sidstnævnte idé ikke så praktisk fordi spam mails generelt er for korte til at gøre den metode interessant. Inden afsenderen når op på fuld hastighed er mailen allerede forbi.

Jeg overvejer om der er noget man kan gøre på SMTP niveau for at få afsenderen til at sende mange flere data, men jeg kan ikke finde på noget.

Er her nogen som har bedre forslag til hvad en mailserver der modtager spam kan gøre for at gøre livet surt for spammerne.

Jeg læste lidt op på det her for noget tid siden og faldt over denne side.
Jeg har desværre aldrig fået afprøvet det, men baseret ud fra hans konklussion til sidst, er det måske være værd at prøve?

Edit: Ved nærlæsning kan jeg se at du allerede har kigget nærmere på noget á la denne løsning, men sådan går det når man læser det hurtigt igennem.

Du er ikke den første som har fået den idé.

Sidst jeg kiggede på det, blev min konklusion dog at det at sende data tilbage over den indkomne TCP forbindelse, er virkningsløst, da spammer softwaren blot lukker forbindelsen hvis den modtager for mange data.

Jeg tror i stedet for at du skal over i at sende dine data via UDP, således at det ikke kan blive afbrudt automatisk af spammeren. Gør du det skal du selvfølgelig overveje at din ISP kan have regler for din brug af din internetforbindelse til at floode med (Jeg ved at TDC har sådanne regler) så du skal nok ikke sende så mange data at det bliver opdaget af ISP'en.

Selv hvis du følger de retningslinier, betyder det desværre ikke det store, så længe du er den eneste som gør det. De fleste spam netværk er botnets af inficerede computere og ejerne af disse computere opdager ikke hvis deres linie en sjælden gang imellem bliver flooded.

Hvis du derimod er karismatisk nok til at starte en trend, så tror jeg at det kunne være et ganske effektivt modtræk til spammerne.

Nu er der jo så bare den fejl ved ideen at spammere ikke sender spam fra EN mail server. De sender via en flok inficerede maskiner som står hjemme hos intetanene ejere.

Du ville ikke opnå andet med din hævn-DOS end at disse uskyldige personer får en aften eller to hvor deres youtube ikke lige kører så godt.

Det er netop formålet at disse mennesker skal opdage at der er noget galt med deres maskine og derefter gøre noget ved det.

Så længe alting kører som det skal, så har de jo ingen grund til at undersøge deres maskine og finde deres malware.

Jeg er overbevist om at hvis de pludselig ikke kan bruge deres internetforbindelse, så vil de undersøge hvad der er galt, feks ved at køre en virus scanner.

conFen (2) skrev:

baseret ud fra hans konklussion til sidst, er det måske være værd at prøve?

Jeg havde egentlig forestillet mig, at jeg skulle et lag længere ned i stakken end han er. Han bruger tilsyneladende en standard TCP stak men fra applikationen instruerer han dog kernen om at bruge en meget lille modtage buffer.

Jeg havde forestillet mig at jeg skulle lave min eget TCP lag, som ikke nødvendigvis overholder TCP standarden. Jo mere jeg kan forvirre TCP laget på afsenderen, des bedre.

Og jeg synes det er lettere uopfindsomt at bruge en 4xx kode, hvis hele mailen bliver modtaget. Jeg vil hellere lade være med at acknowledge den TCP pakke, der afslutter mail DATA.

Dermed vil afsenderen både være nødt til at retransmittere den pakke mange gange, men vil samtidigt ikke vide om mailen er blevet accepteret i den anden ende eller ej. Så han er nødt til at vente på svar for at finde ud af, om hele mailen skal retransmitteres.

TCP pakken der afslutter mail DATA kan evt. besvares med sidste fragment af en meget stor fragmenteret pakke.

Mort (3) skrev:

Sidst jeg kiggede på det, blev min konklusion dog at det at sende data tilbage over den indkomne TCP forbindelse, er virkningsløst, da spammer softwaren blot lukker forbindelsen hvis den modtager for mange data.

Det har da heller aldrig været planen. Jeg ville hellere overbelaste deres upstream ved at tvinge dem til at sende mange pakker.

Jeg har mere downstream end upstream, hvis det samme gør sig gældende for afsendren, så vil det være meget mere effektivt at tvinge dem til at sende mange pakker.

Mort (3) skrev:

Jeg tror i stedet for at du skal over i at sende dine data via UDP

Det ville stride imod de etiske principper jeg nævnte i #1, at jeg vil følge. Desuden tror jeg slet ikke på at det vil have den effekt jeg ønsker.

Mort (3) skrev:

De fleste spam netværk er botnets af inficerede computere og ejerne af disse computere opdager ikke hvis deres linie en sjælden gang imellem bliver flooded.

Jeg har slet ikke til hensigt at floode dem. Men hvis man kan få dem til at floode deres egen upstream vil det være et plus.

TrolleRolle (4) skrev:

Du ville ikke opnå andet med din hævn-DOS end at disse uskyldige personer får en aften eller to hvor deres youtube ikke lige kører så godt.

For det første synes jeg at modtagerne af spam mails er mere uskyldige end dem der lader deres computere være en del af et botnet. For det andet mener jeg at en sløv netforbindelse er til væsentlig mindre gene end alle de spam mails computeren kunne sende i den periode.

Er det du er ude på ikke noget ligende man har lavet med tarpit?

Hubert (7) skrev:

Er det du er ude på ikke noget ligende man har lavet med tarpit?

LaBrea som jeg nævnte tidligere er opkaldt efter La Brea Tar Pits.

At stalle klientens TCP forbindelse uden at bruge resurser på serversiden er i princippet nemt nok. Men jeg ville gerne ramme dem lidt hårdere end at de bare har massevis af åbne TCP forbindelser.

I stedet for at lade dem sende data meget langsomt ved at sende en byte ad gangen med sekunders mellemrum, så kunne det være sjovt at lade dem sende data meget hurtigt, for på den måde at overbelaste deres egen upstream.

Jeg ved bare ikke om der er noget man kan gøre i SMTP protokollen som får klienten til at sende flere data. For ellers risikerer man bare at klienten er færdig med at sende før det bliver sjovt.

kasperd (8) skrev:

Jeg ved bare ikke om der er noget man kan gøre i SMTP protokollen som får klienten til at sende flere data.

Hvis man kan, så det alligevel kun virke på afsendere, som overholder SMTP protokollen. Men spam fra afsendere som ikke overholder SMTP protokollen er til gengæld nemmere at filtrere, så det ville stadigvæk ramme, hvor der er mest brug for det.

kasperd (9) skrev:

Hvis man kan, så det alligevel kun virke på afsendere, som overholder SMTP protokollen. Men spam fra afsendere som ikke overholder SMTP protokollen er til gengæld nemmere at filtrere, så det ville stadigvæk ramme, hvor der er mest brug for det.

Tja der ville du vel typisk ramme "uskyldige" mailservere der bliver brugt som relay servere?

Hubert (10) skrev:

Tja der ville du vel typisk ramme "uskyldige" mailservere der bliver brugt som relay servere?

Godt du huskede at få anførselstegn om uskyldige. I den udstrækning det sker vil der være nogle legitime brugere, der får deres emails lidt senere end de ellers ville have fået. Det synes jeg er en rimelig pris at betale for at nogle andre brugere får lidt mindre spam.

Hvis forsinkelserne når et niveau hvor brugerne begynder at beklage sig burde administratoren hurtigt opdage at mail serveren sender spam og få lukket for det.

Og et åbent relay vil hurtigt komme på blacklists som gør at legitime mails sendt gennem den server har stor risiko for at blive filtreret som spam. Jo hurtigere administratoren får lukket helt for relaying af spam, des mindre er risikoen for problemer på langt sigt.

kasperd (1) skrev:

Jeg overvejer om der er noget man kan gøre på SMTP niveau for at få afsenderen til at sende mange flere data, men jeg kan ikke finde på noget.

Kunne kreativ brug af en EHLO eller en TURN kommando hjælpe?

stekkurms (12) skrev:

Kunne kreativ brug af en EHLO eller en TURN kommando hjælpe?

Serveren har jo ingen indflydelse på hvilke kommandoer en spammer sender.

TURN er deprecated. Jeg har aldrig set den brugt, hverken af legitime afsendere eller af spammere.

EHLO kommandoer ses selvfølgeligt. Men jeg kan ikke se hvad den ville kunne udnyttes til. Svaret på en EHLO kommando er typisk længere end svaret på alle andre kommandoer. Men det er jo mig, der sender svaret. Og jeg har jo ikke tænkt mig at sende store datamængder, jeg vil have spammeren til at sende store datamængder, hvilket jeg ikke opnår ved selv at sende et langt svar. I øvrigt kunne jeg jo altid sende et langt svar på en vilkårlig kommando, hvis det var det, jeg ville.