[EMAIL PROTECTED] wrote:
>
> [good writeup on how to write proper ALGs, and how to
> fool even proper ALGs]
> So, you've somehow done this. Ummm... how? Ah! Java will happily do it, if
> you have it enabled. So don't.
Ah, but here lies the red herring :-)
Who, except for very security aware organizations / individuals wants to
turn off Java? (Yes, I admit, I always hava java/javascript turned off,
but I fail horribly in convincing others to do it :-P)
> Scenario 4: As in Scenario 3, but forbid client-initiated PORT
> commands. Proxy translates PASV requests into PORT commands on behalf of the
> client.
This is really good for protecting clients. (I've thought of it too.)
> The best solution of all. It _does_ require PASV-aware clients, but those
> are common enough these days.
Not common enough. I'm still running into dumb ass mission critical
systems
that push data back and forth through home-brew FTP functions that do not
support PASV mode. Especially systems for electronic billing / finance
tend to do this. Since the data itself is encrypted and signed, FTP was
probably deemed "good enough" for moving it.
One could argue that these financial systems could be allowed to use
active mode, but... Yeah ;-)
> I coded (and published) the basics of this as a patch to the FWTK many years
> ago. Dunno' if it ever went anywhere - I haven't touched the toolkit in a
> long time. It certainly wasn't rocket science.
Oh, darn, I wasn't the first one to think of it :-)
(Nah, I'm not surprised. As you say, it isn't rocket science.
No one seems to be doing this however?)
> Now, as long as I'm rambling on about FTP, I might as well cover the other
> half of the problem - somebody else's client connecting to your server.
The easiest solution to this problem would be to instruct the
server what port range to use and limit the allowed range to those
ports only. Voila! Problem solved. You can even use a dumb
stateless packet filter to secure this sort of FTP server to
an acceptable value of "secure".
Too bad none of the FTP server people want to listen to me
when I request that feature :-P
Someone else feel like shouting a bit at them?
> [huge snip - methods of protecting the server with
> a very intelligent proxy]
Why don't people just STOP designing separate data channel protocols?
Each and every one of them have exactly the same set of problems.
Actualy, I'd really like to see "inline" mode FTP; there's no
reason for not having it these days when we have TCP :-)
The only thing you wouldn't be able to do is server-to-server
transfers from a third party, but I for one wouldn't have a problem
with that.
One could also argue that FTP should be scrapped altogether, but
I don't know of a good replacement protocol. HTTP could conceivably
be used, but then we'd need specially written "file serving" HTTP
servers and new clients that understand what batch transfers and
directory listings are.
--
Mikael Olsson, EnterNet Sweden AB, Box 393, SE-891 28 �RNSK�LDSVIK
Phone: +46-(0)660-29 92 00 Fax: +46-(0)660-122 50
Mobile: +46-(0)70-66 77 636
WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
