Re: Option for endpoint.anyconnect.deviceuniqueid of Cisco/ASA DAP

2020-04-17 Thread yesi



On 4/17/20 6:11 PM, David Woodhouse wrote:

I think you can set at least the unique ID with the
openconnect_set_mobile_info() function, which isn't exposed on the
command line. Do you want to try using that and let us know if it does
what you expect?

There was a patch at
http://lists.infradead.org/pipermail/openconnect-devel/2016-July/003808.html
which attempted to add support for it for non-mobile platforms but it
needed a little more work. We should probably revisit that.


I note modern AnyConnect also sends a 'unique-id-global' as well as the
'unique-id' field.


Hi David,

I am not a dev.
I gave in the previous post the logs from AnyConnect v10.x that were 
seen into the ASA.
I would like to give a try if you say me what to do step by step, to run 
on Linux.


Here are the missing logs from ASA for a openconnect client :

Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.devicetype =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.platformversion =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.deviceuniqueid =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.macaddress["0"] =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.publicmacaddress =


This attribute "endpoint.anyconnect.platformversion" is not necessary 
since with option of "openconnect --version-string" is enough.
The last ones are "endpoint.anyconnect.macaddress["0"]" and 
"endpoint.anyconnect.publicmacaddress" would be great.


But for the filter DAP of Cisco/ASA, the esential attribute 
"endpoint.anyconnect.deviceuniqueid" is needed.
I put different options to correspond to a Windows client as a 
AnyConnect client log.


y.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel


Re: Option for endpoint.anyconnect.deviceuniqueid of Cisco/ASA DAP

2020-04-17 Thread David Woodhouse
On Thu, 2020-04-16 at 22:46 +0200, yesi wrote:
> Hi,
> 
> Thank you for your works.
> 
> 
> I was given a windows laptop with Anyconnect client to connect to
> the 
> VPN server.
> 
> There is an registered unique ID (i suppose 
> endpoint.anyconnect.deviceuniqueid) that was made when the windows 
> client was connected for the first time.
> 
> So before that the filter was applied, using Openconnect on Linux to 
> connect to Cisco/ASA SSL VPN does work.
> 
> 
> But today, the admin to secure better uses DAP of Cisco/ASA, to
> filter 
> by that unique ID. I have that ID.
> 
> It seems that it uses |%ASA-7-734003|.
> 
>  From [1], there are various options that can be given.
> 
> Openconnect does not give some options when connecting into the ASA
> logs 
> : it does not give that ID when logging. i do not see these
> informations 
> into the ASA logs.
> 
> But AnyConnect client on a Windows station give to ASA logs some 
> endpoint options as :
> 
> - endpoint.anyconnect.deviceuniqueid
> 
> - endpoint.anyconnect.macaddress
> 
> - endpoint.anyconnect.address
> 
> - etc
> 
> 
> What i would like to use is to give the option of 
> endpoint.anyconnect.deviceuniqueid when running openconnect.
> 
> I am not it is implemented, isn't it ?
> 
> If yes, which option could i use ?
> 
> If not, do you think that option could later be added ?
> 
> Actually, i can use the 8.05, 8.06 and Git version.
> 
> 
> Thank you in advance for return.

I think you can set at least the unique ID with the
openconnect_set_mobile_info() function, which isn't exposed on the
command line. Do you want to try using that and let us know if it does
what you expect?

There was a patch at
http://lists.infradead.org/pipermail/openconnect-devel/2016-July/003808.html
which attempted to add support for it for non-mobile platforms but it
needed a little more work. We should probably revisit that.


I note modern AnyConnect also sends a 'unique-id-global' as well as the
'unique-id' field.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel


Re: GlobalProtect connection loss

2020-04-17 Thread The Wanderer
On 2020-04-13 at 22:21, Daniel Lenski wrote:

> On Mon, Apr 13, 2020 at 6:33 PM The Wanderer 
> wrote:
> 
>> Would a repeating ping over the VPN tunnel (one every 30 seconds,
>> more a keepalive than anything else) be enough to qualify as
>> traffic for this purpose, or would I need to keep something else
>> (e.g. the RDP session) going?
> 
> I don't really know what is used to detect an idle connection. Ping 
> may or may not be enough. ¯\_(ツ)_/¯

It seems to have worked in this case. The session died at about twenty
minutes past midnight; the final timestamp in the file is three hours,
24 seconds after the first one. The resulting file was a round 999K, and
just over a million lines.

It actually looks like the rekey went through successfully, but
something odd happened afterwards. I suspect that the key information
here is going to be in the last dozen or so lines.

There's what looks like the beginning of a client-initiated logout
attempt (although I certainly did not initiate any such logout; I was
asleep at the time), followed by a received result which includes
"Invalid user name", and then EOF - which I interpret to be the program
exiting.

The credentials reported in that received result (which, appropriately,
don't include a password) appear to match those used to authenticate
before. My past experience indicates that when this type of
disconnection happens, reconnecting immediately (as in, within seconds)
with the exact same credentials works fine.

In hindsight I realize there was one thing I could have done differently
on this session invocation to be more sure I didn't miss any stderr,
etc., messages - but I didn't do it, so I'm not entirely positive
there's nothing missing. I hope all the important stuff is there.

>> I hope it's OK if I process the resulting file to strip out
>> identifying information - organization names, not IP addresses et
>> cetera; I'm not entirely sure what is and isn't OK to let out,
>> here, but I know we're told not to share the GlobalProtect portal
>> address and I can see that in the logs already.
> 
> Yep, you should see plenty of examples of how to obfuscate such
> things in the list archives. If you're unsure, you can send the logs
> to "just one random guy on the Internet" (me) instead of "a whole
> bunch of us."

I've looked at the recent archives, but I've only found one log
presented at all and it wasn't at all clear what about it had been
changed for obfuscatory purposes.

Rather than dig through an unknown amount of archives looking for enough
examples to be able to determine what's good practice, I've just gone
through (a copy of) the log and replaced not just the obvious things
(recognizable names, passwords, the external IP address of the VPN
portal) but anything that looked like it even might be a unique ID, down
to in one case something that was reported as being an MD5 hash; the
only apparent hex strings I left unchanged were the "ETag:" entries in
what look like the HTTP traffic.

This is probably far more anonymization than is really necessary, not to
mention far more manual effort, but I'm reasonably confident that it's
sufficient.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
[2020-04-13 21:20:19] POST https://foo.bar.baz/global-protect/prelogin.esp?tmp=tmp=4100=Linux
[2020-04-13 21:20:19] Attempting to connect to server VPN_PORTAL_IPV4:443
[2020-04-13 21:20:19] Connected to VPN_PORTAL_IPV4:443
[2020-04-13 21:20:20] SSL negotiation with foo.bar.baz
[2020-04-13 21:20:20] Connected to HTTPS on foo.bar.baz with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
[2020-04-13 21:20:20] > POST /global-protect/prelogin.esp?tmp=tmp=4100=Linux HTTP/1.1
[2020-04-13 21:20:20] > Host: foo.bar.baz
[2020-04-13 21:20:20] > User-Agent: PAN GlobalProtect
[2020-04-13 21:20:20] > 
[2020-04-13 21:20:20] Got HTTP response: HTTP/1.1 200 OK
[2020-04-13 21:20:20] Date: Tue, 14 Apr 2020 01:20:20 GMT
[2020-04-13 21:20:20] Content-Type: application/xml; charset=UTF-8
[2020-04-13 21:20:20] Content-Length: 401
[2020-04-13 21:20:20] Connection: keep-alive
[2020-04-13 21:20:20] ETag: "d7a5da11d19"
[2020-04-13 21:20:20] Pragma: no-cache
[2020-04-13 21:20:20] Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
[2020-04-13 21:20:20] Expires: Thu, 19 Nov 1981 08:52:00 GMT
[2020-04-13 21:20:20] X-FRAME-OPTIONS: DENY
[2020-04-13 21:20:20] Set-Cookie: PHPSESSID=PHP_SESSION_ID_COOKIE; secure; HttpOnly
[2020-04-13 21:20:20] Set-Cookie: PHPSESSID=PHP_SESSION_ID_COOKIE; secure; HttpOnly
[2020-04-13 21:20:20] Set-Cookie: PHPSESSID=PHP_SESSION_ID_COOKIE; secure; HttpOnly
[2020-04-13 21:20:20] Set-Cookie: PHPSESSID=PHP_SESSION_ID_COOKIE; secure; HttpOnly
[2020-04-13 21:20:20] Set-Cookie: PHPSESSID=PHP_SESSION_ID_COOKIE; secure; HttpOnly
[2020-04-13 21:20:20] Strict-Transport-Security: 

Re: GlobalProtect connection loss

2020-04-17 Thread The Wanderer
On 2020-04-16 at 18:22, The Wanderer wrote:

> My first attempt at sending the below mail seems to have been held up
> in moderation, because the attachment is slightly too large. While I
> wait for it to be noticed and released (or bounced, so that I can try
> again, with a compressed version if necessary), I want to at least
> make it visible that I haven't dropped this.

As I've now been (informally and non-authoritatively) informed that -
contrary to the wording of the moderation-notice message which I
received - basically nothing ever gets released from moderation (or, I
gather, formally rejected) on this mailing list, here's the
previously-attached file in compressed form.

If this gets held for moderation for some reason (opaque binary
attachment?), I'll have to see what else I can try.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


vpn-3hourdisconnect-obfuscated.log.7z
Description: application/7z-compressed


signature.asc
Description: OpenPGP digital signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel


Re: Option for endpoint.anyconnect.deviceuniqueid of Cisco/ASA DAP

2020-04-17 Thread yesi

Here are the log from AnyConnect client on ASA :

Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["8"]["1"] =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["4121"]["1"] =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["9"]["1"] =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.grouppolicy =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.ipaddress =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username1 =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username2 =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.tunnelgroup =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.clientversion =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.platform =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.devicetype =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.platformversion =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.deviceuniqueid =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.macaddress["0"] =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.useragent =
Apr 16 16:03:00 ip_addr_local %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.publicmacaddress =


The logs from Openconnect client on ASA :

Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["8"]["1"] =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["4121"]["1"] =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.radius["9"]["1"] =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.grouppolicy =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.ipaddress =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username1 =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.username2 =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute aaa.cisco.tunnelgroup =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute 
endpoint.anyconnect.clientversion =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.platform =
Apr 16 13:04:28 local_ip_addr %ASA-7-734003: DAP: User user-name, Addr 
public_ip_addr_client: Session Attribute endpoint.anyconnect.useragent =






___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel