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...
[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"?
> 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
> 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.
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
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 ... .. --. -. .- - ..- .-. .
>> 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
> 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.
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.
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 ?
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*]
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
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
> 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
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
> 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
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 :-)
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
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
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?
Ui, nett! Kriegt der einen Anteil von den Spammern?
/ralph
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
<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.
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.
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
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.
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.