Ich habe bereits in diesem Beitrag für Debian Etch erklärt wie man einen Socks5 Proxy Server an den Start bringt.
Das HowTo ist inzwischen veraltet und Debian Lenny aktuell. Unter Debian Lenny geht man wie folgt vor:
apt-get install socks4-server
Danach muss das entsprechende Config File angepasst werden ( /etc/sockd.conf )
# Log Datei
logoutput: /var/log/sockd.log
# IP und Port auf dem der Server auf Verbindungen wartet
internal: 123.123.123.123 port = 8080
# IP Adresse über die Verbindungen der Clients abgeschickt werden
external: 123.123.123.123
# Es ist kein Username und Passwort nötig um sich am Server anzumelden => Die Authentifizierung
# erfolgt über die IP Adresse des Clients
method: username none #rfc931
# Die PAM Methode erfordert einen lokalen Benutzer mit Passwort der ebenso als Benutzer für
# den Socket Proxy gilt.
# method: pam
# Lokale Benutzer unter denen der Socket Proxy läuft
user.privileged: proxy
user.notprivileged: nobody
#user.libwrap: nobody
## Ab hier werden die Ausnahmen für die o.g. Rund-Um Sperre gebildet.
# Alle User aus der IP Range 123.123.0.0/24 dürfen über den Proxy Server Verbindungen zu
# allen Ports ( 1-65535 = Alle ) und allen IP ( 0.0.0.0/0 ) aufbauen.
client pass {
from: 123.123.0.0/24 port 1-65535 to: 0.0.0.0/0
}
# Alle Verbindungen werden abgewiesen ( Alles Abweisen was keine Ausnahme darstellt )
client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
# Alle User aus der IP Range 123.123.0.0/24 dürfen ebenso über den Proxy Server TCP und UDP
# Verbindungen zu sämtlichen Zielen aufbauen
pass {
from: 123.123.0.0/24 to: 0.0.0.0/0
protocol: tcp udp
}
# Default Block für Verbindungen ( Alles Abweisen was keine Ausnahme darstellt )
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
#log: unauthorized
}
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
#log: unauthorized
}Jetzt müssen noch zwei Dateien angelegt werden und der Owner wie im Config File gesetzt werden:
touch /var/log/sockd.log
touch /var/run/sockd.pid
chown nobody:nobody /var/log/sockd.log
chown nobody:nobody /var/run/sockd.pid
Danach ist der Proxy Server fertig und kann mit dem folgenden Befehl gestartet werden:
Wer dies automatisiert beim Systemstart machen möchte kann sich ein passendes init Script anlegen.
Running the paxtest program…
Linux Vanilla Kernel or Debian Kernel
Linux 2.6.32.25 #4 SMP Thu Nov 11 17:04:46 CET 2010 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux
Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Vulnerable
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (PIE) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 12 bits (guessed)
Shared library randomisation test : 10 bits (guessed)
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Vulnerable
Gentoo Hardened with Grsecurity v2 + PaX
Linux 2.6.32-hardened-r22 #1 SMP Fri Nov 12 11:43:28 CET 2010 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 17 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (PIE) : 23 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 15 bits (guessed)
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 23 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Vulnerable
Man stelle sich vor als root auf einem Linux Rechner unterwegs zu sein und folgendes zu erleben:
~/# rm -rf dateiname
rm: cannot unlink `dateiname': Operation not permitted
Bei root entfallen ja bekanntlich sämtliche andere Kriterien wie z.B.
- Ist man Besitzer der Datei?
- Sind Owner- oder Gruppenschreibrechte vorhanden?
Daher gibt es eigentlich nur zwei logische Erklärungen warum man die Datei nicht löschen kann. Entweder es stimmt gewaltig etwas nicht (z.B. Rechner gehackt rm Binary ausgetauscht) oder es wurde mittels Dateisystem Attributen für ext2, ext3 oder ext4 gearbeitet. Diese werden mittels ls nicht angezeigt.
Wenn man sich diese Attribute der o.g. Datei anzeigen lässt, ergibt sich folgendes Bild:
~/# lsattr dateiname
-u-ia--------- dateiname
Erst wenn man alle Attribute entfernt hat, kann man mit der Datei so arbeiten wie man möchte.
Das erledigt man wie folgt:
~/# chattr -i -a -u dateiname
.. und siehe da, der anschließende rm Befehl meldet sich erfolgreich.
Wie man genau mit chattr und lsattr arbeiten kann, ist unter folgendem Wiki Eintrag schön dargestellt und erklärt: http://wiki.ubuntuusers.de/chattr