[PHP] 100% proxycontrole in PHP, mogelijk?

[AW_Bos]

Ik had zojuist van iemand gehoord dat hij een PHP script bouwt, waarmee je heel simpel kon controleren of iemand een proxy gebruikt, en indien dat geval zo is, dat het altijd jouw eigen IP van je ISP doorgeeft.

Nu vroeg ik me af of dit technisch gezien mogelijk is?
We kennen de manier met $_SERVER['HTTP_X_FORWARDED_FOR'] wel om je eigen WAN-IP vaak te tonen, maar bij proxies van proxy4free.com die als high-anonimity worden bestempeld krijg ik toch echt nergens mijn eigen WAN-IP te zien, maar de proxy-IP.

Dus hou zou hij dat flikken dan? Of is het gewoon 'praatjes'...?
Zijn testcase is:
http://www.phpworld.nl/temp/proxy

Deze is wel vrij traag, dus hij doet iets met sockets verwacht ik?

Helaas erg jammer dat hij de source niet wil uitgeven of wilt zeggen hoe hij dat flikt.

[ Voor 7% gewijzigd door AW_Bos op 22-06-2007 16:06 ]

[KatirZan]

tja, als het al mogelijk zou zijn, dan kan je het eventueel vinden door de hops die het ip van de proxy maakt... echter, als jij je op weet ik veel hoeveel servers bevindt (websites) dan wordt dit process een stuk vermoeilijkt.

1 ding : het is mogelijk, maar ik denk niet dat dit via een phpscript te verwezenlijken valt....

[Verwijderd]

Nummerotechnisch beperkt door eigen NICJES. Proxies zouden kunnen dienen als IDONS connector veldjes.

[ Voor 255% gewijzigd door Verwijderd op 16-08-2016 23:53 ]

[gorgi_19]

Geen proxy, IP: 194.134.0.98, REAL: unknown, HOST: cache.euronet.nl.

En of dat het wel een proxy is. Het script werkt iig niet, aangezien mijn IP-adres begint met 212

[ Voor 37% gewijzigd door gorgi_19 op 22-06-2007 16:12 ]

[AW_Bos]

Verwijderd schreef op vrijdag 22 juni 2007 @ 16:07:
Nee dit kan niet. Het schijnt overigens wel mogelijk te zijn d.m.v. javascript.

IP tonen in JS kon toch alleen in Netscape?
Dus hoe zou dat in de nieuwste browsers gechekt kunnen worden met JS?

[KatirZan]

ook met javascript is het niet mogelijk..... tenminste...niet in mijn boekje...

daarnaast werkt dit script idd voor geen meter net even een proxy gebruikt (anony.) en die site van hem geeft aan dat het geen proxy is met het ip adres van de proxy zelf.....

hij heeft dus nog wat te doen

[gorgi_19]

KatirZan schreef op vrijdag 22 juni 2007 @ 16:12:
ook met javascript is het niet mogelijk..... tenminste...niet in mijn boekje...

daarnaast werkt dit script idd voor geen meter net even een proxy gebruikt (anony.) en die site van hem geeft aan dat het geen proxy is met het ip adres van de proxy zelf.....

hij heeft dus nog wat te doen

Dat niet alleen, het lijkt me sterk dat Euronet een anonieme proxy heeft

[martijnve]

Bij mij zegt hij in Firefox: Proxy gedecteerd door record 66
en in IE: Proxy gedecteerd door record 113

ik gebruik geen proxy

[ Voor 10% gewijzigd door martijnve op 22-06-2007 16:13 ]

[m-m]

Het enige dat ik hiervan weet is dat je in Firefox Java icm. javascript kan gebruiken om op een hele ranzige manier het IP te achterhalen, maar dan zie je bij NAT-gebruikers ook een lokaal IP. Zie daarvoor http://jeremiahgrossman.b...llo-nated-ip-address.html Maar dat is (uiteraard) een security hole (wel leuk).

Edit: en dan moet je uiteraard vanuit javascript het IP via bijv een xmlhttprequest o.i.d. naar de server rapporteren.

[ Voor 14% gewijzigd door m-m op 22-06-2007 16:18 ]

[AW_Bos]

Die FF securityhole is wel erg apart, om het via JAVA te kunnen doen..

Aldus de scripter:
Op het WWW is niks anoniem. Jullie hebben totaal geen begrip dat de servers íets moeten versturen om geverifeerd te worden.

Eh ja, joh ?
Dus als ik jullie mag geloven, praat hij onzin, of mist hij wat kennis van zaken... ?

[ Voor 14% gewijzigd door AW_Bos op 22-06-2007 16:27 ]

[wackmaniac]

hehe

Zou jij graag een van de eerste willen zijn die PHPworld krijgt te zien? Ben jij goed te vertrouwen en zweer je dat je geen één detail zult uitlekken? Stuur dan een mail naar [e-mail] waarom jij béta tester moet worden!

Geeft hier trouwens aan dat ik achter proxy zit, dan moet ik toch maar eens goed gaan zoeken, want zover ik weet is dit niet het geval

[drm]

De HTTP_X_FORWARDED_FOR is een representatie van de X-Forwarded-For header die in de HTTP request meegestuurd wordt. (Het geldt overigens voor alle request headers dat deze -volgens cgi specificatie- in met HTTP_ geprefixte variabelen beschikbaar gemaakt worden aan het script).

De X-... aan het begin van de header geeft al aan dat het een header is die buiten specificaties valt, wat direct betekent dat proxies zich er niet aan hoeven te houden die header mee te sturen. Dus dat je met de X-Forwarded-For header een IP zou kunnen achterhalen is sowieso al "glad ijs", want een proxy zou er voor de grap gewoon fake content in kunnen zetten; geen haan die er naar kraait.

Verder fungeert mijn router feitelijk ook als proxy. Als ik hier twee PC's achter mijn router zet en met beide PC's naar een website ga, is er geen hond die er achter kan komen wat het verschil is tussen die twee, op basis van IP-adressen. Die zijn domweg niet te achterhalen. Op het moment dat de router een verbinding opent met een server, houdt de router zelf in de gaten welk verkeer voor pc1 en welk verkeer voor pc2 bestemd is; het gaat tenslotte om verbindingen die open blijven staan. Daarom bestaat er ook het fenomeen van NAT; op het moment dat er van buitenaf een verbinding binnenkomt moet de router opeens zelf uitzoeken waar het verkeer naartoe moet, omdat er niet van binnenuit een verbinding naar buiten wordt aangevraagd (aan de hand waarvan de router vervolgens al het verkeer over die verbinding normaal gesproken naar betreffende PC doorsluist). Met een proxy is dat niet anders; het wordt alleen op een andere netwerklaag geregeld.

Kortom: het is een spannend verhaal dat het zou kunnen zonder security holes te gebruiken. En security holes zijn er om gefixt te worden, dus je hebt er niets aan.

[Cartman!]

Hier veranderd het recordnummer bij elke refresh, wat houdt dat dan in

[Gwaihir]

Je komt een stuk verder door het gebruik van een lijst van bekende anonieme proxies. Die blok je dan voor handelingen waarvoor je dat van onvoldoende vertrouwensniveau vindt.

[frickY]

Dat is, afhankelijk van de proxy, danwel mogelijk danwel onmogelijk.
Op een proxy kan worden ingesteld dat het orginele IP wordt geforward in een HTTP header. Doet de proxy dat neit, dan is het 100% onmogelijk het IP van de eindgebruiker te achterhalen.

Of je moet in de pagina zelf iets flikken wat de proxy omzijlt.
Via webproxies als bijv the-cloack zou je bijvoorbeeld een AJAX-request kunnen doen welke je dusdanig formulier dat deze niet wordt herschreven via the-cloack, en je zo een cookie kunt setten met het echte IP, welke je het volgende request uitleest.
Maar als je een proxy in je verbidninginstellingen opneemt kun je daar op geen enkele manier omheen,.

Gezien de outut als "gedetecteerd door record xx" vermoed ik dat hij gewoon een lijst met proxy-adressen heeft welke hij matched met het IP, om zo te bepalen of je via een dergelijke proxy surft. Maar hij zal lang niet alle proxies kennen.

[ Voor 15% gewijzigd door frickY op 22-06-2007 18:23 ]

[Verwijderd]

inderdaad, als een proxy niet aangeeft dat deze iets doorgeeft van een ander is elke proxy niks anders dan een gewone webbrowser. dus afgezien van het middels javascript doorsluizen van het IP address is er geen manier waarop de webserver en daarom dus ook PHP kan weten of het een request van de proxy zelf is of een doorgegeven request.

er zou echter 1 manier zijn: HTTP 301 headers. als de webserver een location redirect header naar de client stuurt moet de proxy deze eerst doorgeven aan de browser alvorens er een antwoord richting de webserver gaat. hier zit een vertraging in. door deze vertraging te meten en te vergelijken met de ping van de vermoedelijke proxy kun je wellicht uitvinden of de proxy eigenlijk forward voor een ander.

omdat proxy's vaak druk zijn en breedband nog niet overal gebruikelijk is kan dit werken maar het verschill zal op breedbande verbindingen waarbij de vertraging tussen webserver -> proxy -> browser -> proxy -> webserver onder de 30ms valt moeilijk te meten zijn. echter als de ping tussen de proxy en de webserver bijvoorbeeld 75ms is en de ping tussen de browser en de proxy nog eens 50ms is dan zal een location redirect header resulteeren in een 200ms vertraging wat kan duiden op een proxy omdat de ping maar 75ms is zou de browser dus 125ms hebben gewacht alvorens te reageeren.

duidelijk moet je meerdere metingen doen om tot een accurate uitslag te komen.

[kokx]

m-m schreef op vrijdag 22 juni 2007 @ 16:16:
Edit: en dan moet je uiteraard vanuit javascript het IP via bijv een xmlhttprequest o.i.d. naar de server rapporteren.

Wat ook weer makkelijk te faken is (gewoon JS uitschakelen en een ander berichtje in de plaats sturen).

[ Voor 10% gewijzigd door kokx op 22-06-2007 19:36 ]

[Pete]

Als je javascript(/ajax) gebruikt heb je in 9 van de 10 gevallen een 192.168.* adres of 10.*.*.* adres. De client zelf is tenslotte ook niet op de hoogte van zijn 'echte' ip-adres (voor de buitenwereld).

[Verwijderd]

Zijn er wel meerdere detectors

Deze: http://www.daantje.nl/wp-...Counter/download.php?id=9 lijkt ook wel goeie, als ik proxy opzet dan geeft ie die ook weer en men echte IP ook, dus das al goed

Maar niet elke is waterdicht natuurlijk, heb er al meerdere gehad die zeggen dat je geen proxy hebt, terwijl is dat toch echt wel is

[Gomez12]

Vraagje, maar kan je een nat-device ook niet onder de noemer (non-caching) proxy plaatsen??? Want dan zou het wel kunnen, dan is het gewoon simpel lokaal het ip-adres opvragen ( via JS / java / flash / weet ik veel ) en dit vergelijken met het ip-adres waarop het request binnenkomt. Maar ja wat je er dan nog aan hebt.

[Verwijderd]

nee, een NAT is geen proxy maar een router. het grote verschil tussen een router en een proxy is dat een proxy een request doet in naam van, en een router gewoon een doorgeefluik is. een proxy interperteerd de inhoud van de request terwijl een router de request in zijn geheel doorgeeft. een proxy kan dus de inhoud veranderen of kopieeren terwijl een router dat dus niet doet.

verschil is dus dat een proxy een kopie die e.v.t. is gewijziged doorstuurt terwijl een router gewoon het origineel doorstuurt. routers werken daarom ok op het netwerk nivo en proxies op het protocol nivo.

dit is ook gelijk de reden waarom een proxy zo moeilijk is te ontmaskeren. er is geen waterdichte methode al denk ik dat de timing/ping methode nog wel eens best accuraat kan zijn.

[Creepy]

NAT betekent Network Adres Translation. Bij NAT worden de alle packages aangepast (vandaar translation) zodat alle request direct vanuit het NAT device lijken te komen terwijl dit niet het geval is. Een beetje ala een proxy dus. Een NAT device geeft niet domweg alleen packages door.

100% proxy controle is niet mogelijk. Met javascript i.c.m. met een server side check kan je een heel eind komen maar alles wat van de client af komt is altijd aan te passen dus dat kan je niet altijd vertrouwen.

[Verwijderd]

de IP packetten die een NAT router doorgeeft worden niet aangepast. ze worden inkapseld. een IP packetje binnen in een IP packetje dus.

vergelijk het met wanneer de bijvoorbeeld de spaanse postservice jouw ansichtkaart in een envelop stopt om het zodoende middels de franse postservice te versturen. die franse postservice haalt dan de ansichtkaart er uit en stop deze in een eigen envelop die met de belgische postservice wordt verstuurt. de belgische postservice haalt de ansichtkaart weer uit de franse envelop en stop het in een belgische envelop en stuurt het naar de nederlandse postservice welke ansichtkaar uit de belgische envelop haalt en hem in de brievenbus van je familie afleverd.

een analogie met een proxy zou dan zijn dat de spaanse postservice jouw ansichtkaart onder het kopieerapperaat legt, er eventuel wat bijschrijft, een andress invult en deze vervolgens in frankrijk op de post doen. de ansichtkaart die jij in spanje dan op de post hebt gedaan is weggegooid en een kopietje is onderweg naar de ge-addresseerde.

een wezenlijk verschil.

[AW_Bos]

Interessante theorieen allemaal .
Had al in de gaten dat 100% proxies eruitpakken niet kan en ook het tonen van je WAN ip in de normale praktijk. Maar hij blijft zeggen dat het mogelijk is, en dat script uit zijn testcase nog niet goed werkt. ( )

Heb gewoon het idee dat ie lult, een beetje programmeur had wel uit de doeken gedaan hoe het werkt.. behalve hij. Jammer genoeg zal ik hem niet geloven.

Maar ik weet weer genoeg. Als iemand nog wat toe te voegen heeft aan deze discussie... come on

[Thralas]

CANCEL zegt 'ie hier na een SYN mijn kant op op 80 (draai een webserver). Na aanpassen van iptables:

[root@pargon tmp]# wget -q -O - http://www.phpworld.nl/temp/proxy
OK

[root@pargon tmp]# tcpdump -nn host phpworld.nl
03:08:37.686908 IP 195.22.103.83.39647 > 123.123.123.123.80: S 391841910:391841910(0) win 5840 <mss 1460,sackOK,timestamp 1502107820 0,nop,wscale 2>
03:08:38.686220 IP 195.22.103.83.39648 > 123.123.123.123.443: S 389670633:389670633(0) win 5840 <mss 1460,sackOK,timestamp 1502108820 0,nop,wscale 2>
03:08:39.687803 IP 195.22.103.83.39649 > 123.123.123.123.80: S 397670041:397670041(0) win 5840 <mss 1460,sackOK,timestamp 1502109820 0,nop,wscale 2>
03:08:40.685482 IP 195.22.103.83.39650 > 123.123.123.123.8080: S 398131188:398131188(0) win 5840 <mss 1460,sackOK,timestamp 1502110820 0,nop,wscale 2>
03:08:41.685382 IP 195.22.103.83.39651 > 123.123.123.123.443: S 397511377:397511377(0) win 5840 <mss 1460,sackOK,timestamp 1502111820 0,nop,wscale 2>
03:08:42.685065 IP 195.22.103.83.39652 > 123.123.123.123.25: S 403266777:403266777(0) win 5840 <mss 1460,sackOK,timestamp 1502112820 0,nop,wscale 2>

(Je moet kijken naar 123.123.123.123 - 'mijn' IP)

Hij vergeet o.a. de poorten van CODEEN (3127 etc) proxies (en dat zijn er veel).

Kort: het ding probeert een verbinding te maken met je PC op bepaalde poorten (en je op basis daarvan als proxy classificeren). Verder zag ik geen request in m'n HTTP logs (toen ik hem niet firewalled had) - en kan het script dus beter alleen een SYN sturen ipv. een hele connectie opzetten.

Aan je 'echte' IP komt hij nooit bij gebruik van een goede proxy. Enige (al genoemde) manieren zijn clientside gebruik van Java of Flash.

[ Voor 5% gewijzigd door Thralas op 24-06-2007 03:30 ]

[AW_Bos]

Gek dat hij CACEL uitspuugt bij XS4ALL proxy i.p.v. CANCEL..?

Of zou hij toch per bekende proxy deze listen en een eigen return-code geven?

[ Voor 38% gewijzigd door AW_Bos op 24-06-2007 13:00 ]

[Gwaihir]

Verwijderd schreef op zaterdag 23 juni 2007 @ 15:21:
de IP packetten die een NAT router doorgeeft worden niet aangepast. ze worden inkapseld. een IP packetje binnen in een IP packetje dus.

Oh? Dus..

- IP pakketjes hebben geen vaste lengte?
- Ontvangers van IP pakketjes die de data nodig hebben, pakken 'zonder boe of bah' meerdere verpakkingen eraf?
- Zo'n ontvanger krijgt altijd de beschikking over je LAN-IP te (de afzender van de binnenste envelop)? En wellicht ook over het LAN IP van je router?

[Ik weet weinig van TCP/IP; ik probeer het me voor te stellen / bij te leren.]

[Janoz]

Verwijderd schreef op zaterdag 23 juni 2007 @ 15:21:
de IP packetten die een NAT router doorgeeft worden niet aangepast. ze worden inkapseld. een IP packetje binnen in een IP packetje dus.

vergelijk het met wanneer de bijvoorbeeld de spaanse postservice jouw ansichtkaart in een envelop stopt om het zodoende middels de franse postservice te versturen. die franse postservice haalt dan de ansichtkaart er uit en stop deze in een eigen envelop die met de belgische postservice wordt verstuurt. de belgische postservice haalt de ansichtkaart weer uit de franse envelop en stop het in een belgische envelop en stuurt het naar de nederlandse postservice welke ansichtkaar uit de belgische envelop haalt en hem in de brievenbus van je familie afleverd.

een analogie met een proxy zou dan zijn dat de spaanse postservice jouw ansichtkaart onder het kopieerapperaat legt, er eventuel wat bijschrijft, een andress invult en deze vervolgens in frankrijk op de post doen. de ansichtkaart die jij in spanje dan op de post hebt gedaan is weggegooid en een kopietje is onderweg naar de ge-addresseerde.

een wezenlijk verschil.

Ik denk dat je hier NAT met VPN aan het verwarren bent. Je hele beschrijving is onderuit te halen door te vertellen dat er aan de andere kant 0,0 aanpassingen nodig zijn. Er hoeft geen omsluitend pakketje uit gepakt te worden. Er is geen belgische postbode nodig die eerst de ansichtkaart uit de envelop moet halen. Het enige wat bij NAT gebeurt is dat het source IP aangepast wordt (dit is immers het interne IP) en vervolgens onthouden wordt welk intern IP er bij hoort zodat van de binnenkomende pakketjes van dezelfde tcp-ip verbinding het destination IP aangepast kan worden en doorgestuurd kunnen worden naar de computer in het interne netwerk.

[Verwijderd]

klopt, sorry. had even ethernet met IP verwisseld.

VPN doet eigenlijk precies het zelfde alleen worden ethernet frames ge-simuleerd middels IP packetjes. een NAT verander inderdaad alleen het source-ip. de analogie die ik gaf met envoloppen klopt overigens wel alleen is het dus de IP packetjes in ethernet frames worden gestop in niet in andere IP packetjes.

@birdie:
1) IP packetjes hebben een minimum lengte van 20 bytes en een maxium van 64Kilobytes.
2) ja, elke router pakt een IP packetje in een ethernet frame en verstuurt deze naar de volgende router. het internet is een aan-een-schakeling van routers en elke router heeft zijn eigen lokale ethernet address. daarom zijn ethernet frames lokaal en IP packetjes globaal. je kunt dus 2 routers hebben met het zelfde ethernet address maar nooit in het zelfde netwerk. zoals in mijn voorbeeld kan de router in spanje en de router in nederland het zelfde ethernet address hebben en de router in frankrijk weet alleen van de router in spanje en belgie, de router in belgie weet weer alleen van de router in nederland en in frankrijk en weer niks van die in spanje. ethernet frames zijn alleen tussen 'buren' van routers. niet de buren daar weer van.
3) zoals Janoz inderdaad was opgevallen veranderd een NAT-router dus het 'afzender IP' van je computer met die van de router zelf. zodoende weet de ontvanger waar het antwoord dus heen moet, echter het interne IP weet de ontvanger dus niet. dat heeft de NAT-router vervangen met zijn eigen IP.

kort samengevat wordt dat dus:
1, jouw computer pakt de informatie in een IP-paketje
2, jouw computer pakt het IP-paketje in een ethernet frame met het address van jouw router/switch
3, jouw router pakt het ethernet frame uit en kijkt naar het doel address van het IP-paketje
4, jouw router kijkt in zijn router-table over welke netwerpoort deze het paketje moet verder sturen.
5, jouw router pakt het IP-paketje in een nieuw ethernet frame en stuur het over de netwerk verbinding die in stap 4 was gevonden. routers hebben altijd een soort 'overige' verbinding waar alles heen gaat waarneer niet kon worden ontdenkt welke kant het IP-paketje op moet.
6, de router van jouw ISP ontvangt het ethernet frame en herhaalt de stappen 3 t/m 5 totdat het packetje op een router terecht komt waar de computer met het doel IP-address zicht bevindt.
7, de doel computer ontvangt het ethernet frame en pakt het uit en stopt vervolgens het IP-packetje in een buffer van de bijbehorende netwerkkaart.
8, het besturingssysteem leest de buffer van de netwerkkaart uit en stopt de informatie uit de IP-packetjes in een buffer van de bijbehorende poort nummer.
9, het programma leest vervolgens de buffer van het bijbehorende poort nummer en hoeft zich niet bezig te houden met het verzamelen van de individuele IP-packetjes. de bytes kunnen gewoon als een lange stroming van bytes worden gelezen netalsof het een gewoon bestand is zonder einde.

zie ook wikipedia:
http://en.wikipedia.org/wiki/IPv4
http://en.wikipedia.org/wiki/Ethernet
http://en.wikipedia.org/wiki/Network_address_translation

[TheRookie]

Zou die pagina ge /GoT zijn ik krijg iig een page not found...

[Verwijderd]

ik denk dat die immidels door de mand is gevallen en zijn site offline heeft gehaald om verdere verneedering te voorkomen.

aan de andere kant, als zijn server kennis net zo groot is als zijn netwerk kennis zou het me niet verbazen dat zijn brakke server onder de toch ook weer niet zo'n grote aandacht is bezweken.

edit:
ik zie dat ze zijn gesloten 'wegens overtollige werkzaamheden'.
quote uit van www.phpworld.nl

PHPWorld wordt helaas uitgesteld wegens het aftreden van René. Hij heeft definitief bekend gemaakt zijn werk op PHPworld neer te leggen wegens overtollige werkzaamheden. We houden jullie op de hoogte.

ik wens ze veel succes.

[ Voor 35% gewijzigd door Verwijderd op 28-06-2007 16:42 ]

[Sendy]

Verwijderd schreef op donderdag 28 juni 2007 @ 15:35:
klopt, sorry. had even ethernet met IP verwisseld.

Nou, dat had je dan best in die eerdere post kunnen editten. Nu denk ik dat je het gewoon niet snapt. Trouwens, er bestaan ook nog andere computernetwerk technieken dan ethernet (bijv. frame relay.) Een ip pakket wordt dus niet per definitie altijd in een ethernet frame ingepakt.

PHPWorld wordt helaas uitgesteld wegens het aftreden van René. Hij heeft definitief bekend gemaakt zijn werk op PHPworld neer te leggen wegens overtollige werkzaamheden. We houden jullie op de hoogte.

Tja, hij kan beter stoppen met de overtollige werkzaamheden; die zijn toch niet nodig

[ Voor 26% gewijzigd door Sendy op 28-06-2007 17:11 ]

[Hydra]

phsmit schreef op zaterdag 23 juni 2007 @ 09:52:
Als je javascript(/ajax) gebruikt heb je in 9 van de 10 gevallen een 192.168.* adres of 10.*.*.* adres. De client zelf is tenslotte ook niet op de hoogte van zijn 'echte' ip-adres (voor de buitenwereld).

Als het gaat om het buitenhouden van iemand met een anonieme proxy dan gaat alles wat clientside checks vereist ook niet werken. Mensen die slim genoeg zijn een anonieme proxy te vinden snappen meestal ook wel dat je JS uit kunt zetten.

[Verwijderd]

Sendy schreef op donderdag 28 juni 2007 @ 16:58:
[...]

Nou, dat had je dan best in die eerdere post kunnen editten. Nu denk ik dat je het gewoon niet snapt. Trouwens, er bestaan ook nog andere computernetwerk technieken dan ethernet (bijv. frame relay.) Een ip pakket wordt dus niet per definitie altijd in een ethernet frame ingepakt.


[...]

Tja, hij kan beter stoppen met de overtollige werkzaamheden; die zijn toch niet nodig

volgensmij is het nog altijd policy hier op GoT om niet je post te editten nadat iemand na jouw post, en al helemaal niet als je ook nog eens wordt ge-quote, door Janoz in dit geval.

daarnaast is het inderdaad mogelijk om andere netwerk protocollen naast ethernet te gebruiken maar ik denk dat als ik zeg dat 99% van de computers in de wereld ethernet gebruikt dat ik er niet ver afzit. je ISP kan dan wel ATM gebruiken maar daarom gebruik jij nog wel steeds ethernet tot aan je ISP.

wikipedia over Layer 2 zoals ethernet, frame relay en ATM
wikipedia over Layer 3 zoals IPv4 maar ook IPX of IPsec

[Verwijderd]

Ik denk persoonlijk dat mensen hier dingen een beetje verkeerd opvatten.

Ook ik weet dat 100% proxy controle nooit zal werken, dat paginas slomer worden er door en alle anderen dingen waar hier over gesproken wordt. Naast de verhalen dat ik "door de mand" zou zijn gevallen.

Er is maar een iemand in dit topic die begreep hoe het inelkaar zat, en daar ga ik verder ook niet meer over hebben. Ik gebruikte geen lijsten met ips en al die onzinnige troep. Het script "herschreef" zichzelf door alle bezoeken die hij kreeg.

Ik heb het script na een tijdje weg gegooid omdat de desbetreffende server alleen nog maar met die overtollige uitgave van pings/checks e.d. bezig was terwijl ik er een COMET systeem op was aan het testen dat al genoeg load met zich meebrengt (gaat vaak genoeg fout).

Nader tijd heb ik een besloten te stoppen met PHPWorld, maar dit staat uiteraard volledig buiten dit proxy script, kon hem met gemak ergens anders hosten. Maar ik zag het nut er niet van in. Ik heb het desbetreffende script geschreven omdat ik mij eens "verveelden", maar dat er zo'n "ophef" over komt omdat hij enkel verwijderd is, kom op zeg.

Tot slot heb ik ook nooit gezegt dat het een 100% werkend proxy script zou zijn. Zelfs mijn dochter van 2 weet dat dat niet kan. Ik hoop dat er nu meer duidelijkheid is over "dat script".

Sendy schreef op donderdag 28 juni 2007 @ 16:58:

[...]

Tja, hij kan beter stoppen met de overtollige werkzaamheden; die zijn toch niet nodig

Het is maar goed dat het gequote bericht geschreven is na het verwijderen van dit proxy script.

Verwijderd schreef op donderdag 28 juni 2007 @ 16:36:
edit:
ik zie dat ze zijn gesloten 'wegens overtollige werkzaamheden'.
quote uit van www.phpworld.nl

[...]


ik wens ze veel succes.

Gesloten wegens V2, niet wegens mijn overtollige werkzaamheden.

[ Voor 18% gewijzigd door Verwijderd op 01-07-2007 13:56 ]

[Sendy]

