## page was renamed from Vorlagen/Schnellstart ## Benötigte Syntaxelemente können durch Entfernen der Kommentarzeichen genutzt werden. ## Allgemeine Richtlinien zur Gestaltung von Wikiartikeln: ["Wiki/Referenz"] ## Syntaxreferenz mit Richtlinien zur Verwendung: ["Wiki/Syntax"] ## ********Wichtige Syntaxelemente zum Kopieren*********** ## {{{#!Befehl}}} ## {{{#!Text}}} ## {{{#!Hinweis}}} ## {{{#!Warnung}}} ## [[Bild(./.png,,zentriert)]] ## **************Beginn des Artikels******************* ## [[Fehlerhaft(Begründung)]] ## [[Ausbaufaehig(Begründung)]] [[InArbeit(~,otzenpunk)]] ## [[Getestet(warty,hoary,breezy)]] ## [[TableOfContents(1)]] ## Einführung ## {{{#!Wissen ## * [1]: [:Pakete installieren: Installation von Programmen] ## * [2]: [:Paketquellen freischalten: Bearbeiten von Paketquellen] ## * [3]: [:Terminal: Ein Terminal öffnen] ## * [4]: [:Editor: Einen Editor öffnen] ## * [5]: [:Programme compilieren: Pakete aus dem Quellcode erstellen] ## }}} ## = Pakete installieren = ## Freischalten der Universe-Sektion [2], hinzufügen der folgenden Paketquelle [2]: ## {{{#!Text ## }}} ## Installieren [1] der folgenden Pakete: ## * '''Paket 1''' ## = Literaturhinweise = ## Verweis auf eine bestehende Forendiskussion zum Artikel ## [[Diskussion(Threadnummer,Diskussion im Forum)]] ## [[inline:XYZ.txt]] zeigt Inhalt der angehängten Textdatei an ## [attachment:XYZ.Dateiendung] link zu Seitenanhang setzen ---- ## Die Kategorie durch Entfernen der Kommentarzeichen zuweisen! ## * ["Kategorie/Einsteiger"] ## * ["Kategorie/Emulation"] ## * ["Kategorie/GNOME"] ## * ["Kategorie/Grafik"] ## * ["Kategorie/Hardware"] ## * ["Kategorie/Installation"] ## * ["Kategorie/Internet"] ## * ["Kategorie/KDE"] ## * ["Kategorie/Kommunikation"] ## * ["Kategorie/Meeting"] ## * ["Kategorie/Messe"] ## * ["Kategorie/Multimedia"] ## * ["Kategorie/Netzwerk"] ## * ["Kategorie/Paketverwaltung"] ## * ["Kategorie/Problemlösungen"] ## * ["Kategorie/Programmierung"] ## * ["Kategorie/Server"] ## * ["Kategorie/Shell"] ## * ["Kategorie/Sicherheit"] ## * ["Kategorie/Software"] ## * ["Kategorie/Spiele"] ## * ["Kategorie/System"] ## * ["Kategorie/Wiki"] ## * ["Kategorie/Windowmanager"] ## vim:filetype=moin Kenne mich ein bisschen mit der Materie aus, und möchte deswegen auch mal meinen Senf dazugeben: 1. Die Ubuntu-Firewall-Philosophie wurde hier ja schon erklärt, dass standardmäßig Ports nur an Loopback gebunden werden, und deswegen kein Paketfilter (a.k.a. "Firewall") auf dem Rechner notwendig ist. Das ist auf jeden Fall auch logisch, obwohl es anscheinend zu abstrusen Schlußfolgerungen bei Leuten führt, die sich mit dem Thema noch nicht ausreichend beschäftigt haben. Bspw. kann man im aktuellen "Linux-User 03.2006" im Artikel "Feurige Künste" vom "selbstständigen IT-Security Consultant und Netzwerkspezialist" Jörg Harmuth folgendes lesen: Zitat: ... bietet Ubuntu keinerlei Möglichkeit zum Einrichten der Firewall. Erstaunlicherweise ändert sich das auch nach der Systemeinrichtung nicht: Die Firewall bleibt vollkommen unkonfiguriert, der Rechner somit völlig offen... Besitzer eines hinreichend sicher konfigurierten Internet-Routers mögen mit diesem Zustand leben können. Wer hingegen ein DSL-Modem oder vergleichbare Zugangsmethoden verwendet, sieht sich den Gefahren des Internets schutzlos ausgesetzt. und weiter: Zitat: Fazit: ... Ubuntu-Anwender haben das Nachsehen und müssen sich um ihre Sicherheit auf Firewall-Ebene selbst kümmern. Befremdlicherweise befindet sich in den von Ubuntu offiziell unterstützten Repositories auch kein grafisches Firewall-Tools - nur das Universe-Repository bietet ein solches an. Diesem nicht mehr zeitgemäßen Umstand sollten die Entwickler schleunigst abhelfen. Es ist mir total unverständlich, dass jemand sich "IT-Security Consultant und Netzwerkspezialist" nennen darf, bloß weil er sich traut, so einen Unsinn in einer "Fachzeitschrift" zu verbreiten. Aber eins sollten die Ubuntu-Entwickler dadurch lernen: Es ist einfach zeitgemäß, ein grafisches "Firewall-Tool" dabei zu haben, um "IT-Security Consultants" und andere zu befriedigen. So weit ich weiß, ist das aber für Dapper auch schon in Planung. Aber bitte, bitte, bitte nicht in die Standardinstallation packen. 2. Irgendjemand schrieb hier, Ubuntu würde iptables standardmäßig nicht installieren. Das ist falsch, es werden bloß keine restriktiven Regeln aufgestellt. 3. Auch die Behauptung, ein Paketfilter würde "kaputte Pakete" zurückweisen, und dadurch das System schützen, ist falsch. "Kaputte Pakete" werden auch ohne Filter vom Netzwerkstack verworfen, und erreichen die Anwendung (den Server) nicht. Theoretisch könnte es natürlich Fehler im Netzwerkstack geben, die durch solche Pakete getriggert werden. Das könnte aber auch im netfilter-/iptables-Modul passieren, beides gilt jedoch als relativ sicherer Code. 4. Kein Client-Programm (Web-Browser, Email-Programm, etc.) kann von Hackern aus dem Netz heraus direkt angegriffen werden. Niemals. Diese Programme sind nur dazu konzipiert, selber Verbindungen aufzubauen, und diese zu nutzen. Eine solche TCP-Verbindung zu "hijacken" und als Außenstehender zu nutzen, ist zwar theoretisch möglich, aber eindeutig nicht-trivial, und würde dann auch wohl von keiner Firewall entdeckt werden. Angriffe gegen Client-Programme laufen deswegen immer über den Payload, das was du dir (oder dein Programm sich) freiwillig runterlädt. Es gibt zwar Firewall-Systeme, die unter Umständen auch gegen sowas schützen, aber das sind dann nicht die Paketfilter, die so gerne liebevoll "Firewall" genannt werden, sondern inhaltsbezogene Proxy-Systeme (z.B. squidguard, mailserver+virenscanner, intrusion detection/prevention systeme), deren Einrichtung mindestens ein solides Wissen erfordert, und über deren Anschaffung du dann nachdenken solltest, wenn sich viele "Allesklicker" unter den Nutzern deines Netzwerks befinden. 5. Das System "unsichtbar" zu machen, indem man Pakete DROPped, ist ebenfalls nicht sinnvoll. Ein System, dass keine Ports offen hat, wie ein Standard-Ubuntu-Desktop, hat keinen einzigen Grund, "unsichtbar" zu sein. Im Gegenteil: Sendet ein System eine Verbindungsanfrage (bspw. weil es sich vor kurzem mit einem anderen System ausgetauscht hat, dass zu dem Zeitpunkt diese IP-Adresse hatte,) weiß es sofort, dass es dort keinen Dienst gibt, und bricht ab (wenn es sauber programmiert ist). Bei "unsichtbaren" Systemen versucht es dagegen noch eine halbe Ewigkeit, die Daten zuzustellen. Wenn du aber sowieso einen Dienst offen hast, bspw. ssh, dann kann keine "Firewall" der Welt diesen Port "unsichtbar" machen. "Unsichtbarmachen" kann sogar Probleme verursachen. Bspw. versuchen einige FTP- und IRC-Server, bei deinem Login eine ident-Abfrage zu machen (Port 113). Wenn dieser Port nun "unsichtbar" ist, wird dein Login verzögert, bis der Timeout kommt. Andere Probleme kannst du kriegen, wenn du wahllos ICMP-Pakete DROPst, wie es viele Windows-Firewalls machen. Dann funktioniert nämlich unter Umständen Path-MTU-Discovery nicht mehr, und Verbindungen kommen nicht mehr zustande. 6. Das mit gnustep_sndd und gdomap hab ich auch schon gelesen, kann ich auf meinem breezy-System aber nicht nachvollziehen. Im Grunde genommen müsste das dem Paketmaintainer als Bug (critical, security) gemeldet werden. Wenn die Ubuntu-Policy lautet, "keine offenen Ports nach außen", dann müssen sich die Maintainer daran halten. 7. Für Server gilt das natürlich nicht. Wer sich Samba, ssh, apache, etc. auf dem Rechner installiert, der möchte im Allgemeinen den Zugriff von außen erlauben. Wer das nicht will, (bspw. apache als Testumgebung für Webdesign,) der sollte die jeweiligen Konfigurationsmöglichkeiten nutzen, um die Server nur ans Loopback-Interface zu binden. Ist auch nicht schwieriger, als eine "Firewall" zu installieren. 8. Eine "Firewall" auf dem lokalen Rechner ist nicht einfacher, sondern erschwert die Administration noch eher, weil bei jeder Serverinstallation erstmal ne neue Regel erstellt werden muss. Das kann zu undurchschaubaren Fehlern führen, wenn man bspw. im Falle von Samba einen der Handvoll Ports vergisst. 9. Wer Serverdienste nur in seinem lokalen Netzwerk zulassen möchte, braucht in den allermeisten Fällen auch keinen Paketfilter, da er wohl meistens einen Router (Hardware oder PC) sein eigen nennt, der für ihn NAT durchführt. Der Server trägt dann eine lokale Adresse wie 192.168.0.5, die aus dem Internet überhaupt nicht zu erreichen ist, außer der Router führt Forwarding aus, dann dürfte das aber wohl beabsichtigt sein. 10. Anders sieht es evtl. aus, wenn du deine Serverdienste direkt auf dem Router ausführst. Zwar kannst du die meisten Dienste auch dort an das LAN-Interface binden, aber bei manchen ist das vielleicht nicht vorgesehen. Außerdem hast du dann selber noch eine Absicherung für den Fall, dass du das mal vergisst, und für die Minuten zwischen der Installation und der Konfiguration des Dienstes. 11. Richtig wichtig wird eine Firewall erst, wenn du entweder eigene Serverdienste aus einer DMZ heraus ins Netz anbietest, oder wenn dein internes Netz gar öffentliche IP-Adressen besitzt. Davon sollten allerdings Neulinge besser erstmal die Finger lassen und sich informieren. Ein grafisches Tool könnte in dem Fall einem Profi vielleicht helfen, die Konfiguration schneller hinzukriegen, als manuell "iptables zu hacken", sollte aber nicht die Kenntnisse über Netzwerksicherheit ersetzen. 12. Richtig sinnvoll auf einem Einzelplatzrechner ist ein Paketfilter nur, wenn du nicht die Ports, sondern die Herkunft der Pakete einschränken willst. Bspw. willst du einem Kumpel ermöglichen, deinen FTP-Server zu benutzen, oder du willst von deinem Arbeitsplatz ssh benutzen. So etwas lässt sich oft mit iptables einfacher konfigurieren, als über hosts.allow/.deny oder dienstspezifische Konfigurationsdateien. Besonders, wenn es sich um eine ganze Reihe Dienste handelt, die alle für denselben Zugang vorgesehen sind. Ist allerdings auch nur dann praktikabel, wenn keine dynamischen IP-Adressen involviert sind. Da die Möglichkeit des Adress-Spoofing besteht, sollte das jedoch niemals starke Authentifizierungsmechanismen des betreffenden Dienstes ersetzen. Gute Passwörter (oder noch besser Public-Keys) sind auch dann unverzichtbar, wenn "nur" der eigene Arbeitsplatzrechner freigegeben ist. Besser könnte es dann wohl sein, gleich auf VPN zu setzen. Denke außerdem daran, dass du bei gelegentlichem Zugriff auf deinen zu Hause befindlichen Testwebserver o.ä. auch ssh-Tunnels benutzen kannst. Hab ich noch was vergessen? Ach ja, 13. Filesharing-Tools: Diese öffnen in den meisten Fällen auch Ports nach außen, wie ja schon die Bedeutung des Wortes "Sharing" suggeriert. Dass die meisten inzwischen auch hinter einer Firewall funktionieren, liegt an einem Trick. Systeme, die hinter einer Firewall liegen, fragen einfach in gewissen Abständen ihren Server nach, ob jemand etwas von ihnen haben will, und "pushen" diese Datei dann, indem sie selber eine Verbindung zum Tauschpartner ausführen. Wenn dieser allerdings auch hinter einer Firewall sitzt, funktioniert das nicht, so dass man als Filesharer hinter einer Firewall heutzutage doch ziemlich eingeschränkt ist. BitTorrent bestraft dich dafür sogar mit geringerer Downloadrate. Deswegen öffnen viele Filesharer die Ports extra, oder stellen Forwarding auf ihrem Router ein. Solltest du also auf einem Einzelplatzsystem so eine Software einsetzen, aber der Qualität der Software nicht soweit trauen, dass es nur die freigegebenen Daten rausrückt, könntest du einen Paketfilter einsetzen wollen, der diese Ports für den Zugriff von außen sperrt. Dann leidest du allerdings auch unter den oben beschriebenen Nachteilen.