Was sollte ein Systemadministrator, der an private Situationen vom Typ Intranet gewöhnt ist, ähnlich wie bei dieser Frage zu Stack Overflow wissen, bevor er Administrator einer öffentlichen Site ist?
Dies können sicherheitsrelevante Dinge wie "Nicht telnetoffen lassen" oder praktische Dinge wie der Lastausgleich für eine stark frequentierte Site sein.
Antworten:
Jede App, jede Binärdatei, jedes Paket, das auf dem Server vorhanden ist, ist eine Haftung. Abonnieren Sie das Prinzip des kleinsten Bits. Wenn es nicht installiert ist, kann es nicht kompromittiert werden.
Implementieren Sie die Intrusion Detection wie Tripwire oder ähnliches und scannen Sie häufig.
Investieren Sie in eine Hardware-Firewall und öffnen Sie nur die Ports, die Sie für Ihre Anwendung benötigen. Lassen Sie nicht zu, dass Ihre Administrationsports (ssh, rdp usw.) öffentlich sichtbar sind. Beschränken Sie sie auf genehmigte Management-IP-Adressen.
Sichern Sie Ihre Firewall- / Switch- / Routerkonfigurationen zum Zeitpunkt der Produktionsaufnahme. Wenn eines dieser Geräte kompromittiert ist, ist es erheblich schneller, sich durch Abwischen des Gehirns des Geräts und erneutes Laden der Konfiguration zu erholen, als eine zeilenweise Prüfung der Konfiguration durchzuführen, wenn die Uhr tickt.
nmap Ihre Umgebung häufig von außen, um sicherzustellen, dass keine neuen Ports geöffnet wurden.
Vertraue niemals dem Internet; Stellen Sie sicher, dass alles, was Sie im Netz bereitstellen, so sicher wie möglich ist (führen Sie beispielsweise eine serverseitige Eingabevalidierung und -bereinigung durch, um beispielsweise SQL-Injection-Angriffe zu stoppen).
Behalten Sie den Überblick über Ihre Patches.
Wenn Sie kompromittiert sind, erstellen Sie sie mit neu heruntergeladenen Medien von Grund auf neu. Sie können nicht mehr darauf vertrauen, dass Ihre Backups sicher sind und nicht für andere als inerte, nicht ausführbare Daten kompromittiert wurden (obwohl Tripwire dabei helfen kann).
Ein Werkzeug, das ich für die Netzwerkhärtung als nützlich empfunden habe, ist Nessus
Grundsätzlich Sie setzen es auf einem externen Server, und es versucht zu attackieren Ihr Netzwerk mit einem ganzen Gleichgewicht gerät bekannten Exploits. Sie können es für den abgesicherten Modus einstellen (wo keiner der Angriffe Ihren Server zum Absturz bringen sollte) oder wenn Sie ziemlich sicher sind, dass alles gepatcht ist, oder es sich leisten, Ihre Server bei Bedarf für den unsicheren Modus neu zu starten .
Anschließend wird ein sehr vollständiger abgestufter Bericht für jeden Computer bereitgestellt, auf dem festgestellt werden kann, welche Schwachstellen / Schwachstellen gefunden wurden, und der Schweregrad wird bewertet. Außerdem werden Maßnahmen empfohlen, um die Probleme zu beheben.
Sie sollten wissen, wie ihr Backup- und Disaster Recovery-System funktioniert und wie sie das System wiederherstellen, wenn es kompromittiert wird.
Dies ist ein bisschen konträr, aber in Bezug auf die Sicherheit unterscheide ich nicht zwischen einem internen Server und einem externen Server. Früher oder später wird jemand einen Fehler in einer Firewall machen, das Management wird darauf bestehen, dass ein Server wegen eines wichtigen Clients freigelegt wird, Betty in der Buchhaltung wird irgendwie einen VPN-Client auf ihrem infizierten Heimcomputer bekommen usw.
Das heißt, Ebenen sind dein Freund, und du solltest standardmäßig auf die schwarze Liste setzen.
Ebenen - Sie sollten mehrere Sicherheitsebenen haben. Zum Beispiel eine Hardware-Firewall und eine Software-Firewall. Diese dienen theoretisch demselben Zweck, aber mehrere Schichten schützen vor Fehlern und mildern die Folgen der Ausnutzung einer einzelnen Schicht.
Ein weiterer Aspekt der Überlagerung ist "Homeycombing", bei dem es sich im Wesentlichen um mehrere DMZs handelt. Irgendwann müssen Sie ein gewisses Maß an Vertrauen zwischen Ihren Computern und den Personen haben, die auf Ihre Konten zugreifen. Wenn Sie diese Interaktionspunkte eingrenzen können, können Sie die Art des Datenverkehrs, dem Sie vertrauen, jederzeit genau kontrollieren. Wenn Sie beispielsweise Ihre Schnittstellen- / App-Server von Ihren Datenbankservern trennen, verringern Sie das Vertrauensniveau. Wenn Ihre App-Server kompromittiert werden, erhalten diese Angreifer nur minimalen Halt in Ihrer Infrastruktur (dh, um ihren Angriff fortzusetzen und zu versuchen, Ihre anderen Server auszunutzen, müssen sie nur die festgelegten Vertrauenspunkte verwenden).
In Bezug auf die schwarze Liste sollten Sie standardmäßig alles herunterfahren und (auch wenn es nur Sie selbst sind) eine Rechtfertigung für jeden von Ihnen geöffneten Port, den Benutzernamen, den Sie zulassen, die installierte App usw. verlangen.
Stellen Sie auf Systemen mit JEDER öffentlichen Schnittstelle sicher, dass Ihre Benutzer über sichere Kennwörter verfügen , indem Sie eine sichere Kennwortrichtlinie implementieren und die Kennwortdatei mit einem Dienstprogramm zum Knacken von Kennwörtern wie John the Ripper testen
Sie können sich weiter vor Brute-Force-Angriffen schützen, indem Sie IP-Adressen nach mehreren fehlgeschlagenen Versuchen blockieren . Ein gutes Tool dafür (unter Linux) ist fail2ban
Ihr Switch kann gehackt werden und jemand kann die Daten manipulieren. Wenn Sie den Switch nicht besitzen, richten Sie einen VPN ein, da die Zugriffsbeschränkung für die IP-Firewall möglicherweise nicht ausreicht.
Lassen Sie keine Ports offen, außer denen, auf die Benutzer und Hacker zugreifen sollen. Scannen Sie jeden Monat Ihre eigenen Server von einer anderen Site.
Lassen Sie den Standardport von ssh nicht für Hacker offen.