Sacht mal, seit WANN muss man bei einer WAF Freigabe eines Webservers nach außen hin für die Kommunikation der UTM zum internen Webserver eine Firewall Regel auf der UTM schreiben???
Ich hab gestern nicht schlecht geguckt, eine vorhandene WAF Freigabe oder besser gesagt, 2x davon über zwei externe URLs mit 2x verschiedenen Forms für die Anmeldung (wegen zwei verschiedenen AD-Backends/zwei übergebenen Domains) -> extern auf die UTM public IP via HTTPS, intern am Webserver auf TCP9001 via HTTPS und alles ist schick... Nun war das Problem, dass aus 1x interner Webserver 2x derer werden sollten, welche auf der gleichen internen IP lauschen, aber verschiedene Ports nutzen.
Ich also zwei neue "Real Webserver" angelegt, jeweils mit der IP und entsprechenden Ports (TCP9010 + TCP9011), weiterhin via HTTPS und die beiden WAF Freigaben 1:1 nur umgeboten... Dann getestet, nix!???
-> via Telnet von der Konsole versucht, TCP9010 und TCP9011 zu öffnen -> nix
-> via Telnet TCP9001 -> also die alte Verbindung probiert -> geht
-> nach Firewall Rules auf der UTM geschaut -> keine!! vorhanden, also NUR die default Drop Rule
-> mein Netzwerker zusammen geschissen, warum die UTM noch nicht via TCP9010/9011 zum Webserver kommt -> gecheckt, alles sauber eingetragen, gesniffert, kommen gar keine Pakete an
-> wieder UTM, Firewall Livelog und siehe da, Verbindungen von der UTM internen Interface IP zum Real Webserber mit TCP9010 und TCO9011 weden geblockt, sowohl IPv4 als auch v6... Es blockt die default Drop Rule!?
Was zur Hölle läuft da schief??
-> UTM ist die neueste Version von gestern, hab extra nochmal ein Update drüber geschoben... Vorher die 9.405, damit gings aber auch nicht.
-> Booten hilft nicht, sprich bringt keine Besserung... TCP9001 geht (ist aber schon Monate dort als WAF drin), die neu eingerichteten TCP9010 und TCP9011 NICHT??
Ist das ein Bug? Oder ist das gewollt??
Bei NICs halte ich das eher für unnötig/Unsinn - die Verwaltung kann man getrost dem Host (unter ESXi wie Hyper-V) überlassen und wenn man aus "Sicherheitsgründen" den Host nicht in diesem Netz haben will, geht das auch mit Bordmitteln. Die richtigen NICs sind genau dafür gemacht mit SR/IOV, remoteDMA & Co., da wirfst Du Performance eher inne Tonne als das es irgendwas bringt. Dafür spricht auch, dass PCIe-Passthrough bei den beiden großen Virtualisierern (wieder ESXi und Hyper-V) häufig nicht (voll) supported ist bzw. andere Features wegfallen, die man eigentlich gerne hätte.
Nunja, es dürfte in der Tat eher das Thema Sicherheit sein... Du gibst dein Vertrauen halt dem Networkstack des Hypervisors, durchgereicht zur VM liegt das Vertrauen halt bei der VM -> und dessen Networkstack/Treibern.
Relevant wird das genau an der Stelle, wenn über diesen Link potentiell das System angreifbar ist/wird... Durchgereicht an die VM = weg vom System = nicht angreifbar über diesen Weg.
Ob einem das nun den Spaß wert ist, muss selbst gewusst werden... Denn andersrum, potentiell angreifbar ist auch der Weg über die VM, durch den Virtualisierungslayer -> zumindest bei kapitalen Sicherheitsproblemen in Software. Rein aus dem Bauchgefühl herraus, bei einem Hyper-V aka MS Windows Based -> NICs durchreichen
, bei einem Unix/Linux based Hypervisor -> kann man das auch weglassen