Archiv verlassen und diese Seite im Standarddesign anzeigen : [Root Server] Auskunft
Guten Tag
Nach 4 Jahren als Linuxuser denke ich es ist an der Zeit das ich mich an einen Root Server wagen kann.
Ich bin mit der Allgemeinen Verwaltung vertraut sowie mit dem Kernel Konfigurieren und Installieren. Das einzige wo ich noch bisschen wenig Wissen hab sind IPTabels.
Meine Frage: Ich habe die Wahl zwischen Debian und SuSE, an sich würde ich gerne Debian nehmen aber was mir dort fehlt ist die Firewall welche nicht standard mässig "installiert" ist wie bei SuSE.
Mir ist bewusst das eine Firewall viele Konzepte in sich vereint und es nicht einfach nur Ports-Schliessen ist.
Auf dem Server würde ein Apache, MySQL, Rails und vlt. noch ein Gameserver laufen. Daher biete ich schon wenige Dienste an, was die Lücken im System an sich schon mal geringer hält.
Nun frage ich mich ob meine Fähigkeiten reichen für den Server verwalten, Logfiles und co. sind kein Problem zum durchstöbern. Was mich mehr interessiert ist, ob ich mit IPTabels und nem sauberen SSH-Zugang genug sicherheit habe auf dem Server oder ob ich noch zuerst in anderen Gebieten mir Wissen anreichern sollte.
Danke im Vorraus!
Mal wieder eine Philisophie-Frage.
"Gute konfigurierte Dienste brauchen keine Firewall" <-> "Firewall als generelle Kontrollinstanz"
Ich würde sagen - mit 4 Jahren solltest Du die Basics beherrschen und wenn Du dir der Gefahren bewusst bist sollte es eigentlich machbar sein...
Hi,
ein Root-Server ist ja meistens ein Rechner, der Dienste im Internet anbieten soll. Da ist kein lokales Netz, keine DMZ oder ähnliches. Also braucht man da theoretisch auch keinen Paketfilter.
Du solltest dafür soren, dass nur Dienste laufen, die auch laufen müssen. Alles unnötige wird abgeschaltet. Wo kein Port offen ist, kann auch nichts missbraucht werden. Das einzigste Problem sind die Dienste, die du anbieten musst/willst. Bei denen musst du "nur" dafür sorgen, dass sie sicher eingerichtet sind und alle sicherheitsrelevanten Updates eingespielt werden.
Es gibts zwar so Tricks mit iptables, um Angreifer auszusperren (z.B. bei SSH Bruteforce-Attacken). Wenn SSH aber sicher eingerichtet ist, ist das nur "Hintergrundrauschen" und es genügt, das Vorgehen zu beobachten.
Just my 2 cents ...
Ich würde sagen - mit 4 Jahren solltest Du die Basics beherrschen und wenn Du dir der Gefahren bewusst bist sollte es eigentlich machbar sein...
Naja ich habe auch 6 Monate in Kellen nen Server betrieben, der war an sich auch offen am Netz und hatte nie was. :rolleyes:
Aber ich kenne es gut genug was Zombierechner für ne schweinerei sind und ich will dem Netz ja nicht noch einen neuen dazu geben.
ein Root-Server ist ja meistens ein Rechner, der Dienste im Internet anbieten soll. Da ist kein lokales Netz, keine DMZ oder ähnliches. Also braucht man da theoretisch auch keinen Paketfilter.
Da sehe ich den Vorteil da ich wenig Dienste laufen lasse und ich werde sicher nicht auf die Idee kommen einen Gameserver als Root auszuführen. ;-)
Und das System U2D zu halten ist mit Debian oder SuSE ja auch nicht alle Welt. Auch wenn es mir irgendwie graust nen neuen Kernel auf einen Server zu installieren der nicht in meiner Nähe steht.:rolleyes:
Es gibts zwar so Tricks mit iptables, um Angreifer auszusperren (z.B. bei SSH Bruteforce-Attacken). Wenn SSH aber sicher eingerichtet ist, ist das nur "Hintergrundrauschen" und es genügt, das Vorgehen zu beobachten.
Bin gerade nicht sicher, abre ich glaube es gibt ja die Funktion das nur gewisse IP's per SSH drauf kommen, und da ich eh eine feste IP habe kann ich das so sicher noch bisschen sicherer machen. Und halt das sonstige Anmelden per Root verbieten.
Du solltest dafür soren, dass nur Dienste laufen, die auch laufen müssen. Alles unnötige wird abgeschaltet. Wo kein Port offen ist, kann auch nichts missbraucht werden.
Wenn es jemand beispielsweise jemand schafft, durch eine Sicherheitslücke in der Webapplikation einen Telnet-Server hochzuladen (oder auf einem anderen Weg), ist dieser sofort lauffähig, da ihn keine Firewall daran hindert, zu kommunizieren.
Ich halte einen Paketfilter auch nicht für notwendig, jedoch würde ich solch einen implementieren, um die Sicherheit zu erhöhen.
Ich habe die Wahl zwischen Debian und SuSE, an sich würde ich gerne Debian nehmen aber was mir dort fehlt ist die Firewall welche nicht standard mässig "installiert" ist wie bei SuSE.
Man sollte schon wissen, was der Paketfilter eigentlich durchlässt und was nicht. Was SuSe da "einfach installiert", würde ich nicht nehmen.
Da du so wenig Dienste wie möglich laufen lassen willst, hast du noch einen weiteren Grund, Debian zu nehmen.
Bin gerade nicht sicher, abre ich glaube es gibt ja die Funktion das nur gewisse IP's per SSH drauf kommen, und da ich eh eine feste IP habe kann ich das so sicher noch bisschen sicherer machen. Und halt das sonstige Anmelden per Root verbieten.
Genau deshalb würde ich den Einsatz einer Personal Firewall auch zum Erweitern des Sicherheitskonzeptes ansehen.
Ein Angreifer sucht sich in der Regel einen Server, den er schnellstmöglich kompromittieren kann, d.h. mit möglichst wenig Aufwand.
Da es ja zum Glück (für den Angreifer) genug Root-Server gibt, die von Leuten betrieben werden, die überhaupt keine Ahnung habe, wird er sich sowieso meistens weiter auf die Suche machen und deinen Server in Ruhe lassen.
Ich halte einen Paketfilter auch nicht für notwendig, jedoch würde ich solch einen implementieren, um die Sicherheit zu erhöhen.
Es würde an sich wie gesagt ein Apache laufen wo 2-3 Homepages welche mit Rails (bzw. Ruby on Rails) gemacht wurden gehostet werden. Das dies ein Sicherheitsloch ist, ist mir Vorneweg schon klar. Daher werde ich wohl wie du sagtest einen Paketfilter einrichten.
Man sollte schon wissen, was der Paketfilter eigentlich durchlässt und was nicht. Was SuSe da "einfach installiert", würde ich nicht nehmen.
Ich traue SuSE auch sonst irgendwie nicht, ich hatte schon zu schlechte Erfahrungen, so à la IPv6 und die Firewall geht grundlegend nicht und das nach einer frischen Installation.
Da du so wenig Dienste wie möglich laufen lassen willst, hast du noch einen weiteren Grund, Debian zu nehmen.
Bei Debian stört mich bisschen das Updatesystem. Bzw. Die sind nicht mehr gerade die schnellsten. Und 1 Monate warten bis sie einen gepatchten Kernel anbieten finde ich nicht gerade Vorteilhaft. Und wo oben gesagt, den Kernel selber machen finde ich gefährlich. Ich hab mir zwar seit 2 Jahren keinen Kernel mehr verschossen aber Murphy sagt gerne mal hallo.:ugly:
Ein Angreifer sucht sich in der Regel einen Server, den er schnellstmöglich kompromittieren kann, d.h. mit möglichst wenig Aufwand.
Da es ja zum Glück (für den Angreifer) genug Root-Server gibt, die von Leuten betrieben werden, die überhaupt keine Ahnung habe, wird er sich sowieso meistens weiter auf die Suche machen und deinen Server in Ruhe lassen.
Ok, das stimmt. Naja ich werde mir wohl mal noch bevor ich das Ganze abwickle ein Konzept aufzeichen was alles getan werden muss und frage dann nochmals hier nach.
baumgartner
19.09.06, 11:30
Es würde an sich wie gesagt ein Apache laufen wo 2-3 Homepages welche mit Rails (bzw. Ruby on Rails) gemacht wurden gehostet werden. Das dies ein Sicherheitsloch ist, ist mir Vorneweg schon klar. Daher werde ich wohl wie du sagtest einen Paketfilter einrichten.
Wie wärs wenn du das ganze in einen Container einsperrst?
EDIT: http://www.linuxforen.de/forums/showthread.php?t=221304&highlight=Container
Wie wärs wenn du das ganze in einen Container einsperrst?
Meinst du mit Virtualisierung?
können auch "nur" Jails sein...
können auch "nur" Jails sein...
Jails sagt mir jetzt nur unter FreeBSD etwas.:rolleyes:
baumgartner
19.09.06, 11:42
Ich hab mal einen Link nachgetragen.
Jail heißt Gefängnis, und in diese Kategorie würde dann auch chroot(uid) fallen ;)
Einwurf:
Wenn es jemand beispielsweise jemand schafft, durch eine Sicherheitslücke in der Webapplikation einen Telnet-Server hochzuladen (oder auf einem anderen Weg), ist dieser sofort lauffähig, da ihn keine Firewall daran hindert, zu kommunizieren.
Ich halte einen Paketfilter auch nicht für notwendig, jedoch würde ich solch einen implementieren, um die Sicherheit zu erhöhen.
Dann nutzt dir der Paketfilter aber auch nichts mehr, außer du filterst direkt nach Applikation ( ist das so ohne weiteres möglich bei iptables? ).
Der CCC hat dazu einen sehr sehenswerten (Video)beitrag [1]. Dort wird zwar nur auf die gängigen Windows-Firewalls eingegangen, die Grundproblematik bleibt jedoch gleich - man kann die Daten auch einfach über beliebige freigegebene Ports rausschleusen ( und Port 80 sollte bei einem Webserver offen sein ;) ). Zwar nicht über die im Artikel beschriebenen Methoden, aber prinzipiell sollte es möglich sein.
Mit etwas Pech findet man vielleicht auch mal wieder eine DoS-Lücke in Iptables und man hat seinen Spaß ;)
Wer also bereits ein Programm eingeschleust hat und unbedingt Daten möchte wird ohne Weiteres auch Daten rausschleusen können, genügend kriminelle Energie mal vorausgesetzt. Der Rest lässt sich per iptables zugegebenermaßen vermutlich schnell abschrecken. Ist halt die Frage ob man diesen Weg gehen möchte oder lieber direkt bei den Diensten ansetzt ( z.B. über chroot jails & co. ).
-hanky-
[1] http://ulm.ccc.de/ChaosSeminar/2004/12_Personal_Firewalls
edit: Chroot Jails wurden ja schon genannt. Da war ich mal wieder zu langsam :ugly:
Mit etwas Pech findet man vielleicht auch mal wieder eine DoS-Lücke in Iptables und man hat seinen Spaß
Naja, ich würde mal nicht gleich übertreiben.
Lücken gibt es in jeder Personal Firewall, denn wenn sie alle Ports schließen würde, könnte man auch gleich das Netzwerkkabel ziehen.
Ausgehend kann man auch nicht allzuviel tun. Denn außgehende Verbindungen wird ein Angreifer wohl immer etablieren können, sofern er nicht gefilterte Ports kennt.
Trotzdem macht der Paketfilter den Server meiner Meinung nach immer noch sicherer. Das es weitaus wichtigere Dinge gibt, wie z.B. das Absichern der einzelnen Dienste, die laufen sollen, bezweifle ich auch gar nicht.
Naja, ich würde mal nicht gleich übertreiben.
Lücken gibt es in jeder Personal Firewall, denn wenn sie alle Ports schließen würde, könnte man auch gleich das Netzwerkkabel ziehen.
Ausgehend kann man auch nicht allzuviel tun. Denn außgehende Verbindungen wird ein Angreifer wohl immer etablieren können, sofern er nicht gefilterte Ports kennt.
Trotzdem macht der Paketfilter den Server meiner Meinung nach immer noch sicherer. Das es weitaus wichtigere Dinge gibt, wie z.B. das Absichern der einzelnen Dienste, die laufen sollen, bezweifle ich auch gar nicht.
Ich will einen Paketfilter auch nicht generell schlechtreden, das war nicht meine Absicht ( auch wenn es vermutlich so rüber kam ) - ich setze iptables selbst auf dem Laptop ein. Es kommt zudem immer auf das Szenario an.
Im konkreten Fall jedoch halte ich die Devise "Alle Dienste weg die nicht benötigt werden" in Verbindung mit einer chroot Jail für völlig ausreichend - inwiefern ein Paketfilter ein hier einen Sicherheitsgewinn darstellen soll kann ich ehrlich gesagt nicht nachvollziehen.
Er schadet vermutlich nicht, die Gefahr einer DoS-Attacke auf den Paketfilter halte ich momentan für eher gering, aber man benötigt ihn auch nicht und kann sich den Konfigurationsaufwand auch sparen.
Einen möglichen Einsatzzweck sehe ich höchstens als Hilfsmittel gegen Bruteforce-Attacken auf den SSH-Server. Aber das würde ich nur im akuten Fall machen, oft reicht ja bereits das Umlegen des SSH-Ports um die Anzahl der Attacken wirksam einzuschränken.
Aber das handhabt/sieht jeder anders :)
-hanky-
baumgartner
19.09.06, 14:15
Aber das handhabt/sieht jeder anders :)
-hanky-
Ich handhabe das genau so wie du ;)
Iptables verwende ich auf Servern nur für fail2ban, ansonsten gehört eine FW wohl eher auf einen Router.
Iptables verwende ich auf Servern nur für fail2ban, ansonsten gehört eine FW wohl eher auf einen Router.
iptables ist auch keine klassische Firewall wie du sie meinst, sondern nur ein Paketfilter bzw. ein Teil einer Personal Firewall, da eine solche meist noch einen Prozessfilter integriert.
Wenn es jemand beispielsweise jemand schafft, durch eine Sicherheitslücke in der Webapplikation einen Telnet-Server hochzuladen (oder auf einem anderen Weg), ist dieser sofort lauffähig, da ihn keine Firewall daran hindert, zu kommunizieren.
Wenn niemand den Portrange ab 22 abgeschnitten hat. Allerdings habe ich
dieses Feature noch nie probiert.
Ich halte einen Paketfilter auch nicht für notwendig, jedoch würde ich solch einen implementieren, um die Sicherheit zu erhöhen.
+ mod_security, snort
Man sollte schon wissen, was der Paketfilter eigentlich durchlässt und was nicht. Was SuSe da "einfach installiert", würde ich nicht nehmen.
Warum nicht? Ich meine, selbst habe ich die SuSE FW auch häufig ausgestellt,
aber vielleicht ist die erstmal gar nicht schlecht. Besser erstmal ansehen, statt gleich in die Tonne. btw. nutzt hier schon wer nativ IPV6?
Ein Angreifer sucht sich in der Regel einen Server, den er schnellstmöglich kompromittieren kann, d.h. mit möglichst wenig Aufwand.
s/Angreifer/Kiddie/
Da es ja zum Glück (für den Angreifer) genug Root-Server gibt, die von Leuten betrieben werden, die überhaupt keine Ahnung habe, wird er sich sowieso meistens weiter auf die Suche machen und deinen Server in Ruhe lassen.
Das würde ich so auch nicht unterschreiben.
Hallo,
meiner Meinung nach macht ein Paketfilter, der vor allem auch Verbindungen nach aussen verhindert, durchaus Sinn. Man bedenke folgendes Szenario:
1. Angreifer findet Lücke in Webapplikation/Webserver.
2. Es gelingt ihm, Code auf die Maschine einzuschleusen, welchen er dann mit den Rechten des Webservers ausführen kann.
3. Dieser Code baut dann eine Verbindung zu einem entfernten Rechner auf (connect-back shell, bouncer, Warez-FTP, sucht euch was aus).
Problem 1 und 2 läßt sich mit Applikationsspezifischen Einstellungen/Updates/Code Audits soweit möglich vermeiden. Ist jedoch Hürde 2 genommen, gibt es eine praktikable Lösung:
Ich habe dieses Problem damit umgangen, dass ich für den Webserver-User (bei mir www) keinerlei weitere Verbindungen nach aussen zulasse (außer Port 80, welcher sowieso als root gebunden werden muss). Unter FreeBSD mit ipfw2 ist das sehr einfach zu implementieren, mit netfilter/iptables muss es diese Möglichkeit doch ebenfalls geben, oder?
Fazit: Ein Paketfilter macht als _zusätzlicher_ Layer durchaus Sinn, sofern er denn auch Verbindungen vom Server nach außen filtert. Filtert er nur in Eingangsrichtung, ist es m. E. fast schon Geschmackssache (stören mich die 1000 Loginversuche bei SSH oder nicht?).
Gruß,
emwe
mit netfilter/iptables muss es diese Möglichkeit doch ebenfalls geben, oder?
Hi, das wäre sehr interessant. Hat jemand sowas in der Art im Einsatz? Ich wüsste nicht, wie iptables in solche Ebenen vordringen soll und einen User erkennen kann.
s/Angreifer/Kiddie/
Jaja, bin ich auch für.
Das würde ich so auch nicht unterschreiben.
Schau dir doch mal im Forum die ganzen Rootserver-Threads an. Die Leute wissen nicht mal, "was sie bei Putty eingeben müssen" oder verwalten ihrer User mit yast, da ihnen grundlegendes Wissen der Kommandozeile fehlt.
Sicherheit? "Kein plan was man da machen kann^^" <- so ähnlich hat es letztens jemand irgendwo geschrieben.
Warum nicht? Ich meine, selbst habe ich die SuSE FW auch häufig ausgestellt,
aber vielleicht ist die erstmal gar nicht schlecht. Besser erstmal ansehen, statt gleich in die Tonne. btw. nutzt hier schon wer nativ IPV6?
Du hast nicht verstanden, was ich sagen wollte. Ein Systemadministrator sollte darüber Bescheid wissen, wie sein Paketfilter arbeitet und filtert. Wie kann er das wissen, wenn er eine fertige Implementierung nutzt? Das diese unsicher ist, habe ich nicht gesagt - mir würde jedoch der Gedanke nicht gefallen, dass ich nicht 100%ig weiß, was nun gefiltert wird und was nicht.
Du hast nicht verstanden, was ich sagen wollte. Ein Systemadministrator sollte darüber Bescheid wissen, wie sein Paketfilter arbeitet und filtert. Wie kann er das wissen, wenn er eine fertige Implementierung nutzt? Das diese unsicher ist, habe ich nicht gesagt - mir würde jedoch der Gedanke nicht gefallen, dass ich nicht 100%ig weiß, was nun gefiltert wird und was nicht.
Deswegen soll man sich die Regeln ja ansehen. Um einen Vergleich zu verwenden, was ich meine, viele wollen ihre eigenen Verschlüsslungsroutinen
schreiben, und diesen Leuten wird schliesslich auch gesagt, sie sollen erstmal
bestehende Konzepte übernehmen, weil die Gefahr gross ist was zu übersehen. In diesem Sinne sind die SuSE Firewalls sicher ausgereifter als
eine zuerst selbst erstellte Firewall.
Da stimme ich dir zu, jedoch geht es hier um einen Root-Server. Jemand der sich einen Root-Server mietet, sollte solche Grundlagen drauf haben.
nutzt hier schon wer nativ IPV6?
Nicht nativ, aber über einen statischen Tunnel hat mein Root eine quasi native IPv6 Konnektion. :ugly:
Ich finde einen Paketfilter nicht so zwingend notwendig, wenn die Dienste richtig konfiguriert sind. Ich setzte aber dennoch auf eine recht strikte Paketfilterung, die auch den ausgehenden Verkehr stark einschränkt, weil es einfache eine zusätzliche Sicherheit bedeutet, die im Ernstfall von Bedeutung sein kann.
Aber bevor der Paketfilter das zeigen kann, müsste schon erstmal jemand in einen laufenden Dienst einbrechen...
Hallo,
laut "man iptables:"
--uid-owner userid
Matches if the packet was created by a process with the given
effective user id.
Gruß,
emwe
Hallo,
laut "man iptables:"
--uid-owner userid
Matches if the packet was created by a process with the given
effective user id.
Gruß,
emwe
Dürfte aber auch kein hinreichenden Schutz bieten. Mal angenommen es wird damit der Datenverkehr des Webservers gefiltert, der unter einem bestimmten User läuft,..beispielsweise wwwrun. Sollte der Webserver kompromitiert werden, und ein Angreifer seine Backdoor über den kompromitierten Server starten,.eventuell auch des Server dabei abschießen und den Port anstelle des Webservers übernehmen, so läuft seine Backdoor, oder was auch immer ebenfalls als wwwrun, was der Paketfilter so anstandslos durchlässt. Das alleine kann also nicht wirklich helfen.
Es gibt allerdings eine Erweiterung im Kernel, die den Netfilter befähigt nicht nur Paketen einer ProcessID zuzuordnen, sondern auch den zugehörigen Programmnamen und die Komandozeile, mit der es gestartet wurde aufzulösen. Damit ließe sich durchaus etwas mehr Sicherheit erreichen. An Angreifer müsste da schon sein Schadensprogramm als normale Anwendung ausgeben, die von dem Netfilter akzeptiert wird. ;)
Danke mal für die Antworte. Werde mir nächsten Monat mal den Rootserver mieten. Und schauen wie es so läuft. :rolleyes:
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.