Hi mouss, list.
> this thread is becoming too hot!
>
Oh, there are still some points being made--though with a lot of friction,
admittedly. I won't comment on the kindling fire, though.
> As I said before, active ftp is a problem for non-stateful FWs. In
> particular, it is not a problem for proxies, cos' they maintain state.
> I've used the ftp-gw for long and never had problems to get asleep.
> I wouldn't accept that on a stateless FW.
>
I don't understand the last sentence in that context. What would you not
accept on a 'stateless' firewall, i.e. a plain packet filter?
> I agree that passive ftp is the way,
>
Well, as Paul said, it's less bad than active FTP when viewed from the
perspective of the client. For clients (actually, for the dumb packet
filters inbetween), active FTP is bad because a connection to a random port
on the client is initiated from the server side. Passive FTP isn't a lot
better because all it gets you is a reversal of the initiation. That is
something, yes, but almost anything can go through the following rule
combination:
<inside IP>:1024-65535 -----TCP----><any IP>:1-65535
<inside IP>:1024-65535 <--TCP/-SYN-- <any IP>:1-65535
Bottom line is that you need something that is 'application-aware' when
dealing with protocols such as FTP, ones that involve negotiation of TCP/IP
parameters between the communicating parties. ALGs are application-aware by
definition concerning this group of protocols (plug-gw won't help you with
FTP), stateful inspection can theoretically be application-aware, too, while
conventional packet filters aren't. The point is, though, that to be fully
application-aware you need to write an ALG, it's in the very meaning of the
words: *application level* gateway. And so far, most of the support for
tricky protocols in the stateful filters I've seen seems to be motivated by
the demand for them and the level of inspection corresponds directly. This
is true for Linux IP-Masquerading modules, I don't know about ipfilter, but
I believe it suffered the FTP attack as well, and I don't trust
closed-source implementations to be any good unless the vendor provides
serious technical statements (like saying they parse commands and perform
this and that sanity check and perform IP defragmentation and *not* talk
about their Great New Technology(TM) that will magically make your life
happier, the world a peaceful place and secure your network in passing).
> but until lately, MS IE were
> unable to work it out. one can say, ok, don't use IE, but heh, I can't
> just ask all my coworkers to switch to another OS/browser. besides,
> the only viable alternative seems netscape and it is too buggy...
>
Oh, but browsers can use HTTP to a proxy server that FTPs out to the world
for them. Squid does that, though I'm not sure how secure it is.. I'd like
to know if someone has a founded opinion on that.
> some guys went the scp way. I don't see why scp would be more secure.
>
Well, within a community it is definitely more secure than FTP. It just
doesn't extend well to large environments because there is no real key
management funtionality.
> where do I put my keys so that people can download software from my
> machine? on Yahoo? Whatever a honest guy can do, a malicious one can
> do too, and even more:)
>
Hmm.. for users to download from your machine, your machine is the SSH
server. The server identifies itself in a SSH connection (I don't believe
the client machine needs to authenticate itself at all in SSH), so it's the
users that connect to your machine that need to worry about the validity of
the public key they're being presented. You could place the key on Yahoo!,
sure, just add a signature with something else (such as PGP), which can be
verified by a trusted CA. This could all be included in the protocol, of
course, and I believe SSH2 is moving in that direction--at least I believe
they have added support for X.509 certificates and are working on key
management.
> encryption? that's utopia! not so long before the only keys that were
> exported fom the US were those laughable 40bits ones. 40 bits doesn't
> make your more secure, scp, https, shttp, or whatever you use.
>
Well, nowadays 40 bit encryption is a thing of the past that will be phasing
out of significant existence within the next couple of years. There were
ways to get around that before (by installing step-up certificates on the
servers or patching the clients) and encryption definitely does not
automatically secure anything. It is, however, a good tool to provide
protection from data theft (or snooping) and authentication. As everything,
it needs to be implemented properly to be anything but a security blanket.
It also brings about performance issues, so that it is not generally
meaningful to simply encrypt everything--a lot of information needn't be
encrypted unless privacy concerns are very high and even authentication
isn't always necessary, though I suppose it is often useful. If you use
cryptography, you need much higher performance, too, so that becomes a
consideration.
Cheers,
Tobias
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
