Konfigurieren von PIX 5.1.x: TACACS+ und RADIUS

Einleitung

RADIUS- und TACACS+-Authentifizierung kann für FTP-, Telnet- und HTTP-Verbindungen durchgeführt werden. Die Authentifizierung für andere, seltenere Protokolle kann normalerweise so eingerichtet werden, dass sie funktionieren. Die TACACS+-Autorisierung wird unterstützt, die RADIUS-Autorisierung nicht. Die gegenüber der Vorgängerversion vorgenommenen Änderungen bei der Authentifizierung, Autorisierung und Abrechnung (AAA) von PIX 5.1 umfassen die erweiterte Authentifizierung (xauth) - die Authentifizierung von IPSec-Tunneln vom Cisco Secure VPN Client 1.1.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

Authentifizierung und Autorisierung

• Die Authentifizierung ist die Person, die der Benutzer ist.

• Autorisierung ist, was der Benutzer tun kann.

• Die Authentifizierung ist ohne Autorisierung gültig.

• Die Autorisierung ist ohne Authentifizierung nicht gültig.

• Abrechnung ist das, was der Benutzer getan hat.

Angenommen, Sie haben einhundert Benutzer in Ihrem Netzwerk und möchten, dass nur sechs dieser Benutzer FTP, Telnet oder HTTP außerhalb des Netzwerks nutzen können. Der PIX muss ausgehenden Datenverkehr authentifizieren und allen sechs Benutzern IDs auf dem TACACS+/RADIUS-Sicherheitsserver zuweisen. Mit einfacher Authentifizierung können diese sechs Benutzer mit Benutzername und Passwort authentifiziert werden, dann gehen. Die anderen 94 Benutzer konnten nicht ausgehen. Der PIX fordert die Benutzer zur Eingabe von Benutzername/Kennwort auf und gibt dann ihren Benutzernamen und ihr Kennwort an den TACACS+/RADIUS-Sicherheitsserver weiter. Abhängig von der Antwort wird die Verbindung geöffnet oder verweigert. Diese sechs Benutzer können FTP, Telnet oder HTTP ausführen.

Aber nehmen wir an, einer dieser sechs Benutzer, "Festus", ist nicht vertrauenswürdig. Sie möchten Festus erlauben FTP zu machen, aber nicht HTTP oder Telnet nach außen. Dies bedeutet, dass zusätzlich zur Authentifizierung des Benutzers auch die Autorisierung hinzugefügt werden muss, d. h. die Autorisierung dessen, was Benutzer tun können. Dies gilt nur für TACACS+. Wenn wir dem PIX Autorisierung hinzufügen, sendet das PIX zuerst den Benutzernamen und das Passwort von Festus an den Security Server und sendet dann eine Autorisierungsanfrage, die dem Security Server mitteilt, was "Befehl" Festus zu tun versucht. Wenn der Server richtig eingerichtet ist, könnte Festus die Berechtigung "ftp 1.2.3.4" erhalten, aber Festus würde die Möglichkeit verweigert, HTTP oder Telnet überall zu nutzen.

Was der Benutzer bei der Authentifizierung/Autorisierung sieht auf

Bei dem Versuch, von innen nach außen (oder umgekehrt) zu gehen, mit Authentifizierung/Autorisierung auf:

• Telnet - Der Benutzer wird aufgefordert, einen Benutzernamen und anschließend eine Kennwortanforderung einzugeben. Wenn die Authentifizierung (und Autorisierung) auf dem PIX/Server erfolgreich ist, wird der Benutzer vom Zielhost darüber hinaus zur Eingabe von Benutzername und Kennwort aufgefordert.

• FTP - Der Benutzer wird aufgefordert, einen Benutzernamen einzugeben. Der Benutzer muss local_username@remote_username als Benutzernamen und local_password@remote_password als Kennwort eingeben. Der PIX sendet den lokalen_Benutzernamen und das lokale_Kennwort an den lokalen Sicherheitsserver. Wenn die Authentifizierung (und Autorisierung) auf dem PIX/Server erfolgreich ist, werden der remote_Benutzername und das remote_Kennwort an den Ziel-FTP-Server weitergeleitet.

• HTTP - Im Browser wird ein Fenster angezeigt, das einen Benutzernamen und ein Kennwort anfordert. Wenn die Authentifizierung (und Autorisierung) erfolgreich ist, erreicht der Benutzer die Ziel-Website weiter. Beachten Sie, dass Browser Benutzernamen und Kennwörter zwischenspeichern. Wenn es den Anschein hat, dass der PIX eine HTTP-Verbindung zeitlich aussetzen sollte, dies aber nicht tut, ist es wahrscheinlich, dass eine erneute Authentifizierung stattfindet, während der Browser den zwischengespeicherten Benutzernamen und das Passwort an den PIX sendet, der dies dann an den Authentifizierungsserver weiterleitet. PIX Syslog und/oder Server-Debugging zeigt dieses Phänomen. Wenn Telnet und FTP normal zu funktionieren scheinen, HTTP-Verbindungen jedoch nicht, ist dies der Grund.

• Tunnel - Wenn Sie versuchen, IPSec-Datenverkehr mit eingeschaltetem VPN-Client in das Netzwerk zu tunneln, wird ein graues Feld für "User Authentication for New Connection" (Benutzerauthentifizierung für neue Verbindung) als Benutzername/Kennwort angezeigt.

  Hinweis: Diese Authentifizierung wird ab Cisco Secure VPN Client 1.1 unterstützt. Wenn das Menü Hilfe > Info nicht die Version 2.1.x oder höher anzeigt, funktioniert dies nicht.

Für alle Szenarien verwendete Security Server-Konfigurationen

Konfiguration des Cisco Secure UNIX TACACS-Servers

In diesem Abschnitt werden die Informationen zum Konfigurieren des Sicherheitsservers angezeigt.

Stellen Sie sicher, dass Sie die PIX-IP-Adresse oder den vollqualifizierten Domänennamen und -schlüssel in der Datei CSU.cfg haben.

