Re: Sicherheitskonzept eines neuen Servers
Hallo Christian, * Christian Schmidt [EMAIL PROTECTED] [20051127 18:41]: btw: Kennst Du eine gute Einfuehrung in das Thema LDAP? Am besten etwas fuer Leute, die wenig mehr wissen als was LDAP heisst... ;-) Ich habe soeben die Accounts in meinem privaten LAN in LDAP migriert. Da ich mir inzwischen doch ne ganze Menge Dienste bereitstelle und dafür bisher Scripts hatte, die Accounts aus /etc/(passwd|shadow) in entsprechende Dateien für die einzelnen Dienste (Webserver, Mailserver, ...) kopierten muss ich sagen, das hat sich rentiert. Wenn deine Acoounts auch über einen Samba-PDC zur Verfügung stehen sollen ist das hier wirklich empfehlenswert: http://samba.idealx.org/smbldap-howto.en.html Übrigens, was Mail angeht kann man sich da auch ganz toll in den Fuß schießen: Angenommen du willst (was in der Praxis sicher sinnvoll ist) sämtlichen LDAP-Verkehr verschlüsseln. Dann stellst du unter anderem auch in der Konfigurationsdatei für libnss-ldap ssl = start_tls ein. Nun wird überall empfohlen, den LDAP-Host als IP-Adresse anzugeben, damit er im Zweifel auch ohne DNS noch tut. Dumm nur, dass dann die Verifikation des Server-Zertifikats schiefgeht und dein libnss-ldap einfach nicht mehr funktioniert. Resultat: Exim lehnt Mails ab (User unknown) da check_local_user den User nicht mehr findet. ARGHHH. Also, wer SSL/TLS verwenden will und nicht auf die Verifikation des Server-Zertifikats verzichten will: Server als Hostnamen angeben, nicht als IP-Adresse. Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Hi! On Sun, 27 Nov 2005 12:11:38 +0100 Matthias Haegele [EMAIL PROTECTED] wrote: Für Leute die aber *genug RAM* (512/1024) (was bei heutigen [...] Bei einem Mailgrössenlimit von 10MB (Postfix-Standard) wird hierfür 131,25 MB benötigt. Von den 768 MB kann ich locker 256 MB opfern; ich werde das mit dem tmpfs ggf. austesten und berichten. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! On Sun, 27 Nov 2005 10:29:43 +0100 Marc Haber [EMAIL PROTECTED] wrote: Inwieweit ist ein von postfix aufgerufener spamassassin schneller als einer, der von exim aufgerufen wurde? Das ist wohl wahr; ich kann aber bisher auch nicht mit Postfix vergleichen, man munkelte nur irgendwo mal, dass er flotter sei und weniger Speicher frisst. Und da bei meinem letzten Server immer mehrere bis einige Exim-Forks offen waren, kann das dann doch zumindest zur Gesamtleistung beitragen, wenn er wegen der Speicherlast später anfängt zu swappen. Aber bei dem neuen Server ist RAM ja wie gesagt eh kein großes Problem. Ich denke, ich werde letztlich entweder spontan entscheiden oder je nachdem, was eine HowTo, die ich finde und als Wegweiser nehme, beschreiben wird. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
On Sun, 27 Nov 2005 18:41:28 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: btw: Kennst Du eine gute Einfuehrung in das Thema LDAP? Am besten etwas fuer Leute, die wenig mehr wissen als was LDAP heisst... ;-) Da muss ich leider passen. Noch nie mit gearbeitet. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
On Tue, 22 Nov 2005 12:03:20 +0100, Ace Dahlmann [EMAIL PROTECTED] wrote: On Tue, 22 Nov 2005 11:47:47 +0100 Marc Haber [EMAIL PROTECTED] wrote: Nicht wirklich. Ich habe noch nie einen exim merkbar CPU-Last erzeugen sehen, die Systeme sind üblicherweise viel schneller mit der Platte am Ende. Ich schon: Mein alter Server, auf dem ein Exim mit Procmail, SpamAssassin und Antivir lief, hat, wenn er - seiner Zeit noch zu ISDN-Zeiten - sich eingewählt und Mails abgeholt hat und dann angefangen hat, zu scannen und zu spoolen, das System komplett ausgelastet. Inwieweit ist ein von postfix aufgerufener spamassassin schneller als einer, der von exim aufgerufen wurde? Im Gegenteil wird ein Schuh daraus, dass die Geschwindigkeit des MTA immer irrelevanter wird, je mehr Zeit mit aufwendigen externen Contentfiltern drauf geht. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
On Tue, 22 Nov 2005 13:16:18 +0100, Matthias Haegele [EMAIL PROTECTED] wrote: Uwe Laverenz schrieb: Stimmt, mit dem MTA hat das nichts zu tun, aber auch nicht unbedingt mit dem verwendeten Prozessor. Der Flaschenhals ist hier eher der hohe RAM-Bedarf (256MB sind Minimum, IMHO). Im Postfixbuch wurde ein tempfs im RAM für solche Zwecke eingerichtet, was natürlich wiederum genug RAM Inwieweit hilft die Einrichtung eines tempfs für Applikationen, die viel Arbeitsspeicher benötigen? Steht nicht vielmehr nach Einrichtung des tempfs _weniger_ Arbeitsspeicher für Applikationen zur Verfügung. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
On Tue, 22 Nov 2005 13:26:16 +0100, Felix M. Palmen [EMAIL PROTECTED] wrote: In der zweiten ACL können dann Virenscanner und Spamscanner (z.B. Spamassassin über sa-exim) zum Zug kommen, die Mail kann immer noch abgelehnt werden. Ernsthafte Frage: Was kann sa-exim mehr als exims eingebauter Content-Filter, ex exiscan? Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
On Sat, 26 Nov 2005 14:51:31 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: OK, bei der sender verification kann man damit leicht auf die Nase fallen, aber fuer Szenarien mit einem Frontend-Mailserver und mehreren dezentralen Backend-Maschinen ist die recipient verification via SMTP-Callout eine super Sache. Beim Frontend-Backend-Szenario würde ich recipient callout verification aber auch nur im Notfall einsetzen und das Frontend grundsätzlich gegen eine Userdatenbank (z.B. LDAP) verifizieren lassen. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
Marc Haber schrieb: On Tue, 22 Nov 2005 13:16:18 +0100, Matthias Haegele [EMAIL PROTECTED] wrote: Uwe Laverenz schrieb: Stimmt, mit dem MTA hat das nichts zu tun, aber auch nicht unbedingt mit dem verwendeten Prozessor. Der Flaschenhals ist hier eher der hohe RAM-Bedarf (256MB sind Minimum, IMHO). Im Postfixbuch wurde ein tempfs im RAM für solche Zwecke eingerichtet, was natürlich wiederum genug RAM Inwieweit hilft die Einrichtung eines tempfs für Applikationen, die viel Arbeitsspeicher benötigen? Steht nicht vielmehr nach Einrichtung des tempfs _weniger_ Arbeitsspeicher für Applikationen zur Verfügung. Natürlich wird das niemandem was bringen der 256MB und weniger zur Verfügung hat. Für Leute die aber *genug RAM* (512/1024) (was bei heutigen Rootservern Standard ist) haben gibt es die Möglichkeit den evtl. Flaschenhals: Festplattenzugriffe anzugehen. Zitat Amavisd-new makes have use of the filesystem. Erst bei einem höheren Load wird sich das wirklich lohnen, wenn ich nur ein paar hundert Mails am Tag habe (vorausgesetzt nicht alle zur selben Zeit :-) ) ist das wohl eher irrelevant. Bei einem Mailgrössenlimit von 10MB (Postfix-Standard) wird hierfür 131,25 MB benötigt. Dachte das wäre vielleicht für die stummen Mitleser interessant ... Muss ja jeder selber wissen welche Dienste er sonst noch so am laufen hat und ob man das Ram abzweigen kann. Grüße Marc Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo Marc! Marc Haber schrieb am Sonntag, den 27. November 2005: On Tue, 22 Nov 2005 13:16:18 +0100, Matthias Haegele [EMAIL PROTECTED] wrote: Uwe Laverenz schrieb: Inwieweit hilft die Einrichtung eines tempfs für Applikationen, die viel Arbeitsspeicher benötigen? Steht nicht vielmehr nach Einrichtung des tempfs _weniger_ Arbeitsspeicher für Applikationen zur Verfügung. Ich mag mich irren, aber soweit ich weiß, können auch Dateien, die in einem tmpfs liegen bei Bedarf in den swap-Bereich ausgelagert werden. Somit sollte nicht weniger Arbeitsspeicher für andere Anwendungen zur Verfügung stehen. Man gewinnt halt im Idealfall schnellere Zugriffszeiten auf Dateien, auf die häufiger zugegriffen werden muß. Mit freundlichen Grüßen Christian -- Wir leben in einem Lande, in dem einer zum Verbrecher wird, wenn er JENEN lästert, den niemand kennt. -- Hans Henny Jahnn -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Christian Brabandt schrieb: Hallo Marc! Marc Haber schrieb am Sonntag, den 27. November 2005: On Tue, 22 Nov 2005 13:16:18 +0100, Matthias Haegele [EMAIL PROTECTED] wrote: Uwe Laverenz schrieb: Inwieweit hilft die Einrichtung eines tempfs für Applikationen, die viel Arbeitsspeicher benötigen? Steht nicht vielmehr nach Einrichtung des tempfs _weniger_ Arbeitsspeicher für Applikationen zur Verfügung. Ich mag mich irren, aber soweit ich weiß, können auch Dateien, die in einem tmpfs liegen bei Bedarf in den swap-Bereich ausgelagert werden. Was die ganze Situation dann noch schlimmer machen würde falls das System anfinge (wenn der physische Speicher ausgeht), das eigentlich zur Entlastung des Plattenzugriffes eingerichtete tempfs wiederum auf die Platte zu swappen. Somit sollte nicht weniger Arbeitsspeicher für andere Anwendungen zur Verfügung stehen. Man gewinnt halt im Idealfall schnellere Zugriffszeiten auf Dateien, auf die häufiger zugegriffen werden muß. Ack. Mit freundlichen Grüßen Christian Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo Marc, Marc Haber, 27.11.2005 (d.m.y): On Sat, 26 Nov 2005 14:51:31 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: OK, bei der sender verification kann man damit leicht auf die Nase fallen, aber fuer Szenarien mit einem Frontend-Mailserver und mehreren dezentralen Backend-Maschinen ist die recipient verification via SMTP-Callout eine super Sache. Beim Frontend-Backend-Szenario würde ich recipient callout verification aber auch nur im Notfall einsetzen Wieso? und das Frontend grundsätzlich gegen eine Userdatenbank (z.B. LDAP) verifizieren lassen. In der konkreten Situation war es aber leider so, dass keine gemeinsame Benutzerverwaltung existierte, weil die Backend-Maschinen u.a. von verschiedenen Leuten administriert wurden. Und da stellte die recipient callout verification die einfachste Methode dar, der zentralen Maschine Kenntnis von den auf den dezentralen Servern eingerichteten Nutzern zu verschaffen, um bspw. ueber die Annahme einer Mail in der rcpt-ACL zu entscheiden... Darauf beruhender Traffic und evtl. Last stellt bisher kein Problem dar. Mittlerweile konsolidieren wir die Maildienste nac und nach auch auf der zentralen Maschine... Gruss, Christian Schmidt -- Manche Hähne glauben, daß die Sonne ihretwegen aufgeht. -- Theodor Fontane signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
On Sun, 27 Nov 2005 15:02:19 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: Marc Haber, 27.11.2005 (d.m.y): Beim Frontend-Backend-Szenario würde ich recipient callout verification aber auch nur im Notfall einsetzen Wieso? Weil ein recipient callout länger dauert als eine LDAP-Abfrage, und ausserdem für jede Mail mit n Empfängern der Backendserver n+1 SMTP-Verbindungen ertragen muss. In der konkreten Situation war es aber leider so, dass keine gemeinsame Benutzerverwaltung existierte, weil die Backend-Maschinen u.a. von verschiedenen Leuten administriert wurden. Und da stellte die recipient callout verification die einfachste Methode dar, der zentralen Maschine Kenntnis von den auf den dezentralen Servern eingerichteten Nutzern zu verschaffen, um bspw. ueber die Annahme einer Mail in der rcpt-ACL zu entscheiden... Das würde ich als einen Notfall bezeichnen. Wenn nix anderes sinnvoll machbar ist als recipient callout, dann muss man eben recipient callout machen. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
Hallo Marc, Marc Haber, 27.11.2005 (d.m.y): On Sun, 27 Nov 2005 15:02:19 +0100, Christian Schmidt [EMAIL PROTECTED] wrote: Marc Haber, 27.11.2005 (d.m.y): Beim Frontend-Backend-Szenario würde ich recipient callout verification aber auch nur im Notfall einsetzen Wieso? Weil ein recipient callout länger dauert als eine LDAP-Abfrage, und ausserdem für jede Mail mit n Empfängern der Backendserver n+1 SMTP-Verbindungen ertragen muss. Da lag ich mit meiner Vermutung ja richtig. ;-) Wie gesagt: Last und Traffic sind weit von den moeglichen Grenzen entfernt - und das Erstellen eines LDAP-Verzeichnisses haette sich IMO nicht gelohnt, da die Maildienste der dezentralen Maschinen nach und nach auf den zentralen Server umziehen. btw: Kennst Du eine gute Einfuehrung in das Thema LDAP? Am besten etwas fuer Leute, die wenig mehr wissen als was LDAP heisst... ;-) Gruss, Christian Schmidt -- Enzyme sind von Biologen erfundene Dinge, die Dinge erklären, die ansonsten tieferes Nachdenken erfordern würden. -- Jerome Lettvin signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Hallo Felix, Felix M. Palmen, 24.11.2005 (d.m.y): * Christian Schmidt [EMAIL PROTECTED] [20051124 20:47]: [Sender-Verifizierung mit Exim] Die Moeglichkeit, diese Verifizierung auch via SMTP-Callout zu erledigen, hast Du noch gar nicht erwaehnt... Ja, denn die finde ich nicht besonders lobenswert ;) OK, bei der sender verification kann man damit leicht auf die Nase fallen, aber fuer Szenarien mit einem Frontend-Mailserver und mehreren dezentralen Backend-Maschinen ist die recipient verification via SMTP-Callout eine super Sache. Aber das ist wieder ein anderes Thema. ...und nicht weniger spannend. ;-) Gruss, Christian Schmidt -- Um geistreich zu sprechen, habe man - wenn man es auf irgendeine Art ist - nur den Mut, alles auszusagen. An der Furcht stirbt das Genie. -- Jean Paul signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Hallo Ace, Ace Dahlmann, 22.11.2005 (d.m.y): On Tue, 22 Nov 2005 11:47:47 +0100 Marc Haber [EMAIL PROTECTED] wrote: Da ja auch ein paar andere Dinge auf der Kiste laufen, könnte dies doch noch ein weiteres Argument sein. Nicht wirklich. Ich habe noch nie einen exim merkbar CPU-Last erzeugen sehen, die Systeme sind üblicherweise viel schneller mit der Platte am Ende. Ich schon: Mein alter Server, auf dem ein Exim mit Procmail, SpamAssassin und Antivir lief, hat, wenn er - seiner Zeit noch zu ISDN-Zeiten - sich eingewählt und Mails abgeholt hat und dann angefangen hat, zu scannen und zu spoolen, das System komplett ausgelastet. Es war noch nichtmals mehr ein fork() möglich, um z.B. einen Login zu machen (oder sonst irgendwas auszuführen). Kommt mir bekannt vor... ;-) Sobald man aber den SpamAssassin aus dieser Konstellation herausnimmt, geht wieder die gewohnte Post ab. Gruss, Christian Schmidt -- Ich verlange nicht, daß der Kleinbürger seine Moral aufgibt, ich verlange nur, daß er mir meine läßt. -- José Ortega y Gasset signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Hallo Felix, Felix M. Palmen, 22.11.2005 (d.m.y): Exim kann ACLs nach RCPT TO: und nach DATA: abarbeiten. In der ersten lässt sich schon alles ablehnen, was syntaktisch falsch ist oder an nicht zustellbare Adressen adressiert ist. Außerdem kann man mit require verify = sender erzwingen, dass Mail von nicht existierenden Sende-Domains ebenfals abgelehnt wird. Die Moeglichkeit, diese Verifizierung auch via SMTP-Callout zu erledigen, hast Du noch gar nicht erwaehnt... Gruss, Christian Schmidt -- Man unterlässet zu viel Gutes, weil der Nutzen, und begeht so viel Böses, weil der Schaden zweifelhaft ist. -- Jean Paul signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Hallo Christian, * Christian Schmidt [EMAIL PROTECTED] [20051124 20:47]: [Sender-Verifizierung mit Exim] Die Moeglichkeit, diese Verifizierung auch via SMTP-Callout zu erledigen, hast Du noch gar nicht erwaehnt... Ja, denn die finde ich nicht besonders lobenswert ;) Aber das ist wieder ein anderes Thema. Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Moin, On Mon, 21 Nov 2005 23:00:25 +0100 Udo Mueller [EMAIL PROTECTED] wrote: Alternativ hätte ich noch die Idee, den Server über Samba, der ja eh läuft, als PDC einzurichten und damit (also auch für die Linux-Clients) die Authentifizierung zu machen. Was ist von der Idee zu halten? Geht das ueberhaupt? Ja, wenn der Rechner einmal an der Domäne angemeldet ist, haben die Domänen-Benutzer gemappte UNIX-UIDs und -GIDs, denen Du auch Verzeichnisse zuordnen kannst (zumindest ist es so, wenn Du die Kiste in ein Active Directory integrierst - kürzlich gemacht); und per smb.conf kannst Du das /home-Verzeichnis festlegen. z.B. template homedir = /home/%U oder /home/%D/U (für Domänen-Name/username). Ich wuerd ja eher LDAP nehmen und den Samba-Server da mit ranknueppern. Aber ich hab sowas auch noch nie gemacht... Kann ich nur empfehlen. Windows und Linux-Login k_nnen _ber LDAP abgedeckt werden. Desweiteren auch noch Sachen wie Email etc. Hmm, ok, wenn Ihr alle der Meinung seid, dass LDAP der richtige Weg ist, werde ich mich da mal mit befassen (Aber die zentrale Anmeldung lege ich erstmal etwas nach hinten, die anderen Sachen haben Priorität. :)). Ich hatte mir das vor einigen Jahren mal angeguckt und kann mir nur grob an eine komplizierte Einrichtung erinnern; aber das ist auch schon lange her. Vorab: Hätte da jemand eine gute HowTo-Empfehlung? Aber prinzipiell kann auch der sshd gehackt werden und dann hat derjenige Voll-Zugriff auf den Server. Und das ist der Grund, warum man sensible Daten nicht auf einen Rechner legt, der direkt aus dem Internet zugreifbar ist. Deswegen würde ich den Port ja gerne on demand mit meinem Handy öffnen. :) Aber falls das mit xring aus irgendeinem Grund nicht klappen sollte, glaube ich, dass ich mit dem sshd-Filter auch recht sicher bin, wenn der nach der 3. falschen Anmeldung blockt. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! On Tue, 22 Nov 2005 08:48:42 +0100 Marc Haber [EMAIL PROTECTED] wrote: Postfix bietet sehr viele wirksame Antispammassnahmen was mir persönlich wichtig ist. Wie meinste das? Grundsätzlich kann exim mehr als Postfix, erfordert aber aufgrund der größeren Flexibilität mehr Auseinandersetzung mit der Dokumentation. Das Design von Postfix ist moderner, exim ist halt immer noch ein großer suid-Monolith mit single mail queue. Hmmm, das Stichwort erinnert mich gerade daran, dass ich mal gelesen hatte, dass der Postfix auch wesentlich schlanker und schneller ist - stimmt das? Da ja auch ein paar andere Dinge auf der Kiste laufen, könnte dies doch noch ein weiteres Argument sein. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! On Mon, 21 Nov 2005 15:45:12 +0100 Gerhard Brauer [EMAIL PROTECTED] wrote: Mit Routing würde das IMHO sicher gehen, würde aber dem DMZ Prinzip widersprechen, innere und äußere Dienste physikalisch und logisch zu trennen. Dein Rechner in der DMZ wäre aber gleichzeitig Server für Clients im LAN und (per sshd) fürs Badland. Hmm, ich muss dann mal schauen, wie ich den Rechner am Router am besten freigebe - ist so'n doofer T-Online-Router und so ganz raff ich den nicht. Man kann zwar auch externe Ports per IP auf interne freigeben, aber zumindest bei dem einen mal, bei dem ich das mal getestet hatte, war der Port nach außen hin dann dennoch nicht offen. Hat jemand zufällig einen T-Sinus 154 DSL mit Freigaben im Einsatz? xringd geht (vons Haus aus) IMHO auch mit Modems (serial connections). Da bin ich schon gespannt. :) nicht vergessen, dieses z.B. aus der Wahlwiederholung rauszunehmen. Wenn, dann nehm ich dann mein Handy dafür. :) Ich meinte damit, _wenn_ ein Angreifer auf deinen Server gelangt dann kann er wie ein normaler Client agieren (z.B. nfs, smb, eigene Dienste starten, ...) Achso ja, das ist klar... Das alte Thema personal firewalls... ;-) Du kannst definitiv darauf verzichten wenn kein Dienst von außen zu erreichen ist. Muss ich mal gucken, was das Argument von Frank da in der Praxis zu sagt - von wegen NTP!? Ich finde allerdings die Logging-Möglichkeiten bei z.B. iptables hilfreich, um z.B. Art, Zeitpunkt und Häufigkeit diverser Zugriffe zu protokollieren um diese dann ggf. mit Auffälligkeiten im LAN zu kombinieren. Hmmm,... ok. Auch ne Idee. Sinnvoll als Sicherheit auch, um z.B. _vom_ LAN nur bestimmte Dienste z.B. zum Server bzw. ins Internet zuzulassen. Wichtig IMHO weil z.B. vermehrt Trojaner über legale Dienste (mail) ins LAN geschleppt werden. Und wenn jetzt die FW so konfiguriert ist: von Innen nach außen alles erlauben, dann gute Nacht. Obwohl wir von außerhalb ja nie angreifbar waren... Hat da jemand ein paar Beispiel-Ports (oder eine HowTo), die man ruhig nach außen hin sperren sollte? -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! Oh, eine Sache hab ich eben in meinem Kombi-Posting übersehen,.. muss ich doch nochmal einzeln... On Mon, 21 Nov 2005 20:52:58 +0100 Matthias Haegele [EMAIL PROTECTED] wrote: Ich hatte auf meinem damaligen ISDN-Gateway-Firewall-Mail-Proxy-Server Antivir für Linux insalliert. Ich denke, ich werde es wieder nehmen. Die kommerzielle Ver?. Hab bisher auch nur gutes gehört. Jain, die, die für Privat-Anwender kostenlos ist - man aber dennoch einen Key beantragen muss. :) Ok. dann AMAVISD-NEW -clamav, antivir kann nicht schaden :-). In amavisd-new muss ich mich auch mal einlesen, ich hatte das noch einzeln über Procmail gemacht. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
On Tue, 22 Nov 2005 10:27:43 +0100, Ace Dahlmann [EMAIL PROTECTED] wrote: On Tue, 22 Nov 2005 08:48:42 +0100 Marc Haber [EMAIL PROTECTED] wrote: Grundsätzlich kann exim mehr als Postfix, erfordert aber aufgrund der größeren Flexibilität mehr Auseinandersetzung mit der Dokumentation. Das Design von Postfix ist moderner, exim ist halt immer noch ein großer suid-Monolith mit single mail queue. Hmmm, das Stichwort erinnert mich gerade daran, dass ich mal gelesen hatte, dass der Postfix auch wesentlich schlanker und schneller ist - Die Geschwindigkeit von Mailservern ist für Endusersysteme in dieser Welt völlig irrelevant, da sie eh' vom DNS und der üblicherweise dünnen Anbindung ausgebremst werden. Ein DSL 6000 kann jeder MTA problemlos auslasten, wenn das System und die Platte es zulässt. Da ja auch ein paar andere Dinge auf der Kiste laufen, könnte dies doch noch ein weiteres Argument sein. Nicht wirklich. Ich habe noch nie einen exim merkbar CPU-Last erzeugen sehen, die Systeme sind üblicherweise viel schneller mit der Platte am Ende. Und meine Erfahrung mit belasteten Mailsystemen kommt noch aus einer Zeit, wo die Schere zwischen der Leistung von CPU und Platte noch nicht so weit offen war wie sie es heute ist. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Sicherheitskonzept eines neuen Servers
Hi! On Tue, 22 Nov 2005 11:47:47 +0100 Marc Haber [EMAIL PROTECTED] wrote: Da ja auch ein paar andere Dinge auf der Kiste laufen, könnte dies doch noch ein weiteres Argument sein. Nicht wirklich. Ich habe noch nie einen exim merkbar CPU-Last erzeugen sehen, die Systeme sind üblicherweise viel schneller mit der Platte am Ende. Ich schon: Mein alter Server, auf dem ein Exim mit Procmail, SpamAssassin und Antivir lief, hat, wenn er - seiner Zeit noch zu ISDN-Zeiten - sich eingewählt und Mails abgeholt hat und dann angefangen hat, zu scannen und zu spoolen, das System komplett ausgelastet. Es war noch nichtmals mehr ein fork() möglich, um z.B. einen Login zu machen (oder sonst irgendwas auszuführen). Allerdings muss ich dabei sagen, dass es sich um ein Woody mit Kernel 2.2.26 handelte (bzw. handelt, weil die Kiste noch existiert und im Prinzip noch einsatzbereit wäre ;)). Der Rechner ist ein HP Netserver E 45 (PII 233, 128MB RAM). Bei der Kiste, die ich jetzt aufsetzen werde, handelt es sich aber um meine alte Workstation (AMD Duron 700, 768 MB RAM) und es wird Sarge mit 2.6.8 werden. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hallo Andreas, * Andreas Pakulat [EMAIL PROTECTED] [20051121 12:15]: Der SSH-Port soll zunächst als einziger Port nach außen hin offen sein, alles andere wird über die andere NIC nur nach innen freigegeben - alles per iptables; für die Konfiguration dessen werde ich bastille nehmen. ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. Falsch. Wo letztendlich das Paket aufgehalten wird ist egal, das heißt zunächst einmal sind beide Vorgehensweisen gleich sicher. Wenn man sich allerdings nur auf die Kponfiguration der einzelnen Dienste verlässt ist das wesentlich fehleranfälliger, jeder hat eine andere Syntax und es gibt sogar welche, die sich überhaupt nicht beschränken lassen. Man macht also am besten beides (richtige Konfiguration der einzelnen Dienste UND Paketfilter). Die weit verbreiteten Vorbehalte gegen Paketfilter liegen eher in sogenannten Firewalls für Windows begründet, die irgendwelchen Voodoo-Zauber versprechen und zu unsicher konfigurierten Systemen sowie Risikokompensation beim Anwender führen. Linux Netfilter dagegen funktioniert genau wie beschrieben und verspricht nichts Unsinniges, den Einsatz kann man nur empfehlen. Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Ace Dahlmann [EMAIL PROTECTED] writes: On Tue, 22 Nov 2005 11:47:47 +0100 Marc Haber [EMAIL PROTECTED] wrote: Nicht wirklich. Ich habe noch nie einen exim merkbar CPU-Last erzeugen sehen, die Systeme sind üblicherweise viel schneller mit der Platte am Ende. Ich schon: Mein alter Server, auf dem ein Exim mit Procmail, SpamAssassin und Antivir lief, hat, wenn er - seiner Zeit noch zu ISDN-Zeiten - sich eingewählt und Mails abgeholt hat und dann angefangen hat, zu scannen und zu spoolen, das System komplett ausgelastet. Es war noch nichtmals mehr ein fork() möglich, um z.B. einen Login zu machen (oder sonst irgendwas auszuführen). spamassassin lastet auch eine Duron 1000 bis zur unbenutzbarkeit aus. das hat aber mit dem MTA nun ueberhaupt garnix zu tun.
Re: Sicherheitskonzept eines neuen Servers
Gruesse! * Ace Dahlmann [EMAIL PROTECTED] schrieb am [22.11.05 10:38]: Hi! Sinnvoll als Sicherheit auch, um z.B. _vom_ LAN nur bestimmte Dienste z.B. zum Server bzw. ins Internet zuzulassen. Wichtig IMHO weil z.B. vermehrt Trojaner über legale Dienste (mail) ins LAN geschleppt werden. Und wenn jetzt die FW so konfiguriert ist: von Innen nach außen alles erlauben, dann gute Nacht. Obwohl wir von außerhalb ja nie angreifbar waren... Hat da jemand ein paar Beispiel-Ports (oder eine HowTo), die man ruhig nach außen hin sperren sollte? Die bessere Strategie wäre zu fragen, welche Ports man öffnen sollte. Und generell erstmal alles andere zu verbieten. Und was _du_ öffnen willst kannst eigentlich nur du wissen. Du wirst sicher, wenn du das harden bzw. secure Manual durcharbeitest, auf den Punkt stoßen nicht benötigte laufende Dienste abzuschalten oder zumindest an ein bestimmtes Interface zu binden. Das würde auf dem Server für oben gesagtes bedeuten, sowohl für Input als auch für Output/Forward: Rufe auf dem Server: netstat -tulpen auf. Das sind sowohl für udp als auch tcp laufende lauschende Dienste. Wichtig sind jetzt diese Dienste, die an allen Interfaces lauschen, die also bei Local Address 0.0.0.0 bzw. ::: haben. Diese gilt es jetzt bei Nichtgebrauch abzuschalten oder wenn möglich per Konfig an das gewünschte IF zu binden. Für die Dienste, die danach noch übrigbleiben, also bei denen es nicht möglich ist sie an ein bestimmtest IF zu binden, dafür wäre dann eine Zugriffsregelung per iptables notwendig. NTP ist so ein Fall. Zu oben: du könntest aus dem LAN z.B. nur smpt, imap(s),nfs, smb zum Server hin zulassen, weil _du_ weißt: das sind die Dienste, die meine Clients nutzen und die auf dem Server laufen. Alles andere verbieten. Und zum/mit dem Router genauso verfahren (halt die Dienste, die du im Internet nutzen willst). Das würde es einem Schadprogramm aus dem LAN unmöglich machen, sich mit dem Server bzw. dem Badland zu verbinden. Außer, es würde Protokolle nutzen die du freigegeben hast (z.B. http). In diesen Fällen hilft sowieso nur ein IDS, was sich auch den Inhalt der Pakete anschaut. Alles andere, was dann jetzt oder in Zukunft nicht geht, und was dann geloggt werden kann, das kannst du dann nach eigenem Ermessen öffnen. Aber das ist wie gesagt, nur ein Teil eines mehrstufigen Sicherheitskonzeptes. Man sollte da zum einen nicht zu paranoid sein und dem Einfachen den Vorzug vor dem Komplizierten geben. Also lieber abschalten statt regeln, lieber alles verbieten und nachträglich öffnen als umgekehrt. Best regards... Ace Dahlmann Gruß Gerhard -- HAL is running Windows...
Re: Sicherheitskonzept eines neuen Servers
On Tue, Nov 22, 2005 at 12:26:36PM +0100, frank paulsen wrote: spamassassin lastet auch eine Duron 1000 bis zur unbenutzbarkeit aus. das hat aber mit dem MTA nun ueberhaupt garnix zu tun. Stimmt, mit dem MTA hat das nichts zu tun, aber auch nicht unbedingt mit dem verwendeten Prozessor. Der Flaschenhals ist hier eher der hohe RAM-Bedarf (256MB sind Minimum, IMHO). Uwe -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Uwe Laverenz [EMAIL PROTECTED] writes: Stimmt, mit dem MTA hat das nichts zu tun, aber auch nicht unbedingt mit dem verwendeten Prozessor. Der Flaschenhals ist hier eher der hohe RAM-Bedarf (256MB sind Minimum, IMHO). der Duron hat 256+128MB, eigentlich sollte das fuer nen spamfilter reichen. gut, da laeuft noch ein squid mit. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Uwe Laverenz schrieb: On Tue, Nov 22, 2005 at 12:26:36PM +0100, frank paulsen wrote: spamassassin lastet auch eine Duron 1000 bis zur unbenutzbarkeit aus. das hat aber mit dem MTA nun ueberhaupt garnix zu tun. Deswegen versuche ich schon möglichst viel im MTA zu blocken, da das wesentlich schneller/resourcenschonender ist, einfache HELO/EHLO Checks leisten da schon manchmal viel ... grössere content/checks sind aber imho eher dem Spamfilter sein Metier. Stimmt, mit dem MTA hat das nichts zu tun, aber auch nicht unbedingt mit dem verwendeten Prozessor. Der Flaschenhals ist hier eher der hohe RAM-Bedarf (256MB sind Minimum, IMHO). Im Postfixbuch wurde ein tempfs im RAM für solche Zwecke eingerichtet, was natürlich wiederum genug RAM benötigt ... Hatte seither mit dem Athlon 1700/512MB keine Probleme allerdings ist das Ding auch noch nicht produktiv. Uwe Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo Matthias, * Matthias Haegele [EMAIL PROTECTED] [20051121 20:52]: Postfix bietet sehr viele wirksame Antispammassnahmen was mir persönlich wichtig ist. Welche wären das denn? Exim kann ACLs nach RCPT TO: und nach DATA: abarbeiten. In der ersten lässt sich schon alles ablehnen, was syntaktisch falsch ist oder an nicht zustellbare Adressen adressiert ist. Außerdem kann man mit require verify = sender erzwingen, dass Mail von nicht existierenden Sende-Domains ebenfals abgelehnt wird. In der zweiten ACL können dann Virenscanner und Spamscanner (z.B. Spamassassin über sa-exim) zum Zug kommen, die Mail kann immer noch abgelehnt werden. Fehlt da jetzt etwas, was Postfix bietet? Externe Applikationen wie AMAVISD-NEW oder Scripte lassen sich einfach einbinden. Das kann Exim auch, allerdings bin ich von Amavis nicht besonders überzeugt, schließlich hat man die Mail schon angenommen, wenn amavis laufen kann - wenn also dann etwas gefunden wird steht man vor dem Problem, was man mit der Mail tut. Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
On 22.11.05 12:21:39, Felix M. Palmen wrote: Hallo Andreas, * Andreas Pakulat [EMAIL PROTECTED] [20051121 12:15]: Der SSH-Port soll zunächst als einziger Port nach außen hin offen sein, alles andere wird über die andere NIC nur nach innen freigegeben - alles per iptables; für die Konfiguration dessen werde ich bastille nehmen. ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. Falsch. IMHO nicht, aber s.u. Wo letztendlich das Paket aufgehalten wird ist egal, das heißt zunächst einmal sind beide Vorgehensweisen gleich sicher. Wenn der Dienst nicht angeboten wird, wird das Paket nicht aufgehalten, es laeuft ins Leere. Bzw. wird wohl der Kernel ein entsprechendes Antwortpaket generieren. Wenn du aber iptables verwendest um alle Anfragen auf Port X abzublocken, musst du dir sicher sein dass 1. iptables kein Sicherheitsloch haben 2. Deine Regeln alle korrekt sind Und schliesslich auch das der Kernel IP-Kram kein relevantes Sicherheitsloch hat, das aber gilt natuerlich auch fuer die Abschaltung eines Dienstes. Wenn man sich allerdings nur auf die Kponfiguration der einzelnen Dienste verlässt ist das wesentlich fehleranfälliger, ?? Wieso ist das fehleranfaellig? Ich schalte den Dienst ab, bzw. lasse ihn nur auf IP X Port Y lauschen. Verstehe ich nicht. jeder hat eine andere Syntax Mit der Konfiguration der zu installierenden Dienste muss man sich eh beschaeftigen, fuer einen oeffentlichen Server reicht ein apt-get sshd oder apt-get apache einfach nicht. Da muss man schon etwas mehr Zeit investieren. und es gibt sogar welche, die sich überhaupt nicht beschränken lassen. Das ist etwas vollkommen anderes und das Beispiel ntp wurde ja schon genannt. Hier ist es natuerlich sinnvoll die Kommunikation zu dem ntp mittels iptables zu beschraenken. Man macht also am besten beides (richtige Konfiguration der einzelnen Dienste UND Paketfilter). Wenn ein Paketfilter notwendig wird, klar. Aber wieso soll ich den nutzen wenn ich ihn nicht brauche? Das Sicherheitskonzept sollte zwar alle Risiken abdecken, aber nicht mehr damit es uebersichtlich bleibt... Die weit verbreiteten Vorbehalte gegen Paketfilter liegen eher in sogenannten Firewalls für Windows begründet, Die Windows-Firewalls sind sowieso Humbug, aber das hat nichts mit der Tatsache zu tun, dass es besser ist einen Dienst nicht anzubieten als zu versuchen mittels Paketfilter den Zugriff darauf zu beschraenken. Ich hab auf meinem Router auch keine Dienste aufs Externe Interface gelegt, und iptables dient einzig und allein dazu aus dem LAN heraus die Windows-Kommunikation ins Internet zu blocken, sowie das Masquerading durchzufuehren. Linux Netfilter dagegen funktioniert genau wie beschrieben und verspricht nichts Unsinniges, den Einsatz kann man nur empfehlen. Wie gesagt: Wer einen Paketfilter braucht, soll ihn nutzen. Aber wenn man die Sicherheit des Servers ohne Paketfilter auf demselbigen sicherstellen kann, dann besteht keinerlei Grund einen einzusetzen. Andreas -- You never know how many friends you have until you rent a house on the beach. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo Andreas, * Andreas Pakulat [EMAIL PROTECTED] [20051122 18:07]: Wenn man sich allerdings nur auf die Kponfiguration der einzelnen Dienste verlässt ist das wesentlich fehleranfälliger, ?? Wieso ist das fehleranfaellig? Ich schalte den Dienst ab, bzw. lasse ihn nur auf IP X Port Y lauschen. Verstehe ich nicht. Ich merk's. Du schließt Fehler des Admins in deinen Sicherheitsüberlegungen offenbar aus. Solltest du nicht. Außerdem musst du eigentlich bei jedem Dienst nochmal von Hand prüfen, ob er wirklich nur da horcht, wo er laut Konfiguration soll. Ist generell eine gute Idee, das zu tun, aber wer denkt da wirklich /immer/ dran? Wie gesagt: Wer einen Paketfilter braucht, soll ihn nutzen. Aber wenn man die Sicherheit des Servers ohne Paketfilter auf demselbigen sicherstellen kann, dann besteht keinerlei Grund einen einzusetzen. Sind dir die Konzepte Redundanz bzw. mehrere Sicherheitsebenen geläufig? Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
On 22.11.05 22:54:48, Felix M. Palmen wrote: Hallo Andreas, * Andreas Pakulat [EMAIL PROTECTED] [20051122 18:07]: Wenn man sich allerdings nur auf die Kponfiguration der einzelnen Dienste verlässt ist das wesentlich fehleranfälliger, ?? Wieso ist das fehleranfaellig? Ich schalte den Dienst ab, bzw. lasse ihn nur auf IP X Port Y lauschen. Verstehe ich nicht. Ich merk's. Du schließt Fehler des Admins in deinen Sicherheitsüberlegungen offenbar aus. Solltest du nicht. Jaein, mir ist schon bewusst das man Fehler machen kann, aber bei einer einfachen Direktive wie Listen (oder wie auch immer der Dienst bzgl. IP/Port konfiguriert wird) sollten keine Fehler auftreten. Wenn der Admin nicht sorgfaeltig arbeitet geht die ganze Sache eh in die Hose. Dazu gehoert halt auch mal zu testen ob man noch raufkommt, spaetestens dann werden solche Dinge sichtbar. Außerdem musst du eigentlich bei jedem Dienst nochmal von Hand prüfen, ob er wirklich nur da horcht, wo er laut Konfiguration soll. Ist generell eine gute Idee, das zu tun, aber wer denkt da wirklich /immer/ dran? Das kommt halt drauf an, bei nem privaten Server wird das wohl eher nicht passieren, a) Weil nicht jeder so ein Hacker ist um den Dienst wirklich anzugreifen b) Ist ja nur mein Server - viele denken nicht dran, dass der auch missbraucht werden kann Wenn sowas im professionellen Umfeld nicht gemacht wird oder auch z.B. keine regelmaessige Log-Pruefung, ist das IMHO grob fahrlaessig und der Admin duerfte in dem Fall mind. mit seinem Job spielen. Wie gesagt: Wer einen Paketfilter braucht, soll ihn nutzen. Aber wenn man die Sicherheit des Servers ohne Paketfilter auf demselbigen sicherstellen kann, dann besteht keinerlei Grund einen einzusetzen. Sind dir die Konzepte Redundanz bzw. mehrere Sicherheitsebenen geläufig? Ja klar, aber das kann eben auch nach hinten los gehen - wenn man den Ueberblick ueber die ganzen Ebenen verliert. Ja, iptables kann zu einem Sicherheitskonzept gehoeren und tut es auch oft/meist, aber es _muss_ IMHO nicht zwangsweise. Andreas -- Never commit yourself! Let someone else commit you. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
On 21.11.05 11:38:33, Ace Dahlmann wrote: Das wichtigste sind vor allem erstmal die internen Dienste: - der APT-Proxy läuft aktuell bereits auf dem alten Server und soll dorthin verschoben werden (btw: Reicht es, seine Verzeichnisse zu kopieren oder muss man zusätzlich importieren?). Das kopieren sollte reichen, aber achte darauf die Rechte beizubehalten und die Datenbank nicht vergessen (in /var/cache/apt-proxy/.apt-proxy) - Für die Freigabe soll primär NFS verwendet werden, zusätzlich würde Ich kann das selbst nicht bestaetigen oder widerlegen, aber man kann an verschiedenen Stellen im Netz lesen das CIFS besser sein soll. Das spart dir dann auch einen Dienst. Ach und statt NIS kann man auch LDAP nutzen ;-) Für die internen Dienste ist das obige ja zunächst alles kein Problem. Ich würde allerdings sehr gerne von außen auf den Rechner (am Liebsten per SSH) zugreifen können, um z.B. via Shell und Mutt meine Mails zu lesen (Ich halte das für sicherer als den IMAP-Server auch nach außen hin freizugeben. Oder?) Es gibt IMAPS, aber im Prinzip stimme ich dir zu, zumal du ja ssh vllt. auch noch anderweitig benoetigst. Der SSH-Port soll zunächst als einziger Port nach außen hin offen sein, alles andere wird über die andere NIC nur nach innen freigegeben - alles per iptables; für die Konfiguration dessen werde ich bastille nehmen. ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. (Wäre es ggf. auch sinnvoll, zwei sshds laufen zu lassen - einen intern, einen extern - oder eher lieber nicht?) Du koenntest bei dem internen z.B. root-Login erlauben, oder PW-Login und beim externen nur Public-Key-Auth... Den potentiellen Apache würde ich ebenfalls in einem Changeroot laufen lassen. Falls Ihr aber der Meinung seid, dass ein Apache - trotz Changeroot - für den Server viel zu unsicher wäre, werde ich von der Idee ablassen; so wichtig ist er mir dann auch nicht. ?? Weisst du wie viele Webseiten mit Apache laufen, ohne gehackt zu werden... Wenn du den vernuenftig einrichtest und sicherheitstechnisch auf nem aktuellen Stand sollte das kein groesseres Problem darstellen als der extern angebotene sshd. Ob ein chroot allerdings sicherer ist oder nur macht weiss ich nicht, insbesondere da ja die Prozesse die die Seiten ausliefern nicht als root laufen. Per Debian Hardening HowTo wird anschließend alles vom Server entfernt, was auf einem Server nichts zu suchen hat. Das wuerde ich machen bevor die externe NIC angeschlossen ist. Andreas -- Cold hands, no gloves. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Ace Dahlmann schrieb: Hallo zusammen, Hallo!. die Mail von Harald Tobias brachte mich auf die Idee, meine Ideen für einen neuen Server hier mal zu posten... Aufgrund einer Umstrukturierung meines Netzes zu hause, werde ich mir einen Server neu aufsetzen, der mehrere Dinge auf einmal machen und können soll: - Mailserver - (Eingang / IMAP) - inkl. SpamAssassin - und Virenscanner - APT-Proxy - NFS-Freigabe - Samba-Freigabe - SSH - NTP - Printserver - Fileserver - evtl. NIS - (evtl. Webserver) Was ich machen will: [...] - Als NTP-Server soll er dem Netz auch dienen (ebenfalls intern, versteht sich). Was nimmste da?. - Letztlich soll er noch meine Mails abholen, Spam- und Virenfilter drüber laufen lassen und mir per IMAP zur Verfügung stellen. MTA - Postfix (kann ich nur empfehlen). AMAVISD-NEW - clamav?. [...] Den SSH würde ich zum einen - über sshdfilter (http://www.csc.liv.ac.uk/~greg/sshdfilter/) Aah. Schon mal getestet?. absichern, - zum anderen nur für meinen Benutzer erlauben, ja. no root login ... - einen anderen Port als 22 nehmen und Kann ich allein wg. der Script-SSH-Kiddies und Logzumüllung nur empfehlen. Gegen einen ernsthaften Cracker wird das aber auch nicht allzulange helfen ... - außerdem in einem Changeroot (in meinem Home) laufen lassen. Der SSH-Port soll zunächst als einziger Port nach außen hin offen sein, alles andere wird über die andere NIC nur nach innen freigegeben - alles per iptables; für die Konfiguration dessen werde ich bastille nehmen. [...] Per Debian Hardening HowTo wird anschließend alles vom Server entfernt, was auf einem Server nichts zu suchen hat. Bitte posten wenn es da ein paar Haken und Ösen gibt ... [...] Was haltet Ihr davon? Was habe ich vergessen? Was sollte ich lieber nicht oder lieber anders machen? Den Fortlauf des Experimentes dokumentieren? :-). Bis dann erstmal, Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Gruesse! * Ace Dahlmann [EMAIL PROTECTED] schrieb am [21.11.05 11:38]: Hallo zusammen, die Mail von Harald Tobias brachte mich auf die Idee, meine Ideen für einen neuen Server hier mal zu posten... - Von außen möchte ich per DynDNS auf den Server kommen. Für die internen Dienste ist das obige ja zunächst alles kein Problem. Ich würde allerdings sehr gerne von außen auf den Rechner (am Liebsten per SSH) zugreifen können, um z.B. via Shell und Mutt meine Mails zu lesen (Ich halte das für sicherer als den IMAP-Server auch nach außen hin freizugeben. Oder?) Würde ich auch so sehen. Wenn dir die Möglichkeiten per Shell in deinem chroot`den Zugang ausreichen ist das sicher besser und einfacher, als von einem (fremden?) Rechner per MUA, der ja erst konfiguriert werden muß, zuzugreifen. Zunächst mal werde ich zwei NICs einbauen, um die Ports schön nach Interfacce zu trennen. Hält die externe NIC die Verbindung zum Provider-Gateway oder ist noch ein Router zwischengeschaltet? Ich gehe aber von ersterem aus. Auf jedenfall vernünftig. Den SSH würde ich zum einen - über sshdfilter (http://www.csc.liv.ac.uk/~greg/sshdfilter/) absichern, - zum anderen nur für meinen Benutzer erlauben, Und überlegen AUTH nur per Key zuzulassen und Passwort-Auth zu disablen. - einen anderen Port als 22 nehmen und Hält nur die Logs kleiner und die Kids fern, Profis nicht. Und die sind am gefährlichsten. - außerdem in einem Changeroot (in meinem Home) laufen lassen. So erhälst du halt lediglich die Möglichkeit, Daten und Dienste in diesem jail zu nutzen. Wenn dir das langt, ok. Aber jeder Versuch deinerseits dir irgendwie ein Türchen aufzumachen kann auch von anderen genutzt werden. (Alternativ würde mich interessieren, ob jemand eine Möglichkeit (außer Portknocking) kennt, um den Port auf Demand freizugeben - z.B. über ISDN-Einwahl). Mit xringd ist da sehr gut etwas zu machen. Hat die gleichen umfangreichen Möglichkeiten wie portknocking (halt Tonsequenzen statt knock key), dafür brauchst du halt nur ein Telefon/Modem/... als Client. Der SSH-Port soll zunächst als einziger Port nach außen hin offen sein, alles andere wird über die andere NIC nur nach innen freigegeben - alles per iptables; für die Konfiguration dessen werde ich bastille nehmen. Wie du es ansprichst und auch weißt: der internen Absicherung (auch der angeschlossenen Clients) ist mindest genausoviel Aufmerksaamkeit zu schenken wie du es nach außen ins Badland betreiben willst - eher mehr. (Wäre es ggf. auch sinnvoll, zwei sshds laufen zu lassen - einen intern, einen extern - oder eher lieber nicht?) Ich würde v.a. darauf achten, nicht den Überblick zu verlieren - nichts ist schlimmer als ein Sicherheitskonzept (verzahnt über meherer Ebenen), bei denen du in einem halben Jahr nicht mehr weißt, was wann wo passiert. Der beste Schutz ist immer noch Abschalten statt Absichern. Kein Port = kein Angriff. Außerdem wird man per SSH nur AUF den Server kommen, aber nicht davon weg, kein interner Rechner wird einen SSH-Port offen haben. Trügerisch. Es gibt sicher bessere Möglichkeiten Rechner _im_ LAN zu capturen als ein sshd. Den potentiellen Apache würde ich ebenfalls in einem Changeroot laufen lassen. Falls Ihr aber der Meinung seid, dass ein Apache - trotz Changeroot - für den Server viel zu unsicher wäre, werde ich von der Idee ablassen; so wichtig ist er mir dann auch nicht. Dann laß ihn weg, wenn du ihn nicht _brauchst_. S.o.: kein Dienst = kein Angriff. Außerdem werde ich mir zu Überwachung der Logs irgendein IDS-Tool heraussuchen. Irgendwelche Empfehlungen? Hm, nur Vorsicht bei diversen IDS, daß die NICs nicht in den promiscuous mode geschaltet werden. AFAIK würdest du damit deine physikalische Trennung der Netze angreifbar machen. So... Was haltet Ihr davon? Was habe ich vergessen? Was sollte ich lieber nicht oder lieber anders machen? Deine Überlegungen sind IMHO ganz ausgereift. Ich würde lediglich, wie oben angesprochen, darauf achten daß _du_ (jetzt und später) jederzeit verstehst Was Wie und Warum passiert. Vor allem wenn du verschiedene externe Konzepte einsetzt. Also lieber _ein_ gutes Schloß an der Tür als 15 verschiedene. Während du da nämlich noch am dicken Schlüsselbund kramst hat schon längst jemand die Klinke gedrückt. Wenn nach außen nur ein (chroot) sshd lauscht, mit starker Passphrase oder Schlüssel, dann kann dein Rechner nicht gehackt werden. Punkt. Und fange jetzt schon an, die Möglichkeiten/Umgebungen zu schaffen, dein Sicherheitskonzept auch auf jeder Ebene zu testen. Hack yourself ;-) Bis dann erstmal, -- Best regards... Ace Dahlmann Gruß Gerhard -- Don't drink and root!
Re: Sicherheitskonzept eines neuen Servers
Hallo, erstmal schonmal danke für Eure Antworten. :-) Ich werde wohl am besten Themen bezogen antworten... On Mon, 21 Nov 2005 12:15:59 +0100 Andreas Pakulat [EMAIL PROTECTED] wrote: - Für die Freigabe soll primär NFS verwendet werden, zusätzlich würde Ich kann das selbst nicht bestaetigen oder widerlegen, aber man kann an verschiedenen Stellen im Netz lesen das CIFS besser sein soll. Mit CIFS hab ich mich noch nicht befasst; da werde ich mich dann auch mal einlesen. Das spart dir dann auch einen Dienst. Ach und statt NIS kann man auch LDAP nutzen ;-) Ich habe gerade gelesen, dass NIS ziemlich unsicher sein soll. Daher werde wohl davon Abstand nehmen. Alternativ hätte ich noch die Idee, den Server über Samba, der ja eh läuft, als PDC einzurichten und damit (also auch für die Linux-Clients) die Authentifizierung zu machen. Was ist von der Idee zu halten? ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. Gar keine Firewall zusätzlich? Sollte ich denn ggf. auch noch die hosts.allow mit nutzen? ?? Weisst du wie viele Webseiten mit Apache laufen, ohne gehackt zu werden... Aber auf denen läuft wahrscheinlich kein Fileserver, der mit einem Bein im LAN und mit dem anderen im Netz steht? ;) Daher bin ich halt diesbzgl. etwas ängstlich. -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! On Mon, 21 Nov 2005 12:21:24 +0100 Matthias Haegele [EMAIL PROTECTED] wrote: - Als NTP-Server soll er dem Netz auch dienen (ebenfalls intern, versteht sich). Was nimmste da?. Ich glaube, ich werde das ntp-Paket (von welchem ntp-server und ntp-simple abhängen) und ntpdate installieren. MTA - Postfix (kann ich nur empfehlen). Bisher war ich Exim-Fan. Ohne einen Glauben-Krieg auszulösen: Was hätte welche Vorteile? AMAVISD-NEW - clamav?. Ich hatte auf meinem damaligen ISDN-Gateway-Firewall-Mail-Proxy-Server Antivir für Linux insalliert. Ich denke, ich werde es wieder nehmen. - über sshdfilter (http://www.csc.liv.ac.uk/~greg/sshdfilter/) Aah. Schon mal getestet?. Nee, noch nicht. Ich bin selbst gespannt. :-) Den Fortlauf des Experimentes dokumentieren? :-). Ja, ich denke, das werde ich in der Tat tun, allein schon, damit ich hinterher selber noch weiß, was ich alles beachten muss(te). Könnte eigentlich nicht schaden, es auf eine allgemeine HowTo für einen solchen Home-Server zu erweitern, oder meint Ihr, davon gibt's eh schon genug!? -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
Hi! On Mon, 21 Nov 2005 12:44:44 +0100 Gerhard Brauer [EMAIL PROTECTED] wrote: Würde ich auch so sehen. Wenn dir die Möglichkeiten per Shell in deinem chroot`den Zugang ausreichen ist das sicher besser und einfacher, als von einem (fremden?) Rechner per MUA, der ja erst konfiguriert werden muß, zuzugreifen. Schön, dass Ihr das bisher auch alle so seht. :) Zunächst mal werde ich zwei NICs einbauen, um die Ports schön nach Interfacce zu trennen. Hält die externe NIC die Verbindung zum Provider-Gateway oder ist noch ein Router zwischengeschaltet? Ich gehe aber von ersterem aus. Auf jedenfall vernünftig. Der Server hängt (bisher) am Switch und dahinter kommt dann noch der DSL-Router. Ich bin noch am Überlegen, ob ich die beiden Verdindungen der beiden NICs einfach mit an den Switch hänge und am Router nur die Verbindung der externen NIC des Servers freigebe, oder ob ich den Server gleichzeitig als Gateway konfigurieren soll, sprich, dass an der internen NIC der Switch hängt und an der exterenen NUR der Router... Ich weiß momentan aber auch nicht, ob mein DSL-Router das kann, denn wenn ich nicht irre, muss der Router dafür eine nach innen gerichtete Default-Route definieren können!? Oder reicht es, den Server im Router als DMZ anzugeben? Weiß er dann, wo er die Daten nach innen weiter routen muss? Den SSH würde ich zum einen Und überlegen AUTH nur per Key zuzulassen und Passwort-Auth zu disablen. Ehrlich gesagt habe ich es bisher nie wirklich hin bekommen, Auth per Key vernünftig zu konfigurieren. Ich habe zurzeit im LAN zu hause beispielsweise Key-Auth. Die klappt auch, wenn der Key entsprechend freigegeben und auf dem Server ist. Wenn ich aber mit einem neuen Client (ohne Key) verbinde, kommt eine Passwort-Abfrage und nach richtigem Passwort kann ich auch einloggen - obwohl Pass-Auth doch GAR nicht gehen soll. :-\ Ich kann Euch momentan aber leider keine Config-Datei o.ä. schicken, da ich zuhause wegen meiner Umstrukturierung und einer kaputten Platte keine Mails verschicken kann. - außerdem in einem Changeroot (in meinem Home) laufen lassen. So erhälst du halt lediglich die Möglichkeit, Daten und Dienste in diesem jail zu nutzen. Wenn dir das langt, ok. Ja, das würde mir völlig ausreichen. Von außen will ich hauptsächlich an die Mails und ggf. an persönliche Daten. Mit xringd ist da sehr gut etwas zu machen. Hat die gleichen umfangreichen Möglichkeiten wie portknocking (halt Tonsequenzen statt knock key), dafür brauchst du halt nur ein Telefon/Modem/... als Client. Ich hätte eine ISDN-Karte (passiv) übrig (und freue mich dann jetzt schon auf die Konfiguration dieser mit dem 2.6er Kernel. :rolleyes: Bei meinem Vater hatte ich es mit dem 2.6er vor ein paar Monaten nicht hinbekommen) Wie du es ansprichst und auch weißt: der internen Absicherung (auch der angeschlossenen Clients) ist mindest genausoviel Aufmerksaamkeit zu schenken wie du es nach außen ins Badland betreiben willst - eher mehr. Daher die Idee, den DSL-Router ggf. nach außen zu setzen. Dann könnte ich auch mit reinem Gewissen die WLAN-Funktion dessen nutzen. Trügerisch. Es gibt sicher bessere Möglichkeiten Rechner _im_ LAN zu capturen als ein sshd. Oha! Wie denn z.B.? Hm, nur Vorsicht bei diversen IDS, daß die NICs nicht in den promiscuous mode geschaltet werden. Ok, danke! Deine Überlegungen sind IMHO ganz ausgereift. Das beruhigt mich schonmal. :-) Ich würde lediglich, wie oben angesprochen, darauf achten daß _du_ (jetzt und später) jederzeit verstehst Was Wie und Warum passiert. Vor allem wenn du verschiedene externe Konzepte einsetzt. Also lieber _ein_ gutes Schloß an der Tür als 15 verschiedene. Ok, tnx. Bzw: Was sagst Du denn zu der Thematik iptables oder nicht? -- Best regards... Ace Dahlmann
Re: Sicherheitskonzept eines neuen Servers
On Monday 21 November 2005 13:42, Ace Dahlmann wrote: [snip] Den Fortlauf des Experimentes dokumentieren? :-). Ja, ich denke, das werde ich in der Tat tun, allein schon, damit ich hinterher selber noch weiß, was ich alles beachten muss(te). Könnte eigentlich nicht schaden, es auf eine allgemeine HowTo für einen solchen Home-Server zu erweitern, oder meint Ihr, davon gibt's eh schon genug!? Egal - würde mich schon interessieren und sicherlich viele andere. Gruß, viel Erfolg -- [EMAIL PROTECTED]
Re: Sicherheitskonzept eines neuen Servers
Am Montag 21 November 2005 13:54 schrieb Ace Dahlmann: Ehrlich gesagt habe ich es bisher nie wirklich hin bekommen, Auth per Key vernünftig zu konfigurieren. Ich habe zurzeit im LAN zu hause beispielsweise Key-Auth. Die klappt auch, wenn der Key entsprechend freigegeben und auf dem Server ist. Wenn ich aber mit einem neuen Natürlich muss auf dem Server der öffentliche Schlüssel liegen. sonst kann das ganze nicht gehen. Wie soll der Server ohne pubkey was prüfen? Du müsstest halt den pubkey auf den Server packen und den geheimen Schlüssel dabei haben, wenn Du von außen an Deinen Server willst. Client (ohne Key) verbinde, kommt eine Passwort-Abfrage und nach richtigem Passwort kann ich auch einloggen - obwohl Pass-Auth doch GAR nicht gehen soll. :-\ Woran das liegt ging hier in den letzten Wochen über die Liste, ich weiß es aber nicht mehr. Gruß Chris -- A: because it distrupts the normal process of thought Q: why is top posting frowned upon
Re: Sicherheitskonzept eines neuen Servers
Ace Dahlmann: Für die internen Dienste ist das obige ja zunächst alles kein Problem. Ich würde allerdings sehr gerne von außen auf den Rechner (am Liebsten per SSH) zugreifen können, um z.B. via Shell und Mutt meine Mails zu lesen (Ich halte das für sicherer als den IMAP-Server auch nach außen hin freizugeben. Oder?) Wenn Du den sshd eh nach außen offen halten willst, ist IMAP (wie das meiste andere auch) von außen kein Thema mehr, das läßt sich ja prima tunneln (man ssh, /-L). Mache ich hier (also überall nur nicht zu Hause) auch so, damit ich nicht erst WinSCP rauskramen muß, falls tatsächlich mal ein interessantes Attachment ankommt. Mit Thunderbird geht das dann schneller. J. -- If I could have anything in the world it would have to be more money. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Sicherheitskonzept eines neuen Servers
Am Montag 21 November 2005 14:24 schrieb Christian Frommeyer: Am Montag 21 November 2005 13:54 schrieb Ace Dahlmann: snip Client (ohne Key) verbinde, kommt eine Passwort-Abfrage und nach richtigem Passwort kann ich auch einloggen - obwohl Pass-Auth doch GAR nicht gehen soll. :-\ Woran das liegt ging hier in den letzten Wochen über die Liste, ich weiß es aber nicht mehr. Wenn usePam Yes eingestellt ist, nimmt ssh immer an, man möchte mit Password sich einloggen. Ein einfache UsePam No sollte das Problem lösen. Gruß
Re: Sicherheitskonzept eines neuen Servers
On 21.11.05 13:37:44, Ace Dahlmann wrote: On Mon, 21 Nov 2005 12:15:59 +0100 Andreas Pakulat [EMAIL PROTECTED] wrote: - Für die Freigabe soll primär NFS verwendet werden, zusätzlich würde Ich kann das selbst nicht bestaetigen oder widerlegen, aber man kann an verschiedenen Stellen im Netz lesen das CIFS besser sein soll. Mit CIFS hab ich mich noch nicht befasst; da werde ich mich dann auch mal einlesen. Fuer CIFS musst du in den Linux-Clients nichts weiter machen als statt smbfs cifs zu schreiben. Achja und ein paar Optionen fallen weg, da CIFS z.B. Unterstuetzung fuer Unix User/Rechte hat. Alternativ hätte ich noch die Idee, den Server über Samba, der ja eh läuft, als PDC einzurichten und damit (also auch für die Linux-Clients) die Authentifizierung zu machen. Was ist von der Idee zu halten? Geht das ueberhaupt? Ich wuerd ja eher LDAP nehmen und den Samba-Server da mit ranknueppern. Aber ich hab sowas auch noch nie gemacht... ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. Gar keine Firewall zusätzlich? Was heisst Firewall, wenn auf dem externen NIC nur der sshd lauscht kann da nicht viel passieren, ausser eben das der sshd geknackt wird. Wenn der Server dann auch so eingerichtet ist, das nicht geroutet wird sollte das reichen. Aber ich bin kein Netzwerkspezialist, moeglich das ich da was uebersehe. Sollte ich denn ggf. auch noch die hosts.allow mit nutzen? Wenn du den Zugriff auf den externen sshd nur von bestimmten Hosts/IP Addressen erlauben willst: Ja. Oder wenn du nicht automatisch allen Rechner im LAN vertrauen willst (Stichwort: Bekannter stoepselt mal fix seinen PC ans Netz) kann das auch sinnvoll sein. ?? Weisst du wie viele Webseiten mit Apache laufen, ohne gehackt zu werden... Aber auf denen läuft wahrscheinlich kein Fileserver, der mit einem Bein im LAN und mit dem anderen im Netz steht? ;) Daher bin ich halt diesbzgl. etwas ängstlich. Das glaubts auch nur du ;-) Denk mal an die ganzen Webspace-Anbieter, da laeuft fuer den Webspace ein Apache-VHost, ein FTP-Vhost und manchmal auch noch ein sshd... Nun du kannst ja den Apachen erstmal nur fuers LAN installieren und dann spaeter wenn du dich mit dem ein wenig auseinandergesetzt hast auch fuers Netz oeffnen. Aber prinzipiell kann auch der sshd gehackt werden und dann hat derjenige Voll-Zugriff auf den Server. Andreas -- You will be married within a year, and divorced within two. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Andreas Pakulat [EMAIL PROTECTED] writes: ?? Wieso iptables? Lass die Dienste nur auf der internen NIC lauschen, das ist deutlich sicherer als irgendwelche iptables Basteleiein. kann man ntp mitlerweile auf einen bestimmten adapter festnageln? bisher war das immer mein argument fuer iptables... -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Gruesse! * Ace Dahlmann [EMAIL PROTECTED] schrieb am [21.11.05 13:54]: Hi! Zunächst mal werde ich zwei NICs einbauen, um die Ports schön nach Interfacce zu trennen. Hält die externe NIC die Verbindung zum Provider-Gateway oder ist noch ein Router zwischengeschaltet? Ich gehe aber von ersterem aus. Auf jedenfall vernünftig. Der Server hängt (bisher) am Switch und dahinter kommt dann noch der DSL-Router. Ah, der Router wäre also der Angriffspunkt. Und es ist dein Heim-Netzwerk, zu dem du nur ab und an von außerhalb an dein Home bzw. deine Mail im Home per ssh ran willst. Sonst hast du definitiv nicht vor, andere Dienste ins Internet anzubieten? Dann... Ich bin noch am Überlegen, ob ich die beiden Verdindungen der beiden NICs einfach mit an den Switch hänge und am Router nur die Verbindung der externen NIC des Servers freigebe, würde ich wahrscheinlich dies tun. Und da nur zu Port 22 (sshd). oder ob ich den Server gleichzeitig als Gateway konfigurieren soll, sprich, dass an der internen NIC der Switch hängt und an der exterenen NUR der Router... Ich weiß momentan aber auch nicht, ob mein DSL-Router das kann, denn wenn ich nicht irre, muss der Router dafür eine nach innen gerichtete Default-Route definieren können!? Oder reicht es, den Server im Router als DMZ anzugeben? Weiß er dann, wo er die Daten nach innen weiter routen muss? Mit Routing würde das IMHO sicher gehen, würde aber dem DMZ Prinzip widersprechen, innere und äußere Dienste physikalisch und logisch zu trennen. Dein Rechner in der DMZ wäre aber gleichzeitig Server für Clients im LAN und (per sshd) fürs Badland. Den SSH würde ich zum einen Und überlegen AUTH nur per Key zuzulassen und Passwort-Auth zu disablen. Ehrlich gesagt habe ich es bisher nie wirklich hin bekommen, Auth per Key vernünftig zu konfigurieren. Ist dann sicher ein seperates Problem, zu dem es auch genügend Doku gibt. Deinen Public Key mußt du dann halt immer dabei haben. Mit xringd ist da sehr gut etwas zu machen. Hat die gleichen umfangreichen Möglichkeiten wie portknocking (halt Tonsequenzen statt knock key), dafür brauchst du halt nur ein Telefon/Modem/... als Client. Ich hätte eine ISDN-Karte (passiv) übrig (und freue mich dann jetzt schon auf die Konfiguration dieser mit dem 2.6er Kernel. :rolleyes: Bei meinem Vater hatte ich es mit dem 2.6er vor ein paar Monaten nicht hinbekommen) xringd geht (vons Haus aus) IMHO auch mit Modems (serial connections). Nachtrag zu dem Gedanken mit xringd etc. von fremder Hardware daheim Dienste zu starten: z.B. bei einfachem Telefonnummer+Keynummern nicht vergessen, dieses z.B. aus der Wahlwiederholung rauszunehmen. Nichts ist peinlicher seine Spuren in irgendwelchen Historys für die Nachwelt zu erhalten ;-) Wie du es ansprichst und auch weißt: der internen Absicherung (auch der angeschlossenen Clients) ist mindest genausoviel Aufmerksaamkeit zu schenken wie du es nach außen ins Badland betreiben willst - eher mehr. Daher die Idee, den DSL-Router ggf. nach außen zu setzen. Dann könnte ich auch mit reinem Gewissen die WLAN-Funktion dessen nutzen. Trügerisch. Es gibt sicher bessere Möglichkeiten Rechner _im_ LAN zu capturen als ein sshd. Oha! Wie denn z.B.? Ich meinte damit, _wenn_ ein Angreifer auf deinen Server gelangt dann kann er wie ein normaler Client agieren (z.B. nfs, smb, eigene Dienste starten, ...) Ich würde lediglich, wie oben angesprochen, darauf achten daß _du_ (jetzt und später) jederzeit verstehst Was Wie und Warum passiert. Vor allem wenn du verschiedene externe Konzepte einsetzt. Also lieber _ein_ gutes Schloß an der Tür als 15 verschiedene. Ok, tnx. Bzw: Was sagst Du denn zu der Thematik iptables oder nicht? Das alte Thema personal firewalls... ;-) Du kannst definitiv darauf verzichten wenn kein Dienst von außen zu erreichen ist. Kein lauschender Dienst am Port = kein Angriff. Beim sshd willst du ja von außen zugreifen können, also würdest du diesen in einer FW-Konfig auch öffnen. Aber: würdest du Rolläden an Außenwände setzen wo gar keine Fenster sind? Sich um die vernüftige Absicherung der Server/Clients zu kümmern ist wesentlich sicherer, als sich auf eine vermeintlich mit der Anzahl der bunten Bilder oder der Regeln steigende Abwehr zu verlassen. Außerdem: deine Firewall-Konfig findet doch auf dem Router statt? Eine zusätzliche auf dem Server wäre unsinnig. Ich finde allerdings die Logging-Möglichkeiten bei z.B. iptables hilfreich, um z.B. Art, Zeitpunkt und Häufigkeit diverser Zugriffe zu protokollieren um diese dann ggf. mit Auffälligkeiten im LAN zu kombinieren. Sinnvoll als Sicherheit auch, um z.B. _vom_ LAN nur bestimmte Dienste z.B. zum Server bzw. ins Internet zuzulassen. Wichtig IMHO weil z.B. vermehrt Trojaner über legale Dienste (mail) ins LAN geschleppt werden. Und wenn jetzt die FW so konfiguriert ist: von Innen nach außen alles erlauben, dann gute Nacht. Obwohl wir von außerhalb ja nie
Re: Sicherheitskonzept eines neuen Servers
Ace Dahlmann schrieb: Hi! Hallo!. On Mon, 21 Nov 2005 12:21:24 +0100 Matthias Haegele [EMAIL PROTECTED] wrote: MTA - Postfix (kann ich nur empfehlen). Bisher war ich Exim-Fan. Ohne einen Glauben-Krieg auszulösen: Was hätte welche Vorteile? Ich kenne Exim ausser in der rudimentären Debian-Grundkonfiguration nicht ... Je mehr ich Postfix kennenlerne umso besser gefällt es mir, der Einstieg ist aber imo trotzdem nicht trivial (Habe nie Sendmail benutzt :-)) aber der Aufwand lohnt sich. Postfix bietet sehr viele wirksame Antispammassnahmen was mir persönlich wichtig ist. Externe Applikationen wie AMAVISD-NEW oder Scripte lassen sich einfach einbinden. Aber wenn du Exim beherrscht warum nicht ... Bin kein Fanatiker. Wenn Exim deinen Ansprüchen genügt und alles umsetzen kann was du benötigst. AMAVISD-NEW - clamav?. Ich hatte auf meinem damaligen ISDN-Gateway-Firewall-Mail-Proxy-Server Antivir für Linux insalliert. Ich denke, ich werde es wieder nehmen. Die kommerzielle Ver?. Hab bisher auch nur gutes gehört. Ok. dann AMAVISD-NEW -clamav, antivir kann nicht schaden :-). Ja, ich denke, das werde ich in der Tat tun, allein schon, damit ich hinterher selber noch weiß, was ich alles beachten muss(te). Könnte eigentlich nicht schaden, es auf eine allgemeine HowTo für einen solchen Home-Server zu erweitern, oder meint Ihr, davon gibt's eh schon genug!? Doku kanns nie genug geben ... @all: BTW: Kann man Thunderbird abgewöhnen davon auszugehen dass ich bei Neuanlage eines Mail-Kontos per HTML-senden möchte? ---grrr. Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo!. Ich weiß momentan aber auch nicht, ob mein DSL-Router das kann, denn wenn ich nicht irre, muss der Router dafür eine nach innen gerichtete Default-Route definieren können!? Gerade mit den Schlagworten wie DMZ wäre ich bei billigen Routern sehr vorsichtig die Realität ist nicht immer das was das Marketing anpreist ... Best regards... Ace Dahlmann Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
Hallo Andreas, * Andreas Pakulat schrieb [21-11-05 15:25]: On 21.11.05 13:37:44, Ace Dahlmann wrote: Alternativ hätte ich noch die Idee, den Server über Samba, der ja eh läuft, als PDC einzurichten und damit (also auch für die Linux-Clients) die Authentifizierung zu machen. Was ist von der Idee zu halten? Geht das ueberhaupt? Ich wuerd ja eher LDAP nehmen und den Samba-Server da mit ranknueppern. Aber ich hab sowas auch noch nie gemacht... Kann ich nur empfehlen. Windows und Linux-Login k�nnen �ber LDAP abgedeckt werden. Desweiteren auch noch Sachen wie Email etc. Aber auf denen läuft wahrscheinlich kein Fileserver, der mit einem Bein im LAN und mit dem anderen im Netz steht? ;) Daher bin ich halt diesbzgl. etwas ängstlich. Das glaubts auch nur du ;-) Denk mal an die ganzen Webspace-Anbieter, da laeuft fuer den Webspace ein Apache-VHost, ein FTP-Vhost und manchmal auch noch ein sshd... Nun du kannst ja den Apachen erstmal nur fuers LAN installieren und dann spaeter wenn du dich mit dem ein wenig auseinandergesetzt hast auch fuers Netz oeffnen. Aber prinzipiell kann auch der sshd gehackt werden und dann hat derjenige Voll-Zugriff auf den Server. Und das ist der Grund, warum man sensible Daten nicht auf einen Rechner legt, der direkt aus dem Internet zugreifbar ist. Mit freundlichen Gr��en Udo M�ller -- ComputerService Udo M�ller Tel.: 0441-36167578 Sch�llkrautweg 16 Fax.: 0441-36167579 26131 Oldenburg [EMAIL PROTECTED] Mobil: 0162-4365411 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Sicherheitskonzept eines neuen Servers
On Mon, 21 Nov 2005 20:52:58 +0100, Matthias Haegele [EMAIL PROTECTED] wrote: Postfix bietet sehr viele wirksame Antispammassnahmen was mir persönlich wichtig ist. Externe Applikationen wie AMAVISD-NEW oder Scripte lassen sich einfach einbinden. Aber wenn du Exim beherrscht warum nicht ... Bin kein Fanatiker. Grundsätzlich kann exim mehr als Postfix, erfordert aber aufgrund der größeren Flexibilität mehr Auseinandersetzung mit der Dokumentation. Das Design von Postfix ist moderner, exim ist halt immer noch ein großer suid-Monolith mit single mail queue. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
