Dark ITSec
Socks
Um es mit einem Satz zu sagen:
Socks ist die einfachste Implementierung einer Proxy-Firewall.
Der SOCKS-Proxy-Server dient als Bestandteil eines Firewall-Konzepts als Firewall-Proxy, indem die Zugriffe von Clients aus dem geschützten Netzwerkbereich nicht direkt ins Internet weitergeleitet werden. Derartige Anfragen der Clients sind dann nur über den SOCKS-Server möglich. Der SOCKS-Proxy speichert dabei keine www-Seiten in einem Cache. Vielmehr ist seine Aufgabe eine Authentifizierung und Authorisierung zwischen den Socks-Clients und dem Socks-Server zu realisieren.
Im Gegensatz zu anderen Proxy-Servern beschränkt sich die Funktionalität von SOCKS nicht nur im wesentlichen auf das Weiterleiten von Anfragen für die Protokolle http, https oder ftp, sondern bietet als Protokollstandard eine Schnittstelle für sehr viele Anwendungen. Dazu müssen diese Programme aber "socksifiziert" sein. Viele kommerzielle Programme wie beispielsweise der MSIE, Netscape sind von vorne herein für socks ausgelegt und bieten in den Einstellungen für den Internetzugang die Möglichkeit den SOCKS-Server als Proxy einzustellen. Standardmäßig wird hierfür der Port 1080 genutzt.
Prinzipiell ist SOCKS V4 nur für das Netzwerkprotokoll TCP und darauf basierende Anwendungen ausgelegt. Einige socksifizierte Clientanwendungen wie finger, telnet, ftp und whois sind als Paket zusammen mit socks downloadbar und müssen für die Zusammenarbeit mit socks statt der standardmmäßig installierten Clientsoftware installiert werden. Ebenso gibt es im Internet auch kostenlose Tools um z. B. Windowsprogramme zu socksifizieren. Mit SOCKS V5 von NEC sind aber auch UDP und ICMP-basierte Dienste wie archie, ping und traceroute zusammen mit socks einsetzbar. Die SOCKS V5-Implementation von NEC unterstützt auch SOCKS V4. Grundsätzlich ist dies aber nicht der Fall.
Die entsprechende Site von NEC mit einer für
den privaten und nicht-kommerziellen Gebrauch kostenlosen Version von SOCKS ist:
http://www.socks.nec.com
Ablauf in den Schichten
Wie ist die Struktur eines Netzwerkes
mit SOCKS-Server?
Es wird ein Unterschied zwischen Single-Homed und
Multiple- Homed Firewalls gemacht.
Single-Homed Firewalls sind Firewalls mit nur einem Netzwerkinterface.
Die ein- und ausgehenden Daten laufen alle über das gleiche Interface. Hierbei
ist es erforderlich einen sog. choke router zu verwenden, der alle Pakete (die
nicht von SOCKS stammen oder an SOCKS übermittelt werden) filtert.
Multiple-Homed Firewalls sind Firewalls mit zwei oder mehr
Netzwerkinterfaces. Ein Interface wird für eingehende und eins für abgehende
Pakete verwendet. So hat der SOCKSServer direkten Eingriff in die Pakete, da sie
nur über ihn laufen können.
Ein SOCKS-Client kommuniziert ausschließlich mit dem SOCKS-Server. Alle Pakete werden vom Client an den Server versendet. Der Server vermittelt die Pakete nur dann an deren Bestimmungsort weiter, bzw. an den nächsten Gateway, der wiederum die Pakete weiterschickt. In anderer Richtung prüft der SOCKS-Server, ob das ankommende Paket in sein lokales Netzwerk durchgelassen werden darf oder nicht. Im ersten Fall werden die Daten an den Client geleitet.
Konfiguration des SOCKS Proxy Servers
Zum Konfigurieren von SOCKS benötigt man zwei
verschiedene Konfigurationsdateien:
sockd.conf (Access-Datei) Die Access-Datei steuert den Zugriff und wird
auf dem Server abgelegt.
socks.conf (Routing-Datei) Die Routing-Datei leitet die Anforderungen zum
betreffenden Proxy-Server weiter und wird in den einzelnen Clients abgelegt. Bei
DOS- und Macintosh-Rechnern entfällt die Routing-Datei, da sie von den
Betriebssystemen separat verwaltet wird.
sockd.conf:
Diese Datei sollte mindestens zwei Zeilen enthalten.
Eine Erlaubnis-(permit) und eine Ablehnungs- (deny) Zeile.
Jede dieser Zeilen hat drei Einträge:
– Bezeichner (identifier, also permit o. deny)
– IP-Adresse (address)
– Adressenmodifizierer (modifier)
. In der Access-Datei können selbstverständlich mehrere permit- und deny-Zeilen
enthalten sein.
Identifier:
– entweder permit (für Erlaubnis) oder deny (für Ablehnung)
Address:
– IP-Adresse
Modifier:
– Subnetmask in üblicher 4-Byte-Notation. Zum Beispiel 255.255.255.0.
Beispiel 1
"permit 192.168.10.100
255.255.255.255“ bedeutet, dass der Zugriff ausschließlich für die
IP-Adresse 192.168.10.100 zulässig ist.
Beispiel 2
"permit 192.168.10.100 255.255.255.0“ erlaubt
den Zugriff für alle Rechner im 192.168.10.* IP-Netz. . Analog zu permit agiert
deny. Mit dem deny-Identifier macht man deutlich, dass die folgenden IP-Adressen
nicht zugelassen sind.
Beispiel 3
permit 192.168.10.100
255.255.255.255
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
Mit diesen Zeilen wird der Zugriff auf SOCKS allen Rechnern von
192.168.2.x und dem einzelnen Rechner 192.168.10.100 gestattet, allen übrigen
Rechnern ist ein Zugriff nicht möglich. . Zusätzlich zur IP- Autorisation kommt
bei SOCKS5 noch eine UserID/Paßwort-Prüfung hinzu.
socks.conf:
In dieser Datei wird festgelegt, wann der Client SOCKS
verwenden muss und wann nicht. Bei einer direkten Verbindung im lokalen Netzwerk
von Rechner_1 mit IPAdresse 192.168.10.100 zum Rechner_2 mit IP-Adresse
192.168.10.101 ist SOCKS z.B. nicht notwendig. SOCKS sollte jedoch für einen
Zugriff auf ein externes Netzwerk, z.B. das Internet eingesetzt werden.
In der Routing-Datei gibt es drei Einträge:
deny (Verbindung verweigern) Hiermit wird festgelegt, welche abgewiesen
werden sollen. Die Struktur (identifier address modifier) ist hierbei äquivalent
zur Access-Datei.
direct (direkte Verbindung ohne SOCKS) nennt die Adressen, die ohne SOCKS
erreicht werden sollen. Das sind alle Adressen, die keinen Proxy-Server
benötigen, wie zum Beispiel Adressen im lokalen Netzwerk.
sockd (Verbindung über SOCKS) teilt dem Client mit, in welchem Host der
SOCKS-Server Dämon läuft.
Beispiel für
socks.conf:
deny 192.168.10.100 255.255.255.255
direct 192.168.10.0 255.255.255.0
sockd 192.168.10.2 255.255.255.255
Der Client mit dieser Routing-Datei hat keinerlei Zugriff auf den Client
mit der IP 192.168.10.100.
Allerdings hat er direkten Zugriff auf alle Rechner im IP-Bereich von
192.168.10.x (192.168.10.100 ausgeschlossen).
Alle übrigen IP-Adressen werden über den SOCKS-Server angesprochen, welcher die
IP-Adresse 192.168.10.2 hat.e
Beispiel Anwendung
DANTE:
Bei der SuSE 7.2 Professional wird eine freie SOCKS
V4/V5 Implementierung unter der Bezeichnung dante mitgeliefert. Man kann sie per
YaST aus der Serie [sec] als [dante] für die Clientanteile und [dante-server]
für den socks-Server installieren. Es gibt auch noch das Paket [dante-devel] um
ggf. eigene Programme zu socksifiziern.
Bei SuSE ist der Standalone-Betrieb vorgesehen durch das Startscript /etc/init.d/sockd.
Dies lässt sich automatisch beim Hochfahren des Rechners erledigen, wenn man in
der /etc/rc.config die Variable START_SOCKD=yes setzt. Der eigentliche Server
wird nach /usr/sbin/sockd installiert. Mitgeliefert werden eine
Beispielkonfigurationsdatei für den Server /etc/sockd.conf und die Clients /etc/socks.conf,
welche noch für die eigenen Verhältnisse angepasst werden müssen.
Immerhin ist es mit folgenden minimalen Änderungen in der Konfigurationsdatei
möglich den Server ohne Fehlermeldungen zum Laufen zu bringen:
/etc/sockd.conf
...
# the server will log both via syslog, to stdout and to /var/log/lotsoflogs
#logoutput: syslog stdout /var/log/lotsoflogs
logoutput: stderr
# The server will bind to the address 10.1.1.1, port 1080 and will only
# accept connections going to that address.
#internal: 10.1.1.1 port = 1080
# Alternatively, the interface name can be used instead of the address.
#internal: eth0 port = 1080
internal: eth0 port = 1080
# all outgoing connections from the server will use the ipaddress
# 195.168.1.1
#external: 192.168.1.1
external: 192.168.99.1
# list over acceptable methods, order of preference.
# A method not set here will never be selected.
#
# If the method field is not set in a rule, the current global
# method is filled in for that rule.
#
#method: username none #rfc931
method: username none
# when running as usual, it will use the unprivileged userid of "sockd".
#user.notprivileged: sockd
user.notprivileged: nobody
# This is identical to above, but allows clients without a rfc931 (ident)
# too. In practise this means the socksserver will try to get a rfc931
# reply first (the above rule), if that fails, it tries this rule.
#client pass {
# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0
#}
client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}
# drop everyone else as soon as we can and log the connect, they are not
# on our net and have no business connecting to us. This is the default
# but if you give the rule yourself, you can specify details.
#client block {
# from: 0.0.0.0/0 to: 0.0.0.0/0
# log: connect error
#}
client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
# last line, block everyone else. This is the default but if you provide
# one yourself you can specify your own logging/actions
#block {
# from: 0.0.0.0/0 to: 0.0.0.0/0
# log: connect error
#}
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
In der FAQ des Hestellers auf der Seite
http://www.inet.no/dante/
Ein Script welches die gültige IP-Adresse des externen Devices durch die
dynamische des Providers nach erfolgtem Verbindungsaufbau in der Datei:
sockd.conf ersetzen soll und dann den Server mit aktualisierter
Konfigurationsdatei erneut startet:
/etc/socks.sh
#!/bin/bash
#
SOCKD_CONF="/etc/sockd.conf"
EXPIP=`ifconfig ippp0 | grep inet | cut -d : -f 2 | cut -d \ -f 1`
#/usr/bin/ex - +'1,\$s/^external:.*/external: '$EXPIP'/ | wq' $SOCKD_CONF
killall -HUP sockd
exit 0
oder:
Die neueren Versionen des Dante (zumindest ab 1.1.10-26 aufwärts) unterstützen
für die Angabe der nach aussen zeigenden IP-Adresse auch die Angabe des Devices
(also ppp0 bzw ippp0 bei Dyn.IP über den Provider).
# all outgoing connections from
the server will use the ipaddress
# 195.168.1.1
#external: 192.168.1.1
external: ippp0Damit hat sich dein weiter unten beschriebenes Problem mit
dynamischen IP-Adressen erledigt. Desweiteren unterstützt Dante auch die Angabe
von mehreren Devices, für die Angabe der internen Netze unter
# The server will bind to the address 10.1.1.1, port 1080 and will only
# accept connections going to that address.
#internal: 10.1.1.1 port = 1080
# Alternatively, the interface name can be used instead of the address.
#internal: eth0 port = 1080
internal: eth0 port = 1080Es kann also durchaus noch ein weiteres Device (neue
analoge Zeile) hinzugefügt werden. Allerdings sollte man dann die Subnetzmasken
in den Rules der sockd.conf dementsprechend anpassen. ich benutze die Netze
192.168.2.0 und 192.168.1.0 . Die Rules müssten weiter unten dann lauten (die 16
als Subnetzmaske, anstatt 24 bei Class-C netz)
# This is identical to above, but allows clients without a rfc931 (ident)
# too. In practise this means the socksserver will try to get a rfc931
# reply first (the above rule), if that fails, it tries this rule.
client pass {
from: 192.168.0.0/16 port 1-65535 to: 0.0.0.0/0
}