RootForum Community

Gude alle zusammen!

Bin der Meinung mein Server sei schon recht dicht. Hoffe ich zumindest. Gerade aus diesem Grund möchte ich gerne möglichst alle Ports dicht machen, die ich nicht wirklich brauche.

Daher hier mal ein NMAP in dem ich markiert habe, was benötigt wird. Allerdings sind noch Ports offen, von denen ich 0 Plan hab, was die machen.
Also, die 3 oberen müssten noch zu, Frage ist nur: wie?

Grüße!
Toby

Port 111 : Portmapper, dient zur Kommunikation von RPM-basierten Diesten wie NFS. Brauchst du mit Sicherheit nicht. Kurzzeitig kannst du das per /etc/init.d/portmap stop deaktivieren. Wenn du ein Debian-System dein Eigen nennst, deaktivierst du das ganze dauerhaft per update-rc.d -f portmap remove, oder noch besser : das Paket portmap komplett deinstallieren.

Port 515 : Printer. Da du wohl kaum über Internet drucken wirst : weg damit ! apt-get remove --purge lpr

Bezüglich Port 953 habe ich mal selbst Google für dich bemüht : http://www.redhat.com/mailing-lists/eni ... 36864.html
Hängt also mit deinem Nameserver zusammen.

Wenn du denkst, dass du nur dadurch "clean" bist, solltest du aber trotzdem noch mal tief in dich gehen ...

deinstalliere einfach die beiden Packete..

rndc ist der Remote-Controll von Bind..

also 515 (lpd) habe ich bei mir "zugemacht" indem ich den lpd deinstalliert habe ;)

Generell kannst Du Ports am effektivsten "zumachen" in dem Du iptables verwendest (Doku und mehr: http://www.netfilter.org).

Allerdings läufst Du dann Gefahr, dass dieser Thread wieder mir Missionierungsversuchen à la "Ein Paketfilter auf einer einzelnen Maschine macht keinen Sinn!" überschwemmt wird :(

Was 111 (sunrpc) betrifft (es handelt sich hierbei um RPC - Remote Procedure Calls) tappe ich selber noch ein wenig im dunkeln (brauch' ich das überhaupt?) und 953 ist bei mir persönlich nie "da" gewesen, habe also auch keine Ahnung, was man da deinstallieren muss/sollte ...

Erstmal danke für die Infos!

CaptainCrunch wrote:Wenn du denkst, dass du nur dadurch "clean" bist, solltest du aber trotzdem noch mal tief in dich gehen ...

Bestimmt nicht! ;)

Aber hab mir noch so einige andere Spielereien überlegt.... chroot für FTP zum Beispiel und kein SSH für root und einiges mehr...

Sonst noch gute Tipps zum sichern?

mmh.. schmeiss sunRPC runter.. Remote Procedure Call braucht man auf einen Server nicht!

Generell kannst Du Ports am effektivsten "zumachen" in dem Du iptables verwendest

Was könnte effektiver sein, als die Dienste erst gar nicht laufen zu lassen ? Mit den iptables machst du dir nur doppelte Arbeit, und u.U. mehr kaputt als "sicher" ...

dotxp wrote: Sonst noch gute Tipps zum sichern?

Versionskontrolle der Serverdienste..

Eventl. GR-Security

Absolut : GRsecurity, Mailinglisten lesen, auf dem laufenden bleiben ... am wichtigsten aber : ständige Kontrolle (am besten auch von "außenstehenden").

Also, erstmal danke der vielen Tipps!

Zum Thema "aktuelle Versionen":

apt-get macht nächtlich ein Update. Besonders angenhm, finde ich! ;) Bin mir bei Debian auch recht sicher, dass die Updates alle laufen, da ja keine Versionssprünge innerhalb eines stable-Zweigs gemacht werden.

Zum Thema "ports":

Habe jetzt alles zu gemacht, was ich nicht brauche.

Zum Thema "iptables":

Kenn ich mich mit aus. Macht bei mir zu Hause das Routing. Gibt allerdings echte Probleme, wenn man alles zu machen will, besonders wenn FTP offen sein soll. Von daher denke ich mir: Lieber die Dienste rausschmeissen, die ich nicht brauche.

Zum Thema "mailinglisten":

Lese ich schon mit. Keine Bange! Allerdings habe ich bei Debian die überaus positive Erfahrung gemacht immer die aktuellsten Security-Fixes direkt per "apt-get upgrade" zu kriegen.

Nochmal besten Dank!

Toby

dotxp wrote:Zum Thema "iptables":

Kenn ich mich mit aus. Macht bei mir zu Hause das Routing. Gibt allerdings echte Probleme, wenn man alles zu machen will, besonders wenn FTP offen sein soll. Von daher denke ich mir: Lieber die Dienste rausschmeissen, die ich nicht brauche.

Ist mit Sicherheit auch die beste Methode :) IPTables ist für das Sperren von Ports imho auch eher eine Maßnahme unter vielen und nicht das Nonplusultra.

dea wrote:[...] und 953 ist bei mir persönlich nie "da" gewesen, habe also auch keine Ahnung, was man da deinstallieren muss/sollte [...]

Der Unterschied liegt wahrscheinlich darin wie ihr NMAP verwendet... Durch Aufruf von nmap localhost ist 53 und 953 für den DNS offen, bei nmap 217.160.xxx.xxx ist der 953 (zumindest bei mir) nicht mehr offen, da dieser nur lokal irgendwie zur Administration des DNS-Servers benutzt werden kann.

Allerdings hab ich noch ne Frage zum Portmapper... bei mir ist dieser Port leider noch offen, da er von drac (pop-before-smtp) verwendet wird. Hat jemand Drac installiert und der Port ist trotzdem zu? Bzw. wie gross ist das Sicherheitsrisiko wirklich, wenn der Portmapper läuft?

so long
static

da muss ich jetzt mal einhaken. Bei mir ist auch Port 111 = sunrpc offen. Durch Deinstallation von portmap wird drac, qpopper, etc. mit deinstalliert. Somit geht Port 110 verloren. Weiss jemand ne Lösung?

Ne Lösung weiss ich momentan leider nicht auf die Schnelle, aber mich würde brennend interessieren, welche beschissene Distribution und welches beschissene Paketmanagement das ist?!

dodolin wrote: ..welche beschissene Distribution ...beschissene Paketmanagement ..!

Harte Worte .. Nun ja, vielleicht fällt jemand was ein

Harte Worte ..

Harte Worte vielleicht, nur stimmen sie absolut. Welche Distri diese Abhängigkeiten an den Portmapper bindet, hat auf keinen Fall richtig nachgedacht. Welche ist es denn eigentlich ?

Die Lösung ist mehr als einfach : lass den portmapper beim Systemstart einfach nicht mit hochfahren, entweder mit den Tools deiner Distri, löschen des Links, oder indem du ein exit 0 an den Anfang des zuständigen Initscripts schreibst ...

danke, hat geklappt. Jetzt ist noch Port 1024 = kdm offen. Wofür ist denn der ( das ) zuständig? UND 512 (filtered) = exec ??

Jetzt ist noch Port 1024 = kdm offen.

Auf einem Internetserver ??? Wo kommt denn da bitteschön da X-Windows-System her ?
Ganz einfache Lösung : ändere den Standardrunlevel deiner Distri (die du uns immer noch nicht genannt hast) auf den ohne X, dann startet der kdm auch nicht mit ...

:oops: Ist Debian Woody 3 Jetzt hab ich den Salat. Durch obige Aktion ( Entfernen von portmap - und dem anderen ) kann ich keine externen Mails mehr versenden! Die Komponenten drac, qpopper-drac und fam sind wieder drauf. ??

Das ist doch ganz klar - wenn er den Portmapper entfernt, kann DRAC nicht mehr sprechen, da der über RPC kommuniziert!!

Der qpopper wird entfernt, weil dieser zu DRAC gehört und gepatcht ist.

Das ist doch logisch und hat nichts mit beschissenem Paketmanegement zu tun.

Und Relay funktioniert halt jetzt nciht mehr, weil DRAC nicht mehr da ist.

Grüße,

flo.

und die Krönung. Weil das mit dem Relaying gar nicht mehr klappte ( in den Logs stand was von dracd.db Fehler ) , hab ich Postfix deinstalliert. Schwupps, Apache auch weg. Nach Neuinstallation von Postfix und Apache gehen keine Webs mehr ( ist mit Confixx 2.* ) und natürlich keine Emails mehr. :evil: Die "alte" httpd.conf ist noch da ( in etc/httpd ) , bloss Apache startet seine eigene ( in /etc/apache ) .

Naja, ich würde ja Debian Woody bzw. apt nicht wirklich als beschissen bezeichnen 8) Dann schon eher DRAC, weil das den Portmapper benötigt... da ich bislang keine Lösung gefunden habe und ich diesen Port schon gerne zu hätte, steige ich jetzt von pop-before-smtp auf smtp-auth um, damit sollte die Sache dann gegessen sein :roll:

so long
static

static, ich habe bei mir den betreffenden Port (111?) mit iptables für alle anderen Rechner gesperrt, das sollte im Normalfall ausreichen ...

Bei mir sind zwei Rechner beteiligt, da ich dem Sendmail pertout nicht beibringen konnte, das Format der Berkely-DB zu lesen, das DRAC schreibt.

@adjustman - hätte es nicht gereicht, wenn Du Postfix gesagt hättest, daß DRAC nicht mehr da ist?

Grüße,

flo.

Zu spät! Jetzt steht die Frage - wie bring ich das System wieder zum Laufen?

schmeiß doch mal exim drauf und dann wieder Postfix oder bleib bei Exim, wenn Du möchtest, in jedem Fall sollte dabei die saubere Installation eines dieser Mailer rauskommen, und dann bringst Du dem betreffenden SMTP-AUTH oder was auch immer Du brauchst, bei ...

Den Apachen würde ich mir vorher wieder holen.

Grüße,

flo.