Systemlord_1981
Anmeldungsdatum: 18. Januar 2006
Beiträge: 67
Wohnort: /home/...
|
Hallo Leute also ich habe ssh, ftp, webmin, apache am laufen. webmin ist begrenzt auf eine ip eine firewall habe ich aber noch nicht installiert. sollte man eine installieren bzw. wie hoch ist die sicherheit von linux ansich wenn man diese dienste ohne firewall laufen hat ich muss dazu noch sagen das ich einen dyndns account habe. mein router lässt momentan nur emule(auf nem client) und apache(server http port 80 zu). ssh habe ich im router als incoming wieder deaktiviert. ist das sicher? grüsse
|
comm_a_nder
Anmeldungsdatum: 5. Februar 2006
Beiträge: 2533
Wohnort: Dresden
|
Das Problem ist doch einfach, daß wenn Du diese Dienste anbietest, Du sie auch in der Server-Firewall freischalten mußt, die Sicherheit der Dienste ansich also gleich bleibt und nicht wirklich von der Firewall abhängt. Die Firewall kann zB Dir (wenn es der Dienst nicht eh schon kann) Hilfe leisten beim Einschränken der Dienste auf bestimmte Ranges. Viel wichtiger ist die FW im Router.
|
Systemlord_1981
(Themenstarter)
Anmeldungsdatum: 18. Januar 2006
Beiträge: 67
Wohnort: /home/...
|
ok das habe ich mir auch gedacht. meine FW im router lässt wie gesagt nur emule zu nem client zu und apache zum server. ftp.... hab ich noch nicht freigegeben da ich den dienst noch auf dem server konfiguieren muss und webmin ist nur auf eine ip zugelassen alles andere wird geblockt(zumindest eingehend) ausgehend kann ich leider nicht einstellen im router
|
berndix2
Anmeldungsdatum: 22. November 2004
Beiträge: 734
|
Also, wenn Du auf Nummer sicher gehen willst, dann kannst Du den Server in eine DMZ stellen. Das setzt allerdings einen Router voraus, der das kann 😉 zum ssh: Das ist so ne Sache. ☺ Da es auch immer wieder Skripte gibt, die auf bekannte Namen setzen und versuchen ein Passwort zu "erraten". Ich habe meinen SSH-Server laufen, allerdings mit folgenden Einstellungen: * kein root Login erlaubt * keine Eindeutigen Namen, wie z.B. Andy, Fritz etc. * "ordentliche" Passwörter * Standard-Port ist nicht 22 Gruß
|
Systemlord_1981
(Themenstarter)
Anmeldungsdatum: 18. Januar 2006
Beiträge: 67
Wohnort: /home/...
|
was genau ist eine DMZ? ssh passwort ist ziemlich lange(alle). ich glaube kaum das man die mit wenig zeitaufwand knacken kann grüsse
|
Chrissss
Anmeldungsdatum: 31. August 2005
Beiträge: 37971
|
Eine DMZ ist eine "demilitarisierte Zone". Eine Erklärung findest du hier Demilitarized_Zone Tschuess Christoph
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
@berndix2 Warum sollte eine DMZ die Sicherheit verbessern? Eher verschlechter eine DMZ die Sicherheit. Bei Firewalls (ich spreche hier von richtigen (Paketfiltern)) gibt es eine DMZ wo alle Server drin stehen die eine Kommunikation mit dem Internet zu lassen sollen. Diese sind logischerweise weniger geschützt da man direkt auf diese Server aus dem Internet zugreifen kann. Ports müssen zu diesen Rechnern freigeschaltet werden. Clients z.B. Workstation von Mitarbeitern sollen logischerweise nie direkt aus dem Internet erreichbar sein. Also werden sie nicht in der DMZ gebracht, sondern meist in einem Privaten eigenen LAN. Meist hinter NAT. Eine DMZ hat meistens öffentliche IP Adressen für die Server. \––\––\––\––\––\––\–– @Systemlord_1981 Ob du eine "Firewall" brauchst oder nicht, bzw. ob du sie unkonfigurieren musst hängt davon ab ob dein Server nur im eigenen LAN erreichbar sein soll, oder auch aus dem Internet erreichbar sein soll. Da du ja sagst das du einen Router hast, und keine Ports zu dem Server weitergeleitet werden brauchst du auch keine Firewall. Wofür auch? Kann doch eh keiner auf deinen Server aus dem Internet zugreifen, du leitest ja nichts zum Server weiter! Deine Firewall Konfigurieren fällt meistens eh weg. Hab noch keinen Standard Router gesehen wo man großartig eine Firewall konfigurieren kann. Auser du baust einen eigenen Router zusammen. Wenn du aber wüstest wie das geht, wüstest du wie NAT Funktioniert und du wüstest das du dann keine Firewall brauchst. (Ist nicht böse gemeint) Das einzige was eine Firewall dir bringen kann, ist der Schutz gegen andere Rechner in deinem eigenen LAN. Und ich denke da wird es wohl keine großen Cracker bei dir geben? Oder du hast bestimmt kein Firmennetzwerk mit hunderten Leuten am laufen und musst befürchten das dort jemand versucht den Server zu Cracken? Wenn das nicht der Fall ist, brauchst du auch keine Firewall. \––\––\––\––\––\––\––-
zum ssh: Das ist so ne Sache. Smilie Da es auch immer wieder Skripte gibt, die auf bekannte Namen setzen und versuchen ein Passwort zu "erraten". Ich habe meinen SSH-Server laufen, allerdings mit folgenden Einstellungen: * kein root Login erlaubt * keine Eindeutigen Namen, wie z.B. Andy, Fritz etc. * "ordentliche" Passwörter * Standard-Port ist nicht 22
Wenn SSH vom Internet erreichbar ist. Sprich er auf seinen Router SSH so konfiguriert hat, dass Port 22 auf seinen Server weitergeleitet wird, dann stimmt das zur Hälfte. Zur Hälfte deswegen weil Punkt 2 und 4 (sorry) einfach schwachsinnig ist. Wenn er es nicht gemacht hat, und das hat er ja nicht. Kann er machen was er will, er kann root Login erlauben, und root sogar kein Passwort geben, und trotzdem kann niemand auf seinen Server zugreifen aus dem Internet. Etwas so umzukonfigurieren wie du angibst ist in seinem Fall absolut lächerlich und bringt rein gar nichts. Zum letzten Punkt. Zu einer Verschleierung trägt das ganze auch nicht bei. Da man einen Service erkennen kann, egal auf welchem Port er läuft, das trifft gerade auf SSH zu. Verbinde dich einfach mal mittels telnet auf den Port an dem SSH lauscht. Du bekommst bei SSH z.B. folgendes geliefert:
# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.1p1 Debian-7ubuntu4
Protocol mismatch.
Connection closed by foreign host. Möchtest du einen Service verschleiern so das es ausschaut als wenn dort wirklich nichts läuft, dann kannst du Port Knocking benutzen. Port Knocking werde ich jetzt aber nicht erklären und ist auch irrelevant, er bietet ja sowieso keinen Dienst zum Internet an, also wäre auch hier wieder eine Konfiguration absolut überflüssig. Wem es Interessiert kann ja bei Google danach suchen.
|
berndix2
Anmeldungsdatum: 22. November 2004
Beiträge: 734
|
Warum sollte eine DMZ die Sicherheit verbessern? Eher verschlechter eine DMZ die Sicherheit. Bei Firewalls (ich spreche hier von richtigen (Paketfiltern)) gibt es eine DMZ wo alle Server drin stehen die eine Kommunikation mit dem Internet zu lassen sollen. Diese sind logischerweise weniger geschützt da man direkt auf diese Server aus dem Internet zugreifen kann. Ports müssen zu diesen Rechnern freigeschaltet werden. Clients z.B. Workstation von Mitarbeitern sollen logischerweise nie direkt aus dem Internet erreichbar sein. Also werden sie nicht in der DMZ gebracht, sondern meist in einem Privaten eigenen LAN. Meist hinter NAT. Eine DMZ hat meistens öffentliche IP Adressen für die Server.
Ich glaube da haben wir uns mißverstanden, bzw. ich habe ihn mißverstanden. Genau das meinte ich ja. Wenn er einen Server am laufen hat, der direkt aus dem Internet ereibar ist, kann er die Sicherheit erhöhen, indem er den Server in eine DMZ stellt. Für den "Clienten", also den Desktop oder whatever ist die DMZ ungeeignet. Sorry, dass es so raus gekommen ist 😳
Wenn SSH vom Internet erreichbar ist. Sprich er auf seinen Router SSH so konfiguriert hat, dass Port 22 auf seinen Server weitergeleitet wird, dann stimmt das zur Hälfte. Zur Hälfte deswegen weil Punkt 2 und 4 (sorry) einfach schwachsinnig ist. Wenn er es nicht gemacht hat, und das hat er ja nicht.
Aber ich 😛
Etwas so umzukonfigurieren wie du angibst ist in seinem Fall absolut lächerlich und bringt rein gar nichts.
Absolut richtig! Das kommt davon, wenn man zu wortkark ist. Ich hatte es eilig und, wie ich sehe, das Anliegen nicht ganz geblickt (wer lesen kann ist klar im Vorteil)! 😳 Oh Panne!
Zum letzten Punkt. Zu einer Verschleierung trägt das ganze auch nicht bei.
Doch, aber nur, wenn die Scriptkiddies die Range 1 - 1024 scannen und Dein Port höher liegt. Zugegeben eine recht billige Maßnahme, aber alles ist besser als gar nix 🤣 I. Ü. Port Knocking ist ein recht interessanter Ansatz. An dieser Stelle muss ich mich für die Verbesserung Deiner Seits bedanken. Habe aufgrund der Hektik die eigentliche Fragestellung wohl ignoriert *schäm* Gruß
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
@berndix2: Ich bin auch der Ansicht von Sid Burn. SSH auf einem anderen Port laufen lassen ("Security by Obscurity") hält dir vielleicht die automatisierten SSH-Scans vom Hals, aber die sollten sowieso nicht in der Lage sein, dein Passwort zu erraten. Für jemanden, der sich wirklich für deinen Host interessiert, (weil er vielleicht was gegen dich persönlich hat, oder weil du interessante High-Ports offen hast, 😉 ) ist das überhaupt keine Hürde. Sinnvoller wäre, mit AllowUsers nur deinen eigenen Zugang zu erlauben, sowie Passwortzugang komplett abzuschalten und Public-Keys zu benutzen. Zufälligerweise schreibe ich gerade einen Wiki-Artikel über SSH. Der befindet sich jedoch noch auf der Baustelle, und das Kapitel über Public-Keys ist noch leer. @Systemlord_1981: So wie ich das verstanden habe, hast du Apache so laufen, dass es aus dem Internet erreichbar ist. (Port-Forwarding am Router.) Dann solltest du wirklich über die Einrichtung einer DMZ nachdenken, in der du den Server vom Rest deines Netzes trennst, vor allem wenn du beabsichtigst, dort irgendwelche PHP- oder sonstige Skriptsachen auszuprobieren. (Siehe auch Sicherheits_1x1#head-d56c51d0db9eddeabf85f8f7c11cac038ed9e93b.) Allerdings stelle ich mir die Frage: Was bezweckst du damit? Webspace, auch mit allen möglichen Skriptsprachen gibt es inzwischen an jeder Ecke für'n Appel und'n Ei. Oder ist das nur dein persönlicher Entwicklungsserver, den du ab und zu selber von außen erreichen willst? Dann würde ich eher SSH von außen zugänglich machen, und auf den Apache über einen SSH-Tunnel zugreifen. (Mehr darüber in ein paar Tagen unter obigem Link.) Webmin sollte jedenfalls auf gar keinen Fall von außen erreichbar sein. Ist es aber auch nicht, solange du nicht auf die Idee kommst, es durch den Router forwarden zu lassen.
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
Ich bin auch der Ansicht von Sid Burn. SSH auf einem anderen Port laufen lassen ("Security by Obscurity") hält dir vielleicht die automatisierten SSH-Scans vom Hals, aber die sollten sowieso nicht in der Lage sein, dein Passwort zu erraten
Ja das war es was ich sagen wollte. 😉 "Security by Obscurity" halte ich persönlich für einen schlechten weg. Etwas sollte an sich schon sicher sein, und nicht erst dadurch sicher sein das ich Informationen verberge. Natürlich "kann" SBO die Sicherheit verbessern, sollte aber kein Hauptanker sein. Ich wollte aber noch was zu den automatischen SSH Scans sagen. Diese sind in dem Sinne volkommen harmlos. Wenn du dir mal genau anschaust wie sie Funktionieren dann sieht man das sie nutzlos sind. Wenn ein SSH Server irgendwo offen ist, dann gehen sie bei jedem Versuch ein neuen Benutzernamen durch und probieren genau 1 Passwort aus. Mit 1 Versuch kann man kein Passwort erraten oder man hat extrem viel glück. Es wird da wohl auch kein Random Passwort bei solchen Skripten genommen, da es wohl fast unmöglich ist ein Passwort mit einen Versuch Random zu erraten. Die einzige Sinvolle möglichkeit wäre zu überprüfen ob kein Passwort vergeben wurde. Das einzige was solche Skripte also machen sind Standard Accounts durchzugehen und immer zu überprüfen ob kein Passwort vergeben wurde. Und selbst wenn dein Account in dieser Auswahlliste dabei ist, ist es nicht schlimm solange du ein Passwort vergeben hast. Ein Angreifer kann bei einem Fehlschlag bei einem Login nicht erkennen ob nun das Passwort falsch war, oder ob der Account überhaupt existiert. Von daher müsste ein Angreifer schon dein Account Wissen und das Passwort herausfinden. Versuch das erstmal. root nicht zu erlauben ist sehr sinvoll, weil man damit einen Standard Account ausschließt der auf jedem System existiert. Aber wie gesagt selbst wenn jemand versucht dein Root passwort Brute Force zu knacken ist es egal. Ein Angreifer sieht ja auch nicht das ein root Login nicht erlaubt ist. Selbst wenn das Passwort richtig ist, wird man zurück gewiesen. SSH also mittels erraten von Username/Passwort herauszufinden ist eigentlich ziemlich Sinnlos. Das einzige was diese Skripte machen sind das Internet zu durchsuchen nach irgendeinem SSH Zugang der kein Passwort hat. Von daher brauch man da keine Angst haben wenn seine LOG datei von solchen "Angriffen" volgemüllt wird. Und du kannst dir da auch Sicher sein das wahrscheinlich nie einer versuchen wird dein Passwort mittels Brute Force zu knacken. Warum? Weil es zu aufwendig wird. Da lässt man lieber das Skript auf andere IPs laufen bis man irgendwann erfolg hat. Und die Chance einen Account ohne Passwort zu finden, ist höher als ein Passwort mittels Brute Force zu knacken. Wer solche Methoden einsetzt ist meistens ein Script Kiddie, und hat sowieso nicht das Interesse deinen Account zu knacken, zum einen weil er es wahrscheinlich auch nicht schafft. Und wenn du es mit richtigen Crackern zu tun hast die dich wirklich angreifen wollen, dann macht das nicht viel Unterschied ob dein SSH Zugang nun auf Port 5000/2222/2204 ... läuft. Dieser wird sowieso gefunden. Solange du aber eine Private Person bist, und nicht gerade eine große Firma, oder dies ein Server ist wo wichtige Daten drauf liegen die für andere Interessant ist, wird sich da kein Cracker dran versuchen deinen Account zu cracken. Der Aufwand ist es gar nicht wert. (Man wird sowieso schneller zum erfolg kommen einfach weiter auszuprobieren bis man ein Account findet ohne passwort)
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Sid Burn hat geschrieben: Ich wollte aber noch was zu den automatischen SSH Scans sagen. Diese sind in dem Sinne volkommen harmlos.
Harmlos würde ich das nicht nennen, wenn man nachts davon geweckt wird, dass die Festplatte im Stakkato das auth.log vollrattert. 😉 Ansonsten hast du natürlich Recht. Leere Passwörter, und vielleicht noch "password" oder "Accountname" ist alles, was diese Skripte testen. Da sitzt dann auch nicht mal ein Skript-Kid hinter, sondern ein Bot. Das ist dann das "Low-Hanging-Fruits"-Prinzip. Ein Dieb stiehlt immer die Früchte vom Baum, die am tiefsten hängen. Man könnte also zynischerweise sagen, dass man als Privatanwender nicht in einem Sicherheitswettbewerb mit den Crackern steht, sondern mit den anderen potentiellen Opfern. :twisted: Anders sieht es aus, wenn man ein riesiges System mit tausenden Usern betreut. Da gibt es immer irgendwelche Leute, die einfache Passwörter wählen, wenn man sie nicht bspw. über geeignete PAM-Module daran hindert, und Brute-Force kann durchaus eine Bedrohung darstellen. P.S.: Ich wollte mich sowieso noch mal mit ipt_recent beschäftigen. Damit kann man die Anzahl der Verbindungsversuche von bestimmten Adressen limitieren.
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
Witzig ist auch knockd. Sicherheitsgewinn ist zwar nicht riesig, aber zu knocken hat einfach Stil 😉
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
Harmlos würde ich das nicht nennen, wenn man nachts davon geweckt wird, dass die Festplatte im Stakkato das auth.log vollrattert. Winken
Mein Rechner ist so schallgedämpft da höre ich keine festplatte mehr \^^
P.S.: Ich wollte mich sowieso noch mal mit ipt_recent beschäftigen. Damit kann man die Anzahl der Verbindungsversuche von bestimmten Adressen limitieren.
Das habe ich schon getan. Allerdings läuft das recent Modul nicht so einwandfrei. Wenn du ein Flood Angriff machst, oder ähnliche Sachen dann greift die Einstellen "3 Packete von dieser IP in 10sek" etc. nicht mehr und es wird alles durchgelassen. Das liegt daran das recent eine tabelle aufbaut. Bei Flood angriffe wird die tabelle zu schnell gefühlt, und es sind nichtmal mehr die gevorderten Einträge der letzten 3 Sekunden lesbar. Von daher klappt dann ein Login immer. Musst nur genug packete verschicken. Also ab einer bestimmte grenze greift recent nicht mehr. Besser ist wenn du einen Simplen Perl Daemon schreibst der die "auth.log" immer mit captured. Wenn dann mehrere Fehlversuche kommen, setzt du mit den Daemon einfach einen IPTables Befehl ab der die IP Adresse einfach für eine zeit lang sperrt. 2 oder 3 Minuten reichen aus. Oder du benutzt den "xinetd" der kann auch einen Service begrenzen. Auch so das eine IP nur maximal 1 Verbindung aufbauen kann etc. IPTables hat zwar viele nette erweiterungen, und habe mich damit schon komplett auseinander gesetzt, aber vieles machen Programme auf höheren OSI Schichten besser, anstatt einen paketfilter dazu zu benutzen.
Witzig ist auch knockd. Sicherheitsgewinn ist zwar nicht riesig, aber zu knocken hat einfach Stil
In der letzten oder vorletzten Ausgabe der hackin9 wurde Port Knocking genau erklärt, funktionsweise und Programme vorgestellt. Eines der besten Port Knocking Programme war dort Doorman: http://doorman.sourceforge.net/ Das schickt die geforderte Sequenz um den Port zu öffnen nicht einfach so über das Netz, sondern generiert noch MD5 Hashes etc. Allerdings setze ich es bei mir nicht ein, da solche Port Knocking Programme außschlißlich dann brauchbar sind, wenn du entsprechende Tools hast um solche IP/TCP/UDP etc. packete zu erzeugen. Unter Windows ist das praktisch nie der Fall, und auch nicht auf jedem Linux System ist "sendip" installiert. Und ein SSH zugang an dem ich mich nicht einloggen kann, bringt mir auch nichts.
|
Systemlord_1981
(Themenstarter)
Anmeldungsdatum: 18. Januar 2006
Beiträge: 67
Wohnort: /home/...
|
otzenpunk hat geschrieben: @berndix2: @Systemlord_1981: So wie ich das verstanden habe, hast du Apache so laufen, dass es aus dem Internet erreichbar ist. (Port-Forwarding am Router.) Dann solltest du wirklich über die Einrichtung einer DMZ nachdenken, in der du den Server vom Rest deines Netzes trennst, vor allem wenn du beabsichtigst, dort irgendwelche PHP- oder sonstige Skriptsachen auszuprobieren. (Siehe auch Sicherheits_1x1#head-d56c51d0db9eddeabf85f8f7c11cac038ed9e93b.) Allerdings stelle ich mir die Frage: Was bezweckst du damit? Webspace, auch mit allen möglichen Skriptsprachen gibt es inzwischen an jeder Ecke für'n Appel und'n Ei. Oder ist das nur dein persönlicher Entwicklungsserver, den du ab und zu selber von außen erreichen willst? Dann würde ich eher SSH von außen zugänglich machen, und auf den Apache über einen SSH-Tunnel zugreifen. (Mehr darüber in ein paar Tagen unter obigem Link.) Webmin sollte jedenfalls auf gar keinen Fall von außen erreichbar sein. Ist es aber auch nicht, solange du nicht auf die Idee kommst, es durch den Router forwarden zu lassen.
ja du hast recht. habe einen apache laufen auf dem man von aussen zugreifen kann. ist eigentlich nur ne kleine website mit ein paar dateien(darauf sollen auch ein paar freunde zugreifen können, daher wäre tunnel eine zu aufwendige lösung). iptables ist eine firewall oder? ist die bei ubuntu standardgemäss mit auf dem system drauf? das prob ist das genau in dem gleichen server ein raid läuft wo ziemlich viele daten drauf sind und es SEHR schlimm wäre wenn diese daten weg sind. würde ich mehr sicherheit haben beim apache wenn ich alle skriptsprachen deaktiviere? brauche ansich nur einfaches html. falls das mit dem apache zu riskant wäre könnte ich ihn auch wieder entfernen.
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
So funktioniert das einfach nicht ☹. Ein komplexer Serverdienst in einem WAN ist nicht wie OpenOffice starten, sondern eher sowas wie eine exotische Orchidee (was für ein Vergleich 😀). Der muß gehätschelt und gepflegt, zuallererst aber mal sicher aufgesetzt (chroot) werden. Aber auch dann heißt es logs kontrollieren, aktuell halten, Einstellungen anpassen usw. Bei iptables kann dir Harry beim Start helfen, bei Null anfangen ist echt nicht besonders lustig. Auf jedenfall verursacht ein Webserver kontinuierlich Arbeit, wenn du das nicht willst, solltest du wirklich auf einen Anbieter von Webspace zurückgreifen. Du hast eigentlich schon eine gute Übungsbasis mit einem Server zu Hause, der nichts wichtiges anbietet, allemal besser als einen dedicated in einem RZ, aber viel Arbeit bleibt es trotzdem. Kein php installiert zu haben ist schonmal top Ungültiges MakroDieses Makro ist nicht verfügbar
|