A client AV detected as malware so I wanted to confirm the hash
certutil is built in so I used that but there are some free GUI tools
certutil -hashfile Cisco_Secure_FW_Mgmt_Center_Upgrade-7.2.9-44.sh.REL.tar MD5 | find /v "hash"
Compare the result to the MD5 hash on cisco.com downloads section. If you hover the version the MD5 and SHA1 hashes will be there to copy.
aaa group server radius DUO-AUTH
aaa authentication login default group DUO-AUTH local
aaa authentication login CON-LOCAL local
aaa group server radius DUO-AUTH
server name DUO-AUTH-PROXY
ip radius source-interface Vlan2
radius server DUO-AUTH-PROXY
address ipv4 192.168.1.1 auth-port 18122 acct-port 18122
pac key 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Move away from Groups 2, 5, 24.
DH Groups 2, 5, 24 are considered insecure and are deprecated in FTD’s running 6.5/6.6 and will be removed in a later version.
check 6.7 and 7.1 release notes and search for group 5
https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/710/management-center-device-config-71/vpn-s2s.html?
IKEv1
show vpn-sessiondb detail l2l filter ipaddress x.x.x.x
Look for "D/H Group" in IKEv1 section
sh crypto isakmp sa detail | i Grp:
sh crypto isakmp sa | i PFS Group 2,
Looking for groups 2 and 5
sh crypto isakmp sa detail | i Grp:2,
sh crypto isakmp sa detail | i Grp:5,
Can copy the full output of " sh crypto isakmp sa detail" to a text file and search
No one good way to do this, depends on variables. Some commands may help
sh ip arp (only works if you have l3 interfaces in each vlan)
sh ip dhcp snooping binding (needs dhcp snooping)
sh ip device tracking interface gigabitEthernet
ISE
Test lab is quite involved
Packet-tracer never worked well with VPN traffic, that was ok but now in FMC/FTD its also not working at all if you have snort or geoblocking rules. You will see an ip any any allow. Instead you must use the system support trace on live traffic. The whole point of packet tracer is that we don't always have live traffic or access to generate live traffic.
From cisco:
Indeed, from the packet tracer side it looks like the packet is going through in that IP permit any any, but that rule in reality does not exist.
Any rule which relies on snort will be classified by the box as a L4 permit ip any any, and unfortunately having a geodb rule looks like a snort rule for the box.
This is documented here:
https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/218196-understand-how-lina-rules-configured-wit.html
Rules with Snort Features Are Deployed As Permit Any Any
When you create a rule with features that are run by Snort side, like Geolocation, URL (Universal Resource Locator) filter, Application detection, etc, they are deployed on Lina side as a permit any any rule.
At a first glance, this can confuse you and make you think that the FTD allows all the traffic on that rule and stops the rule match verification for the rules that follow.
We also have an enhancement request for this: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd00446
Unfortunately, this breaks the usage of the packet tracer feature, and in this case, you should rather use “> system support trace” if there is live traffic.
302013 - built inbound connection
302014 - teardown TCP connection
725012 - Device chooses cipher for the SSL session with peer interface
725008 - ssl client propose cipher
725007 - teardown new ssl connection / terminated
725001 - starting ssl handsharek
725002 - ssl handsake completed
725003 - request to resume
113005 - AAA user authentication rejected
See:
https://www.cisco.com/c/en/us/support/docs/security/secure-client/221880-implement-hardening-measures-for-secure.html
Also:
http://www.cisco.com/en/US/docs/security/asa/asa82/system/message/logmsgs.html#wp4776913
Each connection that passes through the ASA is 9 syslogs so that will be a lot of logs
Old TAC sec pod cast
https://community.cisco.com/t5/security-knowledge-base/tac-security-podcast-show-information-and-episode-listing/ta-p/3126414
General syslog tips
Text zip's up well so you can zip before sending
Knowing the time frame of the issue helps any source / destination IPs
Notepad++ / sublime are good for working with big files
For really big files we really want a linux box
For windows users you can run a VM as well or install cygwin
User grep to look for sev1 events
grep "ASA-1-" ASASYSLOG.txt
Looks for sev 6 and pipe to head
grep "ASA-6" ASAlogs.txt | head -n 3
-v can be used to remove items from the log
grep "ASA-6" ASAlogs.txt | grep -v "ASA-6-302011" | grep -v "ASA-6-302015" | head -n 3
We can build up our command adding more -v items
grep "ASA-6" ASAlogs.txt | grep -v "ASA-6-302011" | grep -v "ASA-6-302015" | grep -v "ASA-6-305011" | head -n 3
Other linux CLI tools that are very useful
count / sed / awk / uniq / sort / bc
To remove all the charactors on the line leading up to "Mar 28", use the sed program to find and replace that text with "nothing":
cat ASAlogs.txt | sed 's/^.*Mar 28/Mar 28/g' | head -n 4
cut can be used to display something specific from each line:
grep "ASA-6-305011" ASAlogs.txt | cut -f 13 -d ' '
<166>Mar 28 2013 08:22:50: %ASA-6-305011: Built dynamic TCP translation from inside:10.10.103.38/63894 to outside:192.168.124.149/63894
becomes
outside:192.168.124.149/61128
Now lets say you wanted to get rid of the 'outside' text at the start of each line. Use sed to replace that text with nothing:
grep "ASA-6-305011" ASAlogs.txt | cut -f 13 -d ' ' | sed 's/outside://g'
When connection is torn down (teardown event) there is a byte count included
You could look for the initiator and the byte count
IP and how many bytes transfer
Then sort that based on byte count
This would give you talker
Sort by IP addresses
Use bc to sum up all the ip and sort on byte counts and see which IP was the top talker over all
You could also work on top number of connections. Look for usernames instead of IP's etc. A ddos may make a lot of connections but small amount of data transfered
You could look at denied connections
When the umbrella roaming client detects a VA on the LAN with it by default it will switch itself off and let the VA discover identity. Umbrella support said we can change this option.
https://support.umbrella.com/hc/en-us/articles/230901168#VirtualAppliance
Good capture option here for ASA
You can do a show trace on it and it goes though it like a packet tracer
capture capout2 type raw-data trace detail interface OUTSIDE include-decrypted match ip host 192.168.10.50 host 8.8.4.4
show capture capout2 trace detail packet-number 1
To configure Virtual appliance (VA), enter configuration mode (CTRL+B)
config va name umbrella01 (this name is just a label)
config va interface 172.16.0.6 255.255.255.0 172.16.0.1
config localdns add 172.16.0.8 (DC1)
config localdns add 172.16.0.9 (DC2)
https://docs.umbrella.com/deployment-umbrella/docs/appendix-d-troubleshooting-the-va-using-a-restricted-shell#section-use-configuration-mode-to-troubleshoot
Config auto updates
Need 2 VAs'
FW access to the URLS in setup doc
Config Deployments > Configuration > Sites and Active Directory.
Settings button top right
Auto upgrade
This is down to how cisco/webex resolves DNS. Depending on config it can be looking for external DNS records which need to resolve.
We already had an internal AD domain added (customer.com) in the umbrella dashboard as part of the internal domains.
On a working cap we saw it look for
_collab-edge._tls.customer-ext.com which didn't resolve
Then it looked for
_cisco-uds._tcp.customer-ext.com
which did resolve to the customer ucm server IP's (this must have been resolve by internal DC/DNS)
On the "not working" capture
Wireshark showed a SRV record
_cisco-uds._tcp.customer-ext.com was attempting to get resolved by the client but getting a "No such name" back from a public DNS server. It tried to resolve on the internet.
We needed to go into the DC and edit DNS on the external domain customer-ext.com
We also added the customer-ext.com to the internal domains in the umbrella dashboard.
Find DNS queries that didn't return an answer
Had an issue could ping vlan1 (LAN) SVI but not vlan146 (VOICE)
The setup was
LAN client -> L2 VL1 -> L3 SVL VL1 -> Inside ASA -> S2S VPN -> HQ
Phone client -> L2 VL146 -> L3SVI VL146 -> L3 SVI 1 -> Inside ASA-> S2S VPN -> HQ -> Phone server
I found some messed up NAT's
Removed the global
object network obj_any
nat (any,outside) dynamic interface
The NoNat had a missing object in the destination
nat (voice,outside) source static obj-10.60.146.0 obj-10.60.146.0 destination static HQ-NET HQ-NETS no-proxy-arp route-lookup
Also needed this NAT on the INSIDE with the 146 networks to ping the SVI. This is becuase the route to the HQ network is through the inside interface of the ASA.
nat (inside,outside) source static obj-10.60.146.0 obj-10.60.146.0 destination static HQ-NET HQ-NETS no-proxy-arp route-lookup
Connect to your anyconnect so you can see what tunnels/profiles are enabled
Use "show run tun" to see your tunnel config
Re-enable anyconnect
no address-pool STAFF-POOL
dhcp-server 10.60.1.6 10.60.1.7
group-policy GP-STAFF attributes
dhcp-network-scope 10.60.6.0
no ip local pool STAFF-POOL
https://www.petenetlive.com/KB/Article/0001050
I was trying to copy files to a cisco ASR 1001x router.
I was having issues due to internal FW rules etc. I could SSH so probably SCP would work.
I needed to enable the following command on the ASR router
ip scp server enable
However it still wasn't working.
I needed to run the pscp command on my server with the files with the -scp switch to force the old protocol
pscp -scp filename.bin username@x.x.x.x:filename.bin
I had to fill in the second filename.bin for the destination otherwise it would not work
When cisco find an issue they sometimes release a hotfix as a small quick fix.
The real fix will be put into the next maintenance release.
6.6 last FMC that supports cisco user agent ID. If you want to go above you need to uninstall useragent and install Cisco ISE-PIC agent
6.7.0 removes support for old ciphers. If you are using FTD you need to make sure all VPNs have been migrated to IKEv2 and updated ciphers.
ASA55xx-X devices only support up to certain sensor patches at time of writing 6.6.5.2
When you upgrade to 6.7.0 for example you should also upgrade to the latest release of 6.7.x at the time of writing it was 6.7.3 this ensures you get all fixes in your branch.
Because branches are worked on by different dev teams just because its fixed in 6.4.0.14 does not mean the same issue is fixed in 6.7.0 so you need to make sure to go to 6.7.3 or what ever is that latest patch in that branch
You get a health warning that interfaces are modified after upgrade to 6.7.3
SSH into FMC
enter "expert" mode
enter "sudo su"
Run this command
OmniQuery.pl -db mdb -e "select status,category,hex(uuid),body from notification where status=11;"
For each UUID delete the notification
OmniQuery.pl -db mdb -e 'delete from notification where uuid=unhex("XXXXXXXXXXXXXXXXXXXXXXXX");'
OmniQuery.pl -db mdb -e 'delete from notification where uuid=unhex("YYYYYYYYYYYYYYYYYYYYYYYY");'
OmniQuery.pl -db mdb -e 'delete from notification where uuid=unhex("ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ");'
Check again, it should be blank
OmniQuery.pl -db mdb -e "select status,category,hex(uuid),body from notification where status=11;"
Check your FMC interface the alert should have cleared
SSH to FMC
expert
cat /etc/sf/patch_history
This is useful for seeing hotfixes applied as they don't show in the version number in the web interface
- FMC:
https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/214756-configure-duo-two-factor-authentication.html#anc7
However, kindly know that this document is describing access for Web users only and not CLI, as CLI access using SSO is not supported for CLI users:
https://www.cisco.com/c/en/us/td/docs/security/firepower/670/configuration/guide/fpmc-config-guide-v67/user_accounts_fmc.html#:~:text=SSO%20users%E2%80%94SSO%20users%20have%20web%20interface%20access%20only.
- ASA and ASDM:
Kindly know that ASA CLI and ASDM GUI authentication is only requiring the integration with an external party (e.g. ISE or NPS), however, for ASA we can configure 2FA for VPN AnyConnect users as below:
https://community.cisco.com/t5/security-documents/configure-two-factor-authentication-on-asa-for-cisco-anyconnect/ta-p/3403768
https://duo.com/docs/sso-ciscoasa#:~:text=for%20each%20application.-,Configure%20Cisco%20ASA%20SSO,-Add%20Duo%20Single
But, if we want to use it for CLI access only without VPN, we could use RADIOUS with supposed to be previously configured:
https://community.duo.com/t/secure-cisco-asdm-with-mfa/7516/4
Accordingly, kindly note that directly configuration of 2FA is not yet supported over ASDM, and an enhancement request has been published to document this feature under bug ID (CSCvs85995):
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs85995
Duo service name and tests:
Duo Security Authentication Proxy Service
sc qc DuoAuthProxy
tasklist | findstr proxy_svc.exe
C:\Program Files\Duo Security Authentication Proxy\bin\proxy_svc.exe
Run a powershell as admin:
C:\Program Files\Duo Security Authentication Proxy\bin
.\authproxy_connectivity_tool.exe
https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs1.html?bookSearch=true
