Penetration Testing: Re: Question: FTP via alternate port

[Neil Kathok <neil.kathok () gmail com>]

On 1/28/2006 10:05 PM, Packet Man wrote:
> Niels Taylor wrote:
>
> > Hello list, I hope this question is not too "newbie," and I am sure if
> > it is
> > I will find out quickly.  I am interested in ways an attacker could
> > circumvent outbound FTP restrictions on a FW.  I have researched this
> > a bit
> > but the information I am seeing is ambiguous, so I thought I'd take it
> > straight to the experts.
> >  
> While the stock ftp.exe that is on my Win2K box does not provide for
> changing the port used, that doesn't prevent other applications from
> doing so.  Since it is a common security practice to run such things as
> sshd on non-standard ports, there's every reason for a trojan, worm, or
> virus to use the same technique to avoid the usual roadblocks or
> detection techniques based on port.
>
> And, don't think for a moment that malware would be restricted to ftp
> for transfer of files.  Any good programmer could choose among the many
> suitable protocols for communicating, or even invent one.  Then, it
> would be a simple matter for the infected host to just keep trying
> outbound ports until it finds an opening.  For example, how many
> firewall configurations block a connection from a high port on the
> originating host to port 80 on a distant server?  Very few, right?
>
> Over and above all the information security hardware, sometimes
> detection simply boils down to a technique that beat cops have used
> since the beginnings of professional security, and that is "suspicious
> behavior".
>
> And, regarding your SQL server on the internal net; you might consider
> blocking ALL traffic from it to the outside world.  Vulnerable,
> high-value systems should be tightly insulated, firewalled, and proxied
> well away from any threat.
>
> I hope this answers your question.
>
> Good luck.
>
> Mark Stingley
Why would you want to open your SQL server to the outside world?

Seems to me that most of the time you'd want your SQL server only
talking to other servers you own (lets say, your webserver).  If so,
then restrict it to those.

Theoretically an attacker could still compromise your SQL by hitting the
web server, and then from there pull something off SQL, but there's no
reason to make it easy.

You can even make it harder by restricting the web server to only
accessing specific ports on the SQL server.

I'm sure there's always a work around, a hole, an exploit; but if you
just make it so time consuming, it becomes impractical for most
attackers, and you cut down on your risk/problems.  Just like
brute-forcing passwords...who's going to bother waiting for 3048972 days?

-- 
Neil.
http://voidfx.net
"I haven't lost my mind; I know exactly where I left it."
--Anonymous

------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner: 

Hackers are concentrating their efforts on attacking applications on your 
website. Up to 75% of cyber attacks are launched on shopping carts, forms, 
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are 
futile against web application hacking. Check your website for vulnerabilities 
to SQL injection, Cross site scripting and other web attacks before hackers do! 
Download Trial at:

http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------