| 3 Mar 2023 |
 carwe | sounds like you need to know a few basic commands - scrolled through this, looks sufficient https://www.comparitech.com/net-admin/configure-cisco-switches/ | 11:50:33 |
| 7 Mar 2023 |
|  s.d.d. joined the room. | 16:17:13 |
| 16 Mar 2023 |
|  ns3sh1bb0l3th joined the room. | 05:20:54 |
| ns3sh1bb0l3th | Anyone here have experience with cisco asa with Firepower module? | 05:21:45 |
| carwe | many, probably. | 07:52:31 |
| carwe | they have been around for ages | 07:52:51 |
| 18 Mar 2023 |
| ns3sh1bb0l3th | Well the reason I asked was that I had recently added a malicious IP to my ACL block, but a day later I was still seeing SSL handshake attempts in the logs. I was wondering if anyone had any opinions on this. The one thing I thought of was that maybe they were spoofing the IP and therefore the IP added to the block list wasn't the actual source IP. I know I could setup an SSL policy on the FTD to only allow known/trusted SSL traffic to potentially deal with that sort of situation, but I was looking for any other opinions on this. Thanks! | 02:26:58 |
| carwe | is the block action configured in lina (asa) or sfr (firepower) part? if the latter: do you have rules with enabled appdetection? | 02:34:22 |
| ns3sh1bb0l3th | on the asa. | 02:35:48 |
| carwe | is the ip you see in asa logs the same as you see in webserver logs? a difference could IMO only happen when the attacker sends x-forwarded-for headers and you are logging them instead the connection-level ip (possibly on a system behind a reverseproxy) | 02:42:57 |
| carwe | real ip spoofing is hard enough and involves announcing wrong bgp routes, and then you would still be able to block the ip on asa. it should absolutely not happen that asa lets traffic pass which matches a block action ACE in its path. do you see the ACE match with simulated traffic (packet-tracer)? | 02:47:28 |
| ns3sh1bb0l3th | You know you gave me a couple of other things to check, this is what I was hoping for. Thank you! | 02:50:19 |
| ns3sh1bb0l3th | I did not see the ACE match and I still don't know why. I'll have to do some more digging tomorrow. The ACL is at the top of the list on the interface and the configuration looks good. So it's perplexing. | 06:52:13 |
| carwe | use packet-tracer to see what exactly happens | 09:48:54 |
| carwe | is the ACL attached to the interface at all? | 09:49:45 |
| carwe | are you filtering for sender ip only, or for destination too? remember ASA is one of the firewalls doing NAT-then- FILTER | 10:28:27 |
| carwe | * are you filtering for sender ip only, or for destination too? remember ASA is one of the firewalls doing NAT-then-FILTER | 10:28:44 |
| ns3sh1bb0l3th | Yes the ACL is attached to the interface and at the top of the list. I was filtering for sender ip and destination. The results of the packet tracer were that the IP is allowed in each phase and final result; never hit the ACL. I decided to look at the FMC and noticed whoever set it up had the default pre-filter policy which allows non tunneled traffic so the traffic is on fast path and would never hit the ACP. I created a prefilter and applied it to see if that fixed it, but the FTD and FMC version didn't match so when I went to deploy after assigning the prefilter to the ACP it was saying that it may not be supported. At this point I think I'm going to just open a TAC case because I need to upgrade the FTD to the same version as the FMC and then see if it works or not. Thanks for your help. | 21:30:48 |
| carwe | i dont fully get this. you said you have a deny-rule on the asa (not sfr). the way sfr is integrated with asa works like that: first asa does everything: nat, filter etc pp., THEN te class-maps are checked and IF the traffic matches a map with sfr inspection enabled, the packets are sent there (they go to the snort engine, and once snort decides, that it has seen enough, it returns a verdict - thats what you see in the logs as "SFR requested to bypass" -> "ASA, forward the remaining flow without bothering me" or "SFR requested to drop"). there is to my knowledge no way that a packet gets forwarded to the sfr module which was not filtered by asa BEFORE. or, are you talking about vpn-traffic? there is an option that vpn traffic bypasses the interface ACL and only gets filtered with a vpn-specific ACL. oooor you have firepower firmware running directly on chassis instead (what i understood) ASA firmware + SFR module (VM) | 21:43:05 |
| carwe | 
Download 02fig15_alt.jpg | 21:44:06 |
| carwe | https://i-bit-therefore-i-byte.com/2020/05/09/sending-traffic-to-sfr-module-cisco-asa-5506-x-with-firepower-services/
short overview WHY traffic ends up in the hands of the sfr module | 21:50:25 |
| carwe | of course, this only applies when there is ASA firmware on the chassis | 21:50:47 |
| ns3sh1bb0l3th | Well I may have been off the mark then based on what you just shared. It is a cisco 5545 asa with firepower module. I just started here and haven't had a lot of time to get aquainted with how it was setup. If it going through the asa before going to the SFR module and the acl is in place and at the top of the list then it should in theory be working. I'll take a look at the article your provided too, but yeah my best bet at this point may be to open a TAC case. Again, I appreciate your help/input. Have a great day! | 21:58:23 |
| carwe | let me know, i'm curious | 22:02:03 |
| ns3sh1bb0l3th | I'll do that. I won't be opening the TAC case until Monday, but then I'll let you know. | 22:07:50 |
| 19 Mar 2023 |
 ataraxia8 | Hi all, any of you experienced in cisco switches and uniquiti unifis? | 08:19:29 |
| carwe | strange question. also, "don't ask to ask, just ask". | 11:54:34 |
| ataraxia8 | strange? | 12:40:02 |
| ataraxia8 | changing a cisco catalyst 2960 plus for a ubiquiti/unifi usw pro 48. anybody that went through similar exercice? | 12:43:17 |
| 30 Mar 2023 |
| carwe | In reply to @ns3sh1bb0l3th:matrix.org
I'll do that. I won't be opening the TAC case until Monday, but then I'll let you know. and? still nothing from tac? | 09:21:40 |
