04-29-2008 09:39 AM - edited 03-11-2019 05:38 AM
Hi,
I need some help. We're a small company and I have inherited a situation which I have very little experience with. I have a Cisco Router 2821 with the ios firewall and things are just not working right. As I look at this router/firewall config and test it, I think this firewall is not doing a whole lot for us. For a sample outside IP (123.456.789.242), I'm natting it to 192.168.1.14 and then going through essentially this config:
ip nat inside source static 192.168.1.14 123.456.789.242
permit udp any host 123.456.789.242
permit tcp any host 123.456.789.242
remark Allow HTTP to WI01
permit tcp any eq www host 192.168.1.14 eq www
remark Allow HTTPS to WI01
permit tcp any eq 443 host 192.168.1.14 eq 443
remark Allow FTP-DATA to WI01
permit tcp any eq ftp-data host 192.168.1.14 eq ftp-data
remark Allow FTP to WI01
permit tcp any eq ftp host 192.168.1.14 eq ftp
remark Allow SSH to WI01
permit tcp any eq 22 host 192.168.1.14 eq 22
remark Allow RDP to WI01
permit tcp any eq 3389 host 192.168.1.14 eq 3389
deny ip 192.168.1.0 0.0.0.255 any
deny ip any any log
It looks to me like the IP is natted, and then everything allowed in for outside IP, and then specific ports for internal IP. My fear here is that we're practically wide open. Is that true? What do I have wrong here?
Thanks in advance.
05-06-2008 05:33 AM
To enable Network Address Translation (NAT) of the inside source address, use the "ip nat inside source" command in global configuration mode. To remove the static translation or remove the dynamic association to a pool, use the no form of this command.
ip nat inside source static 192.168.1.14 123.456.789.242 - translates between inside hosts addressed from 192.168.1.14 alone to the globally unique 123.456.789.242 ip address.
for more details about this command refer:
http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i2g.html#wp1079180
for details about static and dynamic NAT configuration refer:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080093f31.shtml
also check for access lists associated with NAT
05-23-2008 02:47 PM
You are correct. The ACL is nonsense.
The first couple of Access Control Entries (ACEs) are permitting all UDP and TCP traffic to the internal host that is NAT'd to the inside global address of 123.456.789.242. ACEs should specify the specific higher-layer protocols (www, ftp, etc.) that are to be permitted by your security policy.
The ACEs referencing the internal IP address (192.168.1.14) won't ever be matched by traffic originating from outside your organization because that is not the destination IP address that external hosts are sending too.
These ACEs also convey a lack of understanding of protocol behaviour on the part of the author of the ACL. For most protocols, the client will use a source port > 1023.
For an ACE like "permit tcp any eq www host 192.168.1.14 eq www" to be matched, both the client and server would have to be using port 80 (conveyed by the www keyword). This will not happen. Although you can choose to specify a client port > 1023 for most protocols, it is common to omit the client port requirement in most ACEs. I'm refraining from saying source port because it depends on which side of the connection you are referring to.
Consider replacing the ACL with the following:
deny ip 192.168.1.0 0.0.0.255 any
permit tcp any host 123.456.789.242 eq www
permit tcp any host 123.456.789.242 eq 443
permit tcp any host 123.456.789.242 eq ftp-data
permit tcp any host 123.456.789.242 eq ftp
permit tcp any host 123.456.789.242 eq 22
permit tcp any host 123.456.789.242 eq 3389
deny ip any any log
For your anti-spoofing ACE to be effective, it must precede the other ACEs, otherwise spoofed traffic might match another ACE. This ACL prevents the internal host from being accessed by any protocol other than those permitted. If you use "inspection" on the outside interface where this ACL will be applied, you would be able to eliminate the "ftp-data" ACE. The last ACE should be used in all interface ACLs to identify the presence of traffic that would violate security policy.
You should:
- inventory all the protocols that will be permitted (by security policy) between internal and external hosts.
- build an ACL(s) for the internal interface(s) to enforce outbound policy.
- apply inspection on the internal interface(s) to derive the security benefits of inspection, and to facilitate return traffic.
- build an ACL(s) for the external interface(s) to enforce inbound policy.
- apply inspection on the external interface(s) to derive the security benefits of inspection, and to facilitate return traffic.
Note: Inspection creates temporary dynamic holes in the firewall to facilitate returning traffic in the return path. This minimizes the requirement for you to provision ACLs on the return path.
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