ubuntuusers.de

Hallo,

wir haben ein CRM system für unsere kleine Firma auf einem VPS. Gern würde ich eine Art white listing / sicheren Login dafür konfigurieren. (Auf Server / Apache Ebene, nicht OWASP/Software Ebene)

Ziel: Alle die nicht auf der white list sind und/oder Zugriff x mal falsch versuchen, ab in die IPTables DROP section.

Gegeben:

• ca. 15 Benutzer, verteilt über mehrere Länder mit statischen und dynamischen IPs.

• Zugriff über Browser (Chrome oder Smartphone)

• 4 Software Benutzer (API/etc.) auf verschiedenen Servern, zwei davon Drittanbieter die wir nicht gut konfigurieren können. Alle 4 sollten statische IPs haben.

Hatte jetzt mehrere Ideen recherchiert und wollte mal eure Meinung hören, was sinnig ist.

IPTables
Von Maxmind oder IPDeny die IP Zonen der paar Länder wo wir sind und die Software nutzer IP auf die ACCEPT List
Alles andere auf DROP
Etwas riskant, falls die user mal andere IPs bekommen sollte die nicht im richtigen Land sind und der Rest des Landes hat auch Zugriff, ...?

.htpasswd
die 4 Software Benutzer ausschließen mit <If "%{REMOTE_ADDR} != 'IP'"> in der vhost
fail2ban mit apache-auth nach 2 Versuchen
Recht einfache Lösung, "relativ sicher", ...?

X.509
Zertifikate generieren und bei den usern im Browser installieren.
Problem wären dann die Software Nutzer
Relative komplexe Lösung, viel Admin aufwand, sehr sicher, ...?

IPTables advanced
Ein kleines Program/Skript welches die eigene IP an einen server 2 schickt und als txt oder so in einer web / ssh zugänglichen Datei speichert.
Der CRM Server holt sich per cron die txt ab und fügt neue IPs in die ACCEPT chain (alte werden idealerweise gelöscht).
Etwas Aufwand mit dem Skript, sehr sichers white listing, ...?

Transmitter schrieb:

Alle die nicht auf der white list sind und/oder Zugriff x mal falsch versuchen, ab in die IPTables DROP section.

Das kannst du mit fail2ban erreichen.

Gegeben:

• ca. 15 Benutzer, verteilt über mehrere Länder mit statischen und dynamischen IPs.

• Zugriff über Browser (Chrome oder Smartphone)

• 4 Software Benutzer (API/etc.) auf verschiedenen Servern, zwei davon Drittanbieter die wir nicht gut konfigurieren können. Alle 4 sollten statische IPs haben.

Hatte jetzt mehrere Ideen recherchiert und wollte mal eure Meinung hören, was sinnig ist.

Also eine Beschränkung auf IP-Basis halte ich hier nicht für sinnvoll. Eine Client-Auth im Browser per X.509 wäre denkbar. Ich würde dir aber empfehlen die Nutzer einfach ein VPN aufbauen zu lassen. Das kannst du beispielsweise mit OpenVPN machen. Vermehrte Fehlversuche kannst du per fail2ban in iptables blocken. Das hat auch den Vorteil, dass die Weboberfläche nach außen hin gar nicht verfügbar sein muss. OpenVPN ist auf den meisten Geräten und Betriebssystemen verfügbar. Es gibt auch zahlreiche Anleitungen im Netz, sodass auch unerfahrenere Nutzer damit umgehen können sollten.

Zu deinem letzten Vorschlag: So eine Art Portknocking kann man schon machen, ist aber AFAIK nicht sehr verbreitet.

Hallo Transmitter,

ich sehe das ähnlich wie misterunknown: Bau dir einen OpenVPN-Host auf und lass die Benutzer darüber auf das CRM zugreifen. Du hast damit eine wesentlich bessere Kontrolle über die einzelnen Aspekte der Verbindung und bist nicht auf (kostenpflichtige?) GeoIP-Listen angewiesen, die dir wahrscheinlich mehr Arbeit machen als dass sie einen Nutzen haben.

Im Fall der nicht-menschlichen Benutzer kannst du ja schauen, wie weit gut kommst. Da du nur zwei von den vier Benutzern als extern beschreibst, könntest du das mit dem VPN zumindest auch mit den beiden eigenen Benutzern machen.

Ich gehe mal davon aus, dass der Austausch mit den Drittanbietern zumindest verschlüsselt ist. Wenn es sonst keine Alternativen gibt, bleibt dir für die Systeme wirklich erstmal nur ein Whitelisting, denke ich mal. Aber vielleicht kannst du doch was Einzel- oder Site-to-Site-VPN machen. Bei letzterem dann aufpassen, dass nicht zu viel Site von dir gesehen werden kann. 😉

Ja, VPN klingt nach der Ideallösung. Problem sind nur die Software Benutzer und das Kontaktformular. Das können IPs von überall sein, da lassen sich schlecht Ausnahmen in routing tables hinzufügen o. Ä.

Eine Site-to-Site Lösung würde die Webapplikation für das Internet, noch immer offen zugänglich lassen?

Inwiefern soll das Kontaktformular ein Problem sein? Der Anwender baut die VPN-Verbindung auf und benutzt dann den Browser zum Aufrufen der entsprechenden Seite. Je nach Geräteanbieter muss der Anwender dafür zwei bis drei Taps/Klicks vor Bearbeitung des Formulars und nach Bearbeitung des Formulars ausführen, damit die Verbindung aufgebaut und wieder abgebaut wird.

Gehen wir aber nochmal einen Schritt zurück in die ursprüngliche Aufgabe. Du sprichst von einem VPS und das wird voraussichtlich eh nicht in eurem Firmennetz liegen, sondern außerhalb. VPN wird dadurch nicht weniger möglich, aber deutlich weniger nützlich. 😉

Wenn ihr die Webapplikation nicht in die Zentrale zurückholen wollt (keine Kapazitäten, zu wenig Bandbreite, …) sieht die Authentifizierung mit Client-Zertifikaten schon nach der deutlich besten Lösung für dein Problem aus. Mit den richtigen Werkzeugen ist die Client-Authentifizierung auch für deine Software-Benutzer möglich. Allerdings weiß ich hier nicht, was "nicht gut konfigurieren können" im ersten Beitrag nun genau heißen soll.

Zertifikatsbasierte Anmeldeverfahren haben im Gegensatz zur Anmeldung mit einem Passwort den Vorteil, dass Brute Force-Verfahren hier wenig helfen. Zusätzlich ist ein Rate Limiting von Angriffen mit Tools wie fail2ban eine nette Möglichkeit, Angreifern das Leben noch schwerer zu machen.

Auf der anderen Seite bieten dir Zertifikate auch die Möglichkeit, den Zugriff deiner Anwender besser zu steuern. Soll einer nur mal zwei Wochen reinschnuppern, gibt es eben erstmal nur ein Zertifikat, das zwei Wochen hält. Will er danach nochmal rein, wird er dich schon nerven. Im Gegensatz dazu ist es recht leicht, mal ein Passwort einzurichten und den Account dann für immer zu vergessen.

Site-to-Site-Verbindungen machen genau das: Zwei getrennte Netzwerke mit Hilfe eines Tunnels durch ein weiteres (in der Regel ein öffentliches: das Internet) Netzwerk zu verbinden.