Beiträge von Rebus

Ich werfe mal noch Saltstack in den Ring, fuer die Python Fetischisten. Ausserdem bekoommt man da gleich ein Orchestration-Tool mit und nicht nur nen bloedes CMS Einziger Haken, ne richtige Weboberflaeche bekommt man da nur wenn man die kommerzielle Variante kauft oder sich selber eine bastelt, z.B. mit Rundeck.

Wenn man auf ssh managed server steht, tut es auch Ansible, scheint gerade groß im kommen zu sein. Und fuer Schmerzresistente ist cfengine in der neueren Version wohl auch eine Moeglichkeit.
Falls du mehr auf Selbstgebautes stehst, kann auch ein Rudel Bashscripte mit etckeepr und noch ein paar Tools weiterhelfen.

Last but not least sei erwaehnt, dass Debian basierte Systeme mittels debconf theoretisch auch "automatisiert" werden koennen.
Und really least diese Liste Comparison of open-source configuration management software - Wikipedia, the free encyclopedia

Viel Spaß beim ausprobieren.

Hallo Sagandi,

Reverseproxies kenne ich leider nur aus der Linuxwelt, meine Erfahrungen mit Windows basieren da auf Hoerensagen. Softwareloesungen die mir einfallen und wohl ganz gut funktionieren sind:

- Apache mit mod-proxy (Using Apache HTTP Server on Microsoft Windows - Apache HTTP Server Version 2.4 mod_proxy - Apache HTTP Server Version 2.4)
- Squid (SquidFaq/ReverseProxy - Squid Web Proxy Wiki Configuring a Basic Reverse Proxy in Squid on Windows (Website Accelerator) | Accumulative Effect)
- IIS mit ARR (Scott Forsyth's Blog - Creating a Reverse Proxy with URL Rewrite for IIS)

Meine bevorzugte Loesung fuer Linux ist NGINX, aber der ist leider unter Windows weder performant noch stabil.

Die Grundidee ist dabei aber immer Dieselbe; Ein Webserver der alle Zugriffe auf die auf den VMs gehosteten Domains annimmt, diese nach Domain filtert (z.B. indem er einen VHost pro Domain betreibt) und dann als http-proxy an den Webserver im internen Netzwerk (d.h. auf die IP deiner VMs) durchleitet.

Ich hoffe das hilft dir weiter, im Zweifel probiere mal ein wenig herum.

Viele Gruesse,

Eine Möglichkeit o.g. Projekt durchzuführen ist, auf einem der drei oder einer weiteren VM einen Reverse-Proxy zu betreiben der unter der öffentlichen IP des Servers erreichbar ist (Portforwarding o.Ä.), für alle drei Domains und den HTTP Traffic dann auf die drei VMs im internen Netz aufspaltet. Ich mache Ähnliches mit Docker Containern und das funktioniert recht gut.

Eine Alternative wäre noch, reine IPv6 VHosts zu betreiben, beeinträchtigt aber die Menge der potentiellen Besucher (.i.e die müssen IPv6 haben).

Was Skulduggerys Frage nach dem Warum angeht, kann ich zwar nur vermuten aber mir fällt ein:

* Security; wenn ein Webhost bricht, brechen nicht alle
* Performance; Sowohl was shaping als auch mesaurement angeht lassen sich VM wesentlich besser beeinflussen als Webserver-Prozesse
* Maintenance; Deployment und Updates werden einfacher, weil man die VM einfach wegtun und eine neue starten kann und das tatsächlich nur diese eine VM/Website betrifft, Backups lassen sich einfach als VM-Snapshots durchführen. Portabilität ist auch leichter, weil man nicht erst Konfiguration und Daten aus dem Webserver rauspulen muss.

Wichtig ist aber auf jeden Fall Skulduggerys Komemntar zum Typ deines Servers - AFAIk unterstützen die standard-VMs von Netcup keine Nested Virtualisierung. Möglicherweise gibt es eine Containerlösung von Kleinweich die da Alternativ verwendet werden kann?

Viele Grüße,

Hi,

zur Erklaerung; Wenn dein Netzwerkinterface mittels DHCP konfiguriert wird, bekommt es alle naslang ein Update seiner IP und Nameserveradressen zugesand. Ein guter DHCP client erkennt wenn sich nichts aendert, ein Schlechter schreibt dann die zugehoerigen Dateien neu (Die resolv.conf wird fuer Nameserver genutzt) - was zu Warnungen in tripwire fuehren kann.

/dev/pts/0 ust ein pseudoterminalslave device das vor allem fuer terminal emulatoren gebraucht wird, z.B. bei SSH oder SCP-Zugaengen, aber auch von Programmen die mittels des Befehls 'su' arbeiten.

Falls du darueber mehr wissen willst, empfehle ich die Manpages deines Systems: man pts und man resolvconf.
Falls du mehr ueber tripwire wissen willst, schau dich am besten mal in deren Fora um Open Source Tripwire® / Discussion / Discussion und falls du mal eine Alternative sehen willst, wirf einen Blick auf Samhain Samhain Labs | samhain

Hoffe das hilft dir weiter

Falls die Partitionen groesser als der inhalt sind, empfehle ich mal es mit parted zu versuchen und die groesse auf den inhalt anzupassen, dann migrieren und die groesse wieder auf festplattengroesse aufblasen.

Edit: Wie immer bei frickeleien an platte, dateisystem oder partitionen, vorher Backup machen!

Vielleicht zur Erklaerung warum SSL besser ist als unverschluesselt:

Wenn die Seite unverschluesselt ist, kann jeder mitlesen und veraendern was sich jemand anders auf diesem Blog anguckt, der sich irgendwo in einem Netzwerk zwischen dem Abrufenden und deinem Blog befindet. Das reicht vom einsammeln wer was liest, ueber das veraendern von Textinhalten bis zum unterjubeln von Malware und anderem Geschmeiss.

SSL kann das zwar nicht vollstaendig verhindern, macht es aber wesentlich schwerer und gibt dir und deinen Lesern zumindest die Chance unerkannt und unbelaestigt in deinem Blog zu lesen.

Das betrifft nebenbei auch Logins, private Nachrichten (Falls der Blog sowas kann), Kommentare u.a. Sofern sich also z.B. der Login unterhalb der Blog-URI befindet, waere er ohne SSL vor Mitlesern ungeschuetzt.

Last but not least, um einen Teilbereich deiner Seite unverschluesselt auszuliefern ist ein verbreiteter Ansatz, diesen ueber eine Subdomain anzubieten (blog.meinedomain.de) und Zugriffe auf die Blog-URI entsprechend umzuleiten. Auf diese Weise kann deine Seite weiterhin Mechanisment wie HSTS benutzen und der Blog bleibt trotztdem unverschluesselt.
Dafuer musst du z.B. im NginX-Webserver eine location einrichten die auf die Blog Sub-URI matched und dort ein return 301 blog.meinedomain.de zurueck geben. Ein weiterer DNS Eintrag und VHost der dann auf die entsprechende Domain reagiert kann dann unverschluesselt konfiguriert sein.

Statt ohne SSL zu arbeiten koenntest du mal bei einem der kostenlosen ssl Anbieter nachsehen.

Wie oben genannt solltest du mal versuchen dein Interface komplett statisch zu konfigurieren. Die 30 Minuten riechen ziemlich stark nach dem timeout einer DHCP lease.

Ich erinnere mich, das Problem bei der Ersteinrichtung von IPv6 ebenfalls gehabt zu haben. Erst nachdem ich mein Netztwerk komplett statisch konfiguriert hatte, gingen mir auch meine IPv6 Einstellungen nicht mehr verloren.

Falls dein DHCP-Client einen Debugmodus unterstuetzt, waere das vielleicht auch eine Option um festzustellen ob er der Uebeltaeter ist.

Ich nehme an dir ist unklar was einn "offener Port" ist. Im wesentlichen unterteilt sich das oeffnen eines Ports in zwei Teile:

• Ein Dienst muss auf einem Port lauschen. Dafuer muss der Dienst gestartet sein, z.B. ein Webserver, der dann auf port 80 oder 443 lauscht. Feststellen kann man das dann mit dem Befehl netstat -tulpen Dort sollte sowohl der Port als auch die Netzwerkadresse und der Dienst aufgelistet werden. Wenn wir beim Beispiel des Webservers bleiben, sieht das in etwa so aus:
  
  Code

  #> netstat -tulpen
  Active Internet connections (only servers)
  Proto Recv-Q Send-Q Local Address       	Foreign Address     	State   	User   	Inode   	PID/Program name
  tcp6   	0  	0 :::80               	:::*                	LISTEN  	0      	3202817 	67/apache2

  
  Auf manchen Systemen ist kein netstat installiert, dann kann es sein, das man stattdessen den Befehl ss -tulpen nutzen kann. Um zu sehen ob der Prozess ueberhaupt gestartet ist, hilft der Befehl ps faux oder auf machen systemen auch pstree.

  
  

• Der Port muss, sofern gewollt, von aussen erreichbar gemacht werden.
  
  
  • Hat man keine Firewall installiert oder laufen (z.B. iptables), muss nichts weiter getan werden. Testen kann man dann ob ein Dienst auf dem Port erreichbar ist z.B. mit dem Befehl telnet <adresse auf der der dienst lauscht> <port>.
  • Hat man eine Firewall installiert und laufen, muss man sehr wahrscheinlich den Zugriff von aussen auf diesen Port freigeben. Das haengt zwar von der Konfiguration der Firewall ab aber im wesentlichen laeuft es darauf hinaus, dass man Zugriffe von einer oder mehrerer Quelladressen auf die Zieladresse (z.B. die Oeffentliche) und den konkreten Port erlauben muss. Im Falle von iptables sieht dass z.B. so aus:
    
    Code

    iptables -I INPUT 1 -s <quelladresse> -d <zieladresse> -p tcp --dport <portnummer> -j ACCEPT

    Will man den Zugriff von beliebigen Adressen aus erlauben, laesst man den Teil -s <quelladresse> einfach weg. Ansehen kann man sich das ganze dann mit dem Befehl iptables -vnL INPUT

Ich empfehle dir, mal einen Blick hierherein zu Werfen um dich weiter zu informieren: Rheinwerk Computing :: Linux - 15 Netzwerkgrundlagen

Viele Gruesse,

Das A+ bekommst du uebrigens sobald du HSTS einschaltest
Und ja die Beschreibung fuer dhparam ist so simpel wie sie sich anhoert, das dhparam.pem einfach an das Zertifikat konkatenieren.

Du hast insofern recht, das der DS Eintrag in der .de Zone vollkommen ausreichend sein sollte.

Je nach Registry wird das aber anders gehandhabt und tatsaechlich ist es sogar netter den DNSKEY Record des KSK eine Zone hoeher schon anzulegen. Damit spart man sich eines DNS Roundtriptime und kann direkt die ZSK und ihre Signaturen aus dem DNS deiner Zone abfragen und validieren.

Ich rate auf jeden Fall dazu mal hier nachzusehen um sich mit dem Thema eingehender vertraut zu machen und vor allem auch das Key-Management hinzubekommen und zu _testen_:

- Good Practices Guide for Deploying DNSSEC — ENISA
- DNSSEC Policy and Practice Statement — RIPE Network Coordination Centre

Viele Gruesse

Ich nehme mal an du meinst den Mailservice von NetCup selber?

Wenn du einen eigenen Mailserver betreibst sollte es dir wohl auch moeglich sein, dich um SSL Konfiguration und DNS eintraege fuer TLSA und DNSSEC selbst zu kuemmern.

Wenn man dem -I noch ein "INPUT 1" nachstellt passt das dann auch

Der Vollstaendigkeit halber sei hier noch auf xtables mit geoip filter verwiesen; siehe auch

Frustrate SSH Scanners with Iptables GeoIP Blocking - Internet Staff oder
http://www.atwillys.de/content…p-and-iptables-on-ubuntu/

Ich schlage vor, du fuehrst dir das hier mal zu Gemuete: ProFTPD: FTP and SSL/TLS