user = ddunlap {
password = clear "rtp"
default service = permit
}

user = can_only_do_telnet {
password = clear "telnetonly"
service = shell {
cmd = telnet {
permit .*
}
}
}

user = can_only_do_ftp {
password = clear "ftponly"
service = shell {
cmd = ftp {
permit .*
}
}
}

user = httponly {
password = clear "httponly"
service = shell {
cmd = http {
permit .*
}
}
}

Konfiguration des Cisco Secure UNIX RADIUS-Servers

Fügen Sie die PIX-IP-Adresse und den PIX-Schlüssel über die Benutzeroberfläche der Liste für den Netzwerkzugriffsserver (NAS) hinzu.

user=adminuser {
radius=Cisco {
check_items= {
2="all"
}
reply_attributes= {
6=6
}
}
}

Cisco Secure ACS für Windows 2.x RADIUS

Gehen Sie wie folgt vor, um Cisco Secure ACS für Windows 2.x RADIUS zu konfigurieren.

1. Rufen Sie das Kennwort über die Benutzeroberfläche für die Benutzereinrichtung ab.

2. Legen Sie im Abschnitt GUI für die Gruppeneinrichtung das Attribut 6 (Servicetyp) auf Anmelden oder Administrativ fest.

3. Fügen Sie die PIX-IP-Adresse in der GUI des NAS-Konfigurationsabschnitts hinzu.

EasyACS TACACS+

Die Einrichtung wird in der EasyACS-Dokumentation beschrieben.

1. Klicken Sie im Gruppenabschnitt auf Shell exec, um exec-Berechtigungen zu erteilen.

2. Um die Autorisierung zum PIX hinzuzufügen, klicken Sie unten in der Gruppeneinrichtung auf Nicht übereinstimmende IOS-Befehle verweigern.

3. Wählen Sie für jeden Befehl, den Sie zulassen möchten, z. B. Telnet, den Befehl Hinzufügen/Bearbeiten.

4. Wenn Telnetting für bestimmte Standorte zulässig ist, geben Sie die IP-Adresse(n) im Argumentabschnitt im Formular "permit #.#.#.#" ein. Klicken Sie andernfalls auf Alle nicht aufgelisteten Argumente zulassen, um Telnetting zuzulassen.

5. Klicken Sie auf Bearbeitungsbefehl beenden.

6. Führen Sie die Schritte 1 bis 5 für jeden der zulässigen Befehle aus (z. B. Telnet, HTTP oder FTP).

7. Fügen Sie die PIX IP im Abschnitt "NAS Configuration GUI" hinzu.

Cisco Secure TACACS+ 2.x

Der Benutzer erhält ein Kennwort in der Benutzeroberfläche für die Benutzereinrichtung.

1. Klicken Sie im Gruppenabschnitt auf Shell exec, um exec-Berechtigungen zu erteilen.

2. Um die Autorisierung zum PIX hinzuzufügen, klicken Sie unten in der Gruppen-Konfiguration auf Nicht übereinstimmende IOS-Befehle verweigern.

3. Wählen Sie für jeden zuzulassenden Befehl (z. B. Telnet) den Befehl Add/Edit new aus.

4. Um Telnetting für bestimmte Standorte zuzulassen, geben Sie die IP-Adresse im Argumentabschnitt im Format "permit #.#.#.#.#" ein. Um Telnetting für einen Standort zuzulassen, klicken Sie auf Alle nicht aufgelisteten Argumente zulassen.

5. Klicken Sie auf Bearbeitungsbefehl beenden.

6. Führen Sie die Schritte 1 bis 5 für jeden der zulässigen Befehle aus (z. B. Telnet, HTTP oder FTP).

7. Stellen Sie sicher, dass die PIX-IP-Adresse in der NAS-Konfigurations-GUI hinzugefügt wird.

Konfiguration des Livingston RADIUS-Servers

Fügen Sie der Client-Datei die PIX IP-Adresse und den Schlüssel hinzu.

adminuser Password="all" User-Service-Type = Shell-User 

Konfiguration des Merge-RADIUS-Servers

Fügen Sie der Client-Datei die PIX IP-Adresse und den Schlüssel hinzu.

adminuser Password="all" Service-Type = Shell-User 

Konfiguration des TACACS+-Freeware-Servers

key = "cisco"
user = adminuser {
login = cleartext "all"
default service = permit
}

user = can_only_do_telnet {
login = cleartext "telnetonly"
cmd = telnet {
permit .*
}
}

user = httponly {
login = cleartext "httponly"
cmd = http { 
permit .*
}
}

user = can_only_do_ftp {
login = cleartext "ftponly"
cmd = ftp { 
permit .*
}
}

Schritte zum Debuggen

Hinweis: Bestimmte show-Befehle werden vom Output Interpreter Tool (nur registrierte Kunden) unterstützt, mit dem Sie eine Analyse der show-Befehlsausgabe anzeigen können.

• Stellen Sie sicher, dass die PIX-Konfiguration funktioniert, bevor Sie AAA hinzufügen. Wenn Sie den Datenverkehr vor der Aktivierung der Authentifizierung und Autorisierung nicht weiterleiten können, ist dies im Nachhinein nicht mehr möglich.

• Aktivieren Sie die Protokollierung im PIX.

  • Das Debuggen der Protokollierungskonsole sollte nicht auf einem stark ausgelasteten System verwendet werden.

  • Das Protokollieren gepufferter Debugging-Vorgänge kann verwendet werden, und führen Sie dann den Befehl show logging aus.

  • Die Protokollierung kann auch an einen Syslog-Server gesendet und dort untersucht werden.

• Aktivieren Sie das Debuggen auf den TACACS+- oder RADIUS-Servern (diese Option steht allen Servern zur Verfügung).

Netzwerkdiagramm

PIX Version 5.1(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 pix/intf2 security10
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname pix3
fixup protocol ftp 21
fixup protocol http 80
fixup protocol smtp 25
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol sqlnet 1521
names
pager lines 24
no logging timestamp
no logging standby
logging console debugging
no logging monitor
no logging buffered
no logging trap
no logging history
logging facility 20
logging queue 512
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
mtu outside 1500
mtu inside 1500
mtu pix/intf2 1500
ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
ip address pix/intf2 127.0.0.1 255.255.255.255
no failover
failover timeout 0:00:00
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address pix/intf2 0.0.0.0
arp timeout 14400
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
nat (inside) 1 10.31.1.0 255.255.255.0 0 0
static (inside,outside) 99.99.99.99 10.31.1.50 netmask 255.255.255.255 0 0
conduit permit icmp any any 
conduit permit tcp any any 
conduit permit udp any any 
route outside 0.0.0.0 0.0.0.0 99.99.99.2 1
route inside 171.68.118.0 255.255.255.0 10.31.1.1 1
route inside 171.68.120.0 255.255.255.0 10.31.1.1 1
timeout xlate 3:00:00 conn 1:00:00 half-closed 0:10:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+ 
aaa-server RADIUS protocol radius 
aaa-server AuthInbound protocol tacacs+ 
aaa-server AuthInbound (inside) host 171.68.118.101 cisco timeout 5
aaa-server AuthOutbound protocol radius 
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authentication include http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include http inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authentication include ftp outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include ftp inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
terminal width 80
Cryptochecksum:b26b560b20e625c9e23743082484caca
: end
[OK] 

Beispiele für Authentifizierungsdebugging aus PIX

In diesem Abschnitt werden Beispiele für Authentifizierungsdebugs für verschiedene Szenarien veranschaulicht.

Eingehend

Der externe Benutzer unter 99.99.99.2 initiiert Datenverkehr an den internen Server 10.31.1.50 (99.99.99.99) und wird über TACACS authentifiziert (d. h. der eingehende Datenverkehr verwendet die Serverliste "AuthInbound", die den TACACS-Server 171.68.118.1 enthält. 01).

PIX-Debugging - Gute Authentifizierung - TACACS+

Das folgende Beispiel zeigt ein PIX-Debugging mit guter Authentifizierung:

109001: Auth start for user '???' from 
    99.99.99.2/11008 to 10.31.1.50/23
109011: Authen Session Start: user 'cse', sid 4
109005: Authentication succeeded for user 'cse' 
    from 10.31.1.50/23 to 99.99.99.e
302001: Built inbound TCP connection 10 for 
    faddr 99.99.99.2/11008 gaddr 99.99.)

PIX-Debugging - Ungültige Authentifizierung (Benutzername oder Kennwort) - TACACS+

Das folgende Beispiel zeigt ein PIX-Debugging mit schlechter Authentifizierung (Benutzername oder Kennwort). Dem Benutzer werden drei Benutzername/Kennwort-Sets angezeigt, gefolgt von der folgenden Meldung: Error: max number of tries beyond.

109001: Auth start for user '???' from 
     99.99.99.2/11010 to 10.31.1.50/23
  109006: Authentication failed for user '' from 
     10.31.1.50/23 to 99.99.99.2/11010 on 
     interface outside

PIX-Debugging - Ping-Server kann angefordert werden, keine Antwort - TACACS+

Das folgende Beispiel zeigt ein PIX-Debugging, bei dem der Server Ping-fähig ist, aber nicht mit dem PIX spricht. Der Benutzer sieht den Benutzernamen einmal, aber das PIX fragt nie nach einem Passwort (das ist bei Telnet). Der Benutzer sieht Fehler: Maximale Anzahl von Versuchen überschritten.

109001: Auth start for user '???' from 99.99.99.2/11011 
     to 10.31.1.50/23
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11011 failed 
     (server 171.68.118.101 failed) on interface outside
  109006: Authentication failed for user '' from 10.31.1.50/23 
     to 99.99.99.2/11011 on interface outside

PIX-Debugging - Ping-Server kann nicht angefordert werden - TACACS+

Das folgende Beispiel zeigt ein PIX-Debugging, bei dem der Server nicht pingbar ist. Der Benutzer sieht den Benutzernamen einmal, aber das PIX fragt nie nach einem Passwort (das ist bei Telnet). Die folgenden Meldungen werden angezeigt: Timeout für TACACS+-Server und Fehler: Max. Anzahl der Versuche überschritten (in der Konfiguration wurde ein falscher Server ausgetauscht).

111005: console end configuration: OK
  109001: Auth start for user '???' from 
     99.99.99.2/11012 to 10.31.1.50/23
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109002: Auth from 10.31.1.50/23 to 99.99.99.2/11012 
     failed (server 1.1.1.1 failed) on interface outside
  109006: Authentication failed for user '' from 
     10.31.1.50/23 to 99.99.99.2/11012 on interface 
     outside

PIX-Debugging - gute Authentifizierung - RADIUS

Das folgende Beispiel zeigt ein PIX-Debugging mit guter Authentifizierung:

109001: Auth start for user '???' from 
     10.31.1.50/11008 to 99.99.99.2/23
  109011: Authen Session Start: user 'pixuser', sid 8
  109005: Authentication succeeded for user 
     'pixuser' from 10.31.1.50/11008 to 
     99.99.99.2/23 on interface inside
  302001: Built outbound TCP connection 16 for faddr 
     99.99.99.2/23 gaddr 99.99.99.99/11008 
     laddr 10.31.1.50/11008 (pixuser)

PIX-Debugging - Ungültige Authentifizierung (Benutzername oder Kennwort) - RADIUS

Das folgende Beispiel zeigt ein PIX-Debugging mit schlechter Authentifizierung (Benutzername oder Kennwort). Dem Benutzer wird die Anforderung eines Benutzernamens und Kennworts angezeigt, und er hat drei Möglichkeiten, diese einzugeben. Wenn die Eingabe nicht erfolgreich war, wird die folgende Meldung angezeigt: Fehler: Maximale Anzahl der Versuche überschritten.

109001: Auth start for user '???' from 10.31.1.50/11010 
     to 99.99.99.2/23
  109006: Authentication failed for user '' 
     from 10.31.1.50/11010 to 99.99.99.2/23 
     on interface inside

PIX-Debugging - Kann Ping-Server, Daemon Down - RADIUS

Das folgende Beispiel zeigt ein PIX-Debugging, bei dem der Server Ping-fähig ist, der Daemon jedoch ausgefallen ist und nicht mit dem PIX kommunizieren wird. Der Benutzer sieht Benutzername und Kennwort, die Meldung RADIUS server failed (RADIUS-Server fehlgeschlagen) und die Fehlermeldung Error: Max number of tries beyond (Maximale Anzahl von Versuchen überschritten). (Fehlermeldung).

109001: Auth start for user '???' from 10.31.1.50/11011 
     to 99.99.99.2/23
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  1ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  ICMP unreachable (code 3) 171.68.118.101 > 10.31.1.75
  09002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 
     failed (server 171.68.118.101 failed) on interface inside
  109002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 failed 
     (server 171.68.118.101 failed) on interface inside
  109002: Auth from 10.31.1.50/11011 to 99.99.99.2/23 failed 
     (server 171.68.118.101 failed) on interface inside
  109006: Authentication failed for user '' from 10.31.1.50/11011 
     to 99.99.99.2/23 on interface inside

PIX-Debugging - Server- oder Schlüssel-/Client-Konflikt kann nicht gepingt werden - RADIUS

Das folgende Beispiel zeigt ein PIX-Debugging, bei dem der Server nicht pingbar ist oder eine Client/Schlüssel-Diskrepanz vorliegt. Dem Benutzer werden ein Benutzername, ein Kennwort, die Nachricht Timeout to RADIUS server (Timeout an RADIUS-Server) und der Fehler: Max. Anzahl der Versuche überschritten die Nachricht, dass ein falscher Server in der Konfiguration ausgetauscht wurde) angezeigt.

109001: Auth start for user '???' from 10.31.1.50/11012 
     to 99.99.99.2/23
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109002: Auth from 10.31.1.50/11012 to 99.99.99.2/23 failed 
     (server 1.1.1.1 failed) on interface inside
  109006: Authentication failed for user '' from 10.31.1.50/11012 
     to 99.99.99.2/23 on interface inside 

Autorisierung hinzufügen

Wenn Sie die Autorisierung hinzufügen möchten, da die Autorisierung ohne Authentifizierung nicht gültig ist, müssen Sie die Autorisierung für denselben Quell- und Zielbereich benötigen.

aaa authorization telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization http inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization ftp inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

Beachten Sie, dass Sie keine Autorisierung für ausgehenden Datenverkehr hinzufügen, da der ausgehende Datenverkehr mit RADIUS authentifiziert wird und die RADIUS-Autorisierung ungültig ist.

Beispiele für Authentifizierungs- und Autorisierungsdebugs aus PIX

PIX-Debugging - Gute Authentifizierung und erfolgreiche Autorisierung - TACACS+

Das folgende Beispiel zeigt ein PIX-Debugging mit guter Authentifizierung und erfolgreicher Autorisierung:

109001: Auth start for user '???' from 99.99.99.2/11016 
   to 10.31.1.50/23
109011: Authen Session Start: user 'cse', Sid 11
109005: Authentication succeeded for user 'cse' 
   from 10.31.1.50/23 to 99.99.99.2/11016 on interface outside
109011: Authen Session Start: user 'cse', Sid 11
109007: Authorization permitted for user 'cse' from 
   99.99.99.2/11016 to 10.31.1.50/23 on interface outside
302001: Built inbound TCP connection 19 for faddr 99.99.99.2/11016 
   gaddr 99.99.99.99/23 laddr 10.31.1.50/23 (cse)

PIX-Debugging - gute Authentifizierung, fehlgeschlagene Autorisierung - TACACS+

Das folgende Beispiel zeigt das PIX-Debugging mit guter Authentifizierung, aber fehlgeschlagener Autorisierung. Hier wird dem Benutzer auch die Meldung Error: Authorization Denied (Fehler: Autorisierung abgelehnt) angezeigt.

109001: Auth start for user '???' from 
    99.99.99.2/11017 to 10.31.1.50/23
109011: Authen Session Start: user 'httponly', 
   Sid 12
109005: Authentication succeeded for user 'httponly' 
   from 10.31.1.50/23 to 99.99.99.2/11017 on 
   interface outside
109008: Authorization denied for user 'httponly' from 
   10.31.1.50/23 to 99.99.99.2/11017 on interface outside

Buchhaltung hinzufügen

TACACS+

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

TACACS+-Freeware-Ausgabe:

Tue Feb 22 08:52:20 2000  10.31.1.75 cse PIX 
   99.99.99.2 start task_id=0x14 
   foreign_ip=99.99.99.2 local_ip=10.31.1.50 
   cmd=telnet
Tue Feb 22 08:52:25 2000  10.31.1.75 cse PIX 
   99.99.99.2 stop task_id=0x14 
   foreign_ip=99.99.99.2 local_ip=10.31.1.50 
   cmd=telnet elapsed_time=5 
   bytes_in=39 bytes_out=126

RADIUS

aaa accounting include any outbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound

Merit RADIUS-Ausgabe:

Tue Feb 22 08:56:17 2000
        Acct-Status-Type = Start
        NAS-IP-Address = 10.31.1.75
        Login-IP-Host = 10.31.1.50
        Login-TCP-Port = 23
        Acct-Session-Id = 0x00000015
        User-Name = pixuser

        Tue Feb 22 08:56:24 2000
        Acct-Status-Type = Stop
        NAS-IP-Address = 10.31.1.75
        Login-IP-Host = 10.31.1.50
        Login-TCP-Port = 23
        Acct-Session-Id = 0x00000015
        Username = pixuser
        Acct-Session-Time = 6
        Acct-Input-Octets = 139
        Acct-Output-Octets = 36

Verwenden des Ausschlussbefehls

Wenn wir einen anderen Host außerhalb (unter 99.99.99.100) zu unserem Netzwerk hinzufügen und dieser Host vertrauenswürdig ist, können Sie ihn mit den folgenden Befehlen von der Authentifizierung und Autorisierung ausschließen:

