DNET & AV Problemen.

[Jive]

Mijn Kudde DNET Koeien staat voorlopig even grotendeels op non-aktief, totdat de problemen van McAfee/NAI met DNET opgelost is

Het is nu al 2 weken aan de gang, met als hoogtepunt nu dat hij overal gaat lopen bleren over virussen & trojans met defs 4557.

zie http://bugs.distributed.net/show_bug.cgi?id=3883

[Pim.]

Niet zo mooi, Norton heeft het ook een tijdje gehad, laten we hopen dat het snel opgelost wordt. Ga je in de tussentijd nog een ander project draaien ?

[Verwijderd]

DNet is RiskWare, overtuigen van het tegenovergestelde zal denk ik niet lukken, daarvoor wordt het te vaak silent geïnstalleerd.

Waarom exclude je de geflagde files niet gewoon?

[ParaNoiMia]

Verwijderd schreef op maandag 15 augustus 2005 @ 19:45:
DNet is RiskWare, overtuigen van het tegenovergestelde zal denk ik niet lukken, daarvoor wordt het te vaak silent geïnstalleerd.

Waarom exclude je de geflagde files niet gewoon?

Kan jij als anti-virus expert eens aangeven waarom het een hele tijd niet geflagged wordt, plots bij een update weer wel en een update later weer niet ?

Daarnaast lijkt een dnet client mij niet echt riskware, of er moet andere zooi bijgestopt worden ?

[ Voor 11% gewijzigd door ParaNoiMia op 15-08-2005 20:03 ]

[Verwijderd]

ParaNoiMia schreef op maandag 15 augustus 2005 @ 20:02:
[...]


Kan jij als anti-virus expert eens aangeven waarom het een hele tijd niet geflagged wordt, plots bij een update weer wel en een update later weer niet ?

Daarnaast lijkt een dnet client mij niet echt riskware, of er moet andere zooi bijgestopt worden ?

Is inderdaad wel waar wat je zegt.
Bij de 1e update wel en de andere niet.
Alleen vaag dat er nu ineens problemen mee zijn gezien McAfee dat al heeft zo lang ik me kan herinderen.
Zelfs bij RC5-64 was dat al zo.

Al kan ik het me wel voorstellen in een bedrijfsnetwerk waar ook gebruikers gaan klagen.

[Verwijderd]

ParaNoiMia schreef op maandag 15 augustus 2005 @ 20:02:
[...]


Kan jij als anti-virus expert eens aangeven waarom het een hele tijd niet geflagged wordt, plots bij een update weer wel en een update later weer niet ?

Het is niet echt nuttig om zomaar elke DNet client aan de bases toe te voegen, pas als er een ItW wordt aangetroffen bij een Trojan zal deze worden toegevoegd.

Waarom die een update later weer uit de bases verdwenen zou zijn kan ik niet beantwoorden, mogelijk adv de hoeveelheid klachten. Hoewel dat bij extended bases/PUP een minder grote rol zou moeten spelen.

Daarnaast lijkt een dnet client mij niet echt riskware, of er moet andere zooi bijgestopt worden ?

Er zijn genoeg Trojan-Droppers welke DNet clients stiekem op een systeem installeren.
Behalve dat zo'n client zomaar alle extra CPU cycles opslurpt werkt het ook nog eens fraude in de hand.

[stappel_]

op 27 juni heb ik hetzelfde probleem met symantec gemeld -url-. Na 3 mailtjes richting d.net ben ik er maar mee gestopd. Ik heb nooit antwoord van ze gehad.

[Jive]

Er was dus een "exclusion" voor de dnet client, zoals ik ook aangegeven had & gebruikte .(zie dnet bug-report) ..

Het is alleen ineens gesloopt dooe mcafee/nai ..

En "eventjes" op 175 pc & 25 servers een ander projectje installeren is nu niet bepaald een optie als je in vakantietijd zit op een afdeling van 4 man waarvan er 2 op vakantie zijn en je een 36-urige (4dagen) werkweek hebt

Even een ander projectje is enkel een optie als ..
1: draaien als nt service (native, dus geen firedeamon/anyservice meuk)
2: centrale beheersbaarheid voor de updates (zoals muon ftp proxy of dnet proxyper)
3: installeren op afstand over windows domain.
4: redelijk gebruik resources (geen gekke dingen als 256mb ram voor de client)

Dus als je er zo eentje weet, kudde koeien op zoek naar gras.

[ Voor 5% gewijzigd door Jive op 15-08-2005 23:59 ]

[Jive]

stappel_ schreef op maandag 15 augustus 2005 @ 23:25:
op 27 juni heb ik hetzelfde probleem met symantec gemeld -url-. Na 3 mailtjes richting d.net ben ik er maar mee gestopd. Ik heb nooit antwoord van ze gehad.

Gewoon een bug geopend bij dnet, zij zijn toch ook degenen die moeten zeuren bij mcafee/norton ... en signatures moeten maken voor clients.

[Verwijderd]

Numerous of my users are recieving messages by their av-scanners about the
proxy-DistNet trojan ,

Dat heeft dus niets (meer) met een Cracker te maken.

Ik snap trouwens niet waarom je op categorie wil excluden, kun je niet gewoon op file name/locatie excluden?

[Jive]

1: Ik had alle 7 extra categories aan staan, met 1 exclusion op die "PWCrack-DNET" die in de lijst staat.
2: Die Exclusion werkt ineens niet meer.
3: De hele category uitschakelen werkt een week later ook ineens niet meer.
4: Tot de update van de 20e heeft het gewoon allemaal goed gewerkt.

Conclusie : mcafee/nai heeft zitten sleutelen aan de definities, en het word alleen maar steeds erger.
normaal zijn ze altijd lekker snel met toevoegen van nieuwe virii & malware , en meestal fixxen ze ook wel dingen vrij vlot als het false is (dameware utilities & remote control zaten ook ineens in de malware-remote control sectie .. dat was ook binnen 2 dagen gefixxed)

Dit duurt nu gewoon al meer dan 3 weken, en het is enkel erger geworden.

[Verwijderd]

Laat het me wat duidelijker maken.

Proxy(-DistNet) = Trojan = standard bases != PUP

Dus nogmaals mijn vraag: Waarom exclude je niet op filename/location?

[Jive]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 00:39:
Laat het me wat duidelijker maken.
Proxy(-DistNet) = Trojan = standard bases != PUP
Dus nogmaals mijn vraag: Waarom exclude je niet op filename/location?

Leg dan ook even uit waarom hij gelijk gaat gillen als je enkel maar de officiele zip-file van de dnet-site uitpakt in de temp dir ofzow ....

Er zit een exclusion in de definities voor de dnetc executable, deze heeft altijd gewerkt, deze werkt nu niet meer.

[Verwijderd]

nieuwste def en engine 8.0.0 mcafee vind bij mij wel oude clients maar de niet 496 laat te met rust, gebruik je wel de nieuwste koe?

[Verwijderd]

Er is een lichtelijke overspoeling van meldingen, waardoor het niet doenlijk is alle mails te beantwoorden. Er is communicatie met de AV companies, maar dat verloopt zwaar moeilijk.

Het is verd*mme iedere keer hetzelfde. In plaats van dat ze nou ergens aantekenen dat er afspraken zijn gemaakt Hopelijk komt er snel schot in de zaak.

Neemt trouwens niet weg dat het sowieso praktisch is zsm over te stappen naar de nieuwste client, omdat alle clients pre.496 straks uitgefaseerd worden. Als in dat de WU's van die clients niet meer aangenomen gaan worden (RC5)

[ Voor 26% gewijzigd door Verwijderd op 16-08-2005 07:44 ]

[EZ-Cow]

In eerste instantie had ik ook last van een klagende AV, maar heb vervolgens in McAffee de directory "c:\Program Files\Distributed.net" in de exclude list gezet. Nu klaagt tie niet meer .

Ik snap dat dit niet de oplossing is voor de mensen met een serverpark, maar voor de mensen met 1 of 2 PC'tjes is het een leuke workaround

[Jive]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 06:42:
nieuwste def en engine 8.0.0 mcafee vind bij mij wel oude clients maar de niet 496 laat te met rust, gebruik je wel de nieuwste koe?

Als ik de laatste download van de release-page mag ik wel aannemen dat het de laatste is ja ..
Daar heb ik het juist op getest

[Jive]

1: Update nai met 4561 definitions.
2: Download verse client-zip van www.distributed.net/download/
3: Pak de zip uit ....
4: Constateer dat de dnetc.exe & dnetc.scr nog steeds volautomatisch door de scanner gezien worden, en de exception nog steeds niet gefixxed is.

[MarcyDarcy]

Blijft opzich vreemd dat niet alle virusscanners/bedrijven de d.net client op de blacklist zetten. Heb even een test gedaan maar eTrust Antivirus laat het netjes toe.

[Verwijderd]

Jive schreef op dinsdag 16 augustus 2005 @ 01:03:
[...]


Leg dan ook even uit waarom hij gelijk gaat gillen als je enkel maar de officiele zip-file van de dnet-site uitpakt in de temp dir ofzow ....

Leg mij eens uit waarom hij dat _niet_ zou doen?
Als je een of andere worm tegenkomt wil je toch ook dat die overal gedetecteerd wordt en niet alleen in %windir%? Het gaat hier om een antivirus, niet om een antispyware.

Er zit een exclusion in de definities voor de dnetc executable, deze heeft altijd gewerkt, deze werkt nu niet meer.

Dus ze voegen iets toe aan de database om het zo te kunnen excluden? Lijkt me niet.
Het doet er ook niet toe.

Nogmaals: Gewoon %Program Files%\Distributed.net excluden. Waarom doe je dat niet?

MarcyDarcy schreef op donderdag 18 augustus 2005 @ 12:12:
Blijft opzich vreemd dat niet alle virusscanners/bedrijven de d.net client op de blacklist zetten. Heb even een test gedaan maar eTrust Antivirus laat het netjes toe.

Mwhoa, ook lang niet alle AVs detecteren ServU of mIRC als RiskWare.

[Jive]

Als je een signature maakt om iets te detecteren, is het eenvoudig om deze via een extra optie te kunnen omzeilen (zo lijkt het iig te werken).

Als er dan van de ene op de andere dag besloten word om toch de signature voor dnetc op de active-list te zetten, dan is het zeker vreemd te noemen dat dan niet ook de optie om hem te excluden bijgewerkt word naar de nieuwe versie.

Ik vind het ook helemaal niet erg dat ze detectie geupgrade hebben naar de nieuwere versie van de clients, wat ik er erg aan vind is dat ze er zolang over doen om de exclusion-switch voor die detectie welke al reeds aanwezig is te updaten zodat hij ook weer werkt.

En gewoon botweg de dir excluden waar de client instaat vind ik een workaround, en geen fix van een fout zoals dit, want het is gewoon een bug in de signatures van NAI.

En als het te lang gaat duren voordat het gewoon netjes gefixxed word, dan kap ik er toch gewoon mee, jammer voor dpc, jammer voor de lol, jammer voor DNET ... die imo wel iets harder mogen lopen of meer info mogen geven over de status omtrend dit.

[Verwijderd]

Jive schreef op donderdag 18 augustus 2005 @ 16:10:
Als je een signature maakt om iets te detecteren, is het eenvoudig om deze via een extra optie te kunnen omzeilen (zo lijkt het iig te werken).

In het programma ja, dat staat 'los' van de bases.

Als er dan van de ene op de andere dag besloten word om toch de signature voor dnetc op de active-list te zetten, dan is het zeker vreemd te noemen dat dan niet ook de optie om hem te excluden bijgewerkt word naar de nieuwe versie.

Zoals ik eerder al zei, file wordt gedetecteerd als Proxy Trojan, dat heeft niets(meer) met PUP te maken.

Ik vind het ook helemaal niet erg dat ze detectie geupgrade hebben naar de nieuwere versie van de clients, wat ik er erg aan vind is dat ze er zolang over doen om de exclusion-switch voor die detectie welke al reeds aanwezig is te updaten zodat hij ook weer werkt.

Zo werkt het dus niet.

En gewoon botweg de dir excluden waar de client instaat vind ik een workaround, en geen fix van een fout zoals dit, want het is gewoon een bug in de signatures van NAI.

Het is geen workaround, het is geen bug.

En als het te lang gaat duren voordat het gewoon netjes gefixxed word, dan kap ik er toch gewoon mee, jammer voor dpc, jammer voor de lol, jammer voor DNET ... die imo wel iets harder mogen lopen of meer info mogen geven over de status omtrend dit.

Om dit nu op DNet af te schuiven...ik weet het niet hoor.

[joh14vers6]

Edit by Pim.:
ff overleg John, mail/msn/icq/irc me even als je wilt

[ Voor 202% gewijzigd door Pim. op 18-08-2005 17:44 ]

[Jive]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:41:
[...]
In het programma ja, dat staat 'los' van de bases.
[...]
Zoals ik eerder al zei, file wordt gedetecteerd als Proxy Trojan, dat heeft niets(meer) met PUP te maken.
[...]
Zo werkt het dus niet.
[...]
Het is geen workaround, het is geen bug.
[...]
Om dit nu op DNet af te schuiven...ik weet het niet hoor.

Het word ook niet als een virus gezien, maar door de unwanted programs scan-part in de category dialers en andere troep geduwd.
Er zit een exclusion in voor de dent client, deze hoeft enkel bijgewerkt te worden door mcafee.
Mijn probleem is dat dnet geen plan zet, of stukje bij de bug zet, of enig ander info geeft hierover.
De oplossing van het probleem is bij nai/mcafee

[Verwijderd]

Jive schreef op donderdag 18 augustus 2005 @ 17:49:
[...]

Het word ook niet als een virus gezien, maar door de unwanted programs scan-part in de category dialers en andere troep geduwd.

Nogmaals: Proxy = Trojan != PUP

Er zit een exclusion in voor de dent client, deze hoeft enkel bijgewerkt te worden door mcafee.

Nogmaals: Zo werkt het niet, wat je niet in je bases wil hebben zet je er ook niet in.

De oplossing van het probleem is bij nai/mcafee

Er is geen helemaal geen probleem behalve dat jij er een probleem van maakt.

Concluderend:
Je zegt zelf dat DNet als Proxy wordt geflagd, Proxy detections horen niet in de potentially unwanted programs groep thuis maar is een klasse Trojan.
Dus dan is het niet meer dan logisch dat het alleen op filename/location te excluden is.

[alexcj]

Jongens, jongens, wat wordt er weer een boel naar elkaar geschreeuwd i.p.v. dat men elkaars standpunt probeert te begrijpen.
Voor zover ik het kan zien, is Jive het eens met Schouw dat het een optie is om de distributed.net dir te excluden. Jive vind dat echter een 'workaround'.
Hij heeft gegronde redenen om dat te vinden, aangezien het tot voor kort WEL goed werkte.

[Jive]

code:

7/26/2005   10:11:34 AM Move failed (Clean failed)  CHIEFTAN\Jive   TeaTimer.exe    C:\Programs\DPC\dnetc.exe   Distributed.net (Potentially Unwanted Program)
7/26/2005   10:19:12 AM Moved (Clean failed)    NT AUTHORITY\SYSTEM cidaemon.exe    C:\System Volume Information\_restore{0EF8EAF7-D926-4EBB-96F4-05D23E1DEA5B}\RP233\A0031417.exe  Proxy-DistNet (Trojan)
8/11/2005   9:05:00 AM  Moved (Clean failed)    NT AUTHORITY\SYSTEM cidaemon.exe    C:\Programs\DPC\dnetc.exe   Distributed.net (Potentially Unwanted Program)

Dit zijn een paar meldingen uit de logfile van de on-access scanner .. kun jij me die dan beter uitleggen, en vertellen waarom hij 2 verschillende benamingen schijnt te hebben voor hetzelfde bestand ??
Want ik weet nml 1000% zeker dat het om dezelfde file gaat, eerst de file die hij vind & killed, en daarna in de sysvol de "backup" van de file ineens anders classificeert omdat hij een andere naam heeft.

[Jive]

* Jive bedankt Alexcj voor de kleine interventie terwijl hij zijn bovenstaande post aan het tikken was, het enigste waar ik idd op doel is, het heeft gewerkt, ik wil graag dat het weer werkt.

Voor mij mag de client 100% gezien worden als een "POTENTIAL" unwanted program, omdat hij nu eenmaal illegaal geinstalleerd word vaak, maar tot voorheen kon hij altijd netjes excluded worden, en sinds 20juli ineens niet meer.

Het enigste wat ik DNET verwijt is dat er van hun uit nul communicatie is over de gemelde bug of het probleem in kwestie, niet eens een .plan update van iemand om te bevestigen dat het een "probleempje" is waar aan gewerkt word .. gewoon helemaal niet zeggen is de slechtste communicatie.

En als nai hardnekkig blijft en dus idd niet van plan is om de exclusion die al reeds aanwezig is in de software aan te passen zodat hij weer werkt zoals voorheen, dan is dat heel jammer, en zal ik dus niet meer de koe draaien, want de av-scanner staat juist op alle werkstations strak ingesteld omdat z e allemaal overal maar op klikken & proberen te installeren, en enkel door goede beveiliging van inkomende lijnen & server & werkstations heb ik dus 0 virusuitbraken gehad op ons bedrijfswan, en dat is iets waar we veel geld aan uitgeven om dat ook zo te houden.

[Pim.]

Ik heb even een alias gemaakt in Beveiliging & Virussen aangezien het topic zich op twee onderwerpen toespitst, DPC en AV

[ Voor 3% gewijzigd door Pim. op 19-08-2005 06:40 ]

[Jive]

------- Comment #16 From Mike Reed 2005-08-19 00:18 GMT [reply] -------
I've had some discussions with NAI personnel in the last few days. Their
position is that because our software is regularly installed by malware and
abused, they will continue to detect it as a potentially unwanted program.

They have also directed me to http://vil.nai.com/vil/pups/configuration.htm,
which gives instructions on how to set an exception so their software doesn't
screech and holler about your dnetc installation the whole time. It's not much
of an olive branch...

Sorry folks.

Mike
distributed.net User Support

[ColdFusion]

Dat is dan iig duidelijk. De goeien moeten dus weer lijden onder de slechten...

[Verwijderd]

Ho ho, het verhaal is daarmee nog niet ten einde... Er wordt nog steeds gepoogd duidelijk te maken dat ze het moeten aanpassen. Ze brengen schade toe aan een legitieme organisatie, ze weten dat ze dat doen en zijn gevraagd daarmee te stoppen. Nu is de vraag hoever we gaan (rechter?) of hoe lang we blijven doorgaan met communicatiebombardementen om het gedaan te krijgen.
Vandaag gaat er weer een mail van mij die kant op, en zo blijf je aan de gang

[ParaNoiMia]

Verwijderd schreef op maandag 22 augustus 2005 @ 06:59:
Ho ho, het verhaal is daarmee nog niet ten einde... Er wordt nog steeds gepoogd duidelijk te maken dat ze het moeten aanpassen. Ze brengen schade toe aan een legitieme organisatie, ze weten dat ze dat doen en zijn gevraagd daarmee te stoppen. Nu is de vraag hoever we gaan (rechter?) of hoe lang we blijven doorgaan met communicatiebombardementen om het gedaan te krijgen.
Vandaag gaat er weer een mail van mij die kant op, en zo blijf je aan de gang

Als we ergens mee kunnen helpen, dan horen we het wel neem ik aan ?

[Xaverius]

Even een vraagje tussendoor.

Aan welke getallen van abusers moet er gedacht worden die dat soort geintjes uithalen waardoor dnet door de antivir's worden opgepikt. Wordt er echt op grotere schaal dit soort praktijken uitgevoerd?

Of is dit een beetje classified information?

[Jive]

Reken er maar op dat ik als zakelijke klant van NAI's total-solution packet aardig kan zeuren als ik dit soort dingen op mijn netwerk zou vinden, en NAI ze niet pakt. (dat ik ze specifiek in mijn instellingen zou excluden allah) ...

Het grote probleem is dus dat er maar een paar zakelijke klanten hoeven te klagen bij NAI om de bal aan het rollen te krijgen, en dat krijg je dus niet zo 123 weg bij NAI, want zij verdienen immers aan het weghalen van "foute"progs .. niet aan het laten staan ervan.

Dat ze het overigens niet netjes doen door niet te communiceren met d.net en niet eventjes netjes de scandefinities te updaten dat ze netjes te excluden zouden zijn, en enkel reageren op outdated versies .. das IMO wel iets waar NAI op aan te spreken is door d.net

[Verwijderd]

Jive schreef op maandag 22 augustus 2005 @ 16:30:
Reken er maar op dat ik als zakelijke klant van NAI's total-solution packet aardig kan zeuren als ik dit soort dingen op mijn netwerk zou vinden, en NAI ze niet pakt. (dat ik ze specifiek in mijn instellingen zou excluden allah) ...

Het grote probleem is dus dat er maar een paar zakelijke klanten hoeven te klagen bij NAI om de bal aan het rollen te krijgen, en dat krijg je dus niet zo 123 weg bij NAI, want zij verdienen immers aan het weghalen van "foute"progs .. niet aan het laten staan ervan.

Dat ze het overigens niet netjes doen door niet te communiceren met d.net en niet eventjes netjes de scandefinities te updaten dat ze netjes te excluden zouden zijn, en enkel reageren op outdated versies .. das IMO wel iets waar NAI op aan te spreken is door d.net

Redelijk onzin.
RC5 is een van de weinige DC projecten die door AV gezien word als iets wat een PC bedreigt.
DPAD, SOB, UD, D2ol, TSC, F@H allemaal geen enkel probleem.
En de meeste zijn erg goed te remote pushen.
En kijkent naar client zelf lijkt DPAD best op RC5 en die kan je op zeker overall inbakken.

Blijft voor mij vaag (al doe ik amper RC5) dat D-net wel in de AV lijst voorkomt.
En ik ben ook wel eens smilie packs tegen gekomen met een DPAD client erin en ook SoB heb ik wel eens verkapt gezien.
Blijft allemaal ook redelijk makkelijk om te maken.
Ik heb b.v. voor gebruik van ons subteam een eigen kant en klaar DPAD paketje gemaakt die alles doet incl. starten als services enz enz.
Kwestie van avondje klooien en je bent er

[Jive]

Tja, ach .. ik werk dan mischien maar bij een "kleine" zakelijke klant ..
Maar ik kan je echt op een heel groot briefje geven dat als een dikke corporate client erover klaagt, het dus gewoon gebeurt ... zo zit het bedrijfsleven nu eenmaal in elkaar ..

Zie maar naar M$ antispy die ineens de warning verlaagt van een product wat ze mischien willen overkopen ...

[Jive]

http://bugs.distributed.net/show_bug.cgi?id=3883

I managed to get a fix from NAI through my own support contract.
I suggest you guys at D.Net contact them about it & find out if you can make a procedure to resolve this for everybody public, since i am uncertain if i am allowed to post it here.

If you need my help with it, Floppus can contact me on it.

Ik heb het weten te fixxen via OFFICIEELE weg, en zal er een change voor moeten uitrollen naar mijn farm in voordat ik weer kan beginnen met koeien houden.

Ennuh, het is dus voorlopig wel een UNDOCUMENTED fix die ik bij de NAI support afdeling heb los moeten peuteren en iig vanaf 4593 werkt.

[Pim.]

Dat is dan knap werk van je Jive, iets wat ze bij D.net niet hebben kunnen bereiken, hebben ze iig een luisterd oor voor de klant

[alexcj]

Nou, ik ben ook blij dat het gelukt is !

Goeie zaak Jive !

[Verwijderd]

http://bugs.distributed.net/show_bug.cgi?id=3883#c19

Nice work Jive