[OGR] Proxy + authenticatie

[SKiLLa]

Beste mede DPC'ers,

Tijdens de laatste d.net storing zijn er wat proxy-vijandigheden tussen de Russen en DPC uitgebroken. Anders gezegd: er werden proxies leeggeroofd. Om dit in de toekomst structureel te voorkomen is een degelijke vorm van authenticatie vereist.

Een aantal randvoorwaarden:

* Geen/minimale aanpassingen aan de bestaande proxy software.
* Geen aanpassingen aan de bestaande dnetc clients (maar een minimale install-less helper-tool).
* Waterdicht & foolproof.
* Moet werken met dynamische (client-) IP adressen.
* Makkelijk in gebruik.

Nu denk ik dat dit relatief makkelijk te realiseren is door whitelisting te gebruiken; dit betekent dat in principe elke verbinding geweigerd wordt, op een lijstje van "goedgekeurde" IP adressen na.

Dit (tijdelijk) whitelisten kan door clients b.v. op een authenticatie webpagina te laten inloggen, waarna het betreffende client IP adres (tijdelijk) ge-whitelist is. Een dergelijk systeem moet "server-side" relatief simpel te realiseren zijn.

Client-side is hiervoor een dnetc background proces nodig dat b.v. de dnetc logfile monitoort op "mislukte fetches" en/of gewoon wacht op user-interactie (Windows trasktray ?) en vervolgens de authenticatie url aanroept met de benodigde gegevens en daarna dnetc opnieuw laat fetchen.

Een andere aanpak zou een "bouncer proxy" zijn die tussen de standaard dnetc client en de "echte" proxy inzit en de authenticatie met de "echte" proxy op de achtergrond uitvoert voordat er een "standaard" verbinding opgezet wordt.

Tevens biedt dit de mogelijkheid om een lijstje van failover proxy Urls te configureren, zodat er ten tijde van WU-droogte op je favoriete keyserver/proxy automatisch op een andere server overgeschakeld wordt.

Nu de hamvragen: Wat vinden ervan, is het wel de moeite waard ? En wie wil het helpen realiseren ?

[duarf]

Ik zou wel zoiezo niet meer uit de ruskies hun proxy's stelen...

...zou niet echt sportief zijn

[Robinski]

duarf schreef op maandag 04 februari 2008 @ 20:16:
Ik zou wel zoiezo niet meer uit de ruskies hun proxy's stelen...

...zou niet echt sportief zijn

Alleen wat we echt nodig hebben!?
Dus stub voor stub als je het echt nodig hebt?

Anders is het ook niet echt sportief van hun, en zo is het project sneller afgelopen!
Ze mogen ook wel wat van mij hebben als ze het echt nodig hebben en ik nog genoeg voorraad over heb.


Ik wil eventueel wel helpen met iets bouwen, het server gedeelte moet wel op windows werken ook (wel zo handig)

[ Voor 9% gewijzigd door Robinski op 04-02-2008 20:42 ]

[Jive]

* Jive wil wel behulpzaam zijn bij het in de lucht houden van zo een DPC privoxy .
Heb alleen weinig verstand van proggen om het zelf op te zetten cp bij te houden denk ik.

Persoonlijk denk ik dat het erg lastig word om een systeem op te zetten wat met dynamic ip's rekening houd, dan wel het installeren & onderhouden van een background process.

Ik zie dan meer in het volgende systeem.
Aantal vaste team proxies welke op vast ip afgesloten zijn, gaar dus ook alle bekende mensen met vaste ip's naar kunnen connecten om hun eigen proxies te vullen en/of hun clients naar kunnen laten verbinden.

Voor de dynamische gebruikers stel ik voor een aantal aparte proxies op te zetten met een beperkte werkhoeveelheid, en deze op een "geheim" ip op een "geheime" poort te laten draaien. Evt op te zetten door elk subteam zelf voor hun dynamische koeien.
Deze dynamische proxies zouden dan zelfs nog uit te breiden zijn met een aantal blocks op generieke ranges waarvan je weet dat er nooit connecties zullen komen.

Wat stats hosts betrefd kun je deze spook proxies dan ook het beste onder een hostname naar voren laten komen en aangezien je weet waar deze staan kunnen deze dan ook prima via normale proxies naar buiten flushen.

Hoe eerder zo een netwerk als dit opgezet word, hoe beter het staat & functioneert als er straks dus echt een tekort aan zit te komen van wu productie aan dnet zijde.

[FreezeXJ]

Valt er niet iets te regelen waardoor subteams hun proxy een tijdje laten cachen, en dit dan gebruiken? In dat geval kunnen subteams hun eigen proxy een beetje verstoppen (gewoon op een maffe poort laten werken is meestal wel genoeg denk ik, laat die Russkies maar raden welke).
Daarnaast kunnen deze proxies eventueel uit een grotere voorraad plukken, die meest met vaste IP-adressen werkt (ik neem aan dat die proxies niet helemaal zwevend zijn). Op die manier heb je nog wat achter de hand als er ergens iets fout loopt.

Uiteraard kun je ook gewoon pakketjes per mail/FTP-server doorsturen, zo groot zijn ze niet, ook niet in packs van 1000 of zo. FTPs zijn aardig te beveiligen, en draaien redelijk universeel. DM het wachtwoord, en block alle niet-NL-IPs (voor het geval er cloaks gebruikt worden). Uitzondering op aanvraag, en het zit aardig waterdicht.

[SKiLLa]

Security through obscurity alleen is natuurlijk niet genoeg, 15 minuten googlen gisteren leverde me ruim 10+ werkende (inc. WUs) proxies op, waarvan een groot deels DPC proxies waren. Het was moeilijker om non-DPC dan DPC proxies te vinden

Het programmeer gedeelte zal technisch niet zo'n grote uitdaging vormen vermoed ik, dergelijke accesslists zijn makelijk te programmeren en dnetc laat zich goed aansturen. Blijft echter dat de proxy-integratie en "cross-platform" ondersteunen toch veel tijd zal kosten.

Een alternatieve "authenticatie" methode is b.v. een SSL tunnel/bouncer te gebruiken (gebruik ik zelf ook). Stel de proxy in dat ie alleen verbindingen vanaf de SSL-terminator bak accepteert (of b.v. 127.0.0.1) en laat anderen dan via de SSL tunnel een verbinding opzetten.

Voor Windows heb je daar b.v. de gratis Entunnel client voor (en Nix/BSD bakken leven zo ongeveer op SSH clients). Zo heb je authenticatie en hoef je op de clients (of op 1 plek in het netwerk) uitsluitend een klein extra tooltje te draaien om de tunnel in de lucht te brengen, zonder dat je overige Internet verkeer er last van heeft (in tegenstelling tot veel 'default' VPN verbindingen).

Voor de non-nerds onder ons: Draai op je lokale PC / ergens op een PC in je lokale netwerk zo'n SSL tool, geef in de dnetc client die PC als proxy op en vervolgens wordt (uitsluitend) die verbinding middels SSL "getunnelt" (inc. pwd authenticatie) naar de proxy server toe. Geen pwd betekent geen verbinding en 't vereist eigenlijk alleen dat de proxy/SSL server een vast IP/hostname heeft..

[DigiK-oz]

Ik betwijfel of het wel de moeite waard is. Oke, er zijn wat buffertjes leeggeroofd, maar het verstoppen van je proxy is toch redelijk makkelijk te doen.

Als we er toch mee doorgaan, lijkt de eenvoudigste manier om 1 (of een paar) centrale (HTTP)proxies te draaien die je dan opgeeft in je DNET client. Op basis van het source-ip, user/pass of whatever kan een dergelijke proxy dan van alles doen, rejecten, doorrouteren naar een public proxy van dnet, of doorrouteren naar een DPC-proxy (eventueel met fallback als het ding op een lege proxy terecht komt).

Voordeel van deze methode is volgends mij dat je bij je DNET proxies alleen de "DPC-proxies" in je whitelist hoeft te zetten, en in je client alleen een DPC-HTTP-proxy hoeft op te geven. De verificatie gebeurt helemaal in de DPC-HTTP-proxy (op basis van IP, authentication, .....). Geen extra programmatuur op de client.

[BwO]

Kan je niet gewoon simpel alles wat eindigt op .ru blocken?

[Reneger]

Helaas. Alleen op IP is mogelijk.

[Z!oN]

Http proxy met authentication is imho de meest straight forward methode.

[ Voor 68% gewijzigd door Z!oN op 05-02-2008 16:48 ]

[Jive]

Dan nog moet je een IP list maken voor de overigen, want je kan voorzoverikweet niet met username/pass je perproxy met een andere laten kletsen.

Maar als voorbeeld een paar perproxy achter een http muur zetten en deze op het KS.O achter een round robin zetten en je hebt iid een redelijk robuste backend.
En als die beheerders van die proxies dan even de koppen bij elkaar trekken om een manier uit te dokteren om ook ieder van een inlogcombinatie te voorzien (en deze natuurlijk automatisch bij te houden) is dit ook een mogelijkheid om door te werken.
Heb je alleen wel wat IP's nodig waar niet reeds op 80 wat aan de gang is.

[Reneger]

http proxy kan ook best op een andere poort draaien

[Wessie]

Even offtopic:
ik vind het flauw dat er weer naar een NC member gewezen wordt die 300 stubs gebietst had van een public Russische proxy, maargoed dat offtopic.

On topic:
Bij NC wordt er standaard al gewerkt met subproxy's.
We zijn simpelweg te groot en verbruiken teveel om het over 1 proxy te laten lopen.
Normaal heb ik zelf ook een leuke voorraad op mijn eigen proxy welke op mijn eigen domein draait.
Helaas door een technisch probleem is dit momenteel even niet mogelijk.
Als deze binnenkort weer up is, wil ik best een DPC proxy draaien op een andere poort voor de liefhebbers.
Overigens heb ik de beschikking over een 20 Mbit lijn, dus dat moet geen probleem zijn.

[Pim.]

Wessie schreef op dinsdag 05 februari 2008 @ 19:51:
Even offtopic:
ik vind het flauw dat er weer naar een NC member gewezen wordt die 300 stubs gebietst had van een public Russische proxy, maargoed dat offtopic.

Het is dat je het zegt anders had ik niet geweten dat het over een NC'er gaat

[Verwijderd]

SKiLLa schreef op maandag 04 februari 2008 @ 22:08:
Security through obscurity alleen is natuurlijk niet genoeg, 15 minuten googlen gisteren leverde me ruim 10+ werkende (inc. WUs) proxies op, waarvan een groot deels DPC proxies waren. Het was moeilijker om non-DPC dan DPC proxies te vinden

Het programmeer gedeelte zal technisch niet zo'n grote uitdaging vormen vermoed ik, dergelijke accesslists zijn makelijk te programmeren en dnetc laat zich goed aansturen. Blijft echter dat de proxy-integratie en "cross-platform" ondersteunen toch veel tijd zal kosten.

Een alternatieve "authenticatie" methode is b.v. een SSL tunnel/bouncer te gebruiken (gebruik ik zelf ook). Stel de proxy in dat ie alleen verbindingen vanaf de SSL-terminator bak accepteert (of b.v. 127.0.0.1) en laat anderen dan via de SSL tunnel een verbinding opzetten.

Voor Windows heb je daar b.v. de gratis Entunnel client voor (en Nix/BSD bakken leven zo ongeveer op SSH clients). Zo heb je authenticatie en hoef je op de clients (of op 1 plek in het netwerk) uitsluitend een klein extra tooltje te draaien om de tunnel in de lucht te brengen, zonder dat je overige Internet verkeer er last van heeft (in tegenstelling tot veel 'default' VPN verbindingen).

Voor de non-nerds onder ons: Draai op je lokale PC / ergens op een PC in je lokale netwerk zo'n SSL tool, geef in de dnetc client die PC als proxy op en vervolgens wordt (uitsluitend) die verbinding middels SSL "getunnelt" (inc. pwd authenticatie) naar de proxy server toe. Geen pwd betekent geen verbinding en 't vereist eigenlijk alleen dat de proxy/SSL server een vast IP/hostname heeft..

ben wel benieuwd naar wat je gevonden hebt ???

zaten wij er ook tussen? (en wij zijn Graasland )

[SKiLLa]

Verwijderd schreef op dinsdag 05 februari 2008 @ 22:56:
[...]

ben wel benieuwd naar wat je gevonden hebt ???

zaten wij er ook tussen? (en wij zijn Graasland )

Dat weet ik eerlijk gezegd niet meer, ik was op zoek naar non-DPC proxies, dus als het duidelijk was dat het een DPC proxy betrof, zocht ik weer verder. Ben wel veel "verlaten" proxies tegen gekomen, proxies die wel draaidden, maar al jaren "stil stonden" zonder WUs of clients ...

Veder heb weinig ervaring met de proxy en firewall instellingen van de dnetc client, maar als de proxy software (out of the box) geen HTTP authenticatie ondersteunt, dan is dat natuurlijk altijd nog op Apache / IIS niveau te regelen ...

Anyways, nu de NCs hard meedoen zal er vermoedelijk geen heftige strijd meer uitbreken, ik vermoed/hoop dat de Russen eindelijk inzien dat de DPC onoverwinnelijk is op OGR

[Reneger]

Zowel via HTTP als SOCKS is er authenticatie mogelijk vanuit de client.

[CBA]

Is het niet simpeler als iemand connectie maakt met je proxy om te checken of het e-mail adres dat de blockjes vraagt lid is van DPC, zoja kan hij blockjes afhalen zo neen wordt dit e-mail adres doorgestuurd naar een publieke proxy of in het ergeste geval gewoon geblockt ?

[Jive]

Dan zou je dus een proxy moeten instellen datie alleen naar wat fixxed ip's en localhost kijkt, en een SOCKS moeten instellen die verbindingen van internet opvangt met authenticatie en deze doorzet naar de interne proxy.
Werkt dus alleen als je met je koe direct naar buiten kan zonder proxies etc .. maar dat zal idd voor de meeste mensen wel gelden.

Blijft de vraag ... hoe zet je dan zowiets op en hoe zorg je ervoor dat je een "centraal" account lijstje bijhoud zodat iedereen er met zijn eigen gebruiker bij kan.

Enigste wat dan nodig is zal zijn dat alle socks op dezelfde poort luisteren zodat er niet verkeerd geklopt word via de round robin op de poorten.

[Reneger]

Mail adressen kunnen gefaked worden. Als je een beetje research doet, zijn die gegevens zo opvraagbaar.
Op IP adres is al een stuk moeilijker. Dan moet er al toevallig een backdoor/slechte SSH toegang bij een DPC member zijn (Weinig kans op. We zijn en blijven tweakers) wil je zijn of haar IP adres gebruiken.

Ik ben de komende dagen behoorlijk druk (Eindpresentaties afstuderen enzo, gevolgd door feestjes), maar zodra ik tijd heb, wil ik mij wel op dit geval storten. Ik heb een server draaiende, een proxy moet geen probleem zijn.

[Chaos]

Je zou kunnen beginnen met grofweg alleen IP ranges uit west Europa toe te staan. Met enkele tientallen /8's ben je er dan al waarschijnlijk.

[SKiLLa]

Chaos schreef op woensdag 06 februari 2008 @ 10:30:
Je zou kunnen beginnen met grofweg alleen IP ranges uit west Europa toe te staan. Met enkele tientallen /8's ben je er dan al waarschijnlijk.

Dat werkt niet, je hebt publieke proxies, zombies/gehackte PCs, shell accounts, servertjes in een DC in Europa, etc. Als er eentje doorheen glipt - en je geen blockjes-quota hebt - kan die zo de hele proxy leeg slurpen ...

Authenticatie is the way to go denk ik, een team maakt voor haar eigen leden gewoon accounts aan, dat valt prima te managen en teams onderling kunnen dan eventueel een "team account" afspreken zodat ze elkaars proxy als failover-voorraad-keyserver (van proxy naar proxy bedoel ik dus) kunnen gebruiken.

[Chaos]

Daarom "je zou kunnen beginnen met...". Bovendien neem ik niet aan dat de Russische maffia hier achter zit, je maakt het voor de gewone Rus echt wel flink moeilijk om even een van onze proxy's leeg te halen. Waterdicht lukt je sowieso niet, hoe wil je authenticatie voor alle DPC leden regelen zonder dat daar een Rus doorheen glipt?

[SKiLLa]

Ja, ik begrijp dat je het als "quick win" bedoelde, maar Europese ISPs gebruiken tegenwoordig ook zoveel kleine (extra) IP classes die vaak nog als "in Amerika" of zelfs "reserved" geregistreerd staan, dat het voor sommige teams echt onbegonnen werk is om met IP-classes te werken.

Daarnaast moet je de Russen niet onderschatten, de grote spelers daar zijn ook vaak IT-professionals met veel kennis & toegang ... en in sommige gevallen blijkbaar ook de wil om het "hard te spelen". Dit topic is bedoelt om over eventuele tegenmaatregelen na te denken, mocht het hard tegen hard worden; en ookal denk ik dat het wel losloopt, toch blijft voorkomen beter dan genezen.

Verder was het zeker niet de bedoeling om alle (OGR'ende) DPCers accounts te verstrekken en/of alle accounts op alle proxies aan te maken, maar gewoon teams hun eigen proxy (en leden) authenticatie(-gegevens) te laten regelen en dan eventueel op team-niveau weer proxies aan elkaar te laten koppelen. Zo kunnen grote teams hun WU-voorraard veilig stellen en tegen de tijd dat de publieke stubs op zijn, kunnen 3en altijd nog bij een team aankloppen indien nodig ...

[Jive]

Kennis van me maakte me wijs dat het eenvoudiger zou zijn om een reverse SQUID te gebruiken dan met sokken te gaan pielen ..
Daar zo ook zeer eenvoudig http auth in te gebruiken zijn.

Iemand hier wat ervaring mee ??