unstable am Internet
Hallo, ich denke derzeit darüber nach, von stable mit Backports auf unstable umzusatteln. Nun wurde auf dieser Liste ja sehr davon abgeraten, einen Rechner mit unstable direkt am Internet zu betreiben. Mangels Ressourcen will ich aber meinen Heimrechner direkt mit meinem DSL-Modem verkabeln. Gibt es eine Möglichkeit, trotzdem ausreichende Sicherheit bei der Verwendung von unstable zu erreichen? Es fallen ja ab und zu solche Sprüche wie: unstable läuft bei mir stabiler als SuSE. Heißt das, dass man mit unstable auch ungefähr die gleiche Sicherheit wie mit SuSE u.ä. kriegen kann? Wie lange dauert es i.d.R. vom Bekannt-Werden eines Sicherheitsloch bis zur Bereitstellung des Fixes in unstable? An sich will ich kaum irgendwelche Services meines Rechners von außen nutzen. Wie wäre es, wenn ich mittels iptables und Connection-Tracking alle über das Internet kommenden Kontaktierungswünsche abblocke mit Außnahme von SSH-Verbindungsversuchen? Und wenn ich ferner mittels iptables für Verbindungsanforderungen an den SSH-Port nur eine bestimmte IP-Adresse als Absenderadresse zulasse? Wenn ich vielleicht außerdem noch SSH so konfiguriere, dass nur eine Authentifizierungsmethode zugelassen ist und sich auch nur ein ganz bestimmter User per SSH einloggen kann? Was für Sicherheitslücken können dann noch zum Tragen kommen? Wie wahrscheinlich sind sicherheitsrelevante Bugs in iptables und den für Paketfilterung, Connection-Tracking usw. benötigten Kernelmodulen? Sollte ich bei gerade beschriebener iptables/SSH-Konfiguration den Kernel aus stable nehmen? SSH vielleicht auch? Wie ist die Sicherheit eines Debian unstable zu bewerten, wenn ich auch den SSH-Port mittels iptables vollkommen schließe? Viele Grüße Wolfgang
Re: unstable am Internet
On Thu, May 27, 2004 at 03:43:25PM +0200, Wolfgang Jeltsch wrote: ich denke derzeit darüber nach, von stable mit Backports auf unstable umzusatteln. Nun wurde auf dieser Liste ja sehr davon abgeraten, einen Rechner mit unstable direkt am Internet zu betreiben. Mangels Ressourcen will ich aber meinen Heimrechner direkt mit meinem DSL-Modem verkabeln. Gibt es eine Möglichkeit, trotzdem ausreichende Sicherheit bei der Verwendung von unstable zu erreichen? Da die Anwendungen ziemlich unabhängig von der Distribution sind (ob der bind9 einer bestimmten Version unter Debian oder RedHat läuft, ist völlig egal), würde ich mir darum nicht zu viele Sorgen machen. Ich würde zwar davon abraten, einen ungepatchten Windows XP-Rechner ohne Firewalls ins Internet zu hängen. Aber ein Linux-PC mit vernünftigem Regelsatz kann jederzeit ins Internet. Und ich bin schon paranoid, was Sicherheit angeht. Aber die Meinung der geschätzten Mitlister teile ich keineswegs. ;) Es fallen ja ab und zu solche Sprüche wie: unstable läuft bei mir stabiler als SuSE. Heißt das, dass man mit unstable auch ungefähr die gleiche Sicherheit wie mit SuSE u.ä. kriegen kann? Grundsätzlich gilt: jede Anwendung, die du durch die Firewall (bzw. den iptables-Regelsatz) durchlässt, musst du im Auge behalten. Lässt du nur Port 80 für den Apachen durch, musst du dich auf der entsprechenden Security-Mailingliste selbst informieren, welche Sicherheitslöcher bekannt werden. Wie lange dauert es i.d.R. vom Bekannt-Werden eines Sicherheitsloch bis zur Bereitstellung des Fixes in unstable? Einen Fix in unstable gibt es höchstens im Sinne einer neueren Version. Und wann die kommt, obliegt dem Verhalten des Paketverwalters. Bugfixes/Security-Patches gibt es bekanntermaßen nur für Woody. An sich will ich kaum irgendwelche Services meines Rechners von außen nutzen. Wie wäre es, wenn ich mittels iptables und Connection-Tracking alle über das Internet kommenden Kontaktierungswünsche abblocke mit Außnahme von SSH-Verbindungsversuchen? Und wenn ich ferner mittels iptables für Verbindungsanforderungen an den SSH-Port nur eine bestimmte IP-Adresse als Absenderadresse zulasse? Wenn ich vielleicht außerdem noch SSH so konfiguriere, dass nur eine Authentifizierungsmethode zugelassen ist und sich auch nur ein ganz bestimmter User per SSH einloggen kann? Was für Sicherheitslücken können dann noch zum Tragen kommen? Wenn in der SSH-Version keine Probleme bekannt sind, würde ich mir nicht zuviele Gedanken machen. Ich lasse bei mir auch SSH mit Pubkey zu. Wie wahrscheinlich sind sicherheitsrelevante Bugs in iptables und den für Paketfilterung, Connection-Tracking usw. benötigten Kernelmodulen? Genauso wahrscheinlich wie Verwundbarkeit in jedem anderen Modul. Aufgrund der Probleme mit der Speicherverwaltung in den letzten Kerneln, kann theoretisch jeder User-Account missbraucht werden. Schließe also alle User-Accounts, die du nicht brauchst. Auf meinen wichtigeren Servern gibt es deshalb nur den Root-Account. Ich vertrete weniger man soll nicht als root arbeiten, sondern eher man sollte keine unnötigen Accounts haben. Sollte ich bei gerade beschriebener iptables/SSH-Konfiguration den Kernel aus stable nehmen? SSH vielleicht auch? Ich persönlich nehme den aktuellsten 2.4er-Kernel. Wie ist die Sicherheit eines Debian unstable zu bewerten, wenn ich auch den SSH-Port mittels iptables vollkommen schließe? Ziemlich gut. Wie gesagt, Debian Sid/Unstable bedeutet nur zwei Dinge: 1. Niemand versorgt dich mit Bugfixes a la security.debian.org 2. Du benutzt Versionen, die vermutlich noch nicht so lange erprobt sind und Bugs enthalten können. Deine Ideen sind schon gut so. Gruß, Christoph -- ~ ~ .signature [Modified] 3 lines --100%--3,41 All -- 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: unstable am Internet
Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Wie lange dauert es i.d.R. vom Bekannt-Werden eines Sicherheitsloch bis zur Bereitstellung des Fixes in unstable? Es gibt dort keine Regel, d.h. jeder Maintainer entscheidet dies selber. Ein Maintainer kann aber auch mal im Urlaub sein oder Beruflich sehr eingebunden. Es ist dann aber auch kein Problem selber mal schnell ein neues Packet (bassierend auf dem Alten) mit einer neuen Upstream-Version zu bauen (das sollte man dann aber können). Einschlägige ML wo über aktuelle Sicherheitsprobleme informiert wird gibt es ja. An sich will ich kaum irgendwelche Services meines Rechners von außen nutzen. Wie wäre es, wenn ich mittels iptables und Connection-Tracking alle über das Internet kommenden Kontaktierungswünsche abblocke mit Außnahme von SSH-Verbindungsversuchen? Wie wäre es, wenn Du auch noch Deine Dienst so konfiguierst, dass nur SSH auf dem externen Interface lauscht und dort kein Root-Login möglich ist. Und wenn ich ferner mittels iptables für Verbindungsanforderungen an den SSH-Port nur eine bestimmte IP-Adresse als Absenderadresse zulasse? Bringt m.E. nicht wirklich mehr Sicherheit gegenüber Public Key Authentifizierung (Spoofing). Wenn ich vielleicht außerdem noch SSH so konfiguriere, dass nur eine Authentifizierungsmethode zugelassen ist und sich auch nur ein ganz bestimmter User per SSH einloggen kann? Authentifizierung über Public Key Verfahren ist sicherlich sinnvoll. Was für Sicherheitslücken können dann noch zum Tragen kommen? Unbekannte Bugs im Kernel. Wie wahrscheinlich sind sicherheitsrelevante Bugs in iptables und den für Paketfilterung, Connection-Tracking usw. benötigten Kernelmodulen? Sollte ich bei gerade beschriebener iptables/SSH-Konfiguration den Kernel aus stable nehmen? SSH vielleicht auch? Ne, aber MLs mitlesen wenn für diese Software Ubdates von Update oder Maintrainer angeboten werden und dann w.o. angegeben handeln. (Außerdem erzeugen Mischumgebungen andere Probleme.) Wie ist die Sicherheit eines Debian unstable zu bewerten, wenn ich auch den SSH-Port mittels iptables vollkommen schließe? Dienste die von außen nicht erreichbar sind, sind auch nicht von außen angreifbar, egal ob vernüftig konfiguiert oder gesperrt. -- 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)
