Re: Help with understanding SysLogging entries

Eric Snijders · ‎09-18-2018

Hi All,

I think i have a pretty simple issue/question. I have a interface called "LSPXSG4". This interface has a ACL named "LSPXSG4_access_in". Within this ACL i have a few ACE's, but the following are interesting:

access-list LSPXSG4_access_in line 10 extended permit tcp host 172.24.0.43 172.24.0.0 255.255.0.0 eq https (hitcnt=7100098) 0x35047896
access-list LSPXSG4_access_in line 18 extended permit ip host 172.24.0.43 172.24.0.0 255.255.0.0 log informational interval 300 (hitcnt=13122) 0xcfa26d33

There are no denies before/inbetween these lines.
As you can see i have set-up logging for line 18 because i want to know what traffic is involved in this "permit ip" statement.

To my confusion, i see the following lines on the SysLog server:

2018-09-18 12:13:38	Local6.Info	192.168.20.71	Sep 18 2018 12:13:39: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.99.13(56014) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:15:35	Local6.Info	192.168.20.71	Sep 18 2018 12:15:37: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.142.208(45253) hit-cnt 1 300-second interval [0xcfa26d33, 0x00000000]
2018-09-18 12:15:36	Local6.Info	192.168.20.71	Sep 18 2018 12:15:38: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.98.81(55814) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:16:49	Local6.Info	192.168.20.71	Sep 18 2018 12:16:51: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.33.4(60432) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:19:12	Local6.Info	192.168.20.71	Sep 18 2018 12:19:14: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.143.95(46592) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:25:04	Local6.Info	192.168.20.71	Sep 18 2018 12:25:07: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.161.125(21874) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:25:23	Local6.Info	192.168.20.71	Sep 18 2018 12:25:26: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.147.134(59052) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
2018-09-18 12:26:54	Local6.Info	192.168.20.71	Sep 18 2018 12:26:57: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.141.241(7358) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]

As you can see, the hex-code (0xcfa26d33) does match line 18 of my ACL. But there are 2 things i don't understand:

Am i right by saying that in this case, the device "LSPAPPAMD211" behind interface LSPXSG4 is sending packets to various hosts within 172.24.x.x (source port 443, destination port random!?)?
If so, then why are these logs created based on rule #18? ACE Rule #10 literally has the same source and destination, but "https" instead of "ip".

I don't seem to understand these logs entries. Normally you would send from a random port to a defined port (tcp/443 in this case).

Seb Rupik · ‎09-18-2018

Hi there,
In answer to your questions:

1) Yes.

2) ACE #10 you have a source port of TCP/any (ie not specified) and a destination port of TCP/443 . Since it is clients in 172.24.x.x connecting to LSPAPPAMD211, they will be using ephemeral port numbers not TCP/443.

Whereas the ACE #18 doesn't specify port numbers, hence you see the hits there.

Remember this is an inbound ACL on LSPXSG4 which LSPAPPAMD211 is behind, therefore you are seeing traffic where LSPAPPAMD211 is the source.

Use the following to get the ouput you expect, move the port argument:

!
access-list LSPXSG4_access_in line 10 extended permit tcp host 172.24.0.43 eq https 172.24.0.0 255.255.0.0
!

cheers,
Seb.

Eric Snijders · ‎09-18-2018

Hi Seb,

Thanks for your answer, it clears up a lot. Just to be 100% sure:

The object LSPAPPAMD211 is sending traffic to various 172.24.x.x hosts with source port 443 and various destination ports. And since those destination ports are not 443, this traffic is hitting rule #18 in stead of #10, is this right?

If that's right, then i'll just have to track down why the hell this device is sending out traffic with source port 443 and random destination ports, that sounds really weird to me.

Seb Rupik · ‎09-18-2018

Your understanding is correct.

Regarding your concerns about LSPAPPAMD211, this looks like normal HTTPS traffic to me. The clients in 172.24.x.x are connecting to LSPAPPAMD211 on TCP/443. The logs are showing the replies back to the clients.

cheers,

Seb

Eric Snijders · ‎09-18-2018

If you state it that way it looks normal, but isn't it weird that i need a seperate ACE for allowing the return packets?

Seb Rupik · ‎09-18-2018

Although an ASA will permit traffic to flow from a high security-level interface to a lower security-level on, as soon as an ACL is implemented an implicit deny is present.

Irrespective of connection state (eg return traffic) you will have to explicitly permit it in order for the communication to succeed.

cheers,

Seb.

Eric Snijders · ‎09-18-2018

Hi Seb,

Thanks for the reply once again. I'm still having a hard time understanding this one.

Let's say the log entries are return-traffic on HTTPS requests. The traffic is initiated from devices behind the "Zorgnet" interface. On that interface i have a ACE to permit traffic from 172.24.x.x to the LSPAPPAMD211 device.

The traffic coming from the Zorgnet interface reaches the LSPAPPAMD211 machine, and the LSPAPPAMD211 replies to the HTTPS packets. I don't understand why i would have to explicitly define the return traffic on the LSPXSG4 interface. Isn't that what TCP is all about?

Src.Interface	Src.Host	Type	Dst.Interface	Dst.Host
Zorgnet	172.24.x.x	SYN	LSPXSG4	LSPAPPAMD211
LSPXSG4	LSPAPPAMD211	SYN-ACK	Zorgnet	172.24.x.x
Zorgnet	172.24.x.x	ACK	LSPXSG4	LSPAPPAMD211

Seb Rupik · ‎09-19-2018

Forget my last statement I was thinking about routers. On the ASA the packet flow bypasses the ACL check on interface ingress if it is an esablished connection.

The only reason for ACE #18 would be for logging. You should be able to remove ACE #10 and #18 and the connections initiated from 172.24.x.x will be peritted to LSPAPPAMD211 TCP/433 by virtue of the ACL you must have configured on the Zorgnet interface.

cheers,

Seb.