Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Internetfreigabe

1 view
Skip to first unread message

Ralf Britz

unread,
Jun 25, 2003, 5:16:23 PM6/25/03
to
Ich habe einen PC mit 2 Netzwerkkarten als server und 2 clients per
BNC-Netzwerk verbunden,
unter windows aktiviere ich einfach beim server die internetfreigabe und die
beiden anderen
PC teilen sich mit meinem die Internetverbindung, das funktioniert völlig
problemlos. -DSL-
Ich habe auch suse 8.0 prof. installiert, komme damit aber nur mit dem
server ins Netz, das
mit dem Teilen der Verbindung ist mir ein Rätsel.

Kann mir mir jemand, als Linux-Anfänger, mit einfachen Worten erklären, wie
ich die
Verbindung teilen kann, analog zur Windows Internetfreigabe.

Ich hoffe, ich bin hier im richtigen Forum..

Gruß aus der Lüneburger Heide von Ralf, der gerne unabhängiger von Microsoft
wäre...


Andreas Stieger

unread,
Jun 25, 2003, 5:34:06 PM6/25/03
to
Ralf Britz wrote:

[Internetverbindungsfreigabe]

Du hast die Wahl:

a) Du installiert einen Proxy auf deinem Server, z.B. squid. Damit können
die Clients über den Server per HTTP auf das Internet zugreifen.

b) Du leitest den Netzwerkverkehr weiter, und zwar zwischen deinem privaten
Netz und dem Internet. Dazu brauchst du software, die NAT unterstützt, z.B.
die SuSE Firewall. So sind auch nicht HTTP-Verbindungen, z.B. das Abrufen
von E-Mail per POP3 möglich.

a ist sicherer, einfacher und reicht wenn die Clients nur surfen sollen.
b bietet mehr möglichkeiten

--
Document my code? Why do you think they call it "code"?

Ralph Aichinger

unread,
Jun 26, 2003, 2:02:51 AM6/26/03
to
Andreas Stieger <Andreas...@gmx.de> wrote:
> a) Du installiert einen Proxy auf deinem Server, z.B. squid. Damit können
> die Clients über den Server per HTTP auf das Internet zugreifen.
>
> b) Du leitest den Netzwerkverkehr weiter, und zwar zwischen deinem privaten
> Netz und dem Internet. Dazu brauchst du software, die NAT unterstützt, z.B.

> a ist sicherer, einfacher und reicht wenn die Clients nur surfen sollen.
^^^^^^^^^^^^
Wie begründest du das? Ich würde das genau umgekehrt sehen.

/ralph

Stephan Weinberger

unread,
Jun 26, 2003, 2:20:17 AM6/26/03
to
* Ralf Britz <ralf....@tiscali.de> wrote:

> Ich habe auch suse 8.0 prof. installiert, komme damit aber nur mit dem
> server ins Netz, das
> mit dem Teilen der Verbindung ist mir ein Rätsel.

SuSE bietet da inzwischen glaub ich auch irgendwas vorgekautes an
(muesstest Du im Yast nachschauen, ich verwend' das Graffl nicht), aber
"zu Fuss" ist der Lerneffekt wohl groesser :-) Stichwort "Masquerading"
-> IP-Masquerade-Howto, zu finden auf http://www.tldp.org (der oesterr.
Mirror http://www.ldp.at scheint gerade nicht zu funktionieren).


> Ich hoffe, ich bin hier im richtigen Forum..
> Gruß aus der Lüneburger Heide von Ralf, der gerne unabhängiger von
> Microsoft wäre...

.at steht zwar fuer Oesterreich, aber wir haben ja nix gegen deutsche
Gaeste. Ausserdem heiligt der Zweck in diesem Fall wohl die Mittel :-)

--
cu mail: s.wein...@xover.mud.at
Stephan www: http://www.invisible.priv.at
The choices we make, not the chances we take, determine our destiny.

Szomraky Stefan

unread,
Jun 26, 2003, 2:20:57 AM6/26/03
to
Ralf Britz wrote:
> [.. NAT ..]

>
> Kann mir mir jemand, als Linux-Anfänger, mit einfachen Worten erklären, wie
> ich die
> Verbindung teilen kann, analog zur Windows Internetfreigabe.
>
> Ich hoffe, ich bin hier im richtigen Forum..
>

Eine normale Susi Installation sollte bereits alles notwendige dazu
besitzen.

1. IP Pakete weiterleiten lassen
echo 1 > /proc/sys/net/ipv4/ip_forward

2. NAT aktivieren (Network Adress Translations. Die Quelladressen der IP
Pakete deiner LAN Rechner werden während des Routings umgeschrieben,
damit man sie im Internet deinem Linux Rechner zuordnen kann)

iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j DNAT
^^^^^^^^^^^^^^

Markierter Teil bedeutet: Netz 192.168.0.0 mit der Netmask 255.255.255.0
(192.168.0.1-254) - das mußt du evtl. deinem Netzwerk anpassen.

3. Fertig. Eventuell müßen die Clients noch angepasst werden.
(Default Gateway: Dein Linux Recher, DNS Server: Die DNS Server deines ISPs)


mfg

Wolfgang Fuschlberger

unread,
Jun 26, 2003, 2:29:41 AM6/26/03
to

Ich würde sagen, allein schon durch die Komplexität des Setups können
sich bei einem reinen Squid weniger Fehler/potentielle Sicherheitslücken
einschleichen (wenn man nicht genau weiß, was man tut ;-) ). Allerdings
will man wohl auch davor dann einen Paketfilter, insofern ist das
Problem wohl nur theoretisch interessant.

wolfgang
--
http://www.ffs.or.at .-- --- .-.. ..-. --. .- -. --. ...
http://www.unix-stuff.de ... .. --. -. .- - ..- .-. .

Andreas Stieger

unread,
Jun 26, 2003, 3:17:48 AM6/26/03
to
Ralph Aichinger wrote:

>> a ist sicherer,

> ^^^^^^^^^^^^
> Wie begründest du das? Ich würde das genau umgekehrt sehen.

Es ist von der Netztheorie her sicherer, weil so Internet und privates Netz
mit einem Proxy (application level gateway) nur logisch auf Anwendungsebene
(vergl1. OSI bzw. TCP/IP-Schichtenmodell) verbunden wären, nicht aber auf
IP-Ebene. (Routing, NAT)

Ein Client wäre dann beschränkt, per HTTP auf der Internet zuzugreifen. Da
geht kein Verkehr durch den du nicht willst, z.B. kann ein komprimottierter
oder böswilliger Client nicht spammen, hacken oder nach hause telefonieren.

Andreas

Thomas Schlager

unread,
Jun 26, 2003, 3:29:33 AM6/26/03
to
* Szomraky Stefan <st...@gmx.net>:

> 1. IP Pakete weiterleiten lassen
> echo 1 > /proc/sys/net/ipv4/ip_forward
Okay.

> 2. NAT aktivieren (Network Adress Translations. Die Quelladressen der IP
> Pakete deiner LAN Rechner werden während des Routings umgeschrieben,
> damit man sie im Internet deinem Linux Rechner zuordnen kann)
>
> iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -j DNAT
^^^^

Wohl kaum oder?

JFYI - Thomas.

Thomas Schlager

unread,
Jun 26, 2003, 3:40:49 AM6/26/03
to
* Ralf Britz <ralf....@tiscali.de>:

> Ich habe einen PC mit 2 Netzwerkkarten als server und 2 clients per
> BNC-Netzwerk verbunden, unter windows aktiviere ich einfach beim
> server die internetfreigabe und die beiden anderen PC teilen sich
> mit meinem die Internetverbindung, das funktioniert völlig
> problemlos. -DSL- Ich habe auch suse 8.0 prof. installiert, komme
> damit aber nur mit dem server ins Netz, das mit dem Teilen der
> Verbindung ist mir ein Rätsel.
>
> Kann mir mir jemand, als Linux-Anfänger, mit einfachen Worten
> erklären, wie ich die Verbindung teilen kann, analog zur Windows
> Internetfreigabe.

Reine Packetfreigabe erfolgt folgendermaßen:
echo "1" > /proc/sys/net/ipv4/ip_forward

Damit von außen nicht gleich jeder sehen kann, dass da noch ein
Netzwerk ist:
iptables -t nat -A POSTROUTING -o $EXT_IF -j SNAT --to xxx.xxx.xxx.xxx
oder:
iptables -t nat -A POSTROUTING -o $EXT_IF -j MASQUERADE
Hängt ganz davon ab, ob du eine dynamische IP beziehst oder nicht,
wobei $EXT_IF deine externe Netzwerkkarte(zum ISP) ist, ala: "eth1".

SuSe bringt aber sicher etliche Tools mit, die dir das ähnlich
konfigurieren -> Manual.

HTH - Thomas.

Heinrich Elsigan

unread,
Jun 26, 2003, 3:47:31 AM6/26/03
to

Bei Sicherheit, im Sinne von eigeschränktem Zugriff, ist die jeweilige
Konfiguration sehr ausschlaggebend.
Generell unabhänging von der Konfiguration
zu behaupten a.) ist sicher als b.) oder umgekehrt halte ich für gewagt.

Dazu ein Beispiel:

a.) Ein Squid-Proxy der mittels ACLs nur von einigen internen
Hosts nur http auf wieder ein par ausgwählte exterene Hosts,
und das nur am Sonntag und nur von einem gewissen Browsertyp aus,
(acls: src, dst, time, url_regex, port, proto, method, browser)
ist wahrscheinlich sicherer als ein voll offenes SNAT.

b.) SNAT mit iptables, das sehr eingeschränkt wird, wie z.B.:
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -A FORWARD -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -s
[ausgewählte interne IPs] -d [wenige hosts] -p tcp -i eth1 -o eth0
iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED -s
[wenige hosts] -d [ausgewählte interne IPs] -p tcp -i eth0 -o eth1

iptables -t nat -A POSTROUTING -s [ausgewählte interne IPs] -d [wenige
hosts] -p tcp --dport 80 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s [ausgewählte interne IPs] -d [wenige
hosts] -p tcp --dport 443 -o eth0 -j MASQUERADE
ist "sicherer" als ein voll offener, schlecht konfigurierter squid.

lG
Heinrich Elsigan.

P.S.: Wie sicher ist SNAT mit Transparent Squid Proxy ?


Thomas Themel

unread,
Jun 26, 2003, 4:19:14 AM6/26/03
to
Andreas Stieger <Andreas...@gmx.de> wrote on 2003-06-26:
> Es ist von der Netztheorie her sicherer, weil so Internet und privates Netz
> mit einem Proxy (application level gateway) nur logisch auf Anwendungsebene
> (vergl1. OSI bzw. TCP/IP-Schichtenmodell) verbunden wären, nicht aber auf
> IP-Ebene. (Routing, NAT)

Ja, die schöne Theorie. In der Praxis habe ich noch keine Installation
gefunden, wo kein SSL erlaubt wäre. Damit ist der Datenstrom für den
Proxy nicht mehr lesbar, und dann kann man sich beliebig mit SSH, PPP
und diversen IP-over-IP-Schemes spielen.

Und auch sonst kann man, einen willigen Partner außerhalb vorausgesetzt,
TCP-over-HTTP machen - und TCP ist dann wieder ein bidirektionaler Datenstrom,
über den man PPP über das man IP über das man...

> Ein Client wäre dann beschränkt, per HTTP auf der Internet zuzugreifen. Da
> geht kein Verkehr durch den du nicht willst, z.B. kann ein komprimottierter
> oder böswilliger Client nicht spammen, hacken oder nach hause telefonieren.

Es ist vermutlich unmöglich, mindestens unwirtschaftlich, eine größere
Anzahl User zufriedenstellend mit Webzugang zu versorgen und
gleichzeitig zu verhindern, dass jemand beliebige Netzwerkverbindungen
über den Proxy fährt.

ciao,
--
[*Thomas Themel*]
[extended contact] Obscurity is the refuge of incompetence.
[info provided in] - Jubal Harshaw in Stranger In A Strange Land
[*message header*]

Daniel Tiefnig

unread,
Jun 26, 2003, 4:36:04 AM6/26/03
to
Andreas Stieger wrote:
> Ein Client wäre dann beschränkt, per HTTP auf der Internet
> zuzugreifen. Da geht kein Verkehr durch den du nicht willst, z.B. kann
> ein komprimottierter oder böswilliger Client nicht spammen, hacken
> oder nach hause telefonieren.

Außer er spammed, ha^Wcracked und telephoniert über HTTP. :o)

Ich denke die Einschränkung erschwert höchstens die Arbeit, erhöht in
dem Sinn aber nicht automatisch die Sicherheit, was ursprünglich
behauptet wurde.


lg,
daniel

Ralph Aichinger

unread,
Jun 26, 2003, 4:54:16 AM6/26/03
to
Wolfgang Fuschlberger <usenet-...@fuschlberger.net> wrote:
> Ich würde sagen, allein schon durch die Komplexität des Setups können
> sich bei einem reinen Squid weniger Fehler/potentielle Sicherheitslücken
> einschleichen (wenn man nicht genau weiß, was man tut ;-) ).

Derzeit scheinen offene Proxies das Lieblingsspielzeug von Spammern
zu sein. Wie erklärst du das dann? Ich glaube nicht, daß Squid
so fürchterlich einfach zu konfigurieren ist.

Dazu kommt noch die Möglichkeit eines Buffer overflows bei einem
Proxy (oder sonstiger Exploits), die beim Kernel-iptables-Code
viel unwahrscheinlicher sind.

Hingegen geht bei dem üblichen 3-Zeilen Masquerading (alles
dicht, nur von innen nach außen ist erlaubt) die Konfiguration
*wirklich* übersichtlich.

>Allerdings
> will man wohl auch davor dann einen Paketfilter, insofern ist das
> Problem wohl nur theoretisch interessant.

Eben. Ein Squid alleine ist oft nicht so super.

/ralph

Andreas Stieger

unread,
Jun 26, 2003, 4:56:05 AM6/26/03
to
Daniel Tiefnig wrote:

> Ich denke die Einschränkung erschwert höchstens die Arbeit,

Wie gesagt es kommt auf die Anforderungen an, die die Clients haben. Wollen
sie mehr als HTTP, so hast du recht.-

> erhöht in dem Sinn aber nicht automatisch die Sicherheit, was
> ursprünglich behauptet wurde.

Doch, denn ich denke es ist die Minimallösung im Sinne von
Zugriffsmöglichkeiten auf das Internet, vgl. KISS-Prinzip.

Andi

Daniel Tiefnig

unread,
Jun 26, 2003, 5:14:00 AM6/26/03
to
Andreas Stieger wrote:
> Wollen sie mehr als HTTP, so hast du recht.-

Eigentlich meinte ich die Arbeit des Crackers. :o)

> Doch, denn ich denke es ist die Minimallösung im Sinne von
> Zugriffsmöglichkeiten auf das Internet, vgl. KISS-Prinzip.

Naja, aber über HTTP(S) kann man (wohl genau aus dem Grund, dass HTTP(S)
oft die fast einzige Möglichkeit ist ins Netz zu kommen) mittlerweile
fast alles mit fertigen Tools tunneln. Wie gesagt, es wird ein bisschen
aufwendiger, aber nicht "sicherer".


lg,
daniel

Andreas Stieger

unread,
Jun 26, 2003, 5:25:04 AM6/26/03
to
Daniel Tiefnig wrote:

> Naja, aber über HTTP(S) kann man (wohl genau aus dem Grund, dass HTTP(S)
> oft die fast einzige Möglichkeit ist ins Netz zu kommen) mittlerweile
> fast alles mit fertigen Tools tunneln. Wie gesagt, es wird ein bisschen
> aufwendiger, aber nicht "sicherer".

Ich glaube du hast das Anfangsproblem da ein wenig erweitert. Es ging nicht
darum, das System vor den (menschlichen) Benutzern der Clients zu schützen.
Wenn es sich um ein privates Netz handelt, kann man aktive Versuche wie
Tunneln ausschließen.
Dagegen wird ein Application Leven Gateway wahlfreie Verbindungen zum
Internet z.B. im Falle eines trojanischen Pferdes unterbinden, eben weil es
auf Anwendungsschicht und nicht auf der Transportschicht arbeitet.

Andreas

Wolfgang Fuschlberger

unread,
Jun 26, 2003, 5:29:23 AM6/26/03
to
Ralph Aichinger <ra...@dolphy.pangea.at> wrote:
> Wolfgang Fuschlberger <usenet-...@fuschlberger.net> wrote:
>> Ich würde sagen, allein schon durch die Komplexität des Setups können
>> sich bei einem reinen Squid weniger Fehler/potentielle Sicherheitslücken
>> einschleichen (wenn man nicht genau weiß, was man tut ;-) ).
>
> Derzeit scheinen offene Proxies das Lieblingsspielzeug von Spammern
> zu sein. Wie erklärst du das dann? Ich glaube nicht, daß Squid
> so fürchterlich einfach zu konfigurieren ist.

Also, wenn Du mich fragst: doch, das ist er.
Scheiße bauen kann man natürlich auch bei einem Minimalsetup super mit
den Acls, aber das grenzt dann schon an Vorsatz. (Alles natürlich unter
der Voraussetzung, daß der Squid selber keine exploitablen Bugs hat.)

> Dazu kommt noch die Möglichkeit eines Buffer overflows bei einem
> Proxy (oder sonstiger Exploits), die beim Kernel-iptables-Code
> viel unwahrscheinlicher sind.

ACK.

> Hingegen geht bei dem üblichen 3-Zeilen Masquerading (alles
> dicht, nur von innen nach außen ist erlaubt) die Konfiguration
> *wirklich* übersichtlich.

Hmm, wer, der iptables verwendet, bleibt beim 3-Zeilen-Masquerading?
Es hat natürlich sicher nicht jeder 3 Netzwerkkarten und 4 Subnetze so
wie ich, der Normalfall wird wohl irgendwo dazwischen liegen, aber wenn
ich einen (Windows-)Rechner masqerade mach ich ihm aus Prinzip nicht
alles Richtung Internet auf.

>>Allerdings
>> will man wohl auch davor dann einen Paketfilter, insofern ist das
>> Problem wohl nur theoretisch interessant.
>
> Eben. Ein Squid alleine ist oft nicht so super.

Eh klar. Und wenn es nur wegen des ruhigen Schlafs ist :-)

Thomas Themel

unread,
Jun 26, 2003, 5:48:29 AM6/26/03
to
Andreas Stieger <Andreas...@gmx.de> wrote on 2003-06-26:
> Dagegen wird ein Application Leven Gateway wahlfreie Verbindungen zum
> Internet z.B. im Falle eines trojanischen Pferdes unterbinden, eben weil es
> auf Anwendungsschicht und nicht auf der Transportschicht arbeitet.

Das steht vielleicht in der Marketing-Broschüre von Checkpoint. Bei SSL
geht das ganz einfach nicht, weil es mit den üblicherweise zur Verfügung
stehenden Rechnerkapazitäten keine Möglichkeit gibt, zwischen einem
3DES-verschlüsselten 'GET /secure/index.php' und einem
3DES-verschlüsselten 'begin secret.doc 644' zu unterscheiden.

ciao,
--
[*Thomas Themel*] Deine Rechtschreibung ist derartig miserabel, daß ich mich
[extended contact] frage, wie Du das überhaupt schreiben kannst, ohne ständig
[info provided in] zu schreien. Bist Du blind?
[*message header*] - Lutz Donnerhacke in dasr

Peter J. Holzer

unread,
Jun 26, 2003, 8:56:37 AM6/26/03
to
On 2003-06-26 08:54, Ralph Aichinger <ra...@dolphy.pangea.at> wrote:
> Wolfgang Fuschlberger <usenet-...@fuschlberger.net> wrote:
>> Ich würde sagen, allein schon durch die Komplexität des Setups können
>> sich bei einem reinen Squid weniger Fehler/potentielle Sicherheitslücken
>> einschleichen (wenn man nicht genau weiß, was man tut ;-) ).
>
> Derzeit scheinen offene Proxies das Lieblingsspielzeug von Spammern
> zu sein. Wie erklärst du das dann?

Hauptsächlich damit, dass der Squid nicht der einzige Proxy am Markt
ist. Der Großteil (ich habe was von 70-80% gelesen) der offenen Proxies
verwendet eine Windows-Software namens AnalogX, die per default völlig
offen ist (der Autor sieht das als Feature ("einfach zu installieren")
und weigert sich, das zu ändern).

hp

--
_ | Peter J. Holzer | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR | zu Fortran.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Alexander Bartolich in at.linux

Andreas Krennmair

unread,
Jun 26, 2003, 9:21:02 AM6/26/03
to
* Peter J. Holzer <hjp-u...@hjp.at> [at.linux]:

> ist. Der Großteil (ich habe was von 70-80% gelesen) der offenen Proxies
> verwendet eine Windows-Software namens AnalogX, die per default völlig
> offen ist (der Autor sieht das als Feature ("einfach zu installieren")
> und weigert sich, das zu ändern).

Lass mich raten, er ist noch dazu im Autorenteam des Hitchhiker's Guide?
Revolution!

scnr, ak [gestern zuviel H2G2 gesehen]
--
What makes you think I'm not just a chatbot?

Ralph Aichinger

unread,
Jun 26, 2003, 9:25:43 AM6/26/03
to
Peter J. Holzer <hjp-u...@hjp.at> wrote:
> Hauptsächlich damit, dass der Squid nicht der einzige Proxy am Markt
> ist. Der Großteil (ich habe was von 70-80% gelesen) der offenen Proxies
> verwendet eine Windows-Software namens AnalogX, die per default völlig
> offen ist (der Autor sieht das als Feature ("einfach zu installieren")
> und weigert sich, das zu ändern).

Ui, nett! Kriegt der einen Anteil von den Spammern?

/ralph

Bernd Petrovitsch

unread,
Jun 26, 2003, 9:41:04 AM6/26/03
to
On Thu, 26 Jun 2003 13:25:43 +0000, Ralph Aichinger wrote:
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> Hauptsächlich damit, dass der Squid nicht der einzige Proxy am Markt
>> ist. Der Großteil (ich habe was von 70-80% gelesen) der offenen Proxies
>> verwendet eine Windows-Software namens AnalogX, die per default völlig
>> offen ist (der Autor sieht das als Feature ("einfach zu installieren")
>> und weigert sich, das zu ändern).

Hmm, Teergrubing (in http-Servern) implementieren und einsetzen, um solche
Proxies zu bekämpfen?

> Ui, nett! Kriegt der einen Anteil von den Spammern?

Der kann gerne meine Anteil an Spammmail haben.

Bernd
--
Bernd Petrovitsch Email : be...@bofh.at

Alexander Bartolich

unread,
Jun 26, 2003, 11:11:08 AM6/26/03
to
Andreas Krennmair schrieb:
> [...] Revolution!

<d639ba3.03062...@posting.google.com>
<bdcbo0$ratbl$1...@ID-167057.news.dfncis.de>

de.c.o.u.p ist reif für eine feindliche Übernahme.

--
Google ist Gott. Opfere ihr deine Zeit und werde erleuchtet.

Peter J. Holzer

unread,
Jun 27, 2003, 6:52:14 AM6/27/03
to
On 2003-06-26 13:41, Bernd Petrovitsch <be...@bofh.at> wrote:
> On Thu, 26 Jun 2003 13:25:43 +0000, Ralph Aichinger wrote:
>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>> Hauptsächlich damit, dass der Squid nicht der einzige Proxy am Markt
>>> ist. Der Großteil (ich habe was von 70-80% gelesen) der offenen Proxies
>>> verwendet eine Windows-Software namens AnalogX, die per default völlig
>>> offen ist (der Autor sieht das als Feature ("einfach zu installieren")
>>> und weigert sich, das zu ändern).
>
> Hmm, Teergrubing (in http-Servern) implementieren und einsetzen, um solche
> Proxies zu bekämpfen?

Verstehe ich nicht. Wie soll das funktionieren?

Thomas Ogrisegg

unread,
Jun 27, 2003, 2:28:42 PM6/27/03
to
Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2003-06-26 13:41, Bernd Petrovitsch <be...@bofh.at> wrote:
>> Hmm, Teergrubing (in http-Servern) implementieren und einsetzen, um solche
>> Proxies zu bekämpfen?
> Verstehe ich nicht. Wie soll das funktionieren?

zB. Wenn ein derartiger Proxy bei Deinem HTTP-Server "anklopft"
einfach keine Rueckmeldung geben und auf ein Connection-Timeout
warten.

Stefan Heinecke

unread,
Jun 28, 2003, 11:13:50 AM6/28/03
to

Thomas Ogrisegg <tom-u...@rotfl.fnord.at> wrote:
> zB. Wenn ein derartiger Proxy bei Deinem HTTP-Server "anklopft"
> einfach keine Rueckmeldung geben und auf ein Connection-Timeout
> warten.

Oerks, dann lieber mit Mod-Rewrite was machen, und den User
drauf hinweisen - wird allerdings nicht viel bringen, im Undernet und
einigen anderen IRC Netzen funktioniert das.

Stefan
--
That woman speaks eight languages and can't say "no" in any of them.
-- Dorothy Parker

Peter J. Holzer

unread,
Jun 28, 2003, 1:01:49 PM6/28/03
to
On 2003-06-27 18:28, Thomas Ogrisegg <tom-u...@rotfl.fnord.at> wrote:
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> On 2003-06-26 13:41, Bernd Petrovitsch <be...@bofh.at> wrote:
[Proxy-Software, die per default offen ist]

>>> Hmm, Teergrubing (in http-Servern) implementieren und einsetzen, um solche
>>> Proxies zu bekämpfen?
>> Verstehe ich nicht. Wie soll das funktionieren?
>
> zB. Wenn ein derartiger Proxy bei Deinem HTTP-Server "anklopft"

Selbst wenn Du die Software zuverlässig erkennen kannst (was IMHO nicht
sicher ist), erkennst Du daraus nicht, wie sie konfiguriert ist. Wenn
also ein User sich die Mühe gemacht hat, das Handbuch zu lesen und das
Ding zuzumachen, dann wirst Du ihn genauso teergruben wie den DAU, der
gerade mal den "Finish"-Button im Installer zu treffen in der Lage war.

Bernd Petrovitsch

unread,
Jun 30, 2003, 6:39:39 AM6/30/03
to
On Sat, 28 Jun 2003 19:01:49 +0200, Peter J. Holzer wrote:
> On 2003-06-27 18:28, Thomas Ogrisegg <tom-u...@rotfl.fnord.at> wrote:
>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>> On 2003-06-26 13:41, Bernd Petrovitsch <be...@bofh.at> wrote:
> [Proxy-Software, die per default offen ist]
>>>> Hmm, Teergrubing (in http-Servern) implementieren und einsetzen, um solche
>>>> Proxies zu bekämpfen?
>>> Verstehe ich nicht. Wie soll das funktionieren?
>>
>> zB. Wenn ein derartiger Proxy bei Deinem HTTP-Server "anklopft"
>
> Selbst wenn Du die Software zuverlässig erkennen kannst (was IMHO nicht
> sicher ist), erkennst Du daraus nicht, wie sie konfiguriert ist. Wenn

Eben - deshalb würd ich es auch nicht machen.

> also ein User sich die Mühe gemacht hat, das Handbuch zu lesen und das
> Ding zuzumachen, dann wirst Du ihn genauso teergruben wie den DAU, der
> gerade mal den "Finish"-Button im Installer zu treffen in der Lage war.

Das muß man latürnich an der IP-Adresse erkennen - nicht am
Server-Software-Typ/Art/Name. Das ließe sich sogwar automatich testen, ob
auf er IP-Adresse 1.2.3.4 ein schlecht konfigurierter Proxy sitzt.

0 new messages