RADIUS- en TACACS+-verificatie kan worden uitgevoerd voor FTP-, Telnet- en HTTP-verbindingen. Verificatie voor andere minder gebruikelijke protocollen kan meestal aan het werk worden gemaakt. De TACACS+-autorisatie wordt ondersteund, de RADIUS-autorisatie niet. De veranderingen in PIX 5.1-verificatie, -autorisatie en -accounting (AAA) ten opzichte van de vorige versie omvatten uitgebreide verificatie (xauth)— verificatie van IPSec-tunnels vanuit Cisco Secure VPN-client 1.1.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Verificatie is wie de gebruiker is.
De gebruiker kan autorisatie uitvoeren.
Verificatie is geldig zonder machtiging.
De autorisatie is niet geldig zonder authenticatie.
Boekhouding is wat de gebruiker heeft gedaan.
Veronderstel u honderd gebruikers binnen hebt en u wilt slechts zes van deze gebruikers FTP, Telnet, of HTTP buiten het netwerk kunnen doen. U zou PIX vertellen om uitgaand verkeer te authentificeren en alle zes gebruikers id's op de de veiligheidsserver te geven TACACS+/RADIUS. Met eenvoudige authenticatie, deze zes gebruikers kunnen worden geverifieerd met gebruikersnaam en wachtwoord, en vervolgens uitgaan. De overige 94 gebruikers konden niet de straat op. De PIX vraagt gebruikers om gebruikersnaam/wachtwoord, geeft vervolgens hun gebruikersnaam en wachtwoord door aan de TACACS+/RADIUS-beveiligingsserver en opent of ontkent de verbinding, afhankelijk van het antwoord. Deze zes gebruikers kunnen FTP, Telnet of HTTP gebruiken.
Maar stel dat een van deze zes gebruikers, "Festus", niet te vertrouwen is. Je zou Festus willen toestaan om FTP te doen, maar niet HTTP of Telnet naar buiten. Dit betekent dat je autorisatie moet toevoegen, dat wil zeggen dat je moet autoriseren wat gebruikers kunnen doen naast het authenticeren van wie ze zijn. Dit geldt alleen voor TACACS+. Wanneer we autorisatie toevoegen aan de PIX, stuurt de PIX eerst de gebruikersnaam en het wachtwoord van Festus naar de beveiligingsserver, en stuurt vervolgens een autorisatieaanvraag waarin de beveiligingsserver wordt verteld wat "commando" Festus probeert te doen. Als de server correct is geïnstalleerd, kan Festus worden toegestaan om "ftp 1.2.3.4" te gebruiken, maar het wordt hem onmogelijk gemaakt om overal HTTP of Telnet te gebruiken.
Wanneer u probeert om van binnen naar buiten te gaan (of omgekeerd) met authenticatie/autorisatie op:
Telnet - De gebruiker ziet een gebruikersbenamingprompt verschijnen, dan een verzoek om wachtwoord. Als verificatie (en autorisatie) op de PIX/server succesvol is, wordt de gebruiker door de doelhost om gebruikersnaam en wachtwoord gevraagd.
FTP - De gebruiker ziet een gebruikersnaam en prompt verschijnen. De gebruiker moet local_username@remote_username voor gebruikersnaam en local_password@remote_password voor wachtwoord invoeren. De PIX verstuurt de local_username en local_password naar de lokale security server en als authenticatie (en autorisatie) succesvol is op de PIX/server, worden de remote_username en remote_password doorgegeven aan de doel-FTP server.
HTTP - In de browser wordt een venster weergegeven waarin een gebruikersnaam en wachtwoord worden gevraagd. Als de verificatie (en autorisatie) succesvol is, arriveert de gebruiker bij de doelwebsite. Houd in gedachten dat browsers gebruikersnaam en wachtwoord cachen. Als blijkt dat de PIX een HTTP-verbinding zou moeten uitproberen, maar dat niet doet, is het waarschijnlijk dat de herverificatie plaatsvindt met de browser die de gecachede gebruikersnaam en het wachtwoord opneemt naar de PIX, die dit vervolgens doorstuurt naar de verificatieserver. PIX syslog en/of server debug toont dit fenomeen. Als Telnet en FTP normaal lijken te werken, maar HTTP verbindingen niet, is dit de reden.
Tunnel - Wanneer u probeert het IPSec-verkeer met de VPN-client en Xauth te tunnelen in het netwerk, wordt er een grijs vak voor "Gebruikersverificatie voor nieuwe verbinding" weergegeven voor gebruikersnaam/wachtwoord.
Opmerking: deze verificatie wordt ondersteund vanaf de Cisco Secure VPN-client 1.1. Als het menu Help > About geen versie 2.1.x of hoger toont, werkt dit niet.
In deze sectie, wordt u voorgesteld met de informatie om uw veiligheidsserver te vormen.
Zorg ervoor dat u het PIX IP-adres of de volledig gekwalificeerde domeinnaam en sleutel in het CSU.cfg-bestand hebt.
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 .* } } }
Gebruik de GUI om het PIX IP-adres en de sleutel toe te voegen aan de lijst van Network Access Server (NAS).
user=adminuser { radius=Cisco { check_items= { 2="all" } reply_attributes= { 6=6 } } }
Gebruik deze stappen om Cisco Secure ACS voor Windows 2.x RADIUS te configureren.
Verkrijg een wachtwoord in het gedeelte User Setup GUI (Gebruikersinstelling).
Stel vanuit de GUI-sectie Group Setup attribuut 6 (Service-Type) in op Login of Administratief.
Voeg het PIX IP-adres toe in de NAS Configuration-sectie GUI.
De EasyACS-documentatie beschrijft de instellingen.
Klik in het groepsvak op Shell exec om exec-rechten te geven.
Om toestemming aan PIX toe te voegen, klik op Deny unmatched IOS-opdrachten onderaan de groepsinstelling.
Selecteer Nieuwe opdracht toevoegen/bewerken voor elke opdracht die u wilt toestaan, bijvoorbeeld Telnet.
Als telnetting naar specifieke sites is toegestaan, vul dan het IP-adres of de IP-adressen in het gedeelte met argumenten in het formulier "vergunning #.#.#.#". Anders, om Telnetting toe te staan, klik staan alle niet vermelde argumenten.
Klik op Bewerkingsopdracht Voltooien.
Voer stap 1 tot en met 5 uit voor elk van de toegestane opdrachten (bijvoorbeeld Telnet, HTTP of FTP).
Voeg de PIX IP toe in de sectie NAS Configuration GUI.
De gebruiker verkrijgt een wachtwoord in het gedeelte User Setup GUI (Gebruikersinstelling).
Klik in het groepsvak op Shell exec om exec-rechten te geven.
Als u toestemming aan de PIX wilt toevoegen, klikt u onder in de groepsinstallatie op Ongeëvenaarde IOS-opdrachten weigeren.
Selecteer Nieuwe opdracht toevoegen/bewerken voor elke opdracht die u wilt toestaan (bijvoorbeeld Telnet).
Om telnetting toe te staan voor specifieke sites, voer het IP-adres in in het gedeelte met argumenten in het formulier "vergunning #.#.#.#". Om Telnetting aan om het even welke plaats toe te staan, klik toestaan alle niet vermelde argumenten.
Klik op Bewerkingsopdracht Voltooien.
Voer stap 1 tot en met 5 uit voor elk van de toegestane opdrachten (bijvoorbeeld Telnet, HTTP of FTP).
Zorg ervoor dat het PIX IP-adres wordt toegevoegd in het gedeelte NAS Configuration GUI.
Voeg het PIX IP-adres en de sleutel toe aan het Clients-bestand.
adminuser Password="all" User-Service-Type = Shell-User
Voeg het PIX IP-adres en de sleutel toe aan het Clients-bestand.
adminuser Password="all" Service-Type = Shell-User
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 .* } }
Opmerking: Bepaalde show opdrachten worden ondersteund door de Output Interpreter Tool (alleen geregistreerde klanten) , waarmee u een analyse van show opdrachtoutput kunt bekijken.
Zorg ervoor dat de PIX-configuratie werkt voordat u AAA toevoegt. Als u geen verkeer kunt doorgeven voordat u verificatie en autorisatie instelt, kunt u dit nadien niet meer doen.
Inloggen op PIX inschakelen.
Het debuggen van de logboekconsole mag niet worden gebruikt op een zwaar geladen systeem.
Het registreren bufferde het zuiveren kan worden gebruikt, dan voert het bevel van het showregistreren uit.
Vastlegging kan ook naar een syslog server worden verzonden en daar worden onderzocht.
Zet het debuggen op de TACACS+ of RADIUS servers (alle servers hebben deze optie) aan.
PIX-configuratie |
---|
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] |
Deze sectie toont steekproeven van authentificatiedebugs voor diverse scenario's.
De externe gebruiker op 99.99.99.2 initieert verkeer naar binnen 10.31.1.50 (99.99.99.99) en wordt geverifieerd via TACACS (dat wil zeggen, inkomende verkeer gebruikt serverlijst "AuthInbound" die TACACS server 171.68.118.101 omvat).
Het voorbeeld hieronder toont een PIX debug met goede verificatie:
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.)
Het voorbeeld hieronder toont een PIX debug met slechte verificatie (gebruikersnaam of wachtwoord). De gebruiker ziet drie gebruikersnaam/wachtwoord-sets, gevolgd door dit bericht: Fout: max aantal pogingen overschreden.
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
Het voorbeeld hieronder toont een PIX debug waar de server pingable is, maar niet spreken met de PIX. De gebruiker ziet de gebruikersnaam eenmaal, maar de PIX vraagt nooit om een wachtwoord (dit is op Telnet). De gebruiker ziet Fout: Max aantal pogingen overschreden.
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
Het voorbeeld hieronder toont een PIX debug waar de server niet pingable is. De gebruiker ziet de gebruikersnaam eenmaal, maar de PIX vraagt nooit om een wachtwoord (dit is op Telnet). De volgende berichten worden weergegeven: Time-out naar TACACS+ server en Fout: Max aantal pogingen overschreden (een nepserver is in de configuratie verwisseld).
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
Het voorbeeld hieronder toont een PIX debug met goede verificatie:
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)
Het voorbeeld hieronder toont een PIX debug met slechte verificatie (gebruikersnaam of wachtwoord). De gebruiker ziet het verzoek om een gebruikersnaam en wachtwoord, en heeft drie mogelijkheden om deze in te voeren. Wanneer het bericht niet succesvol is, wordt het volgende bericht weergegeven: Fout: max aantal pogingen overschreden.
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
Het voorbeeld hieronder toont een PIX debug waar de server pingable is, maar de daemon is neer en zal niet met PIX communiceren. De gebruiker ziet gebruikersnaam, dan wachtwoord, de RADIUS server is mislukt bericht en de foutmelding: Max aantal pogingen overschreden. foutmelding.
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
Het voorbeeld hieronder toont een PIX debug waar de server niet pingable is of er een client/key mismatch is. De gebruiker ziet een gebruikersnaam, wachtwoord, de Time-out naar RADIUS server bericht en de fout: Max aantal pogingen overschreden bericht (een nepserver is in de configuratie verwisseld).
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
Als u beslist om toestemming toe te voegen, aangezien de vergunning zonder authentificatie niet geldig is, moet u vergunning voor de zelfde bron en bestemmingswaaier vereisen.
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
Merk op dat u geen toestemming voor uitgaand toevoegt omdat het uitgaande verkeer met RADIUS voor authentiek wordt verklaard, en de vergunning van RADIUS is ongeldig.
In het onderstaande voorbeeld ziet u een debug van PIX met goede verificatie en succesvolle autorisatie:
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)
Het voorbeeld hieronder toont de PIX debug met goede authenticatie maar mislukte autorisatie. Hier ziet de gebruiker ook het bericht Error: Autorisatie geweigerd.
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
aaa accounting include any inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
Uitvoer van TACACS+ freeware:
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
aaa accounting include any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthOutbound
RADIUS-uitvoer naar verdienste:
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
Als we een andere host buiten (op 99.99.99.100) aan ons netwerk toevoegen en deze host wordt vertrouwd, kunt u deze uitsluiten van verificatie en autorisatie met de volgende opdrachten:
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
Sommige TACACS+ en RADIUS servers hebben "max-sessie" of "view login users" functies. De mogelijkheid om max-sessies te doen of de ingelogde gebruikers te controleren is afhankelijk van de boekhouding. Wanneer er een accounting "start"-record gegenereerd is, maar er geen "stop"-record is, gaat de TACACS+ of RADIUS-server ervan uit dat de persoon nog steeds ingelogd is (dat wil zeggen dat de gebruiker een sessie heeft via de PIX).
Dit werkt goed voor Telnet en FTP verbindingen vanwege de aard van de verbindingen. Dit werkt niet goed voor HTTP vanwege de aard van de verbinding. In het volgende voorbeeld wordt een andere netwerkconfiguratie gebruikt, maar de concepten zijn hetzelfde.
Gebruiker Telnets door de PIX, die op de weg voor authentiek verklaren:
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
Omdat de server een start record maar geen stop record heeft gezien, toont de server op dit moment aan dat de Telnet-gebruiker is ingelogd. Als de gebruiker een andere verbinding probeert waarvoor verificatie nodig is (wellicht vanaf een andere pc) en als max-sessies is ingesteld op 1 op de server voor deze gebruiker (ervan uitgaande dat de server max-sessies ondersteunt), wordt de verbinding door de server geweigerd.
De gebruiker gaat over hun Telnet of FTP bedrijf op de doelhost, en gaat dan weg (besteedt er tien 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
Of u nu 0 (dat wil zeggen elke keer authenticeren) of meer (eens en niet opnieuw authenticeren tijdens de wachtperiode) is, er wordt een boekhoudkundige record geknipt voor elke site die wordt benaderd.
HTTP werkt anders vanwege de aard van het protocol. Hieronder zie je een voorbeeld van HTTP:
De gebruiker bladert van 171.68.118.100 tot 9.9.9.25 via de 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
De gebruiker leest de gedownloade webpagina.
De start record is gepost om 16:35:34 en de stop record om 16:35:35. Deze download duurde een seconde (dat wil zeggen, er was minder dan een seconde tussen de start en de stop record). Is de gebruiker nog steeds ingelogd op de website en is de verbinding nog steeds open wanneer de gebruiker de webpagina leest? Nee. Zullen max-sessies of inloggebruikers bekijken hier werken? Nee, omdat de verbindingstijd (de tijd tussen de "Built" en "Teardown") in HTTP te kort is. De start en stop record is sub-seconde. Er is geen beginrecord zonder stoprecord omdat de records op vrijwel hetzelfde moment plaatsvinden. Er wordt nog steeds start- en stop-record naar de server gestuurd voor elke transactie, of de uauth is ingesteld op 0 of iets groters. Max-sessies en inloggebruikers van de weergave werken echter niet vanwege de aard van HTTP-verbindingen.
De vorige discussie betreft het verifiëren van Telnet (en HTTP, FTP)-verkeer via de PIX. Zorg ervoor dat Telnet naar de PIX werkt zonder verificatie op:
telnet 10.31.1.5 255.255.255.255 passwd ww
Voeg vervolgens de opdracht toe om gebruikers Telnetting te verifiëren naar de PIX:
aaa authentication telnet console AuthInbound
Wanneer gebruikers Telnet naar de PIX vragen, wordt om het Telnet-wachtwoord (WW) gevraagd. PIX vraagt ook om de TACACS+ of RADIUS gebruikersnaam en wachtwoord. In dit geval aangezien de AuthInbound serverlijst wordt gebruikt, vraagt PIX om de TACACS+ gebruikersnaam en het wachtwoord.
Als de server is uitgeschakeld, kunt u toegang krijgen tot de PIX door pix in te voeren voor de gebruikersnaam en vervolgens het wachtwoord in te schakelen (wachtwoord in te schakelen wat dan ook ). Met de opdracht:
aaa authentication enable console AuthInbound
De gebruiker wordt gevraagd om een gebruikersnaam en wachtwoord die naar de TACACS- of RADIUS-server worden verzonden. In dit geval aangezien de AuthInbound serverlijst wordt gebruikt, vraagt PIX om de TACACS+ gebruikersnaam en het wachtwoord.
Aangezien het verificatiepakket voor inschakelen hetzelfde is als het verificatiepakket voor aanmelding, kan de gebruiker zich met TACACS of RADIUS bij de PIX aanmelden als hij zich met TACACS of RADIUS kan aanmelden via TACACS of RADIUS met dezelfde gebruikersnaam/wachtwoord. Dit probleem is toegewezen aan Cisco bug-id CSCdm47044 (alleen geregistreerde klanten).
Als de server down is, kunt u toegang tot PIX activeren modus door pix in te voeren voor de gebruikersnaam en normaal wachtwoord in te schakelen van de PIX (laat wachtwoord toe wat dan ook ). Als wachtwoord inschakelt wat niet in de PIX-configuratie staat, voert u pix in voor de gebruikersnaam en drukt u op Enter. Als de wachtwoordoptie inschakelen is ingesteld maar niet bekend is, moet een wachtwoordherstelschijf worden gebouwd om het wachtwoord opnieuw in te stellen.
Als u de opdracht hebt:
auth-prompt PIX_PIX_PIX
de gebruikers die door PIX gaan zien de volgende opeenvolging:
PIX_PIX_PIX [at which point one would enter the username] Password:[at which point one would enter the password]
Bij aankomst op de uiteindelijke bestemming, gebruikers zien de Gebruikersnaam: en Wachtwoord: prompt weergegeven door het doelvak. Deze prompt heeft alleen invloed op gebruikers die door de PIX gaan, niet naar de PIX.
Opmerking: er zijn geen boekhoudkundige gegevens geknipt voor toegang tot de PIX.
Als u de opdrachten hebt:
auth-prompt accept "GOOD_AUTH" auth-prompt reject "BAD_AUTH"
dan zien de gebruikers de volgende opeenvolging op mislukte/succesvolle login door PIX:
PIX_PIX_PIX Username: asjdkl Password: "BAD_AUTH" "PIX_PIX_PIX" Username: cse Password: "GOOD_AUTH"
Deze functie werkt momenteel niet en het probleem is toegewezen aan Cisco bug-id CSCdp93492 (alleen geregistreerde klanten).
Als authenticatie vereist is op sites buiten de PIX en op de PIX zelf, kan soms ongebruikelijk browsergedrag worden waargenomen, aangezien browsers de gebruikersnaam en het wachtwoord in de cache plaatsen.
Om dit te voorkomen, kunt u virtuele HTTP implementeren door een RFC 1918-adres (een adres dat niet routeerbaar is op het internet, maar geldig en uniek is voor de PIX in het netwerk) toe te voegen aan de PIX-configuratie met de volgende opdracht:
virtual http #.#.#.# [warn]
Wanneer de gebruiker probeert om buiten de PIX te gaan, is verificatie vereist. Als de waarschuwingsparameter aanwezig is, ontvangt de gebruiker een omleidingsbericht. De authenticatie is goed voor de tijdsduur in de auth. Zoals aangegeven in de documentatie, stel de duur van de opdracht Time-out auth niet in op 0 seconden met virtueel HTTP; dit voorkomt HTTP-verbindingen met de echte webserver.
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
Het is mogelijk om de PIX te configureren om alle inkomende en uitgaande te authenticeren, maar het is geen goed idee omdat sommige protocollen, zoals mail, niet eenvoudig te authenticeren zijn. Wanneer een mailserver en client proberen te communiceren via de PIX wanneer al het verkeer via de PIX wordt geverifieerd, toont PIX syslog voor niet-verificeerbare protocollen berichten zoals:
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)
Als het echter echt nodig is om een ongebruikelijke service te authenticeren, kan dit worden gedaan met behulp van de virtuele telnet opdracht. Met deze opdracht kan verificatie worden uitgevoerd op het virtuele Telnet IP-adres. Na deze verificatie kan het verkeer voor de ongebruikelijke service naar de echte server gaan.
In dit voorbeeld, wilt u TCP poort 49 verkeer te stromen van buiten host 99.99.99.2 naar binnen host 171.68.118.106. Aangezien dit verkeer niet echt authenticeerbaar is, kunt u een virtueel Telnet instellen. Voor virtueel Telnet moet er een gekoppeld statisch signaal zijn. Hier zijn zowel 99.99.99.20 als 171.68.118.20 virtuele adressen.
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
De gebruiker op 99.99.99.2 moet eerst de gegevens via Telnetting verifiëren op het adres 99.99.99.20 op de PIX-computer:
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
Na de succesvolle verificatie toont de opdracht Show Uauth aan dat de gebruiker "tijd op de meter" heeft:
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
En wanneer het apparaat bij 99.99.99.2 TCP/49 verkeer naar het apparaat wil verzenden bij 171.68.118.106:
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)
De vergunning kan worden toegevoegd:
aaa authorization include tcp/49 inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
zodat wanneer TCP/49-verkeer door de PIX wordt geprobeerd, de PIX ook de autorisatiequery naar de server verzendt:
109007: Authorization permitted for user 'cse' from 99.99.99.2/11057 to 171.68.118.106/49 on interface outside
Op de TACACS+ server wordt dit gezien als:
service=shell, cmd=tcp/49, cmd-arg=171.68.118.106
Aangezien uitgaand verkeer standaard is toegestaan, is er geen statische verbinding vereist voor het gebruik van virtueel Telnet uitgaand. In het volgende voorbeeld, de binnengebruiker bij 10.31.1.50 Telnets aan virtuele 99.99.99.30 en verklaart; de verbinding van Telnet wordt onmiddellijk gelaten vallen. Na verificatie is TCP-verkeer toegestaan van 10.31.1.50 naar de server op 99.99.99.2:
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
Opmerking: er is geen autorisatie omdat dit RADIUS is.
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)
Wanneer de gebruikers Telnet aan het virtuele adres van Telnet IP, het bevel van de show uauth hun audio tonen. Als de gebruikers willen voorkomen dat er verkeer doorgaat nadat hun sessies zijn beëindigd wanneer er nog tijd in de wachtrij is, moeten ze opnieuw Telnet naar het virtuele Telnet IP-adres. Hierdoor wordt de sessie van de ene naar de andere sessie verplaatst.
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
pix3# show uauth Current Most Seen Authenticated Users 0 2 Authen In Progress 0 1
Toestemming is toegestaan voor poortbereiken (zoals TCP/30-100). Als virtueel Telnet op de PIX en autorisatie is geconfigureerd voor een reeks poorten, geeft de PIX, zodra het gat is geopend met virtueel Telnet, een TCP/30-100-opdracht voor autorisatie af aan de TACACS+ server:
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
user = anyone { login = cleartext "anyone" cmd = tcp/30-100 { permit 10.31.1.50 } }
Nadat we ervoor hadden gezorgd dat virtueel Telnet werkte om TCP/49 verkeer toe te staan aan de host binnen het netwerk, besloten we dat we dit wilden boeken, dus we voegden eraan toe:
aaa accounting include any inbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound
Dit resulteert in het hebben van een boekhoudingsonderbreking wanneer het tcp/49 verkeer door gaat (dit voorbeeld is van de freeware TACACS+):
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
Het eindigen van IPSec-tunnels op meerdere Cisco Secure PIX-firewall-interfaces met Xauth
IPsec tussen Cisco Secure PIX-firewall en een VPN-client met uitgebreide verificatie
Om gebruikers te verifiëren die van één interface DMZ naar een andere gaan, vertel PIX om verkeer voor de genoemde interfaces voor authentiek te verklaren. Op onze PIX is de regeling:
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
We willen Telnet-verkeer tussen pix/intf4 en pix/intf5 authenticeren:
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
Als de opdracht sysopt connection license-ipsec, niet de opdracht sysopt ipsec pl-compatibel, in de PIX met xauth is geconfigureerd, is accounting geldig voor TCP-verbindingen, maar niet voor ICMP of UDP.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
24-Sep-2001 |
Eerste vrijgave |