May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

FTP server security


FTP Protocol and Clients Recommended Links Pure-ftpd Daemon vsftp daemon WU-FTP daemon
obligatory steps General Steps Securing vsftpd Securing wu-ftpd FXP Scripting FTP sessions
Troubleshooting of ftp connections Free FTP clients for Window sftp chrooting sshd/sftp on Solaris Humor Etc

The most important, obligatory steps

  1. Run ftp on high port if possible.
  2. TCP wrappers are obligatory.  FTP access can be restricted to specific IP addresses using FTP wrappers By limiting access to your FTP site to known entities, you can drastically reduce your exposure to unauthorized access.
  3. Always use a separate disk partition for downloads; it always should be mounted nosuid and possibly noexec.
  4. Switch to sftp whenever practical and when you process sensitive data. Remember in ftp password travels the internet in clear text.
  5. Always run ftp that many users access chrooted. Sysadmins should not use ftp at all, only sftp. 
  6. Ftp log should be processes by script and alert generated.
  7. Ftp server should always have firewall enabled and in RHEL SELinux enabled.

General Steps

Securing vsftp

Red Hat Linux provides vsftpd FTP servers - a standalone, security oriented implementation of the FTP service.

securing Wu-Ftpd server

Top Visited
Past week
Past month


Old News ;-)

[Jan 10, 2014] Yes, the BBC still uses FTP. And yes, a Russian crook hacked the server

December 30, 2013 | The Register

A BBC FTP server was compromised by a Russian hacker and access to it touted online, say computer security researchers.

The miscreant behind the attack on the internet-facing file store tried to sell access to the infiltrated system to other crims on Christmas Day, we're told. Hold Security – which this year has helped break news of data heists at Adobe and a top-flight limo company – spotted someone trying to sell access to, according to Reuters.

FTP is a 1970s vintage protocol for transferring information in bulk over the internet; its use is discouraged because usernames and passwords to log into accounts are sent over the network unencrypted, although there are ways to establish secure connections.

The hacked service was used by reporters to file material from the field, and by advertisers to upload video to BBC Worldwide channels. The invaded computer was cleaned up over the weekend.

Right now the system appears to be running ProFTPD 1.3.3g on Solaris, but there's nothing to indicate that was the vulnerable software. However, versions of ProFTPD prior to 1.3.3g suffer from a use-after-free bug (CVE-2011-4130) that allows an attacker to execute code remotely on the machine hosting the server; a flaw that's been known about since 2011.

"The only other information that I can offer is that the hacker was offering a screenshot proving that he had administrative access to the BBC server," Alex Holden, chief information security officer at Hold Security, told BBC News.

It is not clear how deep the hacker managed to penetrate Auntie: specifically, whether the miscreant obtained just an FTP admin account login, gained control of the user account running the FTP daemon, or gained full control of the machine running the file-transfer server. Don't forget, a compromised computer could have acted as a stepping stone to other systems within the Beeb's network.

If it's not broke...

See title. Just because it's old, doesn't mean it doesn't work. And with very much less overhead than sending big files via HTTP.

Though granted, a restricted-access FTP site should really be sFTP.

Re: If it's not broke...

"should be living on the DMZ"

Should be on A DMZ, not THE DMZ. Why should my FTP server be anywhere near the web server or mail server? Modern firewall design allows individual dirty networks for services so why only have a single big dirty network playground for hackers? The fewer systems they can access from the compromised one the less likely it is they will spread to the internal networks.

I also hate the term DMZ since the dirtiest network after internet is often the internal client one, and DMZ sits next to the internal networks rather than between them and internet these days so DMZ is very outdated.

Re: If it's not broke...

Yup, nothing wrong with FTP if you ask me. It's simple, robust and can be made as secure as a remote connection can be. Certainly the method of choice for the Beeb's field reporters, safer and more robust than pretty much anything more "current", bar sFTP (which ain't that "current" itself, if a good 20 years younger).

Re: If it's not broke...

"safer and more robust than pretty much anything more "current""

There is also FTPS which predates SFTP by a few years while using the actual FTP protocol and daemons. Of course, the protocol isn't what the problem was here, it was a software bug leading to rights escalation and so could just as easily affect SCP/SFTP. It's less likely that anyone would find the bugs in the FTP/S daemon these days when compared to SFTP due to lower usage but if someone wants your system there is usually a way.

Re: If it's not broke...

"FTP is a 1970s vintage protocol".

Yes, like TCP and IP and many others in everyday use. What's your point?

Re: If it's not broke...

> There is also FTPS

I don't usually consider FTPS a separate protocol; it's still FTP

> a software bug leading to rights escalation and so could just as easily affect SCP/SFTP.

Indeed. Especially SCP, which is known to be vulnerable (which is why most "scp" clients actually use SFTP under the hood).

Re: If it's not broke...

The problem with the "If its not broke, don't fit it" attitude is that, when it infects management, it is used as an excuse to deny or delay all preventative maintenance, patching, and so on. Resulting in, eventually, system failures and security breaches due to outdated, bugged, and vulnerable versions of software or sub-optimal configuration. Management would often prefer to have failures they can blame on software bugs or attackers to having a failed modification or patch being blamed on their own department.

Yes, FTP is a relatively lightweight and efficient protocol, but you still need to keep up with the patching and improve security (such as switching to sFTP or FTPS as you mentioned).

Re: If it's not broke...

The problem with the "If its not broke, don't fit it" attitude

And when the Damagement have the desire to fix everything regardless of whether it's broke, we end up with the Windows 8 UI. The problem is in how to educate the bosses enough that they understand what "maintenance" is without going batshit crazy on "new". Or worse, "better because it's newer".


Why blame the BBC? This stuff was outsourced to Siemens in 2004. I should know, I was one of the poor sods who was sold!

That said from the sounds of it, the ftp access pre-dates even BBC Technology back to the days of the beardy wierdy geniuses at Kingswood Warren.

Re: Siemens

The service part of Siemens was bought out by Atos.

There are many parts of BBC IT outsourced to Atos (BBC Desktop for example) but much is run in house as well by BBC Technology / Tech Ops (most of the web based services and as noted above, BBC Worldwide).

There will probably be much finger pointing as there often is with these things. That's if there was any serious threat. A "stepping stone" it may have been, but into what exactly? And let's face it, the Beeb is just a media organisation, not a bank or a holder of huge amounts of important personal data.

Maybe someone could have done us a favour and taken Radio 1 off the air.

Re: Siemens: To be fair...

It's pretty safe to say that the BBC have enormous amounts of personal data.

Given the prevalence of password reuse, they hold plenty of concern even if you only think in terms of email/password pairs. That said, I do see your point. Anybody with best practices in mind when watching "World's Craziest Fools," is fine.

*nips off to change some passwords*


The 1337day site has an exploit for sale which claims to be for ProFTPD 3.3.3g and quotes the BBC FTP site. Some of their exploits for sale have been a bit dubious in the past so rather than it being a new ProFTPD vulnerability it may just be instructions on a misconfiguration of that particular server.

Always have loved the simplicity and stability of FTP personally and added secure SSL functionality has been available for years on many clients/servers. FxP'ing between servers still happens!

"account running the ftp daemon"

Since this was the bbc, what are the chances that ftp was running as root?

Anonymous Coward

Many of our clients still use ftp to send data to us every few minutes throughout the day (Gas Industry). This is all over Europe and beyond not just in the UK so FTP is very far from dead. As for the attack itself, shocker, an FTP account where the username and password are sent in plain text was compromised (although it seems the attacker here had it even easier). That is why an FTP box just does FTP and sits out on its own in the DMZ and only has the required ports open to the outside (in other words was SSH available to the Outside). I do also wonder if they restrict user accounts, I only allow 3rd parties FTP and FTPS access (and that FTPS access is not run by my SSH daemon either), they have no shell so would have to find a vulnerability in order to elevate themselves somehow. Even if they did compromise the box, it wouldn't help them much here as it has no access to anything else.

I live under the assumption I have been hacked or will be, makes it much easier to manage risk. I hope the BBC do the same.

Anonymous Coward

Software Clients - pass the blame

Maybe this is something to do with Microsoft, having failed to support sftp clients/servers as part as their supplied install packages, whilst maintaining support for ftp.

Anonymous Coward

Re: Software Clients - pass the blame

Erm, but Microsoft has supplied and supported an RFC based FTPS (FTP over SSL) server ever since IIS7....

AJ MacLeod

Re: Software Clients - pass the blame

FTPS != SFTP (which is far more widely used IME)

Anonymous Coward


They use a pretty convoluted aspera based ingest system for almost everything important, content wise anyway.

That said, the bbc is a loose collection of individuals who basically hate each other and are allowed to operate as virtually separate companies.

There are hundreds of FTP servers operating internally and externally for various puropses, getting files on and off the system for engineering purposes, providing logs to suppliers for support, just the usual mash up.

They use a broad range of operating systems ranging from windows 3.11 all the way up to win8 and a whole host of x like systems. Nothing gets patched, in case the patch upsets some of the unsupported 15 year old mission critical software that Dave from FM&T wrote in 1999.

I swear, only a few years ago, I looked after ceefax that has only just been switched off, when asked to find out why it kept falling over, I found the servers in a cupboard and they were a rag tag assortment of 386's the occasional Pentium 1 and, well, you can imagine the rest.

They do take perimeter network security reasonably seriously though so I very much doubt that this FTP server will have made an easy stepping stone into the rest of the network.


ITN hacked via FTP too

Many years ago (about 1999/2000) I was called in to deal with a hack via FTP which defaced ITN's web ste. That was a Solaris box to - a Sun E450.

It wasn't a technically difficult hack though. FTP was world available, the username was ITN and the password ITN. This account had root privilege. Doh!

Securing FTP (1/2)

Jim has written a great article on how you can upgrade your FTP site's security through simple configuration changes.Securing FTP

This document contains information about securing the Internet File Transfer Protocol (FTP) server. While there are a variety of daemons around, most of the material covered here pertains only to wu-ftpd.

In the past there have been bugs found in older versions of various ftpd daemons. Crackers have exploited these bugs and will continue to do so. See for the latest attack exploiting a problem in the realpath() function. So, the first order of business is to upgrade that server to the latest version! My favorite site for finding wu-ftpd is at, which also includes "vr" patches; they're in my mind akin to the Linux kernel's "ac" patches.

Now on to some really fun steps (as if compiling ftp isn't already fun):

  1. Check your /etc/ftpusers (a misnomer in my opinion).

    This file includes the login names of those users who are NOT allowed to login to your site. This file may look something like:

    ~[root(lindstrom)1]: cat /etc/ftpusers

    At the very least, this file should contain root, system accounts, and nobody. Other possible users will include anonymous and ftp. Adding those accounts will effectively disable anonymous ftp. Removing the ftp user from /etc/passwd will also disable anonymous ftp.

Lets take a peek at /etc/ftpaccess as well

This file configures ftpd, but only if ftpd is called with -a. I recommend using this handy feature. Discussing all the possibilities of this file is out of the scope of this document. I urge you to man ftpaccess to get a better understanding of it.

Setting up the FTP area file structures

Finally we setup restrictions at the file level.

The root directory and every directory under it should not be owned by the same user/group of the ftp account. We certainly don't want anonymous users writing to just anywhere.

d--x--x--x 2 ftpadmin ftpadmin 1024 Feb 12 18:34 bin/
d--x--x--x 2 ftpadmin ftpadmin 1024 Jul 11 06:36 etc/
drwxr-xr-x 2 ftpadmin ftpadmin 1024 Feb 5 14:48 lost+found/
drwxr-xr-x 7 ftpadmin ftpadmin 1024 Mar 31 17:04 pub/
drwxrws-wt 2 ftpadmin ftpadmin 1024 Jul 18 01:00 incoming
or if you want to use the 'secret' directory approach for uploads: drwxr-x--x 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/
drwxrws-wt 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/secret_upload_dir

Other points of interest

For the paranoid, wu-ftpd has something just for you. Define paranoid in config.h and "questionable functions" will be disabled. Check out FIXES-2.4-HOBBIT from wu-ftpd source for more info on this.

Support for S/Key and OPIE are included in wu-ftpd, and I've seen patches for SSL and SRP floating around the internet. SSL for wu-ftpd is at However, it's a bit dated as far as keeping up with recent versions of wu-ftpd. There i s also edssl (a non SSL to SSL translator) in the /pub/crypto/crypto/SSLapps/SSLlynx/ directory on that site. SRP patches can be found at MrWizard's homepage along with some other nifty things.

Appendix F: Installing in a chroot Environment

This appendix provides instructions for installing and running Sun ONE Identity Server in a chroot environment. This appendix contains the following sections:

Chroot comes from the change root function in Unix®. When Identity Server is installed in a chroot environment, a named directory becomes the root directory. The new chroot directory then becomes the starting point in the path for all Identity Server searches. The chroot prevents malicious programs from accessing the real root file system, providing an added measure of security for the Web Server and Directory Server processes that power Identity Server.

Before beginning the chroot creation process, the following points should be noted:

Identity Server processes that serve requests cannot see or access files outside the chroot directory so the appropriate Identity Server files must be copied into the chroot directory structure. The first step is to create the user root environment for Identity Server. This new root must contain everything that Identity Server expects from the natural root (/).


$CHROOT is the variable name for the chroot directory.

  1. Create the following system directories on the computer system that will host Identity Server.
  2. /dev

















  3. Create system soft links using the command ln -s.
  4. The following soft links should be created:

  5. Create devices under $CHROOT using the command mknod.

  6. Tip

    For example, to create the device /dev/tcp under the $CHROOT directory, enter:

    mknod dev/tcp c 11 42

    The following devices should be created under the $CHROOT directory:

  7. Copy files from directory /etc to corresponding locations under the $CHROOT directory. (For example, copy /etc/hosts to $CHROOT/etc/hosts.)
  8. The following files should be copied:

  9. Copy binaries to the corresponding locations under the $CHROOT directory. (For example, copy /usr/bin/sh to $CHROOT/usr/bin/sh.)
  10. The following files should be copied:

  11. Copy libraries to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/* to $CHROOT/usr/lib/.)

  12. Note

    If the computer system in which Identity Server is installed is a 64-bit machine, the libraries from /usr/lib/64 and /usr/lib/lwp/64 need to be copied to $CHROOT/usr/lib/64 and $CHROOT/usr/lib/lwp/64, respectively.

    The following files should be copied:

  13. Copy the zoneinfo files to corresponding locations under the $CHROOT directory. (For example, copy /usr/share/lib/zoneinfo/* to $CHROOT/usr/share/lib/.)
  14. Copy the locale files to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/locale/* to $CHROOT/usr/lib/locale.)

Installing Identity Server Under chroot

  1. Install Identity Server 6.1 in a directory other than $CHROOT.
  2. If an installation directory is not specified, Identity Server is installed, by default, in /opt/IdentityServer_base .

  3. Stop the instance of Sun ONE Web Server.
  4. ./WebServer_base/https-instanceName/https-stop

  5. Stop the instance of Sun ONE Directory Server.
  6. ./DirectoryServer_base/slapd-instanceName/stop-slapd

  7. Copy the entire Identity Server directly from IdentityServer_base to the $CHROOT directory using the same structure.
  8. Copy files from the following locations to the corresponding directories under $CHROOT:
  9. Create a loopback mount for Java.
  10. The following command makes Identity Server ready to run under chroot environment:

    mount -F lofs /usr/j2se $CHROOT/usr/j2se

  11. Create a loopback mount for /usr/share/lib and /usr/lib/mps.
  12. Examples:

    mount -F lofs /usr/share/lib $CHROOT/usr/share/lib

    mount -F lofs /usr/lib/mps $CHROOT/usr/lib/mps

Starting Identity Server In chroot

To start Identity Server in the chroot environment, both Directory Server and Web Server must be started.

  1. Start Directory Server using the chroot command:
  2. chroot $ROOT $IS_ROOT/DSServers/slapd-hostName/start-slapd

  3. Start Web Server using the chroot command:
  4. chroot $ROOT $IS_ROOT/SUNWam/servers/https-instanceName/https-start

Identity Server Log Files In chroot

Identity Server normally creates log files (Error Log, Debug, etc.) in the following directory:

/var/opt/SUNWam/debug and /var/opt/SUNWam/logs

Under chroot these log files will be created at the following locations:



Setup an FTP user account minus shells

It's important to give to your strictly FTP users no real shell account on the Linux system. In this manner, if for any reasons someone could successfully get out of the FTP chrooted environment, it would not have the possibility of executing any user tasks since it doesn't have a bash shell. First, create new users for this purpose;

These users will be the users allowed to connect to your FTP server.

This has to be separate from a regular user account with unlimited access because of how the chroot environment works. Chroot makes it appear from the user's perspective as if the level of the file system you've placed them in is the top level of the file system.

Use the following command to create users in the /etc/passwd file. This step must be done for each additional new user you allow to access your FTP server.

[root@deep ] /# mkdir /home/ftp
[root@deep ] /# useradd -d /home/ftp/ftpadmin/ -s /dev/null ftpadmin > /dev/null 2>&1
[root@deep ] /# passwd ftpadmin      
Changing password for user ftpadmin
        New UNIX password:
        Retype new UNIX password:
        passwd: all authentication tokens updated successfully

Once the home/ftp/ directory has been created you don't have to use this command again for additional FTP users.

  1. Edit the /etc/shells file, vi /etc/shells and add a non-existent shell name like null, for example. This fake shell will limit access on the system for FTP users.
    [root@deep ] /# vi /etc/shells

    /dev/null, This is our added no-existent shell. With Red Hat Linux, a special device name /dev/null exists for purposes such as these.

  2. Now, edit your /etc/passwd file and add manually the /./ line to divide the /home/ftp directory with the /ftpadmin directory where the user ftpadmin should be automatically chdir'd to. This step must be done for each FTP user you add to your passwd file.

    To read:


    The account is ftpadmin, but you'll notice the path to the home directory is a bit odd. The first part /home/ftp/ indicates the filesystem that should be considered their new root directory. The dot . divides that from the directory they should be automatically chdir'd. change directory'd into, /ftpadmin/.

Once again, the /dev/null part disables their login as a regular user. With this modification, the user ftpadmin now has a fake shell instead of a real shell resulting in properly limited access on the system.

Setup a chroot user environment

What you're essentially doing is creating a skeleton root file system with enough components necessary, binaries, password files, etc. to allow Unix to do a chroot when the user logs in. Note that if you use the --enable-ls option during compilation as seen above, the /home/ftp/bin, and /home/ftp/lib directories are not required since this new option allows Wu-ftpd to use its own ls function. We still continue to demonstrate the old method for people that prefer to copy /bin/ls to the chroot'd FTP directory, /home/ftp/bin and create the appropriated library related to ls.

The following are the necessary steps to run Wu-ftpd software in a chroot jail:

First create all the necessary chrooted environment directories as shown below:

        [root@deep ] /# mkdir /home/ftp/dev
        [root@deep ] /# mkdir /home/ftp/etc
        [root@deep ] /# mkdir /home/ftp/bin    
        [root@deep ] /# mkdir /home/ftp/lib    
The last two are required only if you are not using the --enable-ls option.

Change the new directories permission to 0511 for security reasons: The chmod command will make our chrooted dev, etc, bin, and lib directories readable and executable by the super-user root and executable by the user-group and all users.

    [root@deep ] /# chmod 0511 /home/ftp/dev/
    [root@deep ] /# chmod 0511 /home/ftp/etc/
    [root@deep ] /# chmod 0511 /home/ftp/bin    
    [root@deep ] /# chmod 0511 /home/ftp/lib    
  1. Copy the /bin/ls binary to /home/ftp/bin directory and change the permission of the ls program to 0111. You don't want users to be able to modify the binaries:
        [root@deep ] /# cp /bin/ls /home/ftp/bin            
        [root@deep ] /# chmod 0111 /bin/ls /home/ftp/bin/ls 

    This step is necessary only if you're not using the --enable-ls option during the configure time of Wu-ftpd. See the Compile and Optimize section in this chapter for more information.

  2. Find the shared library dependencies of the ls Linux binary program:
    1.             [root@deep ] /# ldd /bin/ls        => /lib/ (0x00125000)
                  /lib/ =7gt; /lib/ (0x00110000)
    2. Copy the shared libraries identified above to your new lib directory under /home/ftp directory:
                      [root@deep ] /# cp /lib/ /home/ftp/lib/ 
                      [root@deep ] /# cp /lib/ /home/ftp/lib/ 
    3. These library are needed to make ls work. Also, steps 3 and 4 above are required only if you want to use the ls Linux binary program instead of the --enable-ls option that uses the new internal ls capability of Wu-ftpd.
  3. Create your /home/ftp/dev/null file:
                  [root@deep ] /# mknod /home/ftp/dev/null c 1 3
                  [root@deep ] /# chmod 666 /home/ftp/dev/null           
  4. Copy the group and passwd files in /home/ftp/etc directory. This should not be the same as your real ones. For this reason, we'll remove all non FTP users except for the super-user root in both of these files, passwd and group.
    1.                 [root@deep ] /# cp /etc/passwd /home/ftp/etc/
                      [root@deep ] /# cp /etc/group /home/ftp/etc/
    2. Edit the passwd file, vi /home/ftp/etc/passwd and delete all entries except for the super-user root and your allowed FTP users. It is very important that the passwd file in the chroot environment has entries like:
    3. : We can notice two things here: first, the home directory for all users inside this modified passwd file are now changed to reflect the new chrooted FTP directory i.e. /home/ftp/./ftpadmin/ begins /ftpadmin/, and also, the name of the user's login shell for the root account has been changed to /dev/null.

    4. Edit the group file, vi /home/ftp/etc/group and delete all entries except for the super-user root and all your allowed FTP users. The group file should correspond to your normal group file:
  5. Now we must set passwd, and group files in the chroot jail directory immutable for better security.
    1.                 [root@deep ] /# cd /home/ftp/etc/
                      [root@deep ] /# chattr +i passwd             
    2. Set the immutable bit on group file:
                      [root@deep ] /# cd /home/ftp/etc/
                      [root@deep ] /# chattr +i group             

Configure the /etc/ftphosts file

The /etc/ftphosts file is used to define whether users are allowed to log in from certain hosts or whether there are denied access.

  1. Create the ftphosts file, touch /etc/ftphosts and add for example in this file the following lines:
              # Example host access file
              # Everything after a '#' is treated as comment,
              # empty lines are ignored
              allow ftpadmin
              deny ftpadmin

    In the example below, we allow the user ftpadmin to connect via FTP from the explicitly listed addresses, and deny the specified ftpadmin user to connect from the site

  2. Now, change its default permission to be 600:
              [root@deep ] /# chmod 600 /etc/ftphosts        
Configure the /etc/ftpusers file

The /etc/ftpusers/ file specifies those users that are NOT allowed to connect to your FTP server.

  1. Create the ftpusers file, touch /etc/ftpusers and add in this file the following users for security reasons:
  2. Now, change its default permission to be 600:
                [root@deep ] /# chmod 600 /etc/ftpusers          
Configure the /etc/pam.d/ftp file

Configure your /etc/pam.d/ftp file to use pam authentication by creating the /etc/pam.d/ftp file and add the following lines:

          auth       required     /lib/security/ item=user sense=deny file=/etc/ftpusers onerr=succeed
          auth       required     /lib/security/ shadow nullok
          auth       required     /lib/security/
          account    required     /lib/security/
          session    required     /lib/security/



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019