(Diskussion ''eines moeglichen'' Loesungsansatzes)
In meinem kleinen Home-Office gibt es neben der DSL-Anbindung (1024kbit
down / 128 kbit up) lediglich zwei Workstation.
Geplante Vernetzung:
Internet <----> DSL-Modem <---- Kabel ---->
|
[1.WS: Firewall .. OpenBSD 3.5]
|
((( W L A N )))
|
[2.WS: Client ....... SuSE 9.1]
Um in dieser Umgebung ein sicheres Arbeiten (Surfen & Mailen) zu
ermoeglichen habe ich zunaechst auf PF mit 'authpf' (siehe UNIXscout
authpf-Howto) gesetzt - damit ist zumindest die Firewall abgesichert und
es koennen nur authorisierte User ueber die Firewall im Internet
arbeiten, welche sich ueber das sichere Protokoll SSH bei mir (1.WS)
authentifiziert haben.
Nachteil dieser Konfiguration ist, dass der eigentliche Traffic hiernach
nicht verschluesselt ist und letztlich alles zwischen 1. und 2.
Workstation mitgeschnitten werden kann.
WEP als Verschluesselungstechnik bei WLAN-Verbindungen ist zwar zunaechst
einmal moeglich, aber aufgrund von Desing-Fehlern nicht wirklich sicher.
Dh., ein mehr oder minder neugieriger Nachbar wird vielleicht den
Aufwand nicht scheuen den Traffic zu analysieren um hiernach die Mails
oder whatever zu lesen. *g0t 0wn3d*
Als moegliche Loesungsansaetze kommen also nur:
* IPsec, oder ein
* Proxy-Server auf der Firewll (welcher intern die Verbindungen
verschluesselt [zB.: mittels 'stunnel'], oder nur die
* Verwendung von geschuetzten Protokollen/Applikationen (zB.:
SILC anstelles von IRC) oooooder ein
* SSH-Tunnel in Frage.
Der letztgenannten Loesungsansatz ist fuer MEINE Anforderungen optimal,
da die 2.WS lediglich Surfen und Web-Mailen soll - und SSH kam auch bei
authpf schon zum Einsatz!!!
Umsetzung:
Auf der 1.Workstation (der Firewall) wird ein einfacher/kleiner
Proxyserver (zB.: tinyproxy) installiert und so konfiguriert, dass er auf
Port 8000 die Anfragen der Clients entgegen nimmt.
Im Vergleich zu authpf muss am Regelwerk der PF-Firewall _nichts_
geaendert werden - es werden lediglich Anfragen auf tcp-Port 22 und
udp-Port 53 erlaubt.
Auf der 1.WS wird ein User-Account angelegt und dieses mal nicht als
Shell '/usr/sbin/authpf' eingetragen, sondern die Default-Shell
'/bin/sh' belassen.
Zusaetzlich, da es leider noch keine chroot()-Funktionalitaet im SSH
gibt, werden dann noch die User-Prozesse so limitiert, dass ein
eingeloggter User nichts weiter anstellen kann:
# echo "ulimit -p 2" >> /home/username/.profile
Hint: Evtl. kann hier auch die Systrace-Shell 'stsh' helfen ...
Auf der 2.WS, die ueber die 1.WS im Internet arbeiten soll, wird der
Punkt 'Manuelle Proxy Konfiguration' des Browsers so bearbeitet, dass
er auf 'localhost' Port '9000' connected.
So, und dann muss nur noch der SSH-Tunnel eingerichtet werden und damit
der locale Port 9000 (2.WS) auf den Serverport 8000 - also tinyproxy -
(1.WS) umgeleitet werden.
Folgender Befehl wird an der Console der 2.WS ausgefuehrt:
# ssh -l username server -C -L 9000:server:8000
Und schon kann man via SSH-Tunnel im internen Netz verschluesselt!
*sigh* surfen, webmailen u.s.w.
---*---*---
Gleiches geht z.B. auch fuer IRC-Chat:
# ssh -l account IP -C -L 6666:IP_vom_IRC-Server:6667
Und nun lass ich 'irssi' auf mich selbst connecten:
# /server 127.0.0.1 6666
---*---*---
Natuerlich sind dem Ganzen irgendwann Grenzen gesetzt und es kommt der
Tag an dem man ueber VPN nachdenken sollte. Am Beispiel von OpenVPN
werde ich an dieser Stelle demnaechst gesondert berichten.
--
IS
|