Moin, aus nicht ganz aktuellem Anlass mal die Frage: Wie viel Aufwand ist es, einen Server im Internet gegen Missbrauch zu schützen? Das heißt, dafür zu sorgen, dass der Server nicht als Spamversender oder Hackerproxy verwendet wird und über ihn keine anderen virtuellen Server oder das Rechenzentrum beeinflusst wird. Natürlich sollten auch keine Viren installiert werden können. Es geht nicht darum, die Verfügbarkeit zu garantieren und der Schutz der Daten auf dem Server ist auch nicht so wichtig. Reicht es, das einmal einrichten und jede Woche eine Aktualisierung machen oder geht es eher in Richtung jeden Tag Logdateien lesen und Konfigurationen an die neuen Bedrohungen anpassen? Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich oder kann man irgendwie so einschränken, dass es sicher ist.
Es kommt darauf am, was der Server im Internet bereitstellt. Wenn es nur eine Server mit SSH Zugang ist, braucht man sich wenig sorgen zu machen. Wenn darauf aber ein Webserver mit typo3, Wordpress und phpmyadmin usw. Läuft dann sollte man schon auf der hut sein. Auch wenn man andere Webspace anbietet, kann das schnell schief gehen.
Für einen Profi hält sich der Aufwand in Grenzen, für einen Amateur ist es fast aussichtslos. Dussel schrieb: > Reicht es, das einmal einrichten und jede Woche eine Aktualisierung > machen Das ist das Mindeste! > oder geht es eher in Richtung jeden Tag Logdateien lesen und > Konfigurationen an die neuen Bedrohungen anpassen? Je nach Situation ist das angebracht. Dussel schrieb: > Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich > oder kann man irgendwie so einschränken, dass es sicher ist. Kommt wie üblich auf das Programm, die Sprache, die Rechte, usw. an.
Was ich (natürlich) noch vergaß: Das Betriebssystem wäre wohl ein unixähnliches, wie Linux oder FreeBSD. Ich habe schon nach antworten gesucht, aber da ging es dann hauptsächlich um die Sicherstellung der Verfügbarkeit. Peter II schrieb: > Wenn darauf aber ein Webserver mit typo3, Wordpress und phpmyadmin usw. > Läuft dann sollte man schon auf der hut sein. Sowas könnte es unter Anderem sein. T.roll schrieb: > Dussel schrieb: >> Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich >> oder kann man irgendwie so einschränken, dass es sicher ist. > > Kommt wie üblich auf das Programm, die Sprache, die Rechte, usw. an. Selbstprogrammierter Webserver, eigenes Skype, Liveübertragung des Netzbaus der Zitterspinne im Kellerraum… Sowas wären Anwendungsgebiete (die Beispiele sind natürlich nicht alle ernst gemeint ;-) Also Daten empfangen, bearbeiten, weitersenden, vielleicht speichern, vielleicht gespeicherte Daten senden… (Gibt es Server mit noch anderen Aufgaben?)
Es kommt auch darauf an, wer den Server bereitstellt. Wenn das ein grosser Hoster ist, solltest du dich um Updates usw. kaum kümmern müssen, sondern das erledigt der Dienstleiter für dich. Auch Ports und Packets wird er dichtmachen und prüfen. Wenn du das selber hostest, bist du derjenige, der die Firewall nur dort aufmacht, wos gebraucht wird, und du bist auch derjenige, der die Software auf dem neuesten Stand hält und allgemein wissen muss, was er konfiguriert und was besser nicht. Edit, ahh ok, selber hosten. Na dann solltest du dich zuerst mal um die Firewall kümmern und die üblichen Verdächtigen wie telnet, ftp, tftp usw. dichtmachen, am besten alles incoming, was nicht gebraucht wird. Wenn du dann eine aktuelle Linux Distro mit aktuellem Apache installierst, wählst du aus, was du brauchst und kommst vermutlich recht sicher daher. PHP ist allerdings immer ein Einfallstor, das man am besten nur dann benutzt, wenn man es braucht und einigermassen beherrscht. Richtig benutzt, kann PHP den Server noch sicherer machen, falsch angewendet ist es eine Spielwiese für Kiddies.
:
Bearbeitet durch User
Matthias S. schrieb: > Richtig benutzt, kann PHP den Server noch sicherer machen, ? Das müsstest du mal erklären.
Es geht hauptsächlich um einen Server zum Testen. Eigene Programme, 'Webprojekte' und sowas. Ein lokaler Server reicht dafür nicht, weil es in realer Umgebung (Internet) sein soll. Es gibt für wenig Geld virtuelle Server und für viel mehr Geld managed Server. Wenn man aber danach sucht, ob sich ein managed Server lohnt und ob man den Server nicht selber einrichten kann, ist das Hauptargument (zumindest bei dem, was ich gefunden habe) immer die Verfügbarkeit. Bei einem managed Server kümmert sich im Fehlerfall sofort jemand drum. Das ist aber für mich nicht wichtig. Wichtig ist mir nur, dass nicht in meinem Namen Schaden bei anderen verursacht wird bzw. ich nicht unbeabsichtigt eine Plattform dafür liefere. Firewall, Jails, Benutzergruppen und sowas habe ich mal auf einem Server in einer virtuellen Maschine gemacht. Die Frage ist, ob das reicht, wenn man sich ein bisschen reinarbeitet. Einmal pro Woche ein Update zu machen und vielleicht bei besonderen Sicherheitslücken zu reagieren, geht. Aber ich habe keine Lust, mehr oder weniger jeden Tag dransitzen zu müssen.
Matthias S. schrieb: > Es kommt auch darauf an, wer den Server bereitstellt. Wenn das ein > grosser Hoster ist, solltest du dich um Updates usw. kaum kümmern > müssen, sondern das erledigt der Dienstleiter für dich. Aber nur als "Managed Server". Und das lässt der Hoster sich bezahlen. Dafür hast du dann aber auch nur begrenzte Möglichkeiten auf dem Server.
Dussel schrieb: > Wie viel Aufwand ist es, einen Server im Internet > gegen Missbrauch zu schützen? Das hängt ganz allgemein davon ab, wieviel Aufwand du einem Angreifer für einen erfolgreichen Angriff zumuten möchtest. Mit genug Aufwand kommt immer jemand rein, aber für hinreichend geringen Nutzen treibt keiner den Aufwand. > Das heißt, dafür zu sorgen, dass der Server nicht als Spamversender > oder Hackerproxy verwendet wird und über ihn keine anderen virtuellen > Server oder das Rechenzentrum beeinflusst wird. Wenn es dir um Datensicherheit und Verfügbarkeit auf dem Server nicht so ankommt, dann reicht es, wenn du die Kommunikation des Servers mit seiner Umwelt hinreichend einschränkst. Du kannst erstmal sämtlichen Datenverkehr blockieren und dann punktuell Löcher in die Firewall stanzen (und dich wunderbar selbst aussperren!). Außerdem solltest du ständig prüfen, ob die von dir gesetzten Regeln noch gelten. Das reduziert die Angriffsfläche und bietet ein bisschen Schadensbegrenzung. Je genauer du dein gewünschtes Kommunikationsverhalten kennst, desto gezielter kannst du es einschränken. Niemand hindert dich daran, große Teile der Welt (z.B. China, Indien, Russland, Südamerika, USA) grundsätzlich auszusperren, damit Botnetze ins Leere greifen. > Natürlich sollten auch keine Viren installiert werden können. Dagegen kannst du eigentlich nichts tun, außer dein System auf dem aktuellen Stand zu halten und möglichst wenig Angriffsfläche zu bieten. Das heißt: (a) möglichst wenig Dienste anbieten; (b) möglichst wenig Software installiert haben. Vermeide insbesondere Umgebungen, die bekannt unsicher sind (PHP, ...), die gute Ziele sind (WordPress, ...) und die eingeschleusten Code lauffähig machen können (Compiler, Interpreter). Je weniger dein System "standard" ist, desto schwieriger sind sie anzugreifen und zu administrieren (ein fehlendes /bin/sh oder ein umbenannter root-Nutzer macht vieles kaputt, auch manche Exploits). Da musst du einen Kompromiss zwischen Aufwand und Nutzen finden. > Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich > oder kann man irgendwie so einschränken, dass es sicher ist. Jedes von außen erreichbare Programm ist eine Angriffsfläche. Jedes installierte Programm ist eine potentielle Angriffsfläche. Deine eigene Software ist potentiell angreifbarer als bekannte Software. Es gibt relativ kleinteiliges Rechtemanagement (Capabilities), wenn du dich damit befassen willst. Damit kannst du z.B. Syscalls einschränken und vermeiden, dass dein Programm für bestimmte Dinge verwendet werden kann.
Dussel schrieb: > aus nicht ganz aktuellem Anlass mal die Frage: Wie viel Aufwand ist es, > einen Server im Internet gegen Missbrauch zu schützen? Kommt darauf an, wieviel Geld Du dafür ausgeben willst. Persönlich habe ich z.B. einen Server, welcher unter CentOS läuft und darauf ist das Plesk Control Panel (kommerziell, kostet was) installiert. Dieses kann so eingestellt werden, dass es automatisch Patches und Updates von sich selbst, sowie Apache, PHP, FTP, WordPress, etc. vornimmt. Damit ist der Wartungsaufwand sehr gering und das System läuft bockstabil, sofern man es nicht verbastelt. https://www.plesk.com/ Es gibt auch noch viele andere Lösungen. z.B. sei noch cPanel genannt.
Johnny B. schrieb: > Dieses kann so eingestellt werden, dass es automatisch > Patches und Updates von sich selbst, sowie Apache, PHP, FTP, WordPress, > etc. vornimmt. > Damit ist der Wartungsaufwand sehr gering und das System läuft > bockstabil, sofern man es nicht verbastelt. davon würde ich abraten, ich betreibe selber einen Server. Nach jedem Update geht irgendetwas nicht mehr. Automatisch würde ich nur Sicherheits-Patchs installieren aber mehr auch nicht. Apache hat vor 1-2 Jahren die Default ACL geändert SSH hat mal schnell einen alten Algo im Default entfernt, den ich für den zugriff auf alte System brauche VIM hat auch eine neue config bekommen die Nervig ist PowerDNS hat mal schnell die Config Parameter geändert usw.
SR schrieb: > Matthias S. schrieb: >> Richtig benutzt, kann PHP den Server noch sicherer machen, > > ? Das müsstest du mal erklären. Wollte ich gerade, aber das Forum erlaubt mir nicht, ein Beispielskript, bei der ein verborgener Webcam Aufruf drin ist, zu posten, weil da Spam drin sei. Aber du verbirgst mit PHP z.B. auch Benutzernamen und Passworte für Datenbanken.
:
Bearbeitet durch User
Matthias S. schrieb: > SR schrieb: >> Matthias S. schrieb: >>> Richtig benutzt, kann PHP den Server noch sicherer machen, >> >> ? Das müsstest du mal erklären. > Wollte ich gerade, aber das Forum erlaubt mir nicht, ein Beispielskript, > bei der ein verborgener Webcam Aufruf drin ist, zu posten, weil da Spam > drin sei. > Aber du verbirgst mit PHP z.B. auch Benutzernamen und Passworte für > Datenbanken. Was für ein schmarn. Wenn ich BN und PW für die Datenbank verberge (was heißt hier das für eigentlich) würde die DB diese ja nicht sehen. Wie soll ich die Dinge denn dann speichern wenn nicht in einer DB? Matthias S. schrieb: > bei der ein verborgener Webcam Aufruf drin ist, Are you kidding me? Ein skript, vermutlich in PHP geschrieben. Und sowas soll dann meinen Server sicherer machen? Der sicherste Server ist der, auf dem nix installiert ist und auf dem niemand was machen darf. Dann nutzt das Ding aber nix. Mit jedem Programm mache ich das Ding erstmal unsicherer. Alle darauffolgende Schritte dienen nur dazu den evtl. auftretenden Schaden zu minimieren bzw. bestimmte Schadensmöglichkeiten einzudämmen (schließen des telnet ports z.B.)
ui schrieb: > Alle > darauffolgende Schritte dienen nur dazu den evtl. auftretenden Schaden > zu minimieren bzw. bestimmte Schadensmöglichkeiten einzudämmen > (schließen des telnet ports z.B.) Übrigens habe ich genau das als erstes geschrieben, wenn du dir meinen ersten Beitrag anguckst. Beitrag "Re: Aufwand um Server gegen Missbrauch zu schützen" Sich mittendrin was rauszupicken, ist immer schön einfach, aber irreführend.
ui schrieb: > (schließen des telnet ports z.B.) der erhöht auch nicht wirklich die Sicherheit, nur wenn es user gibt sie sie darüber ein loggen. Es verhindert nur nervige Einträge im log.
SR schrieb: > Matthias S. schrieb: >> Richtig benutzt, kann PHP den Server noch sicherer machen, > > ? Das müsstest du mal erklären. Beantworte doch einfach diese Frage. Mich würde das auch brennend interessieren wie die Installation eines Programms (hier PHP) einen Server sicherer machen kann.
SR schrieb: > Matthias S. schrieb: >> Richtig benutzt, kann PHP den Server noch sicherer machen, > > ? Das müsstest du mal erklären. wahrscheinlich meint er "wenn man sich auskennt", und "kein kacknoob ist" ;-) ansonsten: https://www.google.de/search?q=php+cve Peter II schrieb: > Johnny B. schrieb: >> Dieses kann so eingestellt werden, dass es automatisch >> Patches und Updates von sich selbst, sowie Apache, PHP, FTP, WordPress, >> etc. vornimmt. > Automatisch würde ich nur Sicherheits-Patchs installieren aber mehr auch > nicht. > Apache hat vor 1-2 Jahren die Default ACL geändert > SSH hat mal schnell einen alten Algo im Default entfernt, den ich für > den zugriff auf alte System brauche > VIM hat auch eine neue config bekommen die Nervig ist > PowerDNS hat mal schnell die Config Parameter geändert typische admin aufgaben, also mecker nicht. wer admin-rechte hat, hat auch admin-pflichten. @OP: "wie mache ich einen server sicher" ist eine unsinnige frage, genau so wie "ein auto" sicher machen zu wollen. alles was eingaben entgegennimmt und verarbeitet kann hackbare bugs enthalten, und je mehr code an der datenverarbeitung beteiligt ist desto mehr bugs wird es geben. du kannst deinen server also sicherer machen indem wenig code drauf läuft, also nur das was du wirklich an prozessen brauchst. da wir nicht wissen was für dienste du im internet anbieten willst, ist es schwer konkrete tips zu geben. ich persönlich mache es so, das ich nur SSH von außen erreichbar habe, über einen nicht-std port. alle dienste die ich ansprechen will (x2go, sftp, unison, jdownloader) muss ich über diesen dienst tunneln. mehr sicherheit gegen drive by hackversuche hätte ich wenn ich port nocking für SSH verwenden würde - ist mir aber zu aufwändig/unpraktikabel.
c.m. schrieb: > SR schrieb: >> Matthias S. schrieb: >>> Richtig benutzt, kann PHP den Server noch sicherer machen, >> >> ? Das müsstest du mal erklären. > > wahrscheinlich meint er "wenn man sich auskennt", und "kein kacknoob > ist" ;-) Also ich verstehe es wirklich nicht. Der Einsatz von PHP kann - richtig angewendet vorausgesetzt - den Server vielleicht nicht unsicherer machen, aber dass der Einsatz von PHP einen Server sicherer machen soll ist doch nun völlig absurd.
Dussel schrieb: > Es geht hauptsächlich um einen Server zum Testen. Eigene Programme, > 'Webprojekte' und sowas. Ein lokaler Server reicht dafür nicht, weil es > in realer Umgebung (Internet) sein soll. > Es gibt für wenig Geld virtuelle Server und für viel mehr Geld managed > Server. Oder für kleinere Sachen kostenlos z.B. OpenShift von RedHat oder Heroku DigitalOceans Droplets wären u.U. auch eine Möglichkeit oder auch Vultr. https://www.openshift.com https://www.heroku.com/pricing https://www.digitalocean.com/products/compute/ https://www.vultr.com/pricing/
Aber um nochmal auf das Thema zurückzukommen. - Ports zu, die nicht offen sein müssen. - SSH idealerweise mit Keyfile - Alle Dienste die offen sind mit sicheren Passwörtern und Fail2Ban versehen. - Nur Sicherheitsupdates (hält sich Ubuntu 16.04 in Grenzen) - Wordpress-Installationen bekommen von mir folgendes verpasst: --> PHP-Dateien dürfen in wp-uploads/ nicht ausgeführt werden --> Plugins werden händisch verlesen und bekommen ein Gütesiegel --> automatische Updates von WP sind deaktiviert. (Das spart zum Beispiel das aktuelle 4.7-Update Debakel). Das ist aber wirklich nur zu empfehlen, wenn man auch weiß was man tut. Ich sehe die Änderungen durch und bin kein "early adopter", wenn es nicht unbedingt sein muss (Sicherheitslücken). --> xml rpc deaktivieren --> seit 4.7. auch die REST-API deaktivieren - jede Domain mit einem eigenen Nutzer - tägliche DB und htdocs Backups, die ein anderer Server zieht PHP-Konfiguration sollte man natürlich auch immer überdenken; ist exec, shell_exec, passthru, ... notwendig? allow_url_fopen? open_basedir? Falls ein Mailserver darauf läuft sollte man sich auch noch weitere Gedanken machen damit das Ding nicht zur Spamschleuder wird und man dort nur schwer wieder rauskommt. Diese Liste ist nicht vollständig und ändert sich auch regelmäßig - je nachdem was man eben tut muss man verschiedene Wege einschlagen und auch unterschiedlich viel Zeit investieren. Ich administriere hauptberuflich etwa 20 physische Server und darauf etwa 40-50 VMs. Das ist im Übrigen auch ein Konzept: DB Server, http-Server in verschiedenen VMs...
Peter II schrieb: > ich betreibe selber einen Server. Nach jedem > Update geht irgendetwas nicht mehr. Welche Distro? Innerhalb stabiler Distro-Versionen ist das eher ungewöhnlich. Genau deshalb ist z.B. in Redhat 7 auch heute noch per Default PHP 5.4 im Paket, mit Fixes bis 2024, obwohl das an der Quelle schon längst nicht mehr unterstützt wird. Eben damit das stabil bleibt und nicht jeder Update ein Risiko ist.
:
Bearbeitet durch User
Dussel schrieb: [...] > Reicht es, das einmal einrichten und jede Woche eine Aktualisierung > machen oder geht es eher in Richtung jeden Tag Logdateien lesen und > Konfigurationen an die neuen Bedrohungen anpassen? Security Updates täglich automatisiert installieren lassen, dann hat man da eigentlich schon den größten Teil erledigt - sofern die Updates beim gewählten OS bzw. Distribution auch zügig bereitgestellt werden. Dafür sollte man sich dann natürlich auch auf vom Distributor bereitgestellte Software beschränken. IDS und Monitoring sind auch sinnvoll, damit man den Schaden (der ja bei anderen angerichtet wird) wenigstens möglichst einschränken kann, wenn doch mal was passiert. Auch schon mal über Urlaubsvertretung nachdenken (kommt unschön, wenn die Kiste geknackt wird und du erst nach zwei Wochen Urlaub dann etwas dagegen unternimmst - das rutscht dann auch schnell mal Richtung Fahrlässigkeit). > Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich > oder kann man irgendwie so einschränken, dass es sicher ist. Von harmlos bis grausam ist da alles drin, das hängt eben von den Fähigkeiten des Autors und der implementierten Funktionalität ab: - Wenn du einen Mailserver selbst baust, dann mußt du halt auf viele Details achten, damit das Ding nicht Spam verteilt. - Wenn du etwas mit ganz simpler Funktionalität baust, dann ist Mißbrauch schon deutlich schwerer. - Wenn du den Zugriff auf deine eigene Software z.B. auf bestimmte IP-Adressbereiche einschränken kannst (sowohl via Firewall als auch über eigene Prüfungen in der Software), dann verringerst du damit die Angriffsfläche. Prinzipiell solltest du schon wissen, was du tust, bevor du das auf einem relativ fett angebundenen Server, der nackt am Internet hängt, machst. Also bitte nicht die ersten Schritte in Netzwerkprogrammierung gleich draußen in der bösen, weiten Welt machen, sondern im eigenen abgeschotteten Netz und danach erst damit rausgehen.
A. K. schrieb: > Peter II schrieb: >> ich betreibe selber einen Server. Nach jedem >> Update geht irgendetwas nicht mehr. > > Welche Distro? Innerhalb stabiler Distro-Versionen ist das eher > ungewöhnlich. Genau deshalb ist z.B. in Redhat 7 auch heute noch per > Default PHP 5.4 im Paket, mit Fixes bis 2024, obwohl das an der Quelle > schon längst nicht mehr unterstützt wird. Eben damit das stabil bleibt > und nicht jeder Update ein Risiko ist. Debian, aber testing. (ja, ich bin damit selber schuld). Aber selbst bei Stable muss ich irgendwann richtig updaten. Dann kommt alles auf einmal. Da mache ich lieber viele kleine Updates. eine stabiler Distro-Versionen ist zwar schön und gut, aber dafür bekommt man Probleme wenn man wirklich mal etwas aktuelles braucht.
Also ist es wohl nicht so einfach. Ich wollte jetzt kein Experte in Serversicherheit werden. Der Server wäre nur Arbeitsgerät und dafür ist mir der Aufwand zu groß. Dann lasse ich es aber lieber.
Dussel schrieb: > Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich > oder kann man irgendwie so einschränken, dass es sicher ist. Das kommt natürlich immer auf das eigene Wissen an. Solange sie nicht im Internet kommunizieren ist das relativ harmlos. Aber seien wir mal ehrlich: Selbst wenn du einen völlig unsicheren Serverdienst implementierst, bist du wahrscheinlich sicher. Du hast den Vorteil, dass keiner deinen Code kennt und entsprechend ein Angriff schwer wird. Ja, ich weiß auch, Security by obscurity can't work. Aber ein System, dass es nur einmal gibt und kein lohnendes Angriffsziel darstellt? Die Pösen Purschen scannen ohnehin vollautomatisch nach Sicherheitslücken in Standarddiensten wie SSH oder HTTP. Da interessiert sich niemand für den selbstgebastelten Serverdienst. Denen ist wichtig, dass sie schnell neue Rechner finden, die für ihr Botnet interessant sind. Ich denke es ist deutlich wichtiger die Standardsoftware aktuell zu halten. Auch in eigener Software sollte man sich nicht die gröbsten Schnitzer erlauben, es gibt aber eine relativ geringe Wahrscheinlichkeit, dass überhaupt jemand nach Lücken in deiner eigenen Software sucht. Wenn allerdings dann jemand suchen sollte, hast du aber wahrscheinlich ein Problem.
Dussel schrieb: > aus nicht ganz aktuellem Anlass mal die Frage: Wie viel Aufwand ist es, > einen Server im Internet gegen Missbrauch zu schützen? Das heißt, dafür > zu sorgen, dass der Server nicht als Spamversender oder Hackerproxy > verwendet wird und über ihn keine anderen virtuellen Server oder das > Rechenzentrum beeinflusst wird. Natürlich sollten auch keine Viren > installiert werden können. Das kommt darauf an. Darauf, welche Dienste der Rechner nach draußen bereitstellt. Dienste, die es nicht gibt, können nicht mißbraucht werden. Für alle anderen Dienste gilt, daß sie potentiell Sicherheits- lücken enthalten können und daß es deswegen sinnvoll / notwenig sein wird, etwaige Updates möglichst regelmäßig einzuspielen. Falls das ein Linux-System ist und die betroffenen Programme Teil der Distribution sind, dann kann man das i.d.R. automatisieren. > Reicht es, das einmal einrichten und jede Woche eine Aktualisierung > machen oder geht es eher in Richtung jeden Tag Logdateien lesen und > Konfigurationen an die neuen Bedrohungen anpassen? Wenn man Konfigurationen an Bedrohungen "anpassen" muß, dann bedeutet das nichts anderes als daß sie vorher unsicher (vulgo: kaputt) waren. Logfiles können Hinweise auf Probleme geben, allerdings zeigt die Erfahrung, daß unbedarfte Anwender auch nicht wissen, was sinnvoll zu loggen wäre oder woran man Probleme im Log erkennt. Tip: Portscans oder fehlgeschlagene SSH-Logins zu loggen, hilft nicht. > Wie kritisch sind selbstprogrammierte Programme? Sind die gefährlich > oder kann man irgendwie so einschränken, dass es sicher ist. Auch das kommt drauf an, wie gut der jeweilige Programmierer ist. Aber im Prinzip ist jede nach außen offene Verbindung ein mögliches Einfallstor. Einschränkungen gibt es in der Tat, z.B. kann man SE-Linux benutzen und so konfigurieren, daß derartige Programme nur einen eingeschränkten Teil des Systems sehen können. Noch einen Schritt weiter gehen Container-Lösungen wie Docker. Dussel schrieb: > Es geht hauptsächlich um einen Server zum Testen. Eigene Programme, > 'Webprojekte' und sowas. Ein lokaler Server reicht dafür nicht, weil es > in realer Umgebung (Internet) sein soll. Das ist ein groteskes Mißverständnis. Ein Testserver im LAN unter- scheidet sich in allen relevanten Punkten nicht von einem Server, der irgendwo bei einem Hoster steht. Außer daß er natürlich hinter einem Gateway oder einer Firewall steht und Angriffen daher nicht ganz so schutzlos ausgeliefert ist. In den meisten Fällen reicht sogar eine VM, die über ein virtuelles LAN angesprochen wird. Ausnahmen sind Fälle, wo Ausbruchsversuche aus der VM oder spezifische Lücken in der VM selber untersucht werden sollen.
Peter II schrieb: > ui schrieb: >> (schließen des telnet ports z.B.) > > der erhöht auch nicht wirklich die Sicherheit, nur wenn es user gibt sie > sie darüber ein loggen. Das erhöht die Sicherheit wesentlich. Jede Serversoftware, die auf einer öffentlich erreichbaren Schnittstelle lauscht, vergrößert zwangsläufig die Angriffsoberfläche -- insbesondere dann, wenn sie auf einem privilegierten Port (<1024) lauscht, Login-Shells für verschiedene Benutzer starten kann, und daher zwingend Root-Rechte braucht wie der klassische Telnet-Daemon. Nicht zuletzt deswegen ist es der erste Rat jedes seriösen Einsteigerwerks zum Thema Netzwerksicherheit, unnötigte Software mindestens zu stoppen, besser zu deinstallieren, und die benötigte Software so weit irgend möglich hinsichtlich Konnektivität und Privilegien zu beschränken. Und nicht zuletzt deswegen setzen sich in den letzten Jahren immer mehr Sicherheitsframeworks für Mandatory Access Control (MAC) wie RSBAC, SE-Linux, AppArmor und Smack durch, weil die die benötigten Privilegien viel feiner granulieren.
Hans schrieb: > Das kommt natürlich immer auf das eigene Wissen an. Solange sie nicht im > Internet kommunizieren ist das relativ harmlos. Aber seien wir mal > ehrlich: Selbst wenn du einen völlig unsicheren Serverdienst > implementierst, bist du wahrscheinlich sicher. Auch wenn Du mit einem Auto fährst, dessen Lenkung, Bremsen, und Reifen kaputt sind, bist Du wahrscheinlich sicher. Denn meistens mußt Du nicht scharf bremsen oder ausweichen...
Axel S. schrieb: > Dienste, die es nicht gibt, können nicht mißbraucht werden. > > Wenn man Konfigurationen an Bedrohungen "anpassen" muß, dann bedeutet > das nichts anderes als daß sie vorher unsicher (vulgo: kaputt) waren. > > Tip: Portscans oder fehlgeschlagene SSH-Logins zu loggen, hilft nicht. > > Auch das kommt drauf an, wie gut der jeweilige Programmierer ist. Endlich: jemand, der was vom Thema versteht!
SR schrieb: > - SSH idealerweise mit Keyfile check :) > - Alle Dienste die offen sind mit sicheren Passwörtern und Fail2Ban hab fail2ban grade für sshd eingerichtet. danke für den tip!
Axel S. schrieb: > Das ist ein groteskes Mißverständnis. Ein Testserver im LAN unter- > scheidet sich in allen relevanten Punkten nicht von einem Server, der > irgendwo bei einem Hoster steht. Zu mikrocontroller.net habe ich Pings von 20-30 ms. Ich denke doch, dass das im LAN unterboten werden kann. Danke für die Antworten bisher. Hier geht's mehr auf die Programme bezogen weiter Beitrag "Einfallstore für Missbrauch von Serversoftware"
c.m. schrieb: >> - Alle Dienste die offen sind mit sicheren Passwörtern und Fail2Ban > > hab fail2ban grade für sshd eingerichtet. danke für den tip! fail2ban ist mir etwas unheimlich, rückwärts über logs die Ports sperren. ich habe einfach iptables konfiguriert, das nur 1 Syn packet je Minute von einer IP kommen darf.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.