Comfort meet Security

[Artimis]

Da ich immer wieder Stuss und ungerechtes Geflame in Hinsicht auf Serversicherheit lese, habe ich hier mal einen Eintrag veröffentlich, der über "PKI viiieeel sicherer als Passwörter" und "wer sich mit root einloggt, ist ein DAU" aufklärt:
Link zum Artikel

Für Anregungen und insbesondere auch Diskussionen über diesen Standpunkt bin ich dankbar

 

[d4f]

Ich sag nur: JUHU
Endlich ein Beitrag der mich nicht da stehen laesst als waere ich mit Passwort (> 15 Stellen inkl Sonderzeichen) + root-Login ein Sicherheits-Chaot
Eventuell koenntest du noch Portknocker kurz im Beitrag erwaehnen; mit einem solchen ist ein Portscan nach SSH definitiv unmoeglich


Ich bin ein root/toor-Mensch. Wenn ich per SSH auf einen Server einlogge, dann nicht um unnuetz Shell's aufzumachen sondern um drauf rum zu basteln, also root Privileg.
Wer jetzt sagt dass man sich mit sudo vor falschen Kommandos oder ungewollten Aktionen schuetzt; die meisten Aktionen die man auf einem Server durchfuehrt bedarfen Roor-Rechte und somit tippt man das 'sudo' nach einiger Zeit automatisch...
Wenn man gezielt als non-privileged User arbeiten will dann su't man in einen solchen. Non-privileged ist fuer Desktops gut; Ubuntu wird ja auch dementsprechend standartmaessig ausgeliefiert.

 

[Armadillo]

Ich bin ein root/toor-Mensch. Wenn ich per SSH auf einen Server einlogge, dann nicht um unnuetz Shell's aufzumachen sondern um drauf rum zu basteln, also root Privileg.

Klingt eher nach Faulheit.

Wer jetzt sagt dass man sich mit sudo vor falschen Kommandos oder ungewollten Aktionen schuetzt; die meisten Aktionen die man auf einem Server durchfuehrt bedarfen Roor-Rechte und somit tippt man das 'sudo' nach einiger Zeit automatisch...
Wenn man gezielt als non-privileged User arbeiten will dann su't man in einen solchen. Non-privileged ist fuer Desktops gut; Ubuntu wird ja auch dementsprechend standartmaessig ausgeliefiert.

Und warum ist deiner Meinung nach non-privileged nicht für Server gut? Oder interpretiere ich da nur was rein?

 

[Ben.]

Ich nutze kein Fail2Ban. Bin ich ein schlechter Mensch?

Netter Artikel!

 

[DjTom-i]

Alles Blödsinn...

Ohne Kunden und deren Scripte auf den Servern gäbe es 99,9% weniger Angriffsfläche.

Das Risiko, das

a) jemand einen zero day SSH Exploit hat und nutzt ist gleich null
b) die Chance das jemand ein ordentliches Rootpw knackt, bzw an den Hash kommt ist - wie gesagt ohne Kunden drauf - gleich null
c) klar alles was hilft den SSH Daemon zu verbergen ist ok, aber aus meiner Sicht nicht zwingend notwendig

Aus meiner Sicht die beste Lösung:

Ein zweites nicht geroutetes Netzwerk über welches man sich zu den Nodes verbindent.

 

[Artimis]

Hui, wat ne rege Beteiligung!

Und warum ist deiner Meinung nach non-privileged nicht für Server gut?

Da ich in etwa den selbsten Standpunkt vertrete, antworte ich mal für d4f:
Wenn man als nicht privilegierter User arbeitet muss man entweder vor so gut wie jedem Befehl ein sudo schreiben, da Linux dafür konzipiert ist, dass man für jeden Krams eigene Benutzer mit stark eingeschränkten Lese- und Schreibrechten einrichtet, oder man lässt die Serversicherheit intern an sehr langer Leine. Denn ein unprivilegierter User sollte nicht an den Dateien / Configs(!) der anderen rumpfuschen können.
Als root musst du nicht vor jeden Befehl ein sudo klemmen und musst nur bei ausführbaren Dateien mit su arbeiten, was, wie gesagt, der unprivilegierte User auch tun muss, da jede Applikation(-sart) einen eigenen User bekommt.

Ohne Kunden und deren Scripte auf den Servern gäbe es 99,9% weniger Angriffsfläche.

Das ein Webserver, der vielleicht ein bisschen lachs konfiguriert ist und für Kunden nutzbar ist, das Non-plus-ultra an Unsicherheit ist, ist klar.
Ich schrieb diesen Artikel aus der Intuition heraus, weil ich eben beobachte, dass jeder, der sich autet, sich als root mit PW anmelden zu können, von der Community oft totgebasht wird. Da kommen meist empfehlungen von managed bis Kündigung. Und da das totaler Schwachsinn ist, sondern nur ein Standpunkt von Pseudo-Sicherheits-Anfängern ist, wollte ich mal ein bisschen aufklären.

klar alles was hilft den SSH Daemon zu verbergen ist ok, aber aus meiner Sicht nicht zwingend notwendig

Naja, bequemer ist es
Wenn ich da an meine Logs denke, die nach einem Tag schon wie ein Telefonbuch von Berlin aussahen, weil irgendwelche dummdreisten Skript-Kiddies ausprobieren müssen, ob man mit "web0" nicht eventuell ohne PW rein kommt...

Ein zweites nicht geroutetes Netzwerk über welches man sich zu den Nodes verbindent.

Das wäre traumhaft. Dann hätte ich auch nicht ständig Ärger mit SSH-Tunnels und dem Konflikt, wie man dieses olle UDP sicher tunneln kann.

 

[Armadillo]

Wenn man als nicht privilegierter User arbeitet muss man entweder vor so gut wie jedem Befehl ein sudo schreiben, da Linux dafür konzipiert ist, dass man für jeden Krams eigene Benutzer mit stark eingeschränkten Lese- und Schreibrechten einrichtet, oder man lässt die Serversicherheit intern an sehr langer Leine. Denn ein unprivilegierter User sollte nicht an den Dateien / Configs(!) der anderen rumpfuschen können.
Als root musst du nicht vor jeden Befehl ein sudo klemmen und musst nur bei ausführbaren Dateien mit su arbeiten, was, wie gesagt, der unprivilegierte User auch tun muss, da jede Applikation(-sart) einen eigenen User bekommt.

Also ich hab ja keine Ahnung wie ihr eure Server administriert, aber bei mir läuft natürlich so viel wie möglich als eigener Nutzer. Geht man in die High-Security-Richtung muss man da noch ganz andere Sachen machen als solche Kleinigkeiten.
Außerdem mach ich das meiste auf einem Server als root, wenn ich Sachen einrichte. Das ist in großem Stil nur beim ersten Einrichten der Fall. Ansonsten kommt das eher selten vor. Ansonsten macht man noch diverse Logauswertungen und andere Spielereien, die man problemlos als User machen kann.
Und ich versteh auch nicht ganz, wo das Problem ist vor einen Befehl der als root ausgeführt werden soll sudo zu schreiben.

Naja, bequemer ist es
Wenn ich da an meine Logs denke, die nach einem Tag schon wie ein Telefonbuch von Berlin aussahen, weil irgendwelche dummdreisten Skript-Kiddies ausprobieren müssen, ob man mit "web0" nicht eventuell ohne PW rein kommt...

fail2ban ist dein Freund.

Das wäre traumhaft. Dann hätte ich auch nicht ständig Ärger mit SSH-Tunnels und dem Konflikt, wie man dieses olle UDP sicher tunneln kann.

Wenn man kein eigenes Netz hat kann mans auch über VPN lösen.

 

[Artimis]

Und ich versteh auch nicht ganz, wo das Problem ist vor einen Befehl der als root ausgeführt werden soll sudo zu schreiben.

Ganz einfach: Da es unprivilegierte User nichts angeht, was die jeweiligen Applikationen als Logs produzieren, darf man sie nicht mit einem unprivilegierten User lesen können. Man darf ebenfalls keinen Configs öffnen, keine Verzeichnisse wechseln, keine Daemons abfragen oder gar neustarten...
Also muss man vor jedem Befehl, der nicht gerade "whoami" lautet, ein "sudo" klemmen. Es sei denn natürlich, man hat mit seinem "nicht-als-Root-anmelden"-Wahn die Sicherheit auf dem Server unter den Usern vernachlässigt.
Und wo hingegegen ist das Problem mit root-Zugriff?
Zum einen wird niemand Spielchen wie "rm -Rf /" machen, zum anderen weiß wohl jeder, dass man ausführbare Dateien als unprivilegierter User starten muss. Ein "su" / "su -c" und es hat sich.

fail2ban ist dein Freund.

naja, zum einen weise ich ja dringend darauf hin, sich solcher Tools zu bedienen, zum anderen machen auch 5 Versuche von 30 Hosts am Tag keine Freude. Durch Verlegen des SSH-Ports und der hier angesprochenen weiteren Möglichkeiten wie "Portknocking" reduziert sich der Datenmüll in den Logs auf exakt 0.

Wenn man kein eigenes Netz hat kann mans auch über VPN lösen.

Für UDP-Tunnel kein Ding und lange im Einsatz Aber wir sprechen hier ja primär von SSH. Und da weiß ich nicht, ob es etwas bringt, sich erst per VPN ein virtuelles Netz zu schaffen, um dort dann per SSH zu verbinden...

 

[Armadillo]

Na ja, dass mit sudo ist halt Ansichtssache. Ich persönlich halte es bei richtiger Benutzung und entprechendem Setzen der Rechte für deutlich sicherer, aber das muss jeder für sich entscheiden.

naja, zum einen weise ich ja dringend darauf hin, sich solcher Tools zu bedienen, zum anderen machen auch 5 Versuche von 30 Hosts am Tag keine Freude. Durch Verlegen des SSH-Ports und der hier angesprochenen weiteren Möglichkeiten wie "Portknocking" reduziert sich der Datenmüll in den Logs auf exakt 0.

Sorry aber Verlegen des SSH-Ports ist maximal eine temporäre Sicherung. Jemand der per SSH rein will, probiert dann schon die richtigen Ports. Portknocking ist zwar ne nette Spielerei, aber mehr als Security by Obscurity ist es meiner Ansicht nach nicht. Will ich dann doch mal was von nem anderen Server wohin kopieren nervt das nur.
5 Versuche * 30 IPs * 24 Stunden (weil immer 60min Ban) = 3600 Logeinträge pro Tag. Das ist schlicht und einfach gar nichts. Wenn man Bock hat kann man das auch auf 2 Versuche und 240 Minuten hochstellen, dann reduziert es sich entsprechend. Das Gegenüber wird die Versuche da auch recht schnell einstellen, wenn seine Passwortliste 5 Jahre braucht um die ersten 100 Seiten abzuarbeiten und wenn nicht kanns dir auch egal sein (sichere Passwörter/PKI vorausgesetzt).
Wenn man Lust hat verteilt man die Regeln dann noch auf alle seine Hosts und reduziert die Einträge damit allgemein.

Für UDP-Tunnel kein Ding und lange im Einsatz Aber wir sprechen hier ja primär von SSH. Und da weiß ich nicht, ob es etwas bringt, sich erst per VPN ein virtuelles Netz zu schaffen, um dort dann per SSH zu verbinden...

Aha. Warum soll es nichts bringen SSH über VPN zu machen? Mit nem virtuellen Netz kann man die Server untereinander auch viel besser vernetzen. Zum Beispiel noch ein Monitoring darüber laufen lassen, den syslogd darüber zu nem zentralen Loggingserver loggen lassen, Backups machen und lauter so Zeug. Macht meiner Meinung nach extrem viel Sinn. Nur für SSH ist das vielleicht wieder was Anderes und die Frage wie viele Server man dann wirklich hat spielt natürlich ebenfalls ne Rolle.

Allgemein muss man sagen, dass das Sicherheit ein extrem Schwieriges ist und dass der Aufwand dafür sich auch immer an den Anforderungen messen lassen muss. Thema SSH sicher, aber Webserver offen wie ein Scheunentor und solche Geschichten.

 

[d4f]

@Armadillo:
Jap, zuviel interpretiert Alle Daemons werden (fast *huestel*) immer als eigener Benutzer gestartet sofern es moeglich ist.

Aber sich selbst in der SSH einzuschraenken bringt einfach null... Unpriviligierter Login bringt nur dahingehend was dass man root-Login verbietet und sich direkt nach dem Login root-Privilegien verschafft - man verkompliziert damit jedoch die Sache und vergroessert dementsprechend das Risiko dass irgendeine der Etappen nicht will und man geschmissen ist; eine Lara oder Rescue muss dann her...

Imho werden die meisten SSH-Passwoerter halbwegs abgesicherter Server nicht durch direkte Angriffe auf die Server ausgespaet sondern durch Keylogger und sonstiges Gewuerm auf dem Heim-Rechner (oder Firmenrechner) des Administrators. Und in dem Fall ist es recht schnuppe ob man ein Public/Private Keypair nimmt oder ein '123456'-Passwort...

Portknocking ist zwar ne nette Spielerei, aber mehr als Security by Obscurity ist es meiner Ansicht nach nicht.

3 UDP Ports im nicht privilegierten Bereich bedeutet (Anzahl UDP-Ports)^3 x (Anzahl SSH Ports) = 2.68x10^14 x 64535 = 1,75x10^19 moegliche Kombinationen! Ein simples Verlegen des SSH-Ports hingegen nur 6,54x10^4!
Da der Angreifer nicht weiss wieviele Knocks auf welchen Ports notwendig sind kann man den Angriff gleich vergessen; nach dem Rausfinden des Ports muss man ja auch noch den Key oder das Passwort knacken
Security by obscurity kann also was helfen

 

[Armadillo]

Na ja, ich klink mich an der Stelle aus. Wie man sieht hat jeder seine Prinzipien von denen er/sie nicht abweicht, da ist es sinnlos darüber zu diskutieren.

 

[Lord Gurke]

Ich halte ja weiterhin "sudo" an sich für eine Sicherheitslücke an sich - ich habe das nichtmal auf meinen Systemen installiert.
Entweder bin ich root oder ich bin mit su zu einem unpreviligiertem Benutzer geworden. Den SSH-Port habe ich verlegt, damit mir die ganzen Bots nicht das Log vollheulen und ich zwischendurch im Logfile dann auch etwas finde, wonach ich suche

Authentifizierung erfolgt sowohl per PKI als auch per Passwort. Zu Hause per Key, weil "mal eben schnell ein PuTTY aufgeht" und per Passwort, damit ich unterwegs auch ohne den Key mit mir rumzutragen, auf den Server komme.

Und ich kann voller Stolz behaupten, dass die Kisten - obwohl die FTP-Logs rappelvoll mit Bot-Anmeldeversuchen sind - bis heute (und das sind jetzt gute 4 Jahre) nicht einmal etwas getan haben, was ich nicht wollte.

Fail2Ban habe ich mal genutzt, aber leider war die Quote der damit ausgesperrten vergesslichen Benutzer deutlich höher als die der verhinderten Angriffe - also ist das wieder geflogen.

Und so interessante Befehle wie "ftp", "wget" oder "curl" werden umbenannt und eine Dummy-Datei mit diesem Namen erstellt, die nichts weiter tut, als mich per Jabber und Mail über die Ausführung zu informieren.
Sollte also irgendwann mal jemand es dennoch schaffen, eine Shell zu bekommen, werden zumindest so automatisierte "wir greifen jetzt andere Server an"-Scripte nicht funktionieren und ich bekomme brühwarm Bescheid.

 

[Artimis]

Ich halte ja weiterhin "sudo" an sich für eine Sicherheitslücke an sich - ich habe das nichtmal auf meinen Systemen installiert.
Entweder bin ich root oder ich bin mit su zu einem unpreviligiertem Benutzer geworden. Den SSH-Port habe ich verlegt, damit mir die ganzen Bots nicht das Log vollheulen und ich zwischendurch im Logfile dann auch etwas finde, wonach ich suche

Authentifizierung erfolgt sowohl per PKI als auch per Passwort. Zu Hause per Key, weil "mal eben schnell ein PuTTY aufgeht" und per Passwort, damit ich unterwegs auch ohne den Key mit mir rumzutragen, auf den Server komme.

Und ich kann voller Stolz behaupten, dass die Kisten - obwohl die FTP-Logs rappelvoll mit Bot-Anmeldeversuchen sind - bis heute (und das sind jetzt gute 4 Jahre) nicht einmal etwas getan haben, was ich nicht wollte.

Fail2Ban habe ich mal genutzt, aber leider war die Quote der damit ausgesperrten vergesslichen Benutzer deutlich höher als die der verhinderten Angriffe - also ist das wieder geflogen.

Geilo! Das hätte von mir sein können.
Full consent!
Denn zu meinem Scham muss ich gestehen, dass ich mich mit fail2ban immer selbst ausgesperrt habe, weshalb ich es in meinem Tutorial auch so stiefmütterlich vernachlässige =)
Ich rate zwar anderen dazu, benutze es selbst jedoch nicht. Und da ich regelmäßig die Logs prüfe und eben keine Script-Kiddies durch verlegten SSH-Ports habe, mache ich praktisch manuelles "fail2ban".

Die Dummy-Files brauche ich eher nicht, da ich als einziger an meinen Servern bastle und bei Anwendungen wie dem Apache-PHP die sicherheitsrelevanten Befehle zum großen Teil gesperrt habe.

 

[d4f]

Er meint eher dass idR nach einem erfolgreichen Angriff ein automatisiertes Script zur Vorbereitung eines solchen auf andere Server gestartet wird.
(Direkt nach einem Ausbrechen aus etwaigen chroot's)
Und diese Scripte setzen idR auf wget da es standartmaessig auf den meisten Rechner installiert ist, somit kann das System einen warnen bevor der Anbieter es tut
Das funktioniert allerdings nicht wenn der Angreifer mittels SCP zuerst einen Sanity-Check hochlaedt oder ein komplett eigenes Programm mitbringt.