I tried to set an inactivity timeout locally on ASA like this:
timeout uauth 0:5:0 inactivity uauth 1:0:0 absolute
Then I authenticate and see the following on the ASA:
ASA1(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'telnetuser' at 10.0.0.100, authenticated
access-list #ACSACL#-IP-CTP_ICMP_ACL-50074fcb (*)
absolute timeout: 1:00:00
inactivity timeout: 0:05:00
My problem is that after 5 minutes of NOT sending any traffic that in the "aaa
authentication match" ACL the uauth session is still active and will timeout
after an hour
Eugene
From: Alexei Monastyrnyi [mailto:[email protected]]
Sent: Monday, July 23, 2012 3:56 AM
To: Eugene Pefti
Cc: Marta Sokolowska; GuardGrid; ccie_security
Subject: Re: [OSL | CCIE_Security] Radius VSA
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]<mailto:[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]<mailto:[email protected]>>
Date: Sunday, July 22, 2012 8:23 PM
To: Eugene Pefti <[email protected]<mailto:[email protected]>>
Cc: Marta Sokolowska
<[email protected]<mailto:[email protected]>>, GuardGrid
<[email protected]<mailto:[email protected]>>, ccie_security
<[email protected]<mailto:[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<http://10.0.0.0/24> -- (.3 inside) ASA (.3 outside)
-- 10.1.1.0/24<http://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]<mailto:[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]<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]<mailto:[email protected]>>
Reply-To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Date: Sunday, July 22, 2012 4:24 AM
To: Eugene Pefti <[email protected]<mailto:[email protected]>>
Cc: Marta Sokolowska
<[email protected]<mailto:[email protected]>>, GuardGrid
<[email protected]<mailto:[email protected]>>, ccie_security
<[email protected]<mailto:[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]>
[mailto:[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]<mailto:[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<http://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
