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:
pgpwqB1k1UMrD.pgp
Description: PGP signature