06-16-2023 12:27 PM - edited 06-16-2023 12:34 PM
Hello. I have a basic access list applied to the WAN interface, that needs to allow incoming DNS queries, incoming PING requests, and permit any traffic that originates from the LAN (so things like "related", "established" etc). I have so far:
ip access-list extended INBOUND
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
permit tcp any any established
permit udp any any eq domain
permit tcp any any eq domain
permit icmp any any eq echo-reply
deny ip any any
Does this need anything else? Like "related" or what else would you recommend for this basic firewall?
Do I need anything to permit reply UDP packages? for example, an OpenVPN client on the LAN using UDP?
Should I add some hacker-stopping stuff like any incoming LAN IP's from the WAN interface?
How about requests like FIN and SYN? FIN/RST? Stealth scans? PSH without ACK? URG without ACK? FINs without ACK? etc?
Thanks! -turgut
06-16-2023 12:48 PM - edited 06-16-2023 12:52 PM
Hello @tkalfaoglu,
If you have services running on your LAN that require incoming UDP replies, you can add explicit permit statements for those UDP ports. For example, if you have an OpenVPN client on the LAN using UDP, you can add:
permit udp any any eq <openvpn-port>
The rule "permit tcp any any established" covers established TCP connections. This allows incoming traffic that is part of an existing connection initiated from your LAN. It implicitly allows related TCP traffic as well. However, it's a good practice to explicitly permit related traffic too.
If you want to restrict incoming traffic from LAN IP addresses on the WAN interface, you can add deny statements for LAN subnets. For example, if your LAN subnet is 192.168.0.0/24:
deny ip 192.168.0.0 0.0.0.255 any
By default, Cisco IOS ACLs implicitly handle TCP flags and scans. The "established" keyword in the rule "permit tcp any any established" will take care of allowing valid TCP connections and blocking stealth scans, as it only allows incoming TCP packets that are part of an existing TCP connection. Similarly, the "icmp any any eq echo-reply" rule allows ICMP echo-reply packets, which is a response to an outgoing ICMP echo request. This covers normal ICMP traffic and prevents ICMP-based attacks.
06-16-2023 12:55 PM
ACL not help you in this task'
What you config is open port for all.
Use ZFW instead.
06-16-2023 02:59 PM
Have you seen Configure Commonly Used IP ACLs and/or considered using Reflexive Access Lists?
06-17-2023 12:04 AM - edited 06-17-2023 12:05 AM
To enhance your basic access list for the WAN interface, there are a few considerations and recommendations you can take into account:
Related and Established traffic: It is a good practice to allow traffic that is related to established connections. You can achieve this by adding the following line to your access list:
This will permit incoming traffic that is part of an existing connection.
UDP Reply Packages: If you have specific UDP-based applications, such as an OpenVPN client on the LAN, that require incoming UDP reply packets, you can include explicit permit statements for those ports. For example:
Replace <udp_port> with the appropriate port number or port range used by the OpenVPN client.
Filtering Inbound LAN IP Addresses: If you want to restrict incoming access from specific LAN IP addresses, you can add deny statements for those addresses. For example:
Replace <source_ip> with the LAN IP address you want to block incoming access from. Repeat this line for each LAN IP address you wish to deny.
Additional Security Measures: To enhance security and protect against certain types of attacks, you can consider adding specific rules to your access list. For example:
Protect against Stealth Scans: Add the following line to block incoming packets that have all flags set (stealth scans):
Protect against TCP SYN Floods: Add the following line to limit the number of incoming TCP SYN packets:
Protect against ICMP attacks: Consider adding additional deny statements to restrict specific ICMP message types if required. However, be cautious as blocking certain ICMP types might impact network troubleshooting and connectivity.
It's important to note that the specific rules you need may vary depending on your network setup, the services you use, and the level of security you require. It's recommended to carefully evaluate your network's requirements and consult any applicable security guidelines or best practices provided by your network equipment manufacturer or security experts.
06-17-2023 09:22 AM
I'm overwhelmed with the amount of help you have all so kindly provided. THANK YOU very much! I already implemented most of your suggestions and I'm very grateful..
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