Great Circle Associates Firewalls
(April 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Scanning from port 20, and packet filters.
From: Illuminati Primus <vermont @ gate . net>
Date: Wed, 30 Apr 1997 18:26:54 -0400 (EDT)
To: Bob Beck <beck @ obtuse . com>
Cc: Mark . Loveless @ BNSF . COM, ntsecurity @ iss . net, mudge @ l0pht . com, firewalls @ GreatCircle . COM, ntsecurity @ iss . net
In-reply-to: <199704302019 . OAA09128 @ snouts . obtuse . com>

On Wed, 30 Apr 1997, Bob Beck wrote:

> > 
> > Well, there are ways to prevent someone from scanning your network via an
> > FTP bounce.. you can configure your firewall to block any tcp connections
> > from port 20 from connecting to any ports less than 1024.  I think the
> > latest version of the tcpwrapper does this (but that wouldnt be as good
> > as blocking it totally at the gateway router).. Of course, theres always
> > the possibility that someone will find a host on your network with a
> > vulnerable version of ftpd.. In that case, it might be smart to build
> > this filter into those "firewalls" that are built to listen promiscously
> > to network traffic and reset forbidden connections (by spoofing RSTs)..
> > (ie. netwatcher, juggernaut, etc).  Of course, the best solution is to not
> > have any vulnerable FTP daemons on your network (is NT 4's FTPd
> > vulnerable?)
> 
> 	Ftp isn't guaranteed to come from port 20. Lots of server out
> there don't. It usually comes from 20. The fact that it does means
> nothing.  Preventing port 20 from connecting to ports less than 1024
> doesn't stop it from being used to connect to services above 1024,
> like RPC, web proxies, or whatever the idiot in the office next door
> decided to run on his Win95 box this week that listens up high.  The
> question you should be asking is not if there are vulnerable ftp
> daemons, it is what services can be started on your network that
> listen in the range of ports you have opened up to allow for the ftp
> backchannel.
> 	What you are illustrating is the simple fact that if your
> policy is that connections should be allowed to ports over 1024 from
> the outside world, then you can use conventional ftp through a packet
> filter set up in this manner.  If what your policy really is that
> connections to arbitrary services shoult *not* be allowed, then no,
> you can't, Since your packet filter still leaves you with a
> distributed security problem. 

I wasn't trying to suggest what a packet filter's overall policy should
be.. I just wanted to point out that generally, a connection set up
through an FTP bounce usually comes from port 20.  Sure, broken FTP
servers might send it from another port (which ones are these BTW?  Are
they also vulnerable to bouncing?), or the port might get remapped by a
masquerading router.. But in the vast majority of the cases, an attacker
wont spend the time to find a bounce-vulnerable ftp server that sends from
a port other than 20.. so those stupid people can be logged and filtered
by knowing what the usual traffic from a bounced connection will look
like. 
I think we all know that the tightest security measure is to only allow
connections to known secure services running on secure machines.  And of
course, to not have bounce-vulnerable FTP daemons.

PD
What are you trying to say in your last sentence?



References:
Indexed By Date Previous: Re: NT vs Linux IP Performance
From: David LeBlanc <dleblanc @ iss . net>
Next: RE: NT vs Linux FTP Performance -Reply
From: Scott Fagg <scott . fagg @ arup . com>
Indexed By Thread Previous: Scanning from port 20, and packet filters.
From: Bob Beck <beck @ obtuse . com>
Next: Ascend Secure Access with Dynamic Firewall
From: chrisp @ tidalwave . net (Chris Pressley)

Google
 
Search Internet Search www.greatcircle.com