Verwijderd schreef op zondag 01 juli 2007 @ 13:52:
[...]
Het is maar goed dat het gequote bericht geschreven is na het verwijderen van dit proxy script.
[...]
Gesloten wegens V2, niet wegens mijn overtollige werkzaamheden.

Want? Anders stuur je je script op me af?

Wat ik bedoel is dat als een werkzaamheid overtollig is, je het beter niet kan doen:

www.vandale.nl:

over·tol·lig (bn.)
1 boven het benodigde aantal, de benodigde hoeveelheid => overbodig

[roy-t]

Verwijderd schreef op zondag 01 juli 2007 @ 13:52:

...

Ook ik weet dat 100% proxy controle nooit zal werken, dat paginas slomer worden er door en alle anderen dingen waar hier over gesproken wordt. Naast de verhalen dat ik "door de mand" zou zijn gevallen.

Er is maar een iemand in dit topic die begreep hoe het inelkaar zat, en daar ga ik verder ook niet meer over hebben. Ik gebruikte geen lijsten met ips en al die onzinnige troep. Het script "herschreef" zichzelf door alle bezoeken die hij kreeg.

...

Er is maar 1 iemand hier die je begrijpt? ik ben het niet iig, en ok we verwachten natuurlijk nooit 100%

maar ik vind dit toch een beetje hoog "kijk mij eens" gehalte hebben omdat je niet eens een klein tipje van de sluier oplicht.

Misschien had je wel een goede theorie, maar kom op als je de mooie neemt om hier te posten, post dan ook iets nuttigs en niet "jullie snappen het toch niet"

[Pete]

Verwijderd schreef op zondag 01 juli 2007 @ 13:52:
...Ik heb het desbetreffende script geschreven omdat ik mij eens "verveelden", maar dat er zo'n "ophef" over komt omdat hij enkel verwijderd is, kom op zeg.
...

Wat is er dan tegen om dit scriptje te publiceren? Of schaam je je voor je werk?

[Verwijderd]

phsmit schreef op dinsdag 03 juli 2007 @ 16:18:
[...]


Wat is er dan tegen om dit scriptje te publiceren? Of schaam je je voor je werk?

Wat is er tegen het te verwijderen? Ik zie het probleem niet.

therat10430 schreef op dinsdag 03 juli 2007 @ 15:46:
[...]


Er is maar 1 iemand hier die je begrijpt? ik ben het niet iig, en ok we verwachten natuurlijk nooit 100%

maar ik vind dit toch een beetje hoog "kijk mij eens" gehalte hebben omdat je niet eens een klein tipje van de sluier oplicht.

Misschien had je wel een goede theorie, maar kom op als je de mooie neemt om hier te posten, post dan ook iets nuttigs en niet "jullie snappen het toch niet"

Als je het topic goed doorlas had je gezien dat het enkel naar de ip's pingt op ports en vergelijkt met APR records. Dacht dat dat wel makkelijk te achterhalen was?

[Gwaihir]

Verwijderd schreef op dinsdag 03 juli 2007 @ 19:26:Als je het topic goed doorlas had je gezien dat het enkel naar de ip's pingt op ports en vergelijkt met APR records. Dacht dat dat wel makkelijk te achterhalen was?

ARP neem ik aan?

'k snap niet hoe dat helpt bij proxy-detectie . Iemand zin me dat uit te leggen? Proxies (anonieme in elk geval) geven toch neem ik aan net zo min het orginele MAC addres door als ze het orginele IP doorgeven?

[Verwijderd]

sterker nog: ze weten het MAC address niet eens. een MAC address is alleen lokaal uniek dus tenzij jij op het zelfde netwerk zit als die proxy kan de proxy jouw MAC niet eens zien.

maar waarschijnlijk weet alleen de wijkcentrale het MAC address van jouw router/DLS modem en die stuurt de IP packet al weer door naar de backbone van jouw ISP welke ook weer hun eigen MAC address hebben welke de zelfde kan zijn als jouw DLS modem.

een MAC address identificeert een fysieke netwerk poort op het netwerk oftewel Layer 1.

[ Voor 7% gewijzigd door Verwijderd op 04-07-2007 18:26 ]