I think the purpose of this is to demonstrate the use of the established keyword. Using "established" has no kind of application inspection ability. This means that it will not be aware of any PORT commands in ftp. But since you want to restrict passive, and only allow active, you know the control session will be client port >1024 -> server port 21, then the data session will be server port 20 -> client port > 1024. This is what the established keyword was configured todo. Once it sees a session on port 21, it allows a new session to be built "From" port 20 on the outside interface (which is the way active ftp works). Since using the established keyword has no application inspection functionality, any kind of NATing would not work (since you need application inspection to change the ip's within the control packets). I think the configuration is missing a few things however. I think it should be the following:
Policy-map global_policy No class inspection_default ! this command gets rid of the default inspection so you can add your custom classes first Class cmT CP Set connection advanced-options tcpMSS Class cmFTP Exit ! there should be no inspect ftp command here, as it will allow passive ftp as well, if you have no commands for this class, it will not do any application inspection, and your established command will allow active ftp. Class inspection_default Inspect ftp ! this inspect ftp will allow active and passive ftp to all ftp traffic that is not matched in the cmFTP class .. Access-list inside_access_in permit tcp any host 192.1.49.100 eq 21 (allow the intial ftp control stream through) Access-list inside_access_in deny ip any host 192.1.49.100 ! deny any other traffic, otherwise passive ftp will be allowed through. This is due to the fact that both control and data traffic is initiated from the inside, which all traffic is allowed by default. You must only allow port 21 and no other traffic. since you used the established keyword, this will put a pinhole in the outside interface similar to the following acl (which you do not need to define) access-list outside_access_in permit tcp host 192.1.49.100 eq 20 any I hope this is correct, and I hope this helps From: [email protected] [mailto:[email protected]] On Behalf Of Paul Stewart Sent: Thursday, September 10, 2009 9:08 PM To: [email protected] Subject: [OSL | CCIE_Security] Volume 2 Lab 12 Filtering FTP The first bullet poing states to block host from using passive FTP to 192.1.49.100. I cannot understand how this could be done without doing explicit permits for traffic leaving the firewall. It says that the session should be the most state-ful possible. I am struggling to understand how the solution in the 'detailed solution guide' works. Let's start with the first command: established tcp 21 0 permitto tcp 0 permitfrom tcp 20 My interpretation of this command is if traffic is seen destined for tcp port 21 that the firewall should permit return traffic to any tcp port from tcp port 20 so this should actually let active mode ftp work if filtering were the only problem. However, we also need to deal with changing the PORT command to a correct public address. So my question with the established command is this. Does the ASA allow for the DATA channel to be established from any port in active mode without this command? My interpretation is that this would be in addition to connections permitted by the ftp inspections. So how does it improve on the ftp inspect alone or what is its purpose? Then concerning the traffic bein inspected with "inspect ftp". This excludes traffic destined to 192.1.49.100. However, it would then be inspected in "inspection_default". Even if it did not use the ftp inspect at all, I don't see how this would prevent passive ftp. As I understand it, passive FTP estabalishes two outbound sessions. The first is typically from a port above 1023 to port 21 on the server. The second is also typically from a port above 1023 on the client to another high port on the server. This port is specified to the client through the first session. Both initial packets are outbound. So if the ASA only looks at these as TCP connections they still work. The only exception would be if the server was on the inside of the ASA instead of the outside and the role of the ASA reversed. This would require the block of ports open that is used for passive ftp, or fairly intelligent inspection of the control channel. I think this is a good question, I am just somehow not seeing the solution. What am I missing?
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
