Henrik Nordstrom wrote: > > A in my opinion better approach would be to > * require that the 227 (PASV) reply is the one and only line present in > the packet Attackers can accomplished this by setting the TCP MSS to the right size. > * that this packet properly ends with a newline No problem in the case of the STAT command > * that this packet is not oversized for being a 227 reply Shuoldn't be a problem > * and that the TCP byte immediately in front of the response code is a > newline, not a space or anything else. Not sure if this is possible in > the FW1 filter engine. Also, this won't help in the case of buggy > wuftpd. No problem in the case of the STAT command > * The firewall should also obviously only listen for a 227 reply if a > PASV command has been sent. Any 227 replies received outside this > context is an protocol violation and should be handled as such. I think you can accomplish this by actually sending a PASV command after the GET / STAT command. However, I don't know how the firewall will interpret the second "227" message. Possibly by killing the fake channel and opening the real one instead :-( However, what if you send the fake PASV command in a packet with a sequence number that has already been used? Such a packet should be happily ignored by the server, but the firewall would probably listen to it. Hmmm :) The only solution that even begins to look "good" is to completely reassemble the TCP stream and not make "educated" guesses about what packet data belongs on what line and in which order and state of the FTP protocol. It doesn't have to be a "proxy" in order to do this, I think. You DO need to reassemble the stream completely though. Just my $.02 /Mike -- Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK Phone: +46-(0)660-105 50 Fax: +46-(0)660-122 50 Mobile: +46-(0)70-248 00 33 WWW: http://www.enternet.se E-mail: mikael.olssonat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:51 PDT