Kunden kontrollieren und überwachen den Zugriff auf Kundenservices, einschließlich des Netzwerkzugriffs auf ihre VMs (über auf den Kunden-VMs implementierte Layer 2-VLANs und Firewalls), der Authentifizierung für den Zugriff auf die VMs und der Authentifizierung für den Zugriff auf Datenbanken, die auf den VMs ausgeführt werden. Oracle kontrolliert und überwacht den Zugriff auf von Oracle verwaltete Infrastrukturkomponenten. Mitarbeiter von Oracle sind nicht berechtigt, auf Kundenservices zuzugreifen, einschließlich der VMs und Datenbanken von Kunden.

Der Zugriff von Kunden auf Oracle-Datenbanken, die auf Exadata Cloud@Customer ausgeführt werden, erfolgt über eine Layer 2-Verbindung (getaggte VLAN-Verbindung) von den Kundengeräten zu den Datenbanken, die auf der Kunden-VM ausgeführt werden. Dazu werden Oracle Database-Standardverbindungsmethoden wie Oracle Net auf Port 1521 verwendet. Der Zugriff von Kunden auf die VM, auf der die Oracle-Datenbanken ausgeführt werden, erfolgt über Oracle Linux-Standardmethoden wie tokenbasierte SSH an Port 22.

• Defense-in-Depth

  Exadata Cloud@Customer bietet eine Reihe von Kontrollen, um die Vertraulichkeit, Integrität und Rechenschaftspflicht im gesamten Service sicherzustellen.

  Zunächst wird Exadata Cloud@Customer aus dem sicheren Betriebssystemimage erstellt, das von Exadata Database Machine bereitgestellt wird. Weitere Informationen finden Sie unter Überblick über die Sicherheit in Oracle Exadata Database Machine. Hierbei wird die Kernbetriebsumgebung gesichert, indem das Installationsimage nur auf die erforderlichen Softwarepackages beschränkt, unnötige Services deaktiviert und sichere Konfigurationsparameter im gesamten System implementiert werden.

  Neben allen Stärken der ausgereiften Plattform von Exadata Database Machine, die durch das Provisioning von Systemen durch Exadata Cloud@Customer für Kunden gegeben sind, werden zusätzliche sichere Standardkonfigurationsoptionen in den Serviceinstanzen implementiert. Beispiel: Alle Datenbank-Tablespaces erfordern transparente Datenverschlüsselung (TDE), die Durchsetzung sicherer Kennwörter für anfängliche Datenbankbenutzer und Superuser sowie erweiterte Audit- und Ereignisregeln.

  Exadata Cloud@Customer stellt auch ein vollständiges Deployment und einen vollständigen Service dar, daher unterliegt es externen Branchenstandards wie PCI, HIPAA und ISO27001. Diese externen Auditanforderungen bedeuten, dass zusätzliche Mehrwert-Servicefeatures wie Antiviren-Scans, automatische Warnungen bei unerwarteten Systemänderungen und tägliche Scans auf Sicherheitslücken bei allen von Oracle verwalteten Infrastruktursystemen in der Flotte erforderlich sind.

• Least Privilege

  Um sicherzustellen, dass Prozesse nur Zugriff auf die Berechtigungen haben, die sie benötigen, erfordern die Oracle Secure Coding Standards das Least-Privilege-Prinzip.

  Jeder Prozess und jeder Daemon muss als normaler, nicht privilegierter Benutzer ausgeführt werden, es sei denn, es kann nachgewiesen werden, dass er eine höhere Berechtigungsstufe erfordert. Auf diese Weise können unvorhergesehene Probleme oder Sicherheitslücken auf den nicht privilegierten Benutzerbereich beschränkt und eine Gefährdung des gesamten Systems vermieden werden.

  Dieses Prinzip gilt auch für Mitglieder des Oracle Operations-Teams, die individuell benannte Accounts für den Zugriff auf die Oracle Exadata Cloud@Customer-Infrastruktur zur Wartung oder Fehlerbehebung verwenden. Nur bei Bedarf verwenden sie den auditierten Zugriff auf höhere Berechtigungsstufen, um ein Problem zu lösen oder zu beheben. Die meisten Probleme werden durch automatisierte Prozesse gelöst. Daher wenden wir das Least-Privilege Prinzip auch an, indem wir Mitarbeitern keinen Zugriff auf ein System gestatten, es sei denn, eine automatisierte Lösung des Problems ist nicht möglich.

• Auditing und Rechenschaftspflicht

  Bei Bedarf ist der Zugriff auf das System zulässig, aber alle Zugriffe und Aktionen werden protokolliert und zum Zweck der Rechenschaftspflicht verfolgt.

  Dadurch wird sichergestellt, dass sowohl Oracle als auch Kunden wissen, was auf dem System zu welchem Zeitpunkt geschehen ist. Diese Tatsachen stellen nicht nur sicher, dass wir die Berichtsanforderungen für externe Audits weiterhin erfüllen, sondern können auch dazu beitragen, eine Veränderung mit einer Veränderung des wahrgenommenen Verhaltens in der Anwendung abzugleichen.

  Auditfunktionen werden in allen Infrastrukturkomponenten bereitgestellt, um sicherzustellen, dass alle Aktionen erfasst werden. Kunden können Auditing auch für ihre Datenbank- und Gast-VM-Konfiguration konfigurieren und diese nach Wahl in andere Unternehmensauditsysteme integrieren.

• Automatisierung des Cloud-Betriebs

  Durch den Wegfall manueller Vorgänge für Provisioning, Patching, Wartung, Fehlerbehebung und Konfiguration von Systemen wird das Fehlerrisiko reduziert und eine sichere Konfiguration gewährleistet.

  Der Service ist so konzipiert, dass er sicher ist. Durch die Automatisierung aller Provisioning-, Konfigurations- und der meisten anderen operativen Aufgaben kann vermieden werden, dass nicht erfasste Konfigurationen durchgeführt werden. Außerdem wird sichergestellt, dass alle erforderlichen Pfade in das System fest geschlossen sind.

• Sicheres Betriebssystemimage
  • Minimale Packageinstallation:

    Nur die für den Betrieb eines effizienten Systems erforderlichen Packages werden installiert. Durch die Installation eines kleineren Packagesets wird die Angriffsfläche des Betriebssystems reduziert, und das System bleibt sicherer.

  • Sichere Konfiguration:

    Viele nicht standardmäßige Konfigurationsparameter werden während der Installation festgelegt, um den Sicherheitsstatus des Systems und seines Inhalts zu verbessern. Beispiel: SSH ist so konfiguriert, dass nur bestimmte Netzwerkschnittstellen überwacht werden, Sendmail ist so konfiguriert, dass nur Localhost-Verbindungen akzeptiert werden, und viele weitere ähnliche Einschränkungen werden während der Installation implementiert.

  • Nur erforderliche Services ausführen:

    Services, die zwar auf dem System installiert, jedoch für den normalen Betrieb nicht erforderlich sind, sind standardmäßig deaktiviert. Beispiel: Obwohl NFS ein Service ist, der häufig von Kunden für verschiedene Anwendungszwecke konfiguriert wird, ist er standardmäßig deaktiviert, da er für normale Datenbankvorgänge nicht erforderlich ist. Kunden können optional Services entsprechend ihren Anforderungen konfigurieren.

• Minimale Angriffsfläche

  Als Teil des sicheren Images wird die Angriffsfläche durch Deaktivieren von Services reduziert.

• Zusätzliche Sicherheitsfunktionen aktiviert (Grub-Kennwörter, sicheres Booten)
  • Mit den Exadata-Imagefunktionen verfügt Exadata Cloud@Customer über die Funktionen, die in das Basisimage integriert sind, darunter Grub-Kennwörter, sicheres Booten und viele andere.
  • Durch Anpassung können Kunden ihren Sicherheitsstatus weiter verbessern. Diese zusätzlichen Konfigurationen werden weiter unten in diesem Kapitel beschrieben.
• Sichere Zugriffsmethoden
  • Der Zugriff auf Datenbankserver über SSH erfolgt über starke kryptografische Cipher. Schwache Cipher sind standardmäßig deaktiviert.
  • Zugriff auf Datenbanken über verschlüsselte Oracle Net-Verbindungen. Standardmäßig sind unsere Services über verschlüsselte Kanäle verfügbar, und ein Oracle Net-Client verwendet in der Standardkonfiguration verschlüsselte Sessions.
  • Zugriff auf Diagnosefunktionen über die Exadata MS-Webbenutzeroberfläche (HTTPS).
• Auditing und Logging

  Standardmäßig ist das Auditing für administrative Vorgänge aktiviert, und die Auditdatensätze werden zur automatischen Prüfung und gegebenenfalls Benachrichtigung an interne OCI-Systeme weitergeleitet.

• Überlegungen zur Deployment-Zeit
  • Inhalt und Empfindlichkeit des Wallet-Dateidownloads: Der Wallet-Download, der von einem Kunden zur Ermöglichung des Deployments abgerufen wird, enthält vertrauliche Informationen und muss entsprechend behandelt werden, um sicherzustellen, dass der Inhalt geschützt ist. Der Inhalt des Wallet-Dateidownloads wird nach Abschluss des Deployments nicht mehr benötigt. Daher muss er gelöscht werden, um sicherzustellen, dass keine Informationen verloren gehen.
  • Control-Plane-Server (CPS):
    • Zu den Deployment-Anforderungen für den CPS gehören das Gewähren des Zugriffs auf ausgehendendes HTTPS, damit der CPS eine Verbindung zu Oracle herstellen und Remoteadministration, -monitoring und -wartung ermöglicht wird. Weitere Informationen finden Sie in der Deployment-Dokumentation.
    • Zu den Kundenzuständigkeiten gehören die Bereitstellung physischer Sicherheit für die Exadata Cloud@Customer-Geräte in ihrem Data Center. Zwar nutzt Exadata Cloud@Customer viele Softwaresicherheitsfunktionen, doch muss eine physische Beeinträchtigung der Server durch die physischen Sicherheitsmaßnahmen des Kunden verhindert werden, damit die Sicherheit des Serverinhalts gewährleistet ist.

Mehrere Benutzeraccounts verwalten die Komponenten von Oracle Exadata Cloud@Customer regelmäßig. Auf allen Exadata Cloud@Customer-Rechnern verwendet und empfiehlt Oracle nur SSH-basierte Anmeldungen. Kein Oracle-Benutzer oder -Prozess verwendet das kennwortbasierte Authentifizierungssystem.

Im Folgenden werden die verschiedenen Benutzer beschrieben, die standardmäßig erstellt werden.

• Standardbenutzer: Keine Anmeldeberechtigungen

  Diese Benutzerliste besteht aus Standardbenutzern des Betriebssystems sowie einigen speziellen Benutzern wie exawatch und dbmsvc. Diese Benutzer dürfen nicht geändert werden. Diese Benutzer können sich nicht beim System anmelden, da alle auf /bin/false gesetzt sind.

  • exawatch:

    Der Benutzer exawatch ist für das Erfassen und Archivieren von Systemstatistiken auf den Datenbank- und den Speicherservern zuständig.

  • dbmsvc:

    Der Benutzer wird für den Management Server im Datenbankknotenservice auf dem Oracle Exadata-System verwendet.

  NOLOGIN-Benutzer

  bin:x:1:1:bin:/bin:/bin/false
  daemon:x:2:2:daemon:/sbin:/bin/false
  adm:x:3:4:adm:/dev/null:/bin/false
  mail:x:8:12:mail:/var/spool/mail:/bin/false
  nobody:x:99:99:Nobody:/:/bin/false
  systemd-network:x:192:192:systemd Network Management:/:/bin/false
  dbus:x:81:81:System message bus:/:/bin/false
  rpm:x:37:37::/var/lib/rpm:/bin/false
  sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/bin/false
  rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/bin/false
  nscd:x:28:28:NSCD Daemon:/:/bin/false
  saslauth:x:999:76:Saslauthd user:/run/saslauthd:/bin/false
  mailnull:x:47:47::/var/spool/mqueue:/bin/false
  smmsp:x:51:51::/var/spool/mqueue:/bin/false
  chrony:x:998:997::/var/lib/chrony:/bin/false
  rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/bin/false
  uucp:x:10:14:Uucp user:/var/spool/uucp:/bin/false
  nslcd:x:65:55:LDAP Client User:/:/bin/false
  tcpdump:x:72:72::/:/bin/false
  exawatch:x:1010:510::/:/bin/false
  sssd:x:997:508:User for sssd:/:/bin/false
  tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/bin/false
  dbmsvc:x:12137:11137::/home/dbmsvc:/bin/false

• Standardbenutzer mit eingeschränktem Shellzugriff

  Diese Benutzer werden verwendet, um eine definierte Aufgabe mit einer eingeschränkten Shellanmeldung auszuführen. Diese Benutzer dürfen nicht geändert werden, weil die definierte Aufgabe nicht erfolgreich ausgeführt wird, wenn diese Benutzer geändert oder gelöscht werden.

  dbmmonitor: Der Benutzer dbmmonitor wird für das DBMCLI-Utility verwendet. Weitere Informationen finden Sie unter DBMCLI-Utility verwenden.

  Eingeschränkte Shellbenutzer

  dbmmonitor:x:2003:2003::/home/dbmmonitor:/bin/rbash

• Standardbenutzer mit Anmeldeberechtigungen

  Diese privilegierten Benutzer werden zur Ausführung der meisten Aufgaben im System verwendet. Diese Benutzer dürfen niemals geändert oder gelöscht werden, da dies erhebliche Auswirkungen auf das laufende System hätte.

  SSH-Schlüssel werden für die Anmeldung von Kundenpersonal und für die Cloud-Automatisierung verwendet.

  Vom Kunden hinzugefügte SSH-Schlüssel können mit der Methode UpdateVmCluster hinzugefügt werden, oder von Kunden, die direkt auf die Kunden-VM zugreifen und SSH-Schlüssel innerhalb der Kunden-VM verwalten. Die Kunden sind dafür verantwortlich, Kommentare zu Schlüsseln hinzuzufügen, damit sie identifiziert werden können. Wenn ein Kunde den SSH-Schlüssel mit der Methode UpdateVmCluster hinzufügt, wird der Schlüssel nur der Datei authorized_keys des Benutzers opc hinzugefügt.

  Cloud-Automatisierungsschlüssel sind temporär und spezifisch für eine bestimmte Cloud-Automatisierungsaufgabe, wie die Skalierung des VM-Clusterarbeitsspeichers. Sie sind eindeutig. Zugriffsschlüssel für die Cloud-Automatisierung können mit den folgenden Kommentaren identifiziert werden: OEDA_PUB, EXACLOUD_KEY, ControlPlane. Cloud-Automatisierungsschlüssel werden nach Abschluss der Cloud-Automatisierungsaufgabe entfernt, sodass die authorized_keys-Dateien der Accounts root, opc, oracle und grid nur Cloud-Automatisierungsschlüssel enthalten, solange die Cloud-Automatisierungsaktionen ausgeführt werden.

  Privilegierte Benutzer

  root:x:0:0:root:/root:/bin/bash
  oracle:x:1001:1001::/home/oracle:/bin/bash
  grid:x:1000:1001::/home/grid:/bin/bash
  opc:x:2000:2000::/home/opc:/bin/bash
  dbmadmin:x:2002:2002::/home/dbmadmin:/bin/bash

  • root: Linux-Anforderung, die sparsam für die Ausführung lokaler privilegierter Befehle verwendet wird. root wird auch für einige Prozesse wie Oracle Trace File Analyzer Agent und ExaWatcher verwendet.
  • grid: Eigentümer der Oracle Grid Infrastructure-Softwareinstallation, führt Grid Infastructure-Prozesse aus.
  • oracle: Eigentümer der Installation der Oracle-Datenbanksoftware, führt Oracle Database-Prozesse aus.
  • opc:
    • Wird von der Oracle Cloud-Automatisierung für Automatisierungsaufgaben verwendet.
    • Ermöglicht die Ausführung bestimmter privilegierter Befehle ohne weitere Authentifizierung (zur Unterstützung von Automatisierungsfunktionen).
    • Führt den lokalen Agent aus, der auch als "DCS-Agent" bezeichnet wird und Lebenszyklusvorgänge für Oracle Database- und Oracle Grid Infastructure-Software ausführt (Patching, Datenbank erstellen usw.).
  • dbmadmin:
    • Der Benutzer dbmadmin wird für das Command-Line Interface-(DBMCLI-)Utility von Oracle Exadata Database Machine verwendet.
    • Der Benutzer dbmadmin muss zum Ausführen aller Services auf dem Datenbankserver verwendet werden. Weitere Informationen finden Sie unter DBMCLI-Utility verwenden.

Die folgenden Gruppen werden standardmäßig auf dem virtuellen Gastrechner erstellt.

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
input:x:999:
systemd-journal:x:190:
systemd-network:x:192:
dbus:x:81:
ssh_keys:x:998:
sshd:x:74:
rpm:x:37:
rpc:x:32:
unbound:x:997:
nscd:x:28:
tss:x:59:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
chrony:x:996:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
uucp:x:14:
tcpdump:x:72:
exawatch:x:510:
cgred:x:509:
fuse:x:508:
screen:x:84:
sssd:x:507:
printadmin:x:506:
docker:x:505:
dbmsvc:x:2001:
dbmadmin:x:2002:
dbmmonitor:x:2003:
dbmusers:x:2004:
floppy:x:19:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
dialout:x:18:
tape:x:33:
video:x:39:
lock:x:54:
audio:x:63:
users:x:100:
nobody:x:2001:
utmp:x:22:
utempter:x:35:
dbus:x:81:
input:x:999:
kvm:x:36:
render:x:998:
systemd-journal:x:190:
systemd-coredump:x:997:
systemd-resolve:x:193:
tss:x:59:
ssh_keys:x:996:
sshd:x:74:
unbound:x:995:
nscd:x:28:
rpc:x:32:
saslauth:x:76:
mailnull:x:47:
smmsp:x:51:
rpcuser:x:29:
ldap:x:55:
slocate:x:21:
chrony:x:994:
tcpdump:x:72:
cgred:x:993:
fapolicyd:x:992:
printadmin:x:991:
polkitd:x:990:
sssd:x:989:
rpm:x:37:
screen:x:84:
dnsmasq:x:988:
exawatch:x:510:
dbmsvc:x:2002:
dbmadmin:x:2003:
dbmmonitor:x:2004:
dbmusers:x:2005:
uucp:x:14:
floppy:x:19:
mausers:x:2006:
secscan:x:1009:
oinstall:x:1001:
asmdba:x:1004:
asmoper:x:1005:
asmadmin:x:1006:
dba:x:1002:
racoper:x:1003:
opc:x:2000:

Zusätzlich zu allen Exadata-Features, die unter Sicherheitsfeatures von Oracle Exadata Database Machine erläutert werden, gelten auch die folgenden Sicherheitseinstellungen.

• Benutzerdefiniertes Datenbank-Deployment mit nicht standardmäßigen Parametern.
  Mit dem Befehl host_access_control werden Exadata-Sicherheitseinstellungen konfiguriert:

  • Implementierung von Richtlinien zu Kennwortablauf und -komplexität
  • Definieren von Accountsperr- und Sessiontimeout-Policys
  • Begrenzen des Remote-Root-Zugriffs.
  • Beschränken des Netzwerkzugriffs auf bestimmte Accounts.
  • Implementierung von Anmeldewarnungsbanner.
• account-disable: Deaktiviert einen Benutzeraccount, wenn bestimmte konfigurierte Bedingungen erfüllt sind.
• pam-auth: Verschiedene PAM-Einstellungen für Kennwortänderungen und Kennwortauthentifizierung.
• rootssh: Passt den Wert von PermitRootLogin in /etc/ssh/sshd_config an. So wird die Anmeldung des Benutzer root über SSH zugelassen oder verweigert..
  • Standardmäßig ist für PermitRootLogin kein Kennwort festgelegt.
  • Es wird empfohlen, diese Einstellung zu übernehmen, damit der Teil der Cloud-Automatisierung, der diesen Zugriffspfad verwendet (z.B. Patching des VM-Betriebssystems des Kunden), funktioniert. Wenn Sie PermitRootLogin auf no setzen, wird dieser Teil der Cloud-Automatisierungsfunktionalität deaktiviert.
• session-limit: Legt den Parameter * hard maxlogins in /etc/security/limits.conf fest. Dies ist die maximale Anzahl der Anmeldungen für alle Benutzer. Dieser Grenzwert gilt nicht für Benutzer mit uid=0.

  Der Standardwert ist * hard maxlogins 10. Dies ist der empfohlene sichere Wert.

• ssh-macs: Gibt die verfügbaren Message Authentication Code-(MAC-)Algorithmen an.
  • Der MAC-Algorithmus wird in Protokollversion 2 zum Schutz der Datenintegrität verwendet.
  • Der Standardwert ist hmac-sha1, hmac-sha2-256, hmac-sha2-512 für Server und Client.
  • Sichere empfohlene Werte: hmac-sha2-256, hmac-sha2-512 für Server und Client.
• password-aging: Legt den aktuellen Kennwortgültigkeitszeitraum für interaktive Benutzeraccounts fest oder zeigt ihn an.
  • -M: Maximale Anzahl von Tagen, die ein Kennwort verwendet werden kann.
  • -m: Mindestanzahl Tage zwischen Kennwortänderungen.
  • -W: Warnfrist vor Kennwortablauf in Tagen.
  • Standardwerte: -M 99999, -m 0, -W 7
  • --strict_compliance_only -M 60, -m 1, -W 7
  • Sichere empfohlene Werte: -M 60, -m 1, -W 7

• Exadata Cloud@Customer-Gast-VM-Agent: Cloud-Agent für die Verarbeitung von Datenbanklebenszyklusvorgängen
  • Wird als opc-Benutzer ausgeführt.
  • Die Prozesstabelle zeigt die Ausführung als Java-Prozess mit jar-Namen, dbcs-agent-VersionNumber-SNAPSHOT.jar und dbcs-admin-VersionNumver-SNAPSHOT.jar.
• Oracle Trace File Analyzer-Agent: Oracle Trace File Analyzer (TFA) bietet eine Reihe von Diagnosetools in einem Bundle. So können Diagnoseinformationen zu Oracle Database und Oracle Clusterware problemlos erfasst werden, was wiederum bei der der Kontaktaufnahme mit Oracle Support zur Problemlösung hilfreich ist.
  • Wird als Benutzer root ausgeführt.
  • Wird als Daemon initd ausgeführt, /etc/init.d/init.tfa.
  • Prozesstabellen zeigen eine Java-Anwendung, oracle.rat.tfa.TFAMain.

• ExaWatcher:

  • Wird als Benutzer root und exawatch ausgeführt.
  • Wird als Hintergrundskript ExaWatcher.sh ausgeführt, und alle untergeordneten Prozesse werden als Perl-Prozess ausgeführt.
  • Die Prozesstabelle zeigt mehrere Perl-Anwendungen.
• Oracle Database und Oracle Grid Infrastructure (Oracle Clusterware):
  • Wird als Benutzer dbmsvc und grid ausgeführt.
  • Die Prozesstabelle zeigt folgende Anwendungen:
    • oraagent.bin, apx_* und ams_* als Benutzer grid.
    • dbrsMain und Java-Anwendungen, derbyclient.jar und weblogic.Server als Benutzer oracle.
• Management Server (MS): Teil der Exadata-Imagesoftware für Verwaltung und Monitoring der Imagefunktionen.
  • Wird als Benutzer dbmadmin ausgeführt.
  • Die Prozesstabelle zeigt die Ausführung als Java-Prozess.

iptables-Standardregeln für Gast-VM:

#iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination