Besmette abonnee lastig te bereiken door ISP
Internetproviders zitten volgens de Internet Engineering Task Force (IETF) in een unieke positie om het botnet probleem aan te pakken, maar het bereiken van besmette abonnees is lastiger dan het lijkt. De IETF publiceerde onlangs aanbevelingen die ISPs kunnen volgen voor het vinden en verwijderen van bots. Providers zien zowel de activiteit van bots en zijn in staat slachtoffers te waarschuwen. Dit kan de omvang van criminaliteit op het internet verminderen. Zodra internetgebruikers weten dat ze geïnfecteerd zijn, kunnen ze zelf stappen ondernemen om de infectie te verwijderen.
Het detecteren van kwaadaardig verkeer dat van bots afkomstig is, zou op een manier moeten gebeuren die de privacy van de abonnee respecteert. Er zou dus geen persoonlijk identificeerbare informatie verzameld mogen worden. Gebeurt dat toch, dan moet de provider die informatie goed beschermen. Daarnaast mag de provider tijdens de bot detectie ook geen legitiem verkeer blokkeren. Het hele proces moet dan ook transparant voor internetgebruikers en end-user applicaties zijn, aldus het IETF. Die laat verder weten dat veel tools om bots te detecteren nog in de kinderschoenen staan.
Waarschuwing
Zodra er bots binnen het netwerk van de ISP zijn aangetroffen, moet het betrokken klanten gaan waarschuwen en dat is geen eenvoudige opgave. Bij het kiezen van het juiste communicatiemiddel is belangrijk dat cybercriminelen de berichten niet kunnen vervalsen om zo aanvullende malware te installeren. Providers kunnen besmette abonnees e-mailen, maar dan is het de vraag of de abonnee het bericht op tijd ziet, of het e-mailadres van de persoon in kwestie bekend is en kunnen aanvallers zich als de ISP voordoen.
Een andere optie die het IETF noemt is het bellen van abonnees. Dit brengt echter hoge kosten met zich mee en zelfs als de ISP de abonnee weet te bereiken, is het zeer waarschijnlijk dat die de technische kennis mist om het probleem te begrijpen. Ook het waarschuwen per post is een kostbare en trage aangelegenheid. Dat geldt niet voor de "Walled garden" aanpak, waarbij de abonnee in een gecontroleerde omgeving wordt geplaatst. Zodoende kan de Command & Control server niet meer met de bot praten. Toch kent ook de Walled garden verschillende problemen, zoals wanneer laat de ISP de gebruiker eruit.
Andere mogelijke oplossingen zijn het waarschuwen via Instant Messaging en SMS, maar in deze gevallen moet de vereiste informatie bij de provider bekend zijn. De beste optie volgens het IETF is het inlichten van abonnees via hun browser. Het voordeel ten opzichte van de Walled garden is dat deze optie het verkeer en gebruik door de gebruiker niet ontregelt.
Formatteren
Geïnformeerde abonnees moeten vervolgens naar een pagina worden doorverwezen met advies, maar de enige optie om zeker te zijn dat de bot weg is, is het formatteren van het systeem, zo stelt het IETF. Het verwijderen van bots zal dan ook veel gebruikers boven de pet gaan. Zeker door de komst van BIOS-malware, waardoor zelfs het formatteren van de harde schijf niet meer voldoende is.
Noem eens een bot op die dat doet. Iemand die met zulke uitspraken komt kun je niet meer serieus nemen.
dus demo bios malware (http://i.zdnet.com/blogs/core_bios.pdf) -> echte malware is al/ vast binnenkort in omloop
In mijn ogen moet je toch echt verkeer monitoren, en als je dat doet ben je in overtreding als ISP.
Als je de stumperts van KPN als voorbeeld neemt..... Deze sluiten je af als zij een abuse melding krijgen,. vervolgens geef je een abuse melding van buurman door waardoor je buurman zonder internet komt te zitten.
Nu de buurman geen internet heeft belt hij KPN, waarbij hij klaagt dat hij niet kan internetten. Nu vertellen ze meneer dat hij afgesloten is wegens abuse, om weer aangesloten te worden moet de heer een e-mail sturen naar een bepaalt adres .......... eeeuh yeah right..... je zit zonder internet en moet een mail sturen om weer aangesloten te worden. Als je zoiets bedenkt mag je je zelf echt een leeghoofd noemen dan nog maar niet te spreken over de mensen die het doorvoeren in een organisatie ;)
Dan moet er wel geaccepteerd worden dat er gebruik gemaakt wordt van deep packet inspection, aangezien zonder DPI het lastig is om verschil te maken tussen goedaardig en kwaadaardig verkeer wat gebruik maakt van dezelfde network poorten, tenzij er sprake is van communicatie met bekende kwaadaardige hosts op basis waarvan de traffic als kwaadaardig kan worden aangemerkt.... ?
Wat dat betreft gaat het niet alleen om het voorkomen van false positives, maar ook om de vraag of we al dan niet willen accepteren dat ons verkeer gesniffed wordt door de provider t.b.v. malware detection. Daarnaast is het de vraag in hoeverre dit mogelijk is vanuit technisch oogpunt. Immers zal al het verkeer van alle klanten sniffen een behoorlijke impact hebben op de performance van de netwerkapparatuur van de provider.
"Geïnformeerde abonnees moeten vervolgens naar een pagina worden doorverwezen met advies, maar de enige optie om zeker te zijn dat de bot weg is, is het formatteren van het systeem, zo stelt het IETF. "
Oftewel, het IETF gaat ervanuit dat iedereen een clueless newby is ? Laten we voortaan clean functies maar verwijderen uit antivirus software, en vervangen door een formatteer functie in virus scanners, zodat na detectie een systeem wordt gewiped ?
"Zeker door de komst van BIOS-malware, waardoor zelfs het formatteren van de harde schijf niet meer voldoende is."
Laten we de schijf dan maar ritueel verbranden, aangezien er geen goede tools bestaan om virussen en andere malware effectief te verwijderen.
Gebruiker kan nog wel wat doen, maar alleen via de proxy van xs4all. Al het rechtstreekse verkeer wordt afgesloten. Klant kan nog wel email lezen en versturen via de proxy.
EJ
dus demo bios malware (http://i.zdnet.com/blogs/core_bios.pdf) -> echte malware is al/ vast binnenkort in omloop
Dat het kan weet iedereen al jaren. Je veronderstelling dat er binnenkort "echte malware" in omloop komt deel ik helemaal niet en al helemaal niet dat een dergelijke techniek terug te vinden zal zijn in bots.
Het kost te veel moeite, levert heel weinig op (overleven van een formatering is niet interessant) en bovendien werkt het maar op een beperkt aantal systemen.
Dan weet de klant gelijk wat hij moet doen om een bot besmetting tegen te gaan.
Ik heb die beheerder toen gesproken en die vertelde me dat ze bij het hostingbedrijf een policy hadden ingesteld dat logfiles beter bekeken moesten gaan worden en warnings van o.a. de firewall doorgestuurd moesten gaan worden naar providers. Redelijk dom want firewall loggen geregeld attacks terwijl dat lang niet altijd zo is. In mijn firewall logs zie ik ook geregeld meldingen van attacks van mijn eigen IP adres wat natuurlijk onzin is. Maar vaak te herleiden tot een afgebroken FTP sessie ofzo.
Die beheerder had een mailtje naar XS4ALL gestuurd met daarbij de tekst "Goh, wat rare activitieit, misschien iets om in de gaten te houden". Gevolg was dat XS4ALL zonder de klant te contacten gelijk die klant afsloot. Er over bellen is dan niet mogelijk, je kan alleen een mailtje sturen. Daar wordt vaak pas de volgende dag op gereageerd en voordat het ongedaan werd gemaakt was die vriend een paar dagen verder. Ik vind dit erg onverantwoord van XS4ALL !!
Heb precies het tegenovergestelde meegemaakt hoor: bij een vriend was een botnet actief die keurig werd geblokkeerd door xs4all. Pas na tonen van schoning en betere firewall rules werd een en ander weer opengesteld.
Zo ook met een spammailtje dat ik ontving die te herleiden was naar een gecompromitteerde intranetserver (die blijkbaar toch via internet bereikbaar was) werd deze server binnen een half uur van het net geplukt door xs4all.
En ja, dan gaat er wel eens wat verkeerd, waar gehakt wordt vallen spaanders. Waar gehacked wordt ook. Maar desalniettemin is het weer openstellen en het communiceren met xs4all een verademing in vergelijking met wat andere, helaas niet optredende ISP's zoals diverse kabelaars. Ik heb de communicatie met mensen van xs4all nooit als probleem ervaren. In no time doorgezet naar de 2e of 3e lijns, zonder discussie. Zelf heb ik als 3e lijns bij een buitenlandse ISP gewerkt, en van daar uit was communicatie met xs4all ook nooit een probleem. Je kreeg altijd contact met deskundige mensen binnen een mum van tijd.
Dat was bij de kabelaars in Nederland wel anders. Het probleem lag altijd bij jou, nooit bij hun totdat je echt met de logs in de hand kon aantonen dat ze aan het blunderen waren, en dan nog wilden ze je vaak niet geloven...
EJ
dadelijk gaan ze nog verslaafde IRC users afsluiten inverband met botnet activiteid.
dadelijk gaan ze nog verslaafde IRC users afsluiten inverband met botnet activiteid.
Sja Cisco filtert met haar IDSen op een aantal signetures , waaronder 1 die het verkeer inspecteert op de string "/JOIN" wat natuurlijk gebruikt wordt om binnen een IRC netwerk een channel te betreden ....
Wat bedreft afsluiting van klanten is het soms best vermoeiend voor ISP's, ik heb bij meerdere ISP's meegemaakt dat er klanten tussen zaten die het voor mekaar kregen om tig keer per jaar een bar/block van de desbetreffende ISP te krijgen (in sommige gevallen vele malen meer dan volgens contract toegestaan), en vanuit de commercie werd er toch iedere keer besloten de betreffende klanten een laaste kans te geven.
- Even voor de duidelijkheid het betrof meerdere klein en groot zakelijke klanten die volgens contract al geen recht meer hadden op enig vorm van dienst verlening door de hoeveelheid aan abuse problemen, bij verschillende kleine en grote nederlandse ISP's -
Bij de meeste was het duidelijk incompetentie van de mensen die bij die bedrijven (klanten) die verantwoordelijk waren voor de IT al daar, aangezien zij met internet(fraude) hun centen zeer waarschijnlijk niet verdienen (bekende of iets minder bekende bedrijfsnamen/merknamen). Bij de consument word er over het algemeen bij dit soort toestanden veel sneller een beslissing gemaakt om deze permanent af te sluiten.
Daarnaast is het telefonisch informeren van klanten in het algemeen het eenvoudigst omdat de meeste de waarschuwings schermen (in de browser) niet snappen en toch gaan bellen, en als ze het wel snappen bellen ze alsnog om te zeuren waarom er voor hen een uitzondering gemaakt moet worden en meer van die bla.
Nu is het ook nog eens zo dat bij de meeste ISP's de abuse afdeling klanten niet telefonisch te woord zal staan. Procedure van ondere andere een zeer bekende KPN dochter. Er is duidelijk wat meer standaardisatie binnen de ISP sector nodig qua procedure bij dit soort zaken, en wat opvoeding bij klanten van ISP's. Maar in sommige gevallen ook bij de betreffende abuse afdelingen, die niet begrijpen dat een klant zijn eigen (virtual)-server best mag scannen, etc.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?