06-08-2024 04:25 PM
Hello, I’ve just redeployed my ASA5506x and noticed that I kept seeing an unfamiliar ip address popping up and with closer inspection it seems to be in direct communication with my firepower modules ip address. I don’t have nor know anyone near me that’s using the up address range of 172.22.4.33 or 172.17.4.33 but they both are clearly making/building connections and being granted access to the firepower module of the unit. If anyone has any suggestions on how to proceed please let me know. The two ip addresses are the only two that keep popping up and it isn’t occasional but constant filling up the syslog. It just started yesterday. Thank you
06-08-2024 11:26 PM
you can use the following commands:
sh conn address x.x.x.x detail
sh local-host x.x.x.x all detail
this will give you more idea of where it is coming from and what ports.
can you attach a snip of the syslog ?
then you can take a packet capture on the ASA to dig further.
06-09-2024 02:51 AM
The ASA5506x are gone EOL. Use ARP tables on the ASA5506x to see the MAC addresses of the devices associated with these IPs
show arp
show arp | i x.x.x.x
Capture traffic using packet capture tools (e.g., Wireshark or tcpdump) to analyze
capture cap interface [interface_name] match ip host 172.22.4.33
capture cap interface [interface_name] match ip host 172.17.4.33
show capture cap
you can also see the live syslog entries for these ip address to narrow down what are these IPs doing.
show logging | i 172.22.4.33
and you also use command
show conn address 172.22.4.33 netmask 255.255.255.255
you can refer to this Guide
06-09-2024 03:00 AM
Access to box or access through box ?
Access to box you need to disable http in FTD or use control plane ACL
MHM
06-09-2024 04:26 AM
Since 172.16.0.0 through 172.31.255.255 are all private networks (not publicly routable), the connections must be originating somewhere on your internal network. If you are on a corporate network, they could be vulnerability scanners (authorized or unauthorized) that simply sweep through all reachable subnets periodically.
In any case they should only be granted access if they present valid credentials. A TCP conneciton will occur if something tries, for instance, to open an ssh session but does not have valid credentials.
06-09-2024 11:22 AM - edited 06-09-2024 11:34 AM
not necessarily... many ISP backbones are all RFC1918... it could be a scan from them or a malicious host .. Also not all ISP do good RFC1918 filtering inside their network (may do it at peering points) so technically you could have a TCP syn somehow make it and then the response may never get back.. i actually block out any rfc1918 from the outside interface and also put null routes as safeguard
06-09-2024 01:32 PM
Alright, if the issue is due to these IP addresses coming from the outside interface, then defining access-lists to deny them is a good solution. The ASA has an implicit deny rule, but if these IP addresses are reaching your Firepower module, it indicates that the access-list for the outside interface might not be configured properly. Remember, the ASA processes the packet first, and then the SFR module checks the packet.
To address this, you can define access-lists to explicitly deny these IP addresses. Here’s how you can do it
Define access-lists to deny traffic from the IP addresses 172.22.4.33 and 172.17.4.33
access-list OUTSIDE_IN extended deny ip host 172.22.4.33 any
access-list OUTSIDE_IN extended deny ip host 172.17.4.33 any
Apply the access-list to the outside interface
access-group OUTSIDE_IN in interface outside
monitoring the traffic to ensure that these IP addresses are being block
show logging | include 172.22.4.33
show logging | include 172.17.4.33
06-21-2024 05:33 AM - edited 06-21-2024 05:42 AM
06-21-2024 05:37 AM
06-28-2024 06:14 PM
is this issue solved or not?
can you draw topolgy and show in which interface you see this traffic
MHM
07-24-2024 08:38 AM
I will attach a photo copy but the plain and simple thing to it is an unknown private network probing just the firepower module and always the same domain port 53. It’s every 5 seconds round the clock, it’s two slight different 172.x.x.x IPs hitting it double time; as the photo shows
07-24-2024 08:46 AM
The source IP is 192.168.1.2. A device at that address is trying to access a DESTINATION address of 172.17.4.33 for DNS requests (udp/53).
Your ACL inside_Access_in is blocking the requests, probably since it is an RFC 1918 destination which should indeed be excluded from allowed outbound traffic.
Check the source host configuration for any DNS servers setup there and fix them to legitimate allowed DNS servers and the firewall logs messages will stop.
07-24-2024 08:50 AM
Are you use ASA ad dns server for client?
MHM
07-06-2024 04:57 PM
I keep trying to post and no matter what I say it says there’s something in it that goes against something. This is nuts
07-06-2024 04:58 PM
What could I be saying or from what I’ve said what’s possibly wrong with describing my issue and responding to questions?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide