# [Debian] Ports schließen



## KD3 (5. Juli 2007)

Hallo gemeinde 

Ich wollte euch fragen wie ich jetzt z.B einen Port sperren könnte, z.B den Port 8324. Kann ich über Apache das deaktivieren oder muss ich das anders machen? Würde mich sehr um hilfe freuen 

MfG
KD3


----------



## Sinac (6. Juli 2007)

Über Apache Ein Port hat nicht das Geringste mit Apache zu tun. Ports auf denen kein Dienst läuft brauchst du auch nicht sperren da ja nichts dahinter vorhanden ist. Generell macht sowas alles eine Firewall, dieser kannst du auch sagen die soll sämtliche Anfragen verwerfen, also die Ports blocken. Vielleicht erklärst du mal ein wenig genauer was du vor hast...

Greetz...
Sinac


----------



## KD3 (8. Juli 2007)

Ich hab die Ports von meinen Server gescannt und es wurde angezeigt das TCP und UDP Ports offen sind obwohl diese lieber geschlossen sein sollten deswegen


----------



## Matthias Reitinger (8. Juli 2007)

Dann solltest du die jeweiligen Dienste deaktivieren, die hinter diesen Ports laufen.


----------



## KD3 (8. Juli 2007)

Ich hab es geschafft, die UDP Ports zu schließen, war nicht so schwer, man musste sich nur ein bisschen mehr reinhängen 

Nur noch paar fragen 

TCP: 

Port 21 (FTP ist ja klar  werde ich sowieso deaktivieren  )
Port 22 (SSH werde den Port umleiten, aber bis jetzt ging es nicht obwohl ich sicher bin das ich alles umgestellt hatte, werde aber natürlich weiter probieren)
Port 25 (SMTP werde ich auch deaktivieren, ist kein problem)
Port 80 ( HTTP, wäre es besser wenn ich diesen Port auch umstelle? )
Port 110 ( POP3, wäre dieser Port riskant oder so? )

Danke im voraus

MfG
KD3


----------



## Sinac (9. Juli 2007)

Warum willst du die Ports denn umleiten? Macht im Prinzip keinen Sinn sowas. Entweder du brauchst den Dienst, dann lass ihn wie er ist oder schließe den Port. Ob du einen POP3 und einen HTTP Server brauchst weiß außer dir selber wohl niemand


----------



## Dennis Wronka (9. Juli 2007)

Also: Gezieltes Schliessen von Ports ist in der Regel die suboptimale Variante.
Warum? Weil man nur allzu gern auch mal einen Port vergisst und sich somit eventuell unnoetigen Gefahren aussetzen kann.
Ausserdem ist es meist einfacher einfach alles dicht zu machen und nur zu oeffnen was erwuenscht ist.
Dadurch werden dann sogar Ports gesperrt die nicht belegt sind, auch wenn es im Grunde ueberfluessig ist. Dennoch bietet es den Vorteil dass ein Dienst der eventuell irgendwann mal auf einem dieser Ports laeuft gleich geschuetzt ist. Und wenn von aussen darauf zugegriffen werden muss reicht eine weitere Regel dafuer aus.

Mal ein kleines Beispiel wie nur SSH, HTTP, SMTP und POP3 fuer die Aussenwelt erreichbar sind, alles andere wird vom Paketfilter (zumindest einigermassen) RFC-gerecht abgewiesen.

```
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport smtp -j ACCEPT
iptables -A INPUT -p tcp --dport pop3 -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable
```
Was diesen Regeln natuerlich noch fehlt ist die Bindung an ein Interface, wie z.B. eth0 oder ppp0, denn ueber lo, das Loopback-Interface, sollte in der Regel alles erreichbar bleiben, was z.B. bei der Kommunikation PHP<->MySQL ganz sinnvoll sein kann und auch in anderen Faellen genutzt wird. Mein Linux-Server hier im Buero hat innerhalb der letzten 72 Tage schlappe 3GB ueber dieses Interface gejagt.


----------



## KD3 (9. Juli 2007)

Wenn ich jetzt z.B in den Iptables den port für 21 blocke, ist ja trotzdem noch der dienst aktiv, aber ich weiß nicht welche software drauf is, glftpd, vsftpd, ....... wie kann ich das denn herausfinden? 

MfG
KD3


----------



## Flex (9. Juli 2007)

Schau dir mal den Befehl "grep" an.


----------



## Dennis Wronka (10. Juli 2007)

Wenn Du Traffic ueber das Loopback-Device nicht blockst, was ich ja oben empfohlen habe, kannst Du auf der Maschine selbst per nMap einen Portscan durchfuehren und damit herausfinden was auf welchem Port laeuft. Dies kannst Du mit dem Versionsscan machen, Option -sV.
Das darfst Du aber nur noch so lange bis das neue Hacker-Gesetz in Kraft tritt, danach ist nMap ist Deutschland illegal und der Besitz wird mit Penisamputation bestraft.


----------



## zeroize (18. Juli 2007)

Ansonsten habe ich gerade einen interessanten Artikel über Port-Knocking gelesen. Ein verfahren bei dem du alle Ports schließen kannst und auf einer bestimmten Reihenfolge von Portanfragen auf unterschiedlichen Ports öffnet sich dann beispielsweise der SSH-Port.
Bei Interesse kann ich den Artikel man online stellen.


----------



## Dennis Wronka (18. Juli 2007)

Port-Knocking mag eine schoene Idee sein, hab da vor einer ganzen Weile auch mal ein paar Artikel zu gelesen, fuer den normalen User aber meiner Meinung nach nicht zumutbar.
Fuer einen Admin aber koennte dies nicht uninteressant sein um eine eigentlich verschlossene Tuer zu oeffnen.
Ich sehe dabei aber folgende Probleme:

Implementation der Knock-Sequenz.
Es muss eine Moeglichkeit geben, moeglichst einfach natuerlich, an den richtigen Ports anzuklopfen. Praktisch waere hier wohl ein GUI in dem man einfach eine beliebig lange Liste an abzuklappernden Ports anlegen kann. Ob es sowas schon gibt weiss ich nicht, wage es aber zu bezweifeln.
Implementation eines Listeners
Es ist nicht damit getan dass Netfilter die Knocks loggt, die Logs muessen auch staendig ausgewertet werden sodass die Knock-Sequenz auch erkannt wird. Auch wenn zwischendurch andere Zugriffe von anderen Usern geloggt werden.
Das heisst zum einen dass ein Daemon laufen muss, dieser muss zum anderen auch noch relativ komplex sein. Dies koennte sich eventuell nachteilig auf die Performance des Servers auswirken.
Mit Netfilter-Bordmitteln ist dies bislang leider nicht zu machen.
Zum Daemon der die Logfiles ueberwacht werde ich wohl spaeter oder die Tage auch in meinem Blog was schreiben da ich sowas zur Zeit auch auf der Arbeit gebrauchen koennte, aber eben nicht wirklich sicher bin ob sich der Nutzen mit den Kosten deckt.


----------

