Da unsere Prävention aus der Perspektive des Eindringlings betrachtet wird, müssen wir zunächst wissen, wie der Eindringling eindringt. Derzeit bestehen die beliebtesten Web-Intrusion-Methoden darin, zunächst die Webshell der Website durch die Suche nach Programmschwachstellen abzurufen und dann entsprechende ausnutzbare Methoden zu finden, um Berechtigungen basierend auf der Serverkonfiguration zu erweitern und dann Serverberechtigungen zu erhalten. Daher ist es eine wirksame Methode, mit dem Server zusammenzuarbeiten, um Webshell zu verhindern.
1. Verhindern Sie, dass die Datenbank illegal heruntergeladen wird
Es sollte gesagt werden, dass Administratoren mit ein wenig Netzwerksicherheit den Standard-Datenbankpfad von aus dem Internet heruntergeladenen Website-Programmen ändern werden. Natürlich sind einige Administratoren sehr nachlässig. Sie besorgen sich das Programm und installieren es direkt auf ihrem eigenen Server, ohne die Beschreibungsdatei zu löschen, geschweige denn den Datenbankpfad zu ändern. Auf diese Weise können Hacker das Quellprogramm der Website direkt von der Quellcode-Site herunterladen, es dann lokal testen, um die Standarddatenbank zu finden, und dann die Datenbank herunterladen, um die darin enthaltenen Benutzerinformationen und Daten (normalerweise MD5-verschlüsselt) zu lesen und die Verwaltung zu finden Geben Sie ein und melden Sie sich an, um die Webshell zu erhalten. Eine andere Situation besteht darin, dass der Pfad zur Website-Datenbank aufgrund eines Programmfehlers offengelegt wird. Wie kann dies verhindert werden? Wir können die erweiterte MDB-Zuordnung hinzufügen. Wie unten gezeigt:
Öffnen Sie IIS und fügen Sie eine MDB-Zuordnung hinzu, damit mdb in andere Dateien analysiert werden kann, die nicht heruntergeladen werden können: „IIS-Eigenschaften“ – „Home-Verzeichnis“ – „Konfiguration“ – „Zuordnung“ – „Anwendungserweiterung“ und fügen Sie die .mdb-Datei hinzu Um das Parsing anzuwenden, können Sie die zum Parsen verwendete Datei selbst auswählen, solange auf die Datenbankdatei nicht zugegriffen werden kann.
Die Vorteile davon sind: 1. Datenbankdateien im MDB-Suffixformat werden definitiv nicht heruntergeladen. 2. Es funktioniert für alle MDB-Dateien auf dem Server, was für Administratoren virtueller Hosts sehr nützlich ist.
2. Hochladen verhindern
Wenn Sie für die obige Konfiguration eine MSSQL-Datenbank verwenden, können Sie, solange ein Injektionspunkt vorhanden ist, weiterhin das Injektionstool verwenden, um die Datenbank zu erraten. Wenn beim Hochladen von Dateien überhaupt keine Authentifizierung erfolgt, können wir direkt einen ASP-Trojaner hochladen, um die Webshell des Servers abzurufen.
Was das Hochladen betrifft, können wir es wie folgt zusammenfassen: Verzeichnisse, die hochgeladen werden können, erhalten keine Ausführungsberechtigungen, und Verzeichnisse, die ausgeführt werden können, erhalten keine Upload-Berechtigungen. Das Webprogramm wird vom IIS-Benutzer ausgeführt. Wir müssen dem IIS-Benutzer lediglich die Schreibberechtigung für ein bestimmtes Upload-Verzeichnis erteilen und dann die Skriptausführungsberechtigung aus diesem Verzeichnis entfernen, um zu verhindern, dass Eindringlinge die Webshell durch Hochladen erhalten. Konfigurationsmethode: Öffnen Sie zunächst im IIS-Webverzeichnis die Registerkarte „Berechtigungen“ und erteilen Sie IIS-Benutzern nur Lese- und Listenberechtigungen für Verzeichnisse. Geben Sie dann das Verzeichnis ein, in dem hochgeladene Dateien und die Datenbank gespeichert sind, fügen Sie IIS-Benutzern Schreibberechtigungen hinzu und schließlich Ändern Sie einfach „Pure Script“ in „None“ in der Option „Eigenschaften“ – „Ausführungsberechtigung“ dieser beiden Verzeichnisse. Siehe Bild unten:
Eine letzte Erinnerung: Wenn Sie die oben genannten Berechtigungen festlegen, müssen Sie darauf achten, die Vererbung des übergeordneten Verzeichnisses festzulegen. Vermeiden Sie vergebliches Einrichten.
[Seite ausschneiden]
3. MSSQL-Injection
Zur Verteidigung der MSSQL-Datenbank sagen wir, dass wir zunächst mit dem Datenbankverbindungskonto beginnen müssen. Verwenden Sie nicht das SA-Konto für die Datenbank. Die Verwendung des SA-Kontos zum Herstellen einer Verbindung zur Datenbank ist eine Katastrophe für den Server. Im Allgemeinen können Sie das DB_OWNER-Berechtigungskonto verwenden, um eine Verbindung zur Datenbank herzustellen. Wenn diese normal ausgeführt werden kann, ist es am sichersten, den öffentlichen Benutzer zu verwenden. Nach dem Festlegen der DBO-Berechtigung zum Herstellen einer Verbindung zur Datenbank kann der Eindringling die Webshell grundsätzlich nur durch Erraten des Benutzernamens und des Kennworts oder durch differenzielle Sicherung erhalten. Bei ersterem können wir sie durch Verschlüsselung und Änderung der Standard-Anmeldeadresse des Verwaltungshintergrunds verteidigen . Für die differenzielle Sicherung wissen wir, dass die Voraussetzung darin besteht, über Sicherungsberechtigungen zu verfügen und das Verzeichnis des Webs zu kennen. Die Suche nach Webverzeichnissen erfolgt normalerweise durch Durchsuchen des Verzeichnisses zum Durchsuchen oder direktes Lesen der Registrierung. Jede dieser beiden Methoden verwendet die beiden erweiterten gespeicherten Prozeduren xp_regread und xp_dirtree. Natürlich können wir auch die entsprechenden DLL-Dateien zusammen löschen.
Wenn das Webverzeichnis jedoch aufgrund eines Programmfehlers offengelegt wird, können Sie nichts tun. Daher müssen wir auch die Berechtigungen des Kontos herabsetzen, damit der Sicherungsvorgang nicht abgeschlossen werden kann. Die spezifischen Vorgänge sind wie folgt: In den Eigenschaften dieses Kontos – Datenbankzugriffsoptionen – müssen Sie nur die entsprechende Datenbank auswählen und ihr DBO-Berechtigungen erteilen. Betreiben Sie keine anderen Datenbanken. Gehen Sie dann zu den Datenbankeigenschaften-Berechtigungen, um die Sicherungs- und Sicherungsprotokollberechtigungen des Benutzers zu entfernen, damit Eindringlinge nicht durch differenzielle Sicherung an die Webshell gelangen können.
3. MSSQL-Injection
Zur Verteidigung der MSSQL-Datenbank sagen wir, dass wir zunächst mit dem Datenbankverbindungskonto beginnen müssen. Verwenden Sie nicht das SA-Konto für die Datenbank. Die Verwendung des SA-Kontos zum Herstellen einer Verbindung zur Datenbank ist eine Katastrophe für den Server. Im Allgemeinen können Sie das DB_OWNER-Berechtigungskonto verwenden, um eine Verbindung zur Datenbank herzustellen. Wenn diese normal ausgeführt werden kann, ist es am sichersten, den öffentlichen Benutzer zu verwenden. Nach dem Festlegen der DBO-Berechtigung zum Herstellen einer Verbindung zur Datenbank kann der Eindringling die Webshell grundsätzlich nur durch Erraten des Benutzernamens und des Kennworts oder durch differenzielle Sicherung erhalten. Bei ersterem können wir sie durch Verschlüsselung und Änderung der Standard-Anmeldeadresse des Verwaltungshintergrunds verteidigen . Für die differenzielle Sicherung wissen wir, dass die Voraussetzung darin besteht, über Sicherungsberechtigungen zu verfügen und das Verzeichnis des Webs zu kennen. Die Suche nach Webverzeichnissen erfolgt normalerweise durch Durchsuchen des Verzeichnisses zum Durchsuchen oder direktes Lesen der Registrierung. Jede dieser beiden Methoden verwendet die beiden erweiterten gespeicherten Prozeduren xp_regread und xp_dirtree. Natürlich können wir auch die entsprechenden DLL-Dateien zusammen löschen.
Wenn das Webverzeichnis jedoch aufgrund eines Programmfehlers offengelegt wird, können Sie nichts tun. Daher müssen wir auch die Berechtigungen des Kontos herabsetzen, damit der Sicherungsvorgang nicht abgeschlossen werden kann. Die spezifischen Vorgänge sind wie folgt: In den Eigenschaften dieses Kontos – Datenbankzugriffsoptionen – müssen Sie nur die entsprechende Datenbank auswählen und ihr DBO-Berechtigungen erteilen. Betreiben Sie keine anderen Datenbanken. Gehen Sie dann zu den Datenbankeigenschaften-Berechtigungen, um die Sicherungs- und Sicherungsprotokollberechtigungen des Benutzers zu entfernen, damit Eindringlinge nicht durch differenzielle Sicherung an die Webshell gelangen können.
