[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[long] Re: Dienste "beschraenken"



Hallo Christian,

At 01.02.2002, Christian Schmidt wrote:
[...]
> server:~# netstat -ln
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address
> tcp        0      0 192.168.2.1:21          0.0.0.0:* CLOSE
> tcp        0      0 192.168.2.1:21          0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:53          0.0.0.0:* LISTEN
> tcp        0      0 127.0.0.1:53            0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:80          0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:110         0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:548         0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:5865        0.0.0.0:* LISTEN
> tcp        0      0 192.168.2.1:22          0.0.0.0:* LISTEN

Das ist alles auf deine interne IP (dummerweise nicht wie ich bisher
schrieb - Interface) gebunden. Also schon mal sehr gut.

> tcp        0      0 0.0.0.0:515             0.0.0.0:* LISTEN

lpd

> tcp        0      0 0.0.0.0:3306            0.0.0.0:* LISTEN

mysql?

Dazu schrieb bereits jemand was.

> Tja, da habe ich noch ein wenig Lektüre vor mir. ;-)

Wieso? Sieht doch schon gut aus.

> ...bevor ich mich dann mal etwas eingehender mit dem Thema Paketfilter
> beschäftige...;-)

Ich wuerde sagen, mit so einer Konfiguration kann man sich schon
Gedanken ueber _sinnvole_ Paketfilterregeln machen.

> tcp        0      0 192.168.2.1:25          0.0.0.0:* LISTEN
> tcp        0      0 127.0.0.1:25            0.0.0.0:* LISTEN

Intern.

> und exim.
> Der xinetd gefällt mir ganz gut.

Ja, ist ganz nett.

> btw: netstat -ln listet noch eine ganz Reihe an offenen, nicht an eine
> bestimmte IP-Adresse gebundene UDP-Ports auf, z.B.:
> udp        0      0 0.0.0.0:1138            0.0.0.0:*                           
> udp        0      0 0.0.0.0:323             0.0.0.0:*                           
> Diese beiden kann ich nicht zuordnen.

Und was sagt lsof dazu?

> udp        0      0 0.0.0.0:123             0.0.0.0:*                           
> Das ist ntp (in meinem Fall chrony).
> udp        0      0 0.0.0.0:67              0.0.0.0:*                           
> Und das ist der bootp-Port, über den hier DHCP läuft.

Kann man den nicht weiter konfigurieren?

> raw        0      0 0.0.0.0:1               0.0.0.0:*               7           
> raw        0      0 0.0.0.0:6               0.0.0.0:* 
> Hmm... Da kann ich nun nichts mit anfangen.

Macht nichts, daran kannst Du auch nichts aendern ;-)

> Noch einmal ein Dankeschön für die Hinweise!!

Ich sprach es oben schon an. Bei Linux (und einigen anderen
Betriebssystemen) gibt es eine Besonderheit. Du hast jetzt fast alle
Dienste auf eine interne IP Adresse gebunden, die Dienste sind aber auf
jedem Interface erreichbar. Das Problem ist nur das Routing dort hin.
Fuer einen Angreifer im selben Netz ist das kein Problem.

Also musst Du mit einem Paketfilter dafuer sorgen, dass Pakete mit einer
Zieladresse deines internen Netzes, die ueber das externe Interface
reinkommen, nicht ihr Ziel finden. Hier ein Beispiel:

ipchains -A input -i ppp0 -d 192.168.0.0/16 -j DENY

Da solche Pakete entweder von fehlkonfigurierten Rechnern oder einem
Angreifer stammen und auf keinen Fall regulaeren Traffic darstellen,
waehle ich hier DENY und nicht REJECT.

Willst Du keine TCP Dienste im Internet anbieten und auch vorsorgen,
dass nichts passiert, wenn Du mal etwas falsch machst und ein Dienst auf
allen Interfaces horcht (nur tcp), dann reicht:

ipchains -A input -i ppp0 -p tcp -y -j REJECT

(Die Manpage zu ipchains sollte sich aber jeder genau ansehen und nicht
einfach irgendwas uebernehmen!)

