Hi Eugene. If you mean uauth inactivity/absolute timeouts I reckon they might go under ACS user profile Tacacs+ settings idle-time/timeout. Needs to be verified though.
Cheers A. On 23 July 2012 17:14, Eugene Pefti <[email protected]> wrote: > Wow!!! > It's quite a report. Good job, Alexei ;) > I've never seen or even imagined in my life that you can authorize such > commands on ACS, i.e. "command udp/53 arg permit 10.0.0.100" > Ironically enough, I'm deploying Cut through proxy for one of our clients > to have them meet some weird security requirements to authenticate users > interactive access to services hosted in the so-called cyber critical > perimeter. > Two problems that I already ran into. Authorization doesn't work for me, > the way they described in this doc: > > > http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00807349e7.shtml > > See the section starting with "Complete these steps in order to configure > TACACS+ authorization:" > Down below they say "The ACL you use for authorization matching should > contain rules that are equal to, or a subset of, the rules in the ACL used > for authentication matching". > I do exactly the same but it still doesn't work for me. Will try your > method though ;) > > Second problem is inactivity timeout. See my previous posting here. I > described it in details. Also scratching my head and can't figure how to > make the inactivity timer stop the session. > > Eugene > > From: Alexei Monastyrnyi <[email protected]> > Date: Sunday, July 22, 2012 8:23 PM > > To: Eugene Pefti <[email protected]> > Cc: Marta Sokolowska <[email protected]>, GuardGrid < > [email protected]>, ccie_security <[email protected]> > Subject: Re: [OSL | CCIE_Security] Radius VSA > > Yeah, I agree, it is quite off the track for ASA and Tacacs. And to your > last statement, it is true, if you are not matching Telnet on CTP_ACL, > permit telnet makes little sense. > > But this is the command you see sent to Tacacs from ASA IF you match > telnet. If you configure authorization wrong or of you configure accounting > on Tacacs, you see in logs (either failed or accounting) "cmd telnet > a.b.c.d". > > I have just done a quick test with different types of traffic matching ASA > CTP_ACL: > - SSH - TCP port 22 > - DNS - UDP port 53 > - GRE IP - IP protocol 47 > > Here is a test bed: > ACS (.100) --- 10.0.0.0/24 -- (.3 inside) ASA (.3 outside) -- 10.1.1.0/24-- > (.1) R1 > > ! ACS > - ASA as a NAS > - Regular user AUTH with just password defined, no command authorization > or downloadable ACLs. > > ! ASA > interface Ethernet0 > nameif outside > security-level 0 > ip address 10.1.1.3 255.255.255.0 > ! > interface Ethernet1 > nameif inside > security-level 100 > ip address 10.0.0.3 255.255.255.0 > ! > aaa-server ACS_TAC protocol tacacs+ > aaa-server ACS_TAC (inside) host 10.0.0.100 > key cisco > ! > access-list AUTH extended permit tcp any any eq telnet > access-list AUTH extended permit tcp any any eq ssh > access-list AUTH extended permit gre any any > access-list AUTH extended permit udp any any eq domain > ! > aaa authentication match AUTH outside ACS_TAC > aaa authorization match AUTH outside ACS_TAC > > I am omitting OUTSIDE_IN ACL here. It is the same as AUTH ACL. OUDSIDE_IN > ACL has to have whatever AUTH ACL has or else the traffic will never get > matched. > > ! R1 > interface FastEthernet0/0 > ip address 10.1.1.1 255.255.255.0 > ! > ip route 0.0.0.0 0.0.0.0 10.1.1.10 > ! > interface Tunnel1 > ip address 172.16.1.1 255.255.255.0 > tunnel source FastEthernet0/0 > tunnel destination 10.0.0.100 > ! > ip name-server 10.0.0.100 > > Tests from R1: > Initial > telnet 10.0.0.100 – triggers authentication. > > Subsequent > telnet 10.0.0.100 – triggers authorization request for Telnet > telnet 10.0.0.100 22 – triggers authorization request for TCP 22 > ping R1 – triggers authorization request for UDP 53 > ping 172.16.1.2 – triggers authorization request for IP 47 > > Here is what ASA is sending for authorization to ACS (Logging->Failed) > once I start sending the traffic after successful authentication but with > no authorization for commands in user profile: > > service=shell cmd=telnet 10.0.0.100 > service=shell cmd=tcp/22 10.0.0.100 > service=shell cmd=udp/53 10.0.0.100 > service=shell cmd=47/0 10.0.0.100 > > I also ran a capture on ASA inside interface > > ASA1(config)# sh cap > capture ACS type raw-data access-list AUTH interface inside [Capturing - 0 > bytes] > > There is no traffic passed to destinations matched by AUTH ACL with failed > authorization. > > As soon as I authorize a command on ACS, say "command udp/53 arg permit > 10.0.0.100". It starts passing the traffic. > > ASA1(config)# sh cap ACS detail > 1 packet captured > 1: 02:21:57.005630 00ab.bffb.c401 0800.2723.6cae 0x0800 62: > 10.1.1.1.56456 > 10.0.0.100.53: [udp sum ok] udp 20 (ttl 255, id 1) > 1 packet shown > > So it works, but configuration on Tacacs server is REALLY weird. :-) There > is no such real shell commands as udp/53 a.b.c.d or 47/0 a.b.c.d.. but > there you go… what has really been consistent on that bloody ASA/IPX from > day one? :-) It has been 10 years since I started working on PIX and later > ASA, it has always been a constant pain in the… > > On that enthusiastic note I would suggest you listen to one of the last > Cisco TAC Security podcasts “History of PIX”. :-) It would crack me big > time. > > Hope it makes sense. > A. > > On 23 July 2012 09:26, Eugene Pefti <[email protected]> wrote: > >> I agree with that latter but what about the former, i.e. ASA CTP with >> TACACS. Why would you need to authorize telnet to 1.1.1.1 with commands set >> if you don’t run this command on ASA. **** >> >> Here are my reasoning. You enable CTP on ASA with CTP ACL that has to >> contain at least one of the protocols that would trigger CTP.**** >> >> ** ** >> >> E.g. (I want to authenticate the user with HTTP and then allow access to >> the host behind the ASA via SSH)**** >> >> access-list CTP-ACL extended permit tcp any host 136.1.125.5 eq www **** >> >> access-list CTP-ACL extended permit tcp any host 136.1.125.5 eq ssh**** >> >> ** ** >> >> What’s the use of command authorization set ? E.g. If I want to allow >> telnet traffic to my host behind ASA via “telnet permit 136.1.125.5” then >> it will never be useful because telnet is not on CTP-ACL and it will always >> work providing it is allowed by interface ACL. Simply speaking, telnet >> traffic will always bypass CTP.**** >> >> ** ** >> >> Eugene**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *From:* Alexei Monastyrnyi [mailto:[email protected]] >> *Sent:* Sunday, July 22, 2012 3:52 PM >> *To:* Eugene Pefti >> *Cc:* Marta Sokolowska; GuardGrid; ccie_security >> >> *Subject:* Re: [OSL | CCIE_Security] Radius VSA**** >> >> ** ** >> >> I don't think so. I reckon for ASA auth-proxy and Tacacs it is >> recommended to use command authorization sets, say for Telnet it would >> be command telnet arg permit 1.1.1.1 >> >> For ASA and RADIUS it is recommended to use downloadable ACLs in ASA >> format. >> >> Cheers, >> A. >> **** >> >> On 7/23/2012 3:29 AM, Eugene Pefti wrote:**** >> >> Auth-proxy examples:**** >> >> ** ** >> >> >> http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_auth/configuration/12-4/sec-cfg-authen-prxy.html#GUID-06899095-B258-4A9C-85F1-5832D29E754C >> **** >> >> ** ** >> >> A question/comment on ASA EZVPN and SSL VPN related guide. There's table >> D4 in the guide "Table D-4 Examples of Cisco AV Pairs and their Permitting >> or Denying Action"**** >> >> And it shows the ACL like this:**** >> >> ip:inacl#1=deny ip 10.155.10.0 0.0.0.255 10.159.2.0 0.0.0.255 log**** >> >> ** ** >> >> Will ASA understand the wilcard notation ?**** >> >> ** ** >> >> Eugene**** >> >> ** ** >> >> *From: *Alexei Monastyrnyi <[email protected]> >> *Reply-To: *"[email protected]" <[email protected]> >> *Date: *Sunday, July 22, 2012 4:24 AM >> *To: *Eugene Pefti <[email protected]> >> *Cc: *Marta Sokolowska <[email protected]>, GuardGrid < >> [email protected]>, ccie_security <[email protected]> >> *Subject: *Re: [OSL | CCIE_Security] Radius VSA**** >> >> ** ** >> >> Hi guys, >> here are some links covering RADIUS attributes. >> >> For the purpose of quick navigation during the lab, I reckon it is better >> to refer to some documents where those attributes are within a context, not >> just a bare list.**** >> >> IOS EZ VPN related**** >> >> >> http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_esyvpn/configuration/12-4t/sec-easy-vpn-srvr.html#GUID-D0BC5B4D-7BDB-44B6-B49F-EBBD79F1D185 >> **** >> >> >> >> **** >> >> IOS SSL VPN related**** >> >> >> http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_sslvpn/configuration/12-4t/sec-conn-sslvpn-ssl-vpn.html#GUID-F005501D-8992-48A9-8D4A-7650D7554A3F >> **** >> >> ** ** >> >> ASA EZ VPN and SSL VPN related**** >> >> >> http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ref_extserver.html#wp1661512 >> **** >> >> ** ** >> >> ACS RADIUS attributes reference list**** >> >> >> http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2/user/guide/A_RADAtr.html >> **** >> >> ** ** >> >> ACS TACACS attributes list**** >> >> >> http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2.1/User_Guide/A_TACAtr.html >> **** >> >> ** ** >> >> CAR RADIUS attributes list**** >> >> >> http://www.cisco.com/en/US/docs/net_mgmt/access_registrar/5.1/user/guide/a_attrib.html >> **** >> >> ** ** >> >> ** ** >> >> HTHJ >> A. >> >> >> **** >> >> On 7/22/2012 12:10 PM, Eugene Pefti wrote:**** >> >> Good point, Marta,**** >> >> I wish there’s a consolidated documentation showing how to properly form >> those attributes with the required service for different scenarios – >> auth-proxy, shell access, VPN and so on.**** >> >> I.e. we do auth-proxy via RADIUS and it’s not enough to know the >> attribute name - Name=proxyacl.**** >> >> The syntax is auth-proxy:proxyacl#1=permit ip any any”**** >> >> And so on for other situations and scenarios.**** >> >> **** >> >> Eugene**** >> >> **** >> >> **** >> >> *From:* [email protected] [ >> mailto:[email protected]<[email protected]>] >> *On Behalf Of *Marta Sokolowska >> *Sent:* Saturday, July 21, 2012 4:35 PM >> *To:* GuardGrid >> *Cc:* ccie_security >> *Subject:* Re: [OSL | CCIE_Security] Radius VSA**** >> >> **** >> >> Type the following command on the router's CLI: >> >> show aaa attributes >> >> -- >> >> Marta Sokolowska.**** >> >> 2012/7/22 GuardGrid <[email protected]>**** >> >> Guys,**** >> >> **** >> >> Where in the documentation do we get the complete listing of all >> attributes like below for RADIUS and TACACS for that matter,**** >> >> **** >> >> ipsec:tunnel-type=ESP**** >> >> ipsec:key-exchange=IKE**** >> >> ipsec:tunnel-password=ipexpert**** >> >> ipsec:inacl=SPLIT**** >> >> ipsec:save-password=1**** >> >> **** >> >> **** >> >> I found some in examples for configuring EZVPN but not a seperate section >> of just these VSA not IETF's.**** >> >> **** >> >> Let me know.**** >> >> **** >> >> **** >> >> >> >> >> **** >> >> _______________________________________________**** >> >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com**** >> >> ** ** >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com <http://www.platinumplacement.com/>**** >> >> ** ** >> >> ** ** >> > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
