I see what your saying. Sorry I did not actually do the lab yet, so I didn't know there was nat involved. I also forgot about the feature by feature basis for MPF. So what your saying is we need the following: a class to identify all ftp traffic EXCEPT for host 192.1.49.100, and inspect ftp there, then remove inspect ftp for the default inspection. This would accomplish the goal (if nat was not a factor, and the established keyword would work). But since the established command will not work due to the nat, use an acl for the return data session: access-list inside_access_in permit tcp any host 192.1.49.100 eq 21 access-list inside_access_in deny ip any host 192.1.49 access-list outside_access_in permit tcp host 192.1.49.100 eq 20 any That should work!
_____ From: Paul Stewart [mailto:[email protected]] Sent: Friday, September 11, 2009 6:18 AM To: [email protected] Cc: [email protected] Subject: Re: [OSL | CCIE_Security] Volume 2 Lab 12 Filtering FTP Shawn, I think we are both on the same page. To block passive mode ftp, I think we need to not inspect that traffic and block the secondary sessions with an acl. If we don't do both of those, it will still work. My understanding of the established command is exactly as you describe it. Since it doesn't have application inspect ability, I think we still need to have a class that matches everything except for 192.1.49.100 and inspect ftp traffic there. This should allow ftp to continue to work and eliminate the need for the established command (which won't work anyway because we are doing nat). The other thing is that bat removing the "inspect ftp" from cmFTP, that traffic will fall through to the inspection_default. This is due to no "feature" being defined in the class. My understanding of MPF is that the flow is compared against each policy on a feature by feature basis. The features are qos input, tcp normalization, csc, application inspections, AIP IPS, qos output policing, output queue, and shaping. It is possible to have tcp normalization from one class and have inspection from another (inspection_default). My understanding is a class that matches traffic won't really do anything if no feature is applied. This is because the ASA attempts to find a feature for each flow first. Again, thanks for your input and insight on this matter. It has been very helpful. In reply to: Message: 2 Date: Thu, 10 Sep 2009 22:19:33 -0600 From: "Shawn H. Mesiatowsky" <[email protected]> Subject: Re: [OSL | CCIE_Security] Volume 2 Lab 12 Filtering FTP To: <[email protected]> Message-ID: <01d101ca3297$1990f020$ 4cb2d0...@ca> Content-Type: text/plain; charset="us-ascii" 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
