Subject: Upload in unreadable dir

From: Magnus Therkildsen <[email-masked]>
Date: Thu, 04 Mar 1999 10:18:19 +0100

Hi All,

I was suggested to let my ~ftp/incoming dir be unreadable by ftp, in
order to avoid abuse of pirates. That sounds like a good idea. However,
now my ftp users cannot upload anymore, they get a permission denied.

I have tried to set the read bit again, and then it all works fine. The
point is now, that if the dir is unreadable, you cannot upload -
although I also put an upload statement in the ftpaccess file for the
incoming dir.

Does anyone have a hint or solution for this?

Thanks in advance,

Magnus

[email-masked]

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 4 Mar 1999 07:32:14 -0500 (EST)

On Thu, 4 Mar 1999, Magnus Therkildsen wrote:

> order to avoid abuse of pirates. That sounds like a good idea.
> However, now my ftp users cannot upload anymore, they get a permission
> denied.
> 
> I have tried to set the read bit again, and then it all works fine.
> The point is now, that if the dir is unreadable, you cannot upload -

This is almost certainly a Unix permissions problem.  You sound like
you've been through the FAQ already.  There's an example site at
  ftp://ftp.vr.net/pub/wu-ftpd/examples
which may help.  It shows incoming directories.  The document
  ftp://ftp.vr.net/pub/wu-ftpd/upload.configuration.HOWTO
give my recommended permissions.

wu-ftpd Resource Center:  http://www.landfield.com/wu-ftpd/
wu-ftpd FAQ:              http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
wu-ftpd list archive:     http://www.landfield.com/wu-ftpd/mail-archive/

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: [email-masked] (Michael Baehr)
Date: Thu, 4 Mar 1999 18:16:36 +0100

Hi,

does anybody know  about availability for
ldap integration in wu-ftpd 2.4.2 .
where can I find software/information about that ?

Is there anywhere the source available 
and documentation about the necessary ldap
object classes and attributes (home directory,
permissions eg.)?

Thanks in advance

Best Regards

Michael Baehr

---

From: Alex Yu <[email-masked]>
Date: Thu, 04 Mar 1999 12:59:08 -0500

Hello,

My friend email me with security concern about ftpd.  I attached the mail
at below.  Can someone response that to me?  Thank you.

Alex

Date: Thu, 4 Mar 1999 12:40:04 -0500
Subject: Re: academy
:

Hi Alex,

   The biggest problem with ftp is that your user names and
passwords are sent in single packets encoded as plain ascii.
If a hacker has access to _any_ machine on _any_ network between
the client and server, they can sniff the packets easily.
   It is worse than telnet because at least telnet sends each
character of the password in an individual packet.  FTP sends
the entire string "PASS XXXXX" in one packet.  This is an ftp     
problem unrelated to the OS the client or server is using.
   Several machines on the RPI campus have been hacked in the
past, (Tom's was once), and have had password sniffing programs
set up on them.  The only way to prevent this "hole" is to get
rid of ftp altogether, (at least till ipv6 comes out with it's
transparent encryption services).
   I know there aren't necessarily free ssh clients for the
Mac, but I wasn't aware that there weren't even commercial
ones....

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 4 Mar 1999 13:38:27 -0500 (EST)

On Thu, 4 Mar 1999, Alex Yu wrote, on behalf of a friend:

> The biggest problem with ftp is that your user names and passwords are
> sent in single packets encoded as plain ascii. If a hacker has access
> to _any_ machine on _any_ network between the client and server, they
> can sniff the packets easily.

This is also true of telnet, rsh (et al), pop, imap, smb (sometimes), http
(usually) and probably a raft of other protocols which don't come
immedeately to mind.

On today's Internet, most traffic between two networks travels on the
large national backbones.  The risk is extremely low that anyone would
have access to those networks at a point where they could sniff your
packets.  The main risk of this threat is on the end-point networks,
especially so when one of those end points is a college campus.

> It is worse than telnet because at least telnet sends each character
> of the password in an individual packet.  FTP sends the entire string
> "PASS XXXXX" in one packet.  This is an ftp problem unrelated to the
> OS the client or server is using.

Not just FTP.  Telnet's about the only protocol to behave like that.  
Pop, imap and the others usually use a single packet also.  Besides,
anyone looking for passwords in single packets isn't seriously looking.
Sounds like you just happened to notice a password go by on a protocol
analyzer and paniced.  The software most password sniffers is well aware
of how Telnet works and grabs the password just fine, thank you.

> Several machines on the RPI campus have been hacked in the past,
> (Tom's was once), and have had password sniffing programs set up on
> them.  The only way to prevent this "hole" is to get rid of ftp
> altogether, (at least till ipv6 comes out with it's transparent
> encryption services).

With sniffers on your network, unless the only thing running on the host
was FTP, you probably weren't broken into via FTP and getting rid of FTP
definitely won't solve the problem you've described.  I'd be surprised, in
fact, if it had any effect at all.

With most of these protocols, including FTP, it's a simple matter to set
up OPIE, S/Key or some similar feature which will protect your passwords.  
Where the protocol does not support password security, it's drop-dead easy
to tunnel the protocol through an SSL-proxy.  Not knowing your network at
all, but guessing from the fact that it's a campus, I'd say it's WAY past
time you went to Kerberos to secure your servers and workstations.

Computers outside your control (dorm rooms, etc) should be treated as
hostile and placed beyond a firewall from your main network. The firewall
can then enforce requirements for encrypted traffic, Kerberos, etc.

--

---

From: Alex Yu <[email-masked]>
Date: Thu, 04 Mar 1999 17:33:45 -0500

>up OPIE, S/Key or some similar feature which will protect your passwords.  

Well... actually you right.  So is there any secure ftp daemons?  If you
know some, would you please inform me?  If all I have to do is just put a
patch on wu-ftpd, please let me know.  How can I make wu-ftpd ANONYMOUSE
login only?

Alex

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 4 Mar 1999 17:43:25 -0500 (EST)

On Thu, 4 Mar 1999, Alex Yu wrote:

> patch on wu-ftpd, please let me know.

The base daemon supports S/Key and Kerberos authentication (among other
platform-specific methods).  VR16 has OPIE as well.  For these, just edit
config.h to enable the feature.

ISTM BeroFTPD includes FTPSEC support for Kerberos 5, encrypting the
connections, not just the passwords.

You can get an SSL tunnel from a number of places.  I've taken a look at
edssl83, and I know there are others.

There's a free (well, maybe free here in the US) version of WU-FTPD with
SSL patches (old, but they shouldn't be too hard to fix up).  It's at the
SSLeay site which I cannot remember so I Yahoo! for it.  There's a
commercial version of the daemon which has this as well (browse the
mailing list archive for the past two months, or wait .. he'll prolly
speak up in a bit).

> How can I make wu-ftpd ANONYMOUSE login only?

#define ANON_ONLY in config.h

--

---

From: Ayamura Kikuchi <[email-masked]>
Date: 05 Mar 1999 07:48:51 +0900

> How can I make wu-ftpd ANONYMOUSE login only?

see config.h

/*
 * ANON_ONLY 
 * Permit only anonymous logins... disables all other type
 * See FIXES-2.4-HOBBIT for more information on this option.
 */

#undef ANON_ONLY

-- ayamura