aaa authentication exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100
 255.255.255.255 AuthInbound

aaa authorization exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100 255.255.255.255 
AuthInbound  

Maximale Anzahl von Sitzungen und Anzeigen angemeldeter Benutzer

Einige TACACS+- und RADIUS-Server verfügen über die Funktion "max-session" (max-session) oder "view log-in users" (angemeldete Benutzer anzeigen). Die Möglichkeit, max-sessions durchzuführen oder angemeldete Benutzer einzuchecken, hängt von den Abrechnungsdatensätzen ab. Wenn ein Accounting-Startdatensatz generiert wird, jedoch kein Stopp-Datensatz, geht der TACACS+- oder RADIUS-Server davon aus, dass die Person noch angemeldet ist (d. h. der Benutzer hat eine Sitzung über den PIX).

Dies funktioniert bei Telnet- und FTP-Verbindungen aufgrund der Art der Verbindungen gut. Dies funktioniert bei HTTP aufgrund der Art der Verbindung nicht gut. Im folgenden Beispiel wird eine andere Netzwerkkonfiguration verwendet, aber die Konzepte sind identisch.

Benutzer-Telnet über den PIX, Authentifizierung über den Weg:

   171.68.118.100/1200 to 9.9.9.25 /23
  (pix) 109011: Authen Session Start: user 
     'cse', Sid 3
  (pix) 109005: Authentication succeeded for user 
     'cse' from 171.68.118.100/12 00 to 9.9.9.25/23
  (pix) 302001: Built TCP connection 5 for faddr 
     9.9.9.25/23 gaddr 9.9.9.10/12 00 
     laddr 171.68.118.100/1200 (cse)
  (server start account) Sun Nov 8 16:31:10 1998 
     rtp-pinecone.rtp.cisco.com cse
  PIX 171.68.118.100 start task_id=0x3 foreign_ip=9.9.9.25 
     local_ip=171.68.118.100 cmd=telnet

Da der Server einen Startdatensatz, aber keinen Stoppdatensatz gesehen hat, zeigt der Server zu diesem Zeitpunkt an, dass der Telnet-Benutzer angemeldet ist. Wenn der Benutzer versucht, eine andere Verbindung herzustellen, die eine Authentifizierung erfordert (z. B. von einem anderen PC), und wenn max-sessions auf dem Server für diesen Benutzer auf 1 festgelegt ist (vorausgesetzt, der Server unterstützt max-sessions), wird die Verbindung vom Server abgelehnt.

Der Benutzer führt seine Telnet- oder FTP-Geschäfte auf dem Ziel-Host durch und beendet den Vorgang (verbringt dort zehn Minuten):

pix) 302002: Teardown TCP connection 5 faddr 
     9.9.9.25/80 gaddr 9.9.9.10/128 
  1 laddr 171.68.118.100/1281 duration 0:00:00 
     bytes 1907 (cse)
  (server stop account) Sun Nov 8 16:41:17 1998 
     rtp-pinecone.rtp.cisco.com cse
  PIX 171.68.118.100 stop task_id=0x3 foreign_ip=9.9.9.25 
     local_ip=171.68.118.100 
  cmd=telnet elapsed_time=5 bytes_in=98 bytes_out=36

Unabhängig davon, ob uauth den Wert 0 (d. h., authentifizieren Sie sich jedes Mal) oder mehr (authentifizieren Sie sich ein Mal und nicht wieder während des auth-Zeitraums) hat, wird für jeden Standort, auf den zugegriffen wird, ein Abrechnungsdatensatz ausgeschnitten.

HTTP funktioniert aufgrund der Art des Protokolls anders. Nachfolgend finden Sie ein Beispiel für HTTP:

Der Benutzer navigiert von 171.68.118.100 bis 9.9.9.25 durch den PIX:

(pix) 109001: Auth start for user '???' from 
     171.68.118.100/1281 to 9.9.9.25 /80
  (pix) 109011: Authen Session Start: user 'cse', Sid 5
  (pix) 109005: Authentication succeeded for user 
     'cse' from 171.68.118.100/12 81 to 9.9.9.25/80
  (pix) 302001: Built TCP connection 5 for faddr 
     9.9.9.25/80 gaddr 9.9.9.10/12 81 laddr 
     171.68.118.100/1281 (cse)
  (server start account) Sun Nov 8 16:35:34 1998 
     rtp-pinecone.rtp.cisco.com cse
  PIX 171.68.118.100 start task_id=0x9 foreign_ip=9.9.9.25 
     local_ip=171.68.118.100 cmd=http
  (pix) 302002: Teardown TCP connection 5 faddr 
     9.9.9.25/80 gaddr 9.9.9.10/128 
  1 laddr 171.68.118.100/1281 duration 0:00:00 
     bytes 1907 (cse)
  (server stop account) Sun Nov 8 16:35.35 1998 
     rtp-pinecone.rtp.cisco .com cse 
  PIX 171.68.118.100 stop task_id=0x9 foreign_ip =9.9.9.25
  local_ip=171.68.118.100 cmd=http elapsed_time=0 
     bytes_ in=1907 bytes_out=223

Der Benutzer liest die heruntergeladene Webseite.

Der Startrekord wird um 16:35:34 veröffentlicht und der Stopprekord um 16:35:35. Dieser Download dauerte eine Sekunde (das heißt, es gab weniger als eine Sekunde zwischen dem Start- und dem Stopp-Record). Ist der Benutzer noch bei der Website angemeldet und die Verbindung ist noch offen, wenn der Benutzer die Webseite liest? Nein. Werden max-sessions oder angemeldete Benutzer angezeigt? Nein, da die Verbindungszeit (die Zeit zwischen "Built" und "Teardown") in HTTP zu kurz ist. Der Start- und Stopp-Datensatz ist eine Sekunde lang. Es gibt keinen Startdatensatz ohne Stoppdatensatz, da die Datensätze praktisch zum gleichen Zeitpunkt auftreten. Für jede Transaktion wird ein Start- und Stopp-Datensatz an den Server gesendet, unabhängig davon, ob uauth für 0 oder etwas Größeres festgelegt ist. Max-sessions und angemeldete Benutzer können jedoch aufgrund der HTTP-Verbindungen nicht angezeigt werden.

Authentifizierung und Aktivierung auf dem PIX selbst

Das vorhergehende Thema betrifft die Authentifizierung von Telnet- (und HTTP-, FTP-) Datenverkehr über den PIX. Stellen Sie sicher, dass Telnet mit PIX ohne Authentifizierung funktioniert auf:

telnet 10.31.1.5 255.255.255.255
passwd ww

Fügen Sie dann den Befehl hinzu, um Benutzer zu authentifizieren Telnetting auf dem PIX:

aaa authentication telnet console AuthInbound

Wenn Benutzer von Telnet auf PIX zugreifen, werden sie zur Eingabe des Telnet-Kennworts (WW) aufgefordert. Der PIX fordert auch den TACACS+- oder RADIUS-Benutzernamen und das Kennwort an. Da in diesem Fall die AuthInbound-Serverliste verwendet wird, fordert das PIX den TACACS+-Benutzernamen und das TACACS+-Kennwort an.

Wenn der Server ausgefallen ist, können Sie auf den PIX zugreifen, indem Sie pix als Benutzernamen und dann das enable-Kennwort eingeben (enable password any ). Mit dem Befehl:

aaa authentication enable console AuthInbound

Der Benutzer wird aufgefordert, einen Benutzernamen und ein Kennwort einzugeben, die an den TACACS- oder RADIUS-Server gesendet werden. Da in diesem Fall die AuthInbound-Serverliste verwendet wird, fordert das PIX den TACACS+-Benutzernamen und das TACACS+-Kennwort an.

Da das Authentifizierungspaket für "enable" mit dem Authentifizierungspaket für "login" identisch ist, kann der Benutzer, wenn er sich mit TACACS oder RADIUS beim PIX anmelden kann, über TACACS oder RADIUS mit demselben Benutzernamen/Kennwort aktivieren. Diesem Problem wurde die Cisco Bug-ID CSCdm47044 zugewiesen (nur für registrierte Kunden).

Wenn der Server ausgefallen ist, können Sie auf den PIX-Aktivierungsmodus zugreifen, indem Sie pix für den Benutzernamen und das normale enable-Kennwort aus dem PIX eingeben (enable password any ). Wenn Sie das Kennwort aktivieren, was auch immer nicht in der PIX-Konfiguration enthalten ist, geben Sie pix als Benutzernamen ein, und drücken Sie die Eingabetaste. Wenn das enable-Kennwort festgelegt, aber nicht bekannt ist, muss ein Kennwortwiederherstellungsdatenträger erstellt werden, um das Kennwort zurückzusetzen.

Ändern der Eingabeaufforderung Siehe

Wenn Sie den folgenden Befehl haben:

auth-prompt PIX_PIX_PIX

Benutzer, die das PIX durchlaufen, sehen die folgende Sequenz:

PIX_PIX_PIX [at which point one would enter the username] 
   Password:[at which point one would enter the password] 

Bei der Ankunft am endgültigen Ziel wird dem Benutzer die Aufforderung "Username:" und "Password:" angezeigt, die im Zielfeld angezeigt wird. Diese Aufforderung wirkt sich nur auf Benutzer aus, die das PIX-System durchlaufen, nicht auf Benutzer, die das PIX-System verwenden.

Hinweis: Es sind keine Abrechnungsdatensätze für den Zugriff auf den PIX vorhanden.

Anpassen der angezeigten Nachricht für Benutzer bei Erfolg/Fehler

Wenn Sie über die folgenden Befehle verfügen:

auth-prompt accept "GOOD_AUTH" 
auth-prompt reject "BAD_AUTH" 

wird bei einer fehlgeschlagenen/erfolgreichen Anmeldung über den PIX die folgende Sequenz angezeigt:

PIX_PIX_PIX 
   Username: asjdkl
   Password: "BAD_AUTH" 
   "PIX_PIX_PIX" 
   Username: cse 
   Password: "GOOD_AUTH" 

Leerlauf pro Benutzer und absolute Timeouts

Diese Funktion funktioniert derzeit nicht und das Problem wurde mit der Cisco Bug-ID CSCdp93492 (nur registrierte Kunden) behoben.

Virtuelles HTTP

Wenn sowohl auf Seiten außerhalb des PIX als auch auf dem PIX selbst eine Authentifizierung erforderlich ist, kann es vorkommen, dass ein ungewöhnliches Browserverhalten beobachtet wird, da Browser Benutzername und Passwort zwischenspeichern.

Um dies zu vermeiden, können Sie virtuelles HTTP implementieren, indem Sie der PIX-Konfiguration eine RFC 1918- Adresse (d. h. eine Adresse, die im Internet nicht geroutet werden kann, aber für das PIX-interne Netzwerk gültig und eindeutig ist) mit dem folgenden Befehl hinzufügen:

virtual http #.#.#.# [warn]

Wenn der Benutzer versucht, sich außerhalb des PIX zu bewegen, ist eine Authentifizierung erforderlich. Wenn der Parameter warn vorhanden ist, erhält der Benutzer eine Umleitungsnachricht. Die Authentifizierung gilt für die gesamte Authentifizierungszeit. Wie in der Dokumentation angegeben, setzen Sie die Zeitüberschreitungsauth-Befehlsdauer bei virtuellem HTTP nicht auf 0 Sekunden. Dies verhindert HTTP-Verbindungen zum echten Webserver.

Beispiel für ausgehenden virtuellen HTTP-Datenverkehr

PIX-Konfiguration Virtueller HTTP-Ausgang:

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
timeout uauth 01:00:00
aaa authentication include http outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa-server RADIUS protocol radius
aaa-server AuthOutbound protocol radius
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
virtual http 10.31.1.99

Virtuelles Telnet

Es ist möglich, den PIX so zu konfigurieren, dass alle ein- und ausgehenden Nachrichten authentifiziert werden. Dies ist jedoch nicht sinnvoll, da einige Protokolle, z. B. E-Mail, nicht einfach authentifiziert werden können. Wenn ein Mailserver und ein Client bei der Authentifizierung des gesamten Datenverkehrs über den PIX über den PIX kommunizieren, zeigt das PIX-Syslog für nicht authentifizierbare Protokolle Meldungen wie die folgenden an:

109013: User must authenticate before using 
    this service
109009: Authorization denied from 171.68.118.106/49 
    to 9.9.9.10/11094    (not authenticated) 

Wenn jedoch eine Art ungewöhnlicher Dienst authentifiziert werden muss, kann dies mithilfe des virtuellen Telnet-Befehls geschehen. Mit diesem Befehl kann die Authentifizierung für die virtuelle Telnet-IP-Adresse erfolgen. Nach dieser Authentifizierung kann der Datenverkehr für den ungewöhnlichen Dienst an den richtigen Server weitergeleitet werden.

In diesem Beispiel soll der Datenverkehr des TCP-Ports 49 von dem externen Host 99.99.99.2 zu dem internen Host 171.68.118.106 fließen. Da dieser Datenverkehr nicht wirklich authentifizierbar ist, sollten Sie ein virtuelles Telnet einrichten. Für virtuelle Telnet-Verbindungen muss ein zugehöriger statischer Telnet-Knoten vorhanden sein. Hierbei sind sowohl 99.99.99.20 als auch 171.68.118.20 virtuelle Adressen.

Eingehender virtueller Telnet-Datenverkehr

PIX-Konfiguration Virtuelles eingehendes Telnet

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
static (inside,outside) 99.99.99.20 171.68.118.20 netmask 255.255.255.255 0 0
static (inside,outside) 99.99.99.30 171.68.118.106 netmask 255.255.255.255 0 0
conduit permit tcp host 99.99.99.20 eq telnet any
conduit permit tcp host 99.99.99.30 eq tacacs any
aaa-server TACACS+ protocol tacacs+
aaa-server Incoming protocol tacacs+
aaa-server Incoming (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Incoming
aaa authentication include tcp/49 inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Incoming
virtual telnet 99.99.99.20

PIX - Virtuelles eingehendes Telnet debuggen

Der Benutzer mit der Adresse 99.99.99.2 muss sich zunächst mithilfe von Telnetting für die Adresse 99.99.99.20 auf dem PIX authentifizieren:

109001: Auth start for user '???' from 
    99.99.99.2/22530 to 171.68.118.20/23
 109011: Authen Session Start: user 'cse', Sid 13
 109005: Authentication succeeded for user 
    'cse' from 171.68.118.20/23 to 
    99.99.99.2/22530 on interface outside

Nach der erfolgreichen Authentifizierung zeigt der Befehl show auth an, dass der Benutzer "time on the meter" hat:

pixfirewall# show uauth
                        Current    Most Seen
Authenticated Users       1          2
Authen In Progress        0          1
user 'cse' at 99.99.99.2, authenticated
   absolute   timeout: 0:05:00
   inactivity timeout: 0:00:00 

Und wenn das Gerät unter 99.99.99.2 TCP/49-Datenverkehr an das Gerät unter 171.68.118.106 senden möchte:

302001: Built inbound TCP connection 16 
    for faddr 99.99.99.2/11054 gaddr 
    99.99.99.30/49 laddr 171.68.118.106/49 (cse)

Berechtigung kann hinzugefügt werden:

aaa authorization include tcp/49 inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound

Wenn also TCP/49-Datenverkehr über den PIX gesendet wird, sendet der PIX auch die Autorisierungsanfrage an den Server:

109007: Authorization permitted for user 'cse' 
    from 99.99.99.2/11057 to 171.68.118.106/49 
    on interface outside

Auf dem TACACS+-Server wird dies folgendermaßen betrachtet:

service=shell, 
  cmd=tcp/49, 
  cmd-arg=171.68.118.106 

Virtuelles ausgehendes Telnet

Da ausgehender Datenverkehr standardmäßig zulässig ist, ist für die Verwendung des virtuellen ausgehenden Telnet-Datenverkehrs kein statischer Datenverkehr erforderlich. Im folgenden Beispiel wird der interne Benutzer unter 10.31.1.50 Telnet auf virtual 99.99.99.30 festgelegt und authentifiziert. Die Telnet-Verbindung wird sofort getrennt. Nach der Authentifizierung wird der TCP-Datenverkehr von 10.31.1.50 an den Server unter 99.99.99.2 zugelassen:

PIX-Konfiguration Virtual Telnet Outbound:

ip address outside 99.99.99.1 255.255.255.0
ip address inside 10.31.1.75 255.255.255.0
global (outside) 1 99.99.99.7-99.99.99.10 netmask 255.255.255.0
timeout uauth 0:05:00 absolute
aaa-server RADIUS protocol radius
aaa-server AuthOutbound protocol radius
aaa-server AuthOutbound (inside) host 171.68.118.101 cisco timeout 5
aaa authentication include telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
aaa authentication include tcp/49 outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
virtual telnet 99.99.99.30

Hinweis: Es gibt keine Autorisierung, da es sich um RADIUS handelt.

PIX-Debugging Virtual Telnet Outbound:

109001: Auth start for user '???' from 10.31.1.50/11034 
    to 99.99.99.30/23
 109011: Authen Session Start: user 'pixuser', Sid 16
 109005: Authentication succeeded for user 'pixuser' 
    from 10.31.1.50/11034 to 99.99.99.30/23 on interface 
    inside
 302001: Built outbound TCP connection 18 for faddr 
    99.99.99.2/49 gaddr 99.99.99.8/11036 laddr 
    10.31.1.50/11036 (pixuser)
 302002: Teardown TCP connection 18 faddr 99.99.99.2/49 
    gaddr 99.99.99.8/11036 laddr 10.31.1.50/11036 
    duration 0:00:02 bytes 0 (pixuser)

Virtuelle Telnet-Abmeldung

Wenn Benutzer Telnet an die virtuelle Telnet-IP-Adresse senden, zeigt der Befehl show auth ihre Authentifizierung an. Wenn die Benutzer den Datenverkehr nach Abschluss der Sitzungen verhindern möchten, wenn noch Zeit in der Warteschlange ist, müssen sie erneut eine Telnet-Verbindung zur virtuellen Telnet-IP-Adresse herstellen. Dadurch wird die Sitzung deaktiviert.

Nach der ersten Authentifizierung:

 pix3# show uauth
                         Current    Most Seen
 Authenticated Users       1          2
 Authen In Progress        0          1
 user 'pixuser' at 10.31.1.50, authenticated
    absolute   timeout: 0:05:00
    inactivity timeout: 0:00:00
 pix3# 109001: Auth start for user 'pixuser' from 
    10.31.1.50/11038 to 99.99.99.30/23
 109005: Authentication succeeded for user 'pixuser' 
    from 10.31.1.50/11038 to 99.99.99.30/23 on 
    interface inside

Nach der zweiten Authentifizierung (d. h. das Loch wird geschlossen):

 pix3# show uauth 
                         Current    Most Seen
 Authenticated Users       0          2
 Authen In Progress        0          1

Port-Autorisierung

Die Autorisierung ist für Port-Bereiche (wie TCP/30-100) zulässig. Wenn auf dem PIX Virtual Telnet konfiguriert ist und die Autorisierung für eine Reihe von Ports erfolgt, gibt der PIX nach dem Öffnen der Öffnung mit Virtual Telnet einen tcp/30-100-Befehl zur Autorisierung an den TACACS+-Server aus:

static (inside,outside) 99.99.99.75 10.31.1.50 netmask 255.255.255.255 0 0
conduit permit tcp host 99.99.99.75 host 99.99.99.2
static (inside,outside) 99.99.99.75 10.31.1.50 netmask 255.255.255.255 0 0
virtual telnet 99.99.99.75
aaa authentication include any inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
aaa authorization include tcp/30-100 inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
virtual telnet 99.99.99.30

Konfiguration des TACACS+-Freeware-Servers:

user = anyone {
         login = cleartext "anyone"
         cmd = tcp/30-100 {
         permit 10.31.1.50
         }
         }

AAA-Abrechnung für anderen Datenverkehr als HTTP, FTP und Telnet

Nachdem wir sichergestellt hatten, dass das virtuelle Telnet den TCP/49-Datenverkehr zum Host im Netzwerk zulässt, entschieden wir uns für eine Abrechnung, also fügten wir hinzu:

aaa accounting include any inbound 
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound 

Dies führt dazu, dass bei der Übertragung des TCP/49-Verkehrs eine Abrechnung erstellt wird (dieses Beispiel stammt von der TACACS+-Freeware):

Sun Feb 27 05:24:44 2000 10.31.1.75 cse PIX 
    99.99.99.2 start task_id=0x14 foreign_ip=99.99.99.2 local_ip=171.68.118.106 
    cmd=tcp/49 

Erweiterte Authentifizierung (Xauth)

Beispielkonfigurationen

• Terminierung von IPSec-Tunneln an mehreren Cisco Secure PIX Firewall-Schnittstellen mit Xauth

• IPSec zwischen der Cisco Secure PIX Firewall und einem VPN-Client mit erweiterter Authentifizierung

Authentifizierung auf der DMZ

Um Benutzer zu authentifizieren, die von einer DMZ-Schnittstelle zu einer anderen wechseln, weisen Sie den PIX an, den Datenverkehr für die genannten Schnittstellen zu authentifizieren. Auf unserem PIX ist die Anordnung wie folgt:

least secure 

PIX outside (security0) = 1.1.1.1 

pix/intf4 (DMZ - security20) = 4.4.4.4 & device 4.4.4.2 

pix/intf5 (DMZ - security25) = 5.5.5.5 & device 5.5.5.8 

(static to 4.4.4.15)

PIX inside (security100) = 10.31.1.47

 most secure 

Netzwerkdiagramm

PIX-Konfiguration

Wir möchten Telnet-Datenverkehr zwischen pix/intf4 und pix/intf5 authentifizieren:

nameif ethernet0 outside security0 
nameif ethernet1 inside security100 
(nameif ethernet2 pix/intf2 security10 
nameif ethernet3 pix/intf3 security15) 
nameif ethernet4 pix/intf4 security20 
nameif ethernet5 pix/intf5 security25
ip address outside 1.1.1.1 255.255.255.0
ip address inside 10.31.1.47 255.255.255.0 
(ip address pix/intf2 127.0.0.1 255.255.255.255 
ip address pix/intf3 127.0.0.1 255.255.255.255)
ip address pix/intf4 4.4.4.4 255.255.255.0 
ip address pix/intf5 5.5.5.5 255.255.255.0 
static (pix/intf5,pix/intf4) 4.4.4.15 5.5.5.8 netmask 255.255.255.255 0 0 
aaa authentication telnet pix/intf4 5.5.5.0 255.255.255.0 
4.4.4.0 255.255.255.0 AuthInbound
aaa authentication telnet pix/intf5 5.5.5.0 255.255.255.0 
4.4.4.0 255.255.255.0 AuthInbound
aaa-server TACACS+ protocol tacacs+
aaa-server AuthInbound protocol tacacs+ 
aaa-server AuthInbound (inside) host 171.68.118.101 cisco timeout 5

Xauth Accounting

Wenn der Befehl sysopt connection permit-ipsec, nicht der Befehl sysopt ipsec pl-compatible, im PIX mit xauth konfiguriert ist, ist die Abrechnung für TCP-Verbindungen gültig, nicht jedoch für ICMP oder UDP.

Zugehörige Informationen

• PIX-Produkt-Support-Seite
• PIX-Befehlsreferenz
• RADIUS-Support-Seite
• Requests for Comments (RFCs)
• Support-Seite für Cisco Secure UNIX
• Support-Seite für Cisco Secure ACS für Windows
• Technischer Support – Cisco Systems