Re: How to configure Zone Alarm to allow FTP?

From: David (davidwnh@adelphia.net)
Date: 12/06/02 

From: "David" <davidwnh@adelphia.net>
Date: Fri, 06 Dec 2002 22:08:09 GMT

Once you decide to open any service to the internet and allow unsolicited
traffic you face whatever "dangers" that service exposes. That being said
here are at least some of the more prevalent problems you face with FTP with
suggestions of ways to lessen your risks.

If you are running your server on a Win9x system much of what I will say
does not apply so your risks can only be partly dealt with. If this is your
case I would say "don't even try it" and would suggest you find an
alternative which uses encryption to exchange user accounts and passwords. I
would suggest this in any case where you are only allowing access to a
select few and these select few are not restricted to using a standard FTP
client. You can use a variation of FTP that allows for encryption or a type
or filesharing application(and I don't mean the p2p apps that you hear about
on the news).

I am assuming your goal is to allow access to a select known few.
If possible put your FTP accessible directories on a separate hard drive or
at least a separate disk partition from your operating system and private
data files. Use whatever means the Server software and OS provides to
restrict users from traversing upwards through directories.

Since you will be allowing write access you must use accounts with
passwords. User accounts and passwords are sent in plaintext for a standard
FTP server so extreme care must be taken in light of this issue. Use account
names and passwords which are different from those you are using for normal
computer use if possible, particularly accounts that have administrator
access. You can use computer accounts if the OS allows for file and
directory access control, however if this is the case restrict access of
those accounts as best you can to the specific directories needed for FTP
access. Do not allow any execute permissions within FTP accessible
directories if your OS allows for this. And use disk quotas if the OS or
FTP server allows for it. Hopefully you are using an OS and file system that
allows for file and directory access control lists. If not you are very
limited in what you can do to prevent damage if an "intruder" does gain
access.

If you are using an OS that uses "services" run an FTP server that runs as a
service under a computer account that only has the access rights it needs.
If you are using an OS that has an NTFS file system, you are doing yourself
a disservice if you run an FTP server that will be running under the context
of the logged on user.

Now if I haven't made you realize how much care goes into opening a service
to the internet, or that an FTP server is not the best solution if your goal
is simply to allow a select few to transfer files to and from your computer
over the internet, I will answer your question about firewall filtering.
Much of the above concerns limiting damage when you are compromised and what
follows will mostly be things to do to help prevent getting compromised in
the first place.

If possible put the FTP server on a non standard port and if applicable use
a non descriptive service banner or better yet no banner if possible.
As to IP filtering, restrict access as best you can. The ability to restrict
access to only static addresses is best, however if you need to allow
certain dynamic addresses the best you can do is filter for the specific
range of dynamic addresses. The better you can narrow this range the more
you mitigate the risk. If these addresses are within your business as
opposed to a public ISP your risks may be lower. Either way look at the
extent to which you can filter as varying degrees of risk as opposed to a
problem. The more you can filter out, the more you alleviate your chances of
being compromised. Keep in mind there is always the possibility of IP
spoofing, however by using a non standard port with no service banner, and
restricting access with IP filters you have brought the level of risk
regarding compromise down significantly.

All in all you can bring your chances of compromise down to an extremely low
level, but don't lose sight of the fact that you cannot eliminate all
chances and your main objective should be to secure any personal,private or
important data that resides on the computer and your internal network(if
this applies). And if some of these files will reside in your FTP accessible
directories in the first place, then they are sitting at the "front door",
so you might consider encryption in such an instance.

Your firewall is an important part of securing an FTP server but if you add
additional layers of protection you will filter out more and more potential
to a point where simply reviewing access logs will allow you the time to
shut down or reconfigure your FTP server before even the best and most
determined will gain enough access to get your machine to the point of
"reformat and reinstall".

I have seen too many people who have been told that they had to "reformat
and reinstall" whether it was necessary or not, when they could have used a
more appropriate application that is easier to secure in the first place.

> |
> | I have the Plus version.
> | I have figured out how to add client addresses to the Trust Zone. Of
> | course this is a problem if those addresses aren't static.
> | Is it dangerous to open up port 21? How do I do that?
>

Relevant Pages

  • Re: NIM clients and multibos
    ... and how many accounts does it take to make the problem visible? ... large perf hit. ... None APAR points to wtmp. ...
    (comp.unix.aix)
  • Re: ssh bypassing OS procedures?
    ... > passwords every thirty days, the OS will lock the user account. ... > he can still ssh into the system via private key authentication. ... Why are you giving user accounts on your ftp server? ...
    (comp.security.ssh)
  • Re: ssh bypassing OS procedures?
    ... >> I have a ftp server setup so that if the users don't change their ... >> passwords every thirty days, the OS will lock the user account. ... >> he can still ssh into the system via private key authentication. ... > should *NEVER* have user accounts with the same passwords as the ftp ...
    (comp.security.ssh)
  • Re: People trying to hack my MS FTP server (but theyre not getting in)
    ... > same IP address to logon to my MS FTP server with accounts which do not ... > to prevent further attacks from them. ...
    (microsoft.public.inetserver.iis.ftp)
  • Re: Fw1, NAT or router problem ?
    ... to the webserver from the Internet. ... appropriate public IP so as to allow access to the webserver. ... a need to allow access to the web and FTP server from the internal (private) ...
    (comp.security.firewalls)