Somit ist es nicht mehr moeglich, dass von aussen ein TCP Dienst auf
einem Rechner hinter diesem Paketfilter genutzt wird.

Ich waehle hier REJECT, da TCP Pakete mit gesetztem Syn Bit (und ohne
ACK oder FIN Bit) durchaus regulaerer Traffic sind, auch wenn wir da
nichts anbieten wollen. Also beantworte ich das freundlich mit einem
ICMP Port unreachable.

Ausserdem erspart man sich Aerger bei SMTP und IRC, da diese Server
nicht selten eine TCP Ident Anfrage an den Client schicken. Hast Du hier
ein DENY statt einem REJECT, wartet der SMTP oder IRC Server auf ein
Timeout.

Mit UDP geht das nicht so einfach. Kannst Du auf deiner Installation zu
Hause nicht auf einen solchen Dienst verzichten, oder eine Software
waehlen, die es moeglich macht, auf eine interne IP Adresse zu binden,
kannst Du schonmal folgende Regel als Vorlage verwenden:

ipchains -A input -i ppp0 -p udp -d 0/0 :1024 -j REJECT

Damit sind alle UDP Dienste, die sich auf einen privileged Port binden
schonmal erschlagen.

UPD Pakete oeberhalb 1024 zu verbieten ist prinzipiell keine gute Idee,
weil es sich hierbei auch _Antworten_ auf _deine_ Anfragen
(beispielsweise bei einem Nameserver) handeln kann.

Eine Notloesung waere, genau die UDP Ports zu filtern, auf denen bei dir
vorerst leider noch ein Dienst horcht (aber das kann nur eine temporaere
Notloesung sein!):

ipchains -A input -i ppp0 -p udp -d 0/0 <port> -j REJECT

(Nochmals die Bitte, nicht einfach unverstanden irgendwas abzutippen,
sondern die ManPage zu lesen und ggf. einfach nachzufragen, wenn etwas
unklar ist!).

Hast Du das alles gemacht, kann man meiner Meinung davon reden, ein
recht solides System mit einer recht soliden Konfiguration zu haben (was
direkte Netzerkzugriffe von aussen angeht!).

Ueberlegt euch _sehr_ gut, _wenn_ ihr etwas mitloggen wollt (-l), warum
ihr dass denn ueberhaupt mitloggen wollt. Logging kann auch sehr schnell
dazu fuehren, eine Angriffsflaeche fuer DoS Angriffe selbst zu erstellen
(ueberlaufende Platten (/var/log/ _immer_ auf eine eigene Partition!),
ueberlastete Rechner.

Und filtert nicht blind jedes Paket einzeln. Keep it simple stupid!
Sicherheit erreicht man nicht durch Komplexitaet sondern durch
Einfachheit!

Also genau ueberlegen, warum will man was filtern, wie filtert man das.
Welches Konzept hat man sich ueberlegt? Welche benutzerdefinierten
Chains richtet man sich ein?

Ich habe mal einen recht komplexen Paketfilter fuer ein sehr schlecht
konfiguriertes Netz aufsetzen muessen. Die erste Version war schlecht
durchdacht und hatte weit ueber 2000 Regeln (allerdings groesstenteils
durch ein Script erstellt, welches ich mir als Hilfe geschrieben habe).

Das konnte einfach nicht sinnvoll sein. Durch das sinnvolle nutzen von
benutzerdefinierten Chains und erneute Ueberlegung, wie man was filtern,
bin ich dann auf knapp ueber 100 Regeln gekommen (ja, 100 nicht 1000).

Und das ist noch zuviel und war nur deshalb notwendig, weil das Netz in
einem desolaten Zustand war und ich keinen Einfluss darauf hatte, das zu
aendern.

Fuer einen Paketfilter fuer zu Hause reichen meist eine Hand voll Regeln
aus, wenn das System auch ordentlich konfiguriert wurde.

Viel Spass beim Hacken wuenscht, Guido

Attachment: pgp7CgHFaTmVC.pgp
Description: PGP signature


Reply to: