Page 1 of 4 1 2 3 4 LastLast
Results 1 to 20 of 80

Thread: Security News

  1. #1
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Lightbulb Security News

    Malicious DHCP response on OS X can grant root access
    Wednesday, November 26, 2003 @ 2:25pm
    Out of date now, if you have patched and updated your system.


    Carrel.org has posted details of an important Mac OS X Security Advisory--more than 45 days after notifying Apple of the problem: the advisory notes that a Malicious DHCP response can grant root access under Mac OS X 10.2 and Mac OS X 10.3:

    " A series of seemingly innocuous default settings can cause an affected Mac OS X machine to trust a malicious machine on a network for user, group, and volume mounting settings. What does this mean to the average user: Anyone who can gain access to your network can gain administrator (root) access to your computer and therefore steal your data or launch attacks upon others as soon as you reboot your machine. System administrators and users of affected software should read the section 'Workarounds' for immediate actions to protect their machines."
    DHCP Vulnerability
    Carrel.ORG

    Important Mac OS X Security Advisory

    Vulnerability:
    Malicious DHCP response can grant root access

    Affected Software
    Mac OS X 10.3 (all versions through at least 26-Nov-2003)
    Mac OS X Server 10.3 (all versions through at least 26-Nov-2003)
    Mac OS X 10.2 (all versions through at least 26-Nov-2003)
    Mac OS X Server 10.2 (all versions through at least 26-Nov-2003)
    Probably earlier versions of Mac OS X and Mac OS X Server
    Possibly developer seeded copies of future versions of Mac OS X

    Abstract
    A series of seemingly innocuous default settings can cause an affected Mac OS X machine to trust a malicious machine on a network for user, group, and volume mounting settings.

    What does this mean to the average user
    Anyone who can gain access to your network can gain administrator (root) access to your computer and therefore steal your data or launch attacks upon others as soon as you reboot your machine. System administrators and users of affected software should read the section "Workarounds" for immediate actions to protect their machines. It is important to note that WEP security in 802.11b/g (AirPort/AirPort Extreme) wireless networks is generally not sufficient to protect your network from access by an attacker.

    Answers to Frequently Asked Questions

    Is my machine safe if I have the root account "turned off"?
    No. The account attacking can be uid 0 and have any other name in the universe that is a valid account name.

    Is my machine safe if I have all remote access services "turned off"?
    No. This exploit allows malicious people full control of where things are mounting on your system. They can mount malware anywhere. Including places that can virtually guarantee executiong of their target code. For example, and attacker could cause their evil data to be mounted in place of crontabs and have their fake root's crontab point to an evil executable mounted there or somewhere else.

    Why did you release this when you did?
    This was an exploitable remote root vulnerability. After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for the status and they said "December". Meanwhile, users are left exposed and independent rediscovery seemed fairly likely. And maybe by someone less scrupulous than myself. I felt I was being strung along and that the issue may never get properly addressed so I set a hard deadline at that point. They didn't meet it, and I issued my advisory.

    It would not be fair of me to let Mac users hang out in the breeze for more than 2 months on an issue of this magnitude. You may disagree, but I have no regrets about my actions and feel that I was more than fair to Apple Computer and its users.

    Vendor Patch
    Apple Computer has been notified of this issue and may be working a fix at this time. At the time of this writing, a fix is not available from Apple.

    Workarounds
    There are a variety of avenues to avoiding this vulnerability...
    Disable any network authorization services from obtaining settings from DHCP:
    in Directory Access, select LDAPv3 in the Services tab, click "Configure...", uncheck "Use DHCP-supplied LDAP Server"
    in Directory Access, select NetInfo in the Services tab, click "Configure...", uncheck "Attempt to connect using broadcast protocol" and "Attempt to connect using DHCP protocol"
    in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab, if you don't intend to use them

    Turning off DHCP on all interfaces on your affected Mac OS X machine can also keep you from being affected.
    For added security, be sure to disable any unused network ports:
    turn the AirPort card off or remove it, if it is not being used.

    Configuration Awareness
    If a user should need any of these settings turned on due to the network and authorization system they are currently using, they should be aware that they could fall prey to a malicious individual using the techniques outlined in this advisory. Steps to mitigate this concern could be as simple as manually configuring the directory server settings on the affected machine.

    Technical Details
    By default, the affected versions of Mac OS X attempt to negotiate DHCP on all available interfaces. In the event that an Airport card is installed but there is no network nearby, they also default to associate with any network that might appear and then use DHCP to obtain an address. The system will also use DHCP provided fields, if available, to connect to an LDAP or NetInfo server on the network.

    The default settings in "Directory Access" on affected systems will cause the system to place the network LDAP or NetInfo server ahead of the local user info for any given account, and will implicitly trust the LDAP or NetInfo server to provide correct information. Furthermore, nothing in the system prevents a login as a user with uid 0 (zero) with any login name. For example, an LDAP or NetInfo source with an account username "bluemeanie", uid 0, would be perfectly valid and usable for login at the login window and on any network provided service, including ssh (which is turned on by default in certain versions of the affected software).

    In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw. (The netinfod process must be restarted to cause the malicious server to be inserted into the authentication source list.)

    By taking advantage of these default settings, a malicious individual could potentially take full control of a Mac OS X workstation or server without even having to make a physical connection to the machine. With a good antenna the malicious individual wouldn't even have to be in the same building.

    While the further examples in this advisory deal exclusively with LDAP, this vulnerability is equally exploitable using a malicious NetInfo server.
    ------------------
    Author, Credit, Redistribution and Copyright Information
    This advisory was written by William Carrel. Redistribution of this text, in whole or in part, with proper credit given is permitted on or after 17:00 UTC, November 26th, 2003. Any other redistribution of this advisory without the explicit consent of the author is not permitted. Copyright 2003, William Carrel
    Page graphics and layout 1997-2003 William Carrel. All rights reserved.

    -----------------------------
    References
    Last edited by TZ; 03-28-2005 at 08:59 AM.

  2. #2
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    quote:
    WhiteHat Security reports a TRACE security flaw affecting most web servers (although the status of Mac-compatible servers is not clear):

    TRACE security flaw

    WhiteHat Security, Inc. a Santa Clara, California based company that specializes in Web Application Security, has discovered a serious security flaw affecting all web servers world wide. From months of extensive research and testing, WhiteHat has found a way to exploit a flaw in the way all web servers communicate.

    ? Using this vulnerability, an attacker could create a web site that steals User Passwords to access E-commerce sites, Online banks, and Web based e-mail systems from every user that visits that page. This web page could be e-mailed to people to extend the number of people attacked.

    ? "While researching this issue, we discovered that a vast majority of commercial web sites have this vulnerability," stated Jeremiah Grossman, Founder and Chief Executive Officer of WhiteHat.
    ? The vulnerability exploits a flaw in the TRACE method which is used to debug web server connections. This is a rarely used portion of the HTTP protocol but is turned on by default in all major web servers. TRACE is part of the HTTP protocol specification, making it somewhat difficult to remove.

  3. #3
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Lightbulb NIDS, Virus, WORM Resources

    ComputerWorld: Virus

    Sharepoint Users Guide
    Troubleshooting OS X
    Online, electronic, CD, pdf. Excellent resource. $15

    NIDS taken to the level of prevention strategies for the next generation
    Intrusion Prevention and Active Response

    Not just Mac OS X but still critical. NIDS taken to the level of prevention strategies for the next generation Intrusion Prevention and Active Response
    Last edited by TZ; 03-22-2005 at 08:53 AM.

  4. #4
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    Companies still fighting rogue WLANs

    The fight goes on against unauthorized access points as companies work to prevent WLAN clients on home systems from injecting Trojan horses into business networks.

    ComputerWorld: Wireless AP risks

  5. #5
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    CERT: Home Security

    Basic steps and precautions to protect your home system.

    Some of the topics covered:
    quote:
    Introduction
    Thinking About Securing Your Home Computer
    Things You Ought To Know
    What Should I Do To Secure My Home Computer?

    Task 1 - Install and Use Anti-Virus Programs
    Task 2 - Keep Your System Patched
    Task 3 - Use Care When Reading Email with Attachments
    Task 4 - Install and Use a Firewall Program
    Task 5 - Make Backups of Important Files and Folders
    Task 6 - Use Strong Passwords
    Task 7 - Use Care When Downloading and Installing Programs
    Task 8 - Install and Use a Hardware Firewall
    Task 9 - Install and Use a File Encryption Program and Access Controls


    Checklist, pdf manual, etc.

    - G.

  6. #6
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    Second line of defense: Distributed firewalls

  7. #7
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    Bugbear.B - Highlights:

    Initial analysis indicates that this virus also attempts to disarm local security software, such as anti-virus or firewall software. It may also be able to spread via network shares, as was the case with the earlier Bugbear.A strain. Furthermore, it installs a key-logging trojan component and enables an unscrupulous hacker to take control of the infected machine and download a file containing the user's keystrokes, including information entered on websites such as passwords or credit-card details for example.

  8. #8
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    Some new books on security for OS X worth considering (links to Amazon):

    Maximum Mac OS X Security

    Mac OS X Security

  9. #9
    Join Date
    Jan 2001
    Location
    Mobius Strip
    Posts
    13,045

    Default

    I know there are threads on 'virus" and 'security" as well as "firwalls" and 'worms" ... but they aren't here under Networking and Security

    Sobig worm making the rounds via email and installing itself into the Windows registry it seems.

    Here is part of the 'payload' of this worm:
    quote:
    The worm arrives in e-mail messages from a single sender, big@boss.com, and is stored in attached executable files with names such as Sample.pif, Untitled1.pif and Movie_0074.mpeg.pif, according to F-Secure.

    When opened, the worm places a copy of itself into the Windows folder on the infected machine, creates a process to run the worm program and modifies the Windows registry so that the worm program will be launched whenever Windows is started.

    Once it has infected a machine, the worm searches for e-mail addresses in a variety of text files on the computer's hard drive. Those addresses are used to send out more copies of itself. Sobig also searches for any shared folders on networks that the infected machine may have access to and places a copy of itself in any network folder it can access.

    Although the new worm doesn't appear to steal sensitive information from the computers it infects, F-Secure said antivirus companies warned that the worm connects to a Web site hosted by Yahoo Inc.'s GeoCities, from which it tries to download and execute other files.

    The GeoCities Web page used by Sobig was modified recently to instruct the worm to download a Trojan program known as Backdoor.Delf that gives the virus writer and others control of infected machines, according to Mikko Hypponen, manager of antivirus research at F-Secure.

    GeoCities has been notified about the page by F-Secure as well as the CERT Coordination Center in Pittsburgh, according to Hypponen. Yahoo wasn't immediately available to comment on the Sobig worm.

    The worm first came to the attention of antivirus companies last Thursday and began spreading slowly, Hypponen said. In recent days, however, it has spread more rapidly. As of Tuesday, F-Secure gave the worm a Level 2 ranking, indicating "large infections" and putting it in a category with well-known predecessors such as the Klez worm.
    See the article for more about it. This one requires it be opened, and is easy to filter out, but it is spreading quite a bit, meaning people are (ignorantly) opening these email messages! And because it uses your address book, it could appear to come from someone you know.

  10. #10
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    As far as I know, the stock OS X ftpd (the listener for FTP connections) only supports padded cells for anonymous connections.

    It takes some setting up, even so, as you need to:

    1. Define the ftp user in the passwd table (easiest with NetInfo Manager, not the Accounts System Preferences interface). This is an account on your system with the "short" username ftp.

    2. Equip the ftp user's home directory with stripped down OS X root files (devices, its own passwd file, writable & read-only subdirectories).

    3. Create and edit /etc/ftpd.conf if needed (the service's configuration file).

    The reason for step 2 is that the defenses you need are provided in FTP sessions using a facility called chroot, which makes the FTP client see the ftp user's home directory as if it was the root directory of the OS. Nothing escapes from a chrooted process other than the kernel's responses to system calls (a deeply technical point, and not all that important to our discussion), so there is no directory above the chroot-point (the ftp user's home directory) exists as far as the ftpd running the user's connection on your server can tell. So any device-interface files, /etc/passwd and /etc/group files to provide owner and group names on file lists, and so on, need to be plumbed into the "right" locations inside the ftp user's home directory.

    I went looking for the old Washington University of Saint Louis (wustl) FTP server package last year, and apparently it's fallen by the wayside. It was a seriously studly ftp server that could be configured to do chroot access control for authenticated users as well as anonymous users. I'd love to find a replacement for it. All the setup as above (and more) would be required for the wustl-ftpd, but hooo-baby you could make it do whatever you needed it to.

    Jazzbo

  11. #11
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    Jazzbo- thank you so much for your reply. Unfortunately I'm afraid your instructions are above my level of competence. For instance, for step 1 in Netinfo Manager I can't seem to find a ftp user name or a password table. But I do see an sshd in local/users and under Properties I find passwd and _writers_passwd.

    I'm a longtime mac user but this G4 is my first exposure to unix and so far my attempts at mucking about under the hood have ended in disaster. That said however, I really need to get this set up right and I'm game to try if anyone has the time to walk me through it.

    I found this site for WU-FTPD Development Group: http://www.wu-ftpd.org/ and this for the version 2.6.2 daemon itself: ftp://ftp.wu-ftpd.org/pub/wu-ftpd/wu...current.tar.gz Again it's all a little too deep for me.

    I notice that in your post you don't mention SSH and SFTP. My understanding is that these are newer, totally different and more secure protocols. Or is it all the same thing?

  12. #12
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Yep, you're right, sftp can also handle the task, but we still have to learn how to create the 'ftp' user and its chroot environment for anonymous padded-cell transfers.

    The special bit about wustl's ftpd was that one could do chroot's on authenticated connections as well as anonymous. Near as I can tell, no other ftp server supported that. The biggest problem with the wustl ftpd is that it's no longer being actively supported; I've also never seen a port to OS X, let alone current releases of OS X.

    The 's' in sftp means that the TCP connection is run in an encrypted channel between the client and the server, so snooping is far too expensive for most hackers/crackers to bother with. It'll be fine for anonymous ftp access, but we still need to figure out how to construct the ftp user's "home" directory, which contains the only directories and files visible to the anonymous user. I'll start some research work of my own and see what I find.

    Perhaps some other reader with a bookshelf of Mac OS X admin books can come up with the procedure for us -- actually, if you're going to head down this path, you ought to have that "right" book on your bookshelf! The right book and this exercise of setting up your anonymous ftp server will teach you a lot of good stuff about the Un*x underpinnings of your OS X machine (and I will also get to learn how to set up anonymous ftp on OS X).

    Cheers,
    Jazzbo

  13. #13
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    Thanks for the replies guys. I downloaded PureFTP 1.0.10-PPC(OSX) package and ran the installer but I haven't figured out how to make it go yet.

    The link to Pure led me to FINK which is pretty interesting. I installed the FinkCommander utility and tried to use it to download the AxYFTP client which, it promises, has a nice GUI, but I got an error message. I'll keep trying.

    From what I can discern from the PureFTP website it looks like it might be just the ticket for me-if I can just find the start button. (Hey 10 years of Mac's point 'n click has made me soft- I'm used to the computer doing all the thinking! Aside the those damn dummy books any suggestions for a good book on Unix for neophytes?

  14. #14
    Join Date
    Jan 2003
    Location
    washington,dc
    Posts
    23

    Default

    Did you make sure to stop `FTP Access' from the Sharing preferences? If not, both FTP servers will attempt to bind to the same port (21) and lukemftpd will get there first because it will start when the computer starts up if it is enabled in System Preferences.

    About xinetd:

    System Prefences uses xinetd to start and stop internet services. xinetd is basically made up of a main config file (/etc/xinetd.conf) and individual config files for each service located in the directory /etc/xinetd.d. For instance, the FTP server's config file is /etc/xinetd.d/ftp. This file is just a plain text file that explains if the service should be enabled and how to start it (Stuff like where the ftp daemon is located, what user to run as, and what flags to use when starting up).

    For example, my xinetd configuration for FTP is:
    {
    disable = yes
    socket_type = stream
    wait = no
    user = root
    server = /usr/libexec/ftpd
    server_args = -l
    groups = yes
    flags = REUSE
    }


    The basic gist is FTP should not be running (disable = yes), but if it were to be enabled it would use the server located at /usr/libexec/ftpd with the flag -l.

    Of course, if you want to go about editing this file, be sure to make a backup as suggested in the installation post.

    For testing purposes, you'll be fine just stopping the default incarnation of FTP, starting up pure-ftpd like you already have and trying to connect again.

  15. #15
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    Turned off ftp in system preferences. Opened terminal and:

    [banana:/usr/local/sbin] banana% sudo pure-ftpd &
    [2] 630
    [bonobo:/usr/local/sbin] banana% Password:****
    ****: Command not found.
    [banana:/usr/local/sbin] banana%

    Hmmm. That's not what it did last night.

    [banana:~] banana% ftp 0
    ftp: connect: Connection refused
    ftp>

    Obviously I am doing/not doing something. But I think if you'll just pass me that big hammer I can fix it.

  16. #16
    Join Date
    Jan 2003
    Location
    washington,dc
    Posts
    23

    Default

    Okay, almost there.

    quote:
    [banana:/usr/local/sbin] banana% sudo pure-ftpd &


    This command doesn't quite work. Even though you are in the directory where the executable exists, /usr/local/sbin is not part of your PATH so you need to specify the exact location. The best thing to do is give the full path: /usr/local/sbin/pure-ftpd &.

    This is where a startup script or xinetd eventually makes life easier. If you take the xinetd route, you can even forget about the command line after you backup and edit the /etc/xinetd.d/ftp file.

    Hope this is helping you and not driving you nuts.

    [This message was edited by cadaeibf on Mon June 30, 2003 PT at 6:02.]

  17. #17
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    Well I don't know where to begin. Somewhere somehow in this process, finagling with terminal incantations and unix gobbledegook, I managed to give this creature here on my desk such a headache that it couldn't take it anymore. It went down in smoke and refused flat out to boot up again. It had the folks at CDW scratching their heads (a real good support crew there- 24/7- no waiting!) Repair and diagnostics all came back saying everything was OK but it still hung every time before it ever got to the log on screen. But anyway, long story to short, I had to reinstall and now everything is back to normal (except for this kernel panic thing when I wake it from sleep but I think that's another topic.)

    So I went through the configuration process again, enabling xinetd mode, and had no problem until:

    Restart xinetd to affect the changes:
    [banana:~] banana% kill -HUP `cat /var/run/xinetd.pid`
    331: Operation not permitted

    I decided to let that one go and soldiered on. In NetInfo I created a subfolder "ftp" in "/services" and added the three properties- name: ftp, port: 21, protocol: tcp. Then:

    sudo kill -HUP `cat /var/run/netinfo_local.pid`
    sudo kill -HUP `cat /var/run/lookupd.pid`

    That went without a hitch. Now I turn on FTP Access in the Sharing panel and go to my other machine and fire up the FTP client, Transmit, and glory oskey I'm in!

    But I still can't see the directory. The window in Transmit which shows the remote host is blank. Here's an abridged transcript of the session:

    331 User george OK. Password required
    PASS
    230-User george has group access to: staff
    230 OK. Current restricted directory is /
    SYST
    215 UNIX Type: L8
    REST 1234
    350 Restarting at 1234. But we're in ASCII mode
    REST 0
    350 Restarting at 0
    PWD
    257 "/" is your current location
    PASV
    227 Entering Passive Mode

    My sense is that it just needs a little tweek. (george has his own user directory set up.)

    Another funny thing I noticed is that when I attempted to connect with another client, Fetch, is that those lines [REST 1234, 350...But we're in ASCII mode, ...Restarting at 0] changed to

    MACB ENABLE
    500 Unknown command.

    Would MACB be macbinary? What determines whether it connects in ASCII or Binary?

    I really appreciate all the help I'm getting here.

  18. #18
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    Hey Jazz: Thanks for explaining all that. You anticipated several questions. Very interesting.

    As for georgie's directory...the problem is that I can't list the contents at all. It's the empty set "/". Perhaps it has made the home directory the root by default, but denied access by making the whole thing invisible. I feel like I need to somehow tell the daemon exactly what directories george can access.

    I tried to follow the instructions on the link that cadaeibf suggested for creating virtual users but the terminal just returns "command not found" every time. (The commands are for Linux/OpenBSD or FreeBSD.)

    I think I need to see about taking a unix night class at the local CC!

    [This message was edited by funicular on Thu July 03, 2003 PT at 4:17.]

  19. #19
    Join Date
    Feb 2001
    Location
    Sacramento, CA
    Posts
    34

    Default

    cadaeibf- Here's my ftp config:

    disable = yes
    socket_type = stream
    wait = no
    user = root
    server = /usr/local/sbin/pure-ftpd
    server_args = -A -E -p 40000:50000 -c 5 -C 1 -I 5 -T 25 -u 1
    groups = yes
    flags = REUSE

    As you can see the -A switch is on so we must be in george's home directory.

    Individual users need to have their own directories, however, it would be nice to be able to also let them share a common directory. Or have access to such folders as I might designate. Would that be possible? Can one like put an alias in their home directory to point them to files outside of the chroot parameters?

  20. #20
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    *Nothing* escapes from a chroot other than system calls (asking the kernel for something). When chrooted, the kernel treats the chroot directory as if it's / (the system root directory), so there's no way to get outside it using file-path references.

    So it basically rules out the shared-directory within the user directory.

    However, one can chroot to other than the home directory of the user. In fact, one can chroot above the users' home directories, especially if you move users of this type out of the default /Users/username default home directory location.

    =====

    So let's theorize....

    ---- Set up an alternate /Users directory and move georgie ----

    Say you create a directory named /ftpUsers and, as you create users in Accounts (or directly in NetInfo Manager, though you've got just a little more manual labor to do at that point), they'll all come in with home directories like /Users/georgie. By the way, for your own testing, create an account of your own that's going to have the same permissions as your ftp users, and carry out all the changes below for that account, too.

    1. In NetInfo Manager, change georgie's home directory to /ftpUsers/georgie
    1a. Open the users table
    1b. Click "unlock" and authenticate
    1c. Select georgie
    1d. Scan down to the sub-entry for the home directory
    1e. Change it from /Users/georgie to /ftpUsers/georgie
    1f. Press Return to enter the change
    1g. Command-S and save the change
    1h. Run the top menu-bar item: Management->Restart Local NetInfo Domains

    2. Move georgie's files from /Users to /ftpUsers
    2a. Launch Terminal (don't scream in terror!!! :-)
    2b. sudo mv /Users/georgie /ftpUsers
    2b.1. Answer the password prompt with your own password
    2c. exit (you're done)

    ---- Set up a shared read/write directory under /ftpUsers ----

    In Finder, make a folder called "Shared" (or whatever suits) inside the /ftpUsers directory. Then, Command-I this Shared folder and, if you want it fully read/write enabled, turn on all of its read/write/execute bits.

    ---- Reconfigure pure-ftpd to chroot to /ftpUsers ----

    Without the docs, I'm not sure how to do this. I guess that the -A flag needs to be deleted. How you tell pure-ftpd to chroot to /ftpUsers is undoubtedly in there somewhere!

    =====

    Other things we can do, with more NetInfo and Terminal work, but not overly complicated work:

    - Define a special group just for these users and put them into that group
    - Change a Shared folder to be writable only to group members
    - Set up a Shared folder to cause all files loaded by the users to be group writable
    - Set up a Shared folder that's only group writable, not readable (drop box)
    - Reset your ftp users so they can't login over a Terminal connection
    - Get rid of the users' subfolders in their home directories
    - Put a link in each users' home directory to a read-only copy of a ReadMe doc
    - Add a folder of Reference files that are readable but not writable to the users


    and so on and so on! All the above hinges on successfully pulling off the three missions, above (switch ftp-only users to /ftpUsers, set up shared directories under /ftpUsers, reconfigure pure-ftpd to chroot to /ftpUsers).

    Jazzbo

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •