PublicationsNetworking |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
Recent Comments
tron on htpasswd Password Tutoria… htaccess on Basics of password protecting …
International Computer Science Institue Networking Articles
March 8, 2009 — FastserveSome AuthDigest Configuration Directives
August 12, 2008 — Fastservestatic const command_rec digest_cmds[] = { AP_INIT_TAKE1("AuthName", set_realm, NULL, OR_AUTHCFG, "The authentication realm (e.g. \"Members Only\")"), AP_INIT_ITERATE("AuthDigestProvider", add_authn_provider, NULL, OR_AUTHCFG, "specify the auth providers for a directory or location"), AP_INIT_ITERATE("AuthDigestQop", set_qop, NULL, OR_AUTHCFG, "A list of quality-of-protection options"), AP_INIT_TAKE1("AuthDigestNonceLifetime", set_nonce_lifetime, NULL, OR_AUTHCFG, "Maximum lifetime of the server nonce (seconds)"), AP_INIT_TAKE1("AuthDigestNonceFormat", set_nonce_format, NULL, OR_AUTHCFG, "The format to use when generating the server nonce"), AP_INIT_FLAG("AuthDigestNcCheck", set_nc_check, NULL, OR_AUTHCFG, "Whether or not to check the nonce-count sent by the client"), AP_INIT_TAKE1("AuthDigestAlgorithm", set_algorithm, NULL, OR_AUTHCFG, "The algorithm used for the hash calculation"), AP_INIT_ITERATE("AuthDigestDomain", set_uri_list, NULL, OR_AUTHCFG, "A list of URI's which belong to the same protection space as the current URI"), AP_INIT_TAKE1("AuthDigestShmemSize", set_shmem_size, NULL, RSRC_CONF, "The amount of shared memory to allocate for keeping track of clients"), {NULL} }; /* * client list code * * Each client is assigned a number, which is transferred in the opaque * field of the WWW-Authenticate and Authorization headers. The number * is just a simple counter which is incremented for each new client. * Clients can't forge this number because it is hashed up into the * server nonce, and that is checked. * * The clients are kept in a simple hash table, which consists of an * array of client_entry's, each with a linked list of entries hanging * off it. The client's number modulo the size of the array gives the * bucket number. * * The clients are garbage collected whenever a new client is allocated * but there is not enough space left in the shared memory segment. A * simple semi-LRU is used for this: whenever a client entry is accessed * it is moved to the beginning of the linked list in its bucket (this * also makes for faster lookups for current clients). The garbage * collecter then just removes the oldest entry (i.e. the one at the * end of the list) in each bucket. * * The main advantages of the above scheme are that it's easy to implement * and it keeps the hash table evenly balanced (i.e. same number of entries * in each bucket). The major disadvantage is that you may be throwing * entries out which are in active use. This is not tragic, as these * clients will just be sent a new client id (opaque field) and nonce * with a stale=true (i.e. it will just look like the nonce expired, * thereby forcing an extra round trip). If the shared memory segment * has enough headroom over the current client set size then this should * not occur too often. * * To help tune the size of the shared memory segment (and see if the * above algorithm is really sufficient) a set of counters is kept * indicating the number of clients held, the number of garbage collected * clients, and the number of erroneously purged clients. These are printed * out at each garbage collection run. Note that access to the counters is * not synchronized because they are just indicaters, and whether they are * off by a few doesn't matter; and for the same reason no attempt is made * to guarantee the num_renewed is correct in the face of clients spoofing * the opaque field. */ /* * Get the client given its client number (the key). Returns the entry, * or NULL if it's not found. * * Access to the list itself is synchronized via locks. However, access * to the entry returned by get_client() is NOT synchronized. This means * that there are potentially problems if a client uses multiple, * simultaneous connections to access url's within the same protection * space. However, these problems are not new: when using multiple * connections you have no guarantee of the order the requests are * processed anyway, so you have problems with the nonce-count and * one-time nonces anyway. */
Distributing free software is an opportunity
June 20, 2008 — FastserveSelling Free Software
Many people believe that the spirit of the GNU project is that you should not charge money for distributing copies of software, or that you should charge as little as possible — just enough to cover the cost.
Actually we encourage people who redistribute free software to charge as much as they wish or can. If this seems surprising to you, please read on.
The word “free” has two legitimate general meanings; it can refer either to freedom or to price. When we speak of “free software”, we’re talking about freedom, not price. (Think of “free speech”, not “free beer”.) Specifically, it means that a user is free to run the program, change the program, and redistribute the program with or without changes.
Free programs are sometimes distributed gratis, and sometimes for a substantial price. Often the same program is available in both ways from different places. The program is free regardless of the price, because users have freedom in using it.
Non-free programs are usually sold for a high price, but sometimes a store will give you a copy at no charge. That doesn’t make it free software, though. Price or no price, the program is non-free because users don’t have freedom.
Since free software is not a matter of price, a low price isn’t more free, or closer to free. So if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.
Free software is a community project, and everyone who depends on it ought to look for ways to contribute to building the community. For a distributor, the way to do this is to give a part of the profit to the Free Software Foundation or some other free software development project. By funding development, you can advance the world of free software.
Distributing free software is an opportunity to raise funds for development. Don’t waste it!
In order to contribute funds, you need to have some extra. If you charge too low a fee, you won’t have anything to spare to support development.
Did your WordPress site get hacked?
June 11, 2008 — FastserveDid your WordPress site get hacked?
Remember a few weeks ago there was all that noise about WordPress blogs getting hacked? Remember how everyone was urged to upgrade their blogs. You did upgrade didn’t you? No? It was inevitable that you’d be hacked. If you haven’t been hacked yet, it’s only a matter of time.
Unfortunately for some who did upgrade, it was too late. The hacker slimeballs may have known about the security issues before we did and went about their merry way breaking into blogs and websites, grabbing usernames and passwords, and planting backdoor scripts to log them in again at a later date.
That’s how even diligently upgraded blogs were hacked. The bad guys got there before you.In the last week the hackers have started again. There is no zero day WordPress exploit. There is no evidence that version 2.5.1 of WordPress is vulnerable to any exploit at this time. They’re using the old exploits all over again. This time they’re redirecting hits from Google to your blog. Those hits are instead being redirected to your-needs.info and anyresult.net
If you’ve been hacked
- Upgrade to the latest version of WordPress.
- Make sure there are no backdoors or malicious code left on your system. This will be in the form of scripts left by the hacker, or modifications to existing files. Check your theme files too.
- Change your passwords after upgrading and make sure the hacker didn’t create another user.
Hidden Code
The bad guys are using a number of ways to hide their hacks:
The simplest way is hiding their code in your php scripts. If your blog directory and files are writable by the webserver then a hacker has free reign to plant their code anywhere they like. wp-blog-header.php seems to be one place. Theme files are another. When you upgrade WordPress your theme files won’t be overwritten so make sure you double check those files for any strange code that uses the eval() command, or base64_decode(). Here’s a code snippet taken from here:
Mosaic User Authentication Tutorial
May 2, 2008 — Fastserve
Mosaic User Authentication Introduction
This tutorial surveys the current methods in NCSA Mosaic and NCSA HTTPd for restricting access to documents. The tutorial also walks through setup and use of these methods.
Mosaic 2.0 and NCSA HTTPd allow access restriction based on several criteria:
* Username/password-level access authorization.
* Rejection or acceptance of connections based on Internet address of client.
* A combination of the above two methods.
This tutorial is based heavily on work done by Ari Luotonen at CERN and Rob McCool at NCSA. In particular, Ari wrote the client-side code currently in Mosaic 2.0, and Rob wrote NCSA HTTPd 1.3.
Tutorial Contents
* Introduction
* Getting Started
* General Information
* How Secure is it?
* Basic By-Password Authentication: Step By Step
* Multiple Usernames/Passwords
* More Examples
* For More Information
Getting Started
Before you can explore access authorization, you need to install NCSA HTTPd 1.0a5 or later on a Unix machine under your control, or get write access to one or more directories in a filespace already being served by NCSA HTTPd. Other HTTP Servers also support access authentication, and some of the information presented here will help you understand how it works, but this tutorial is designed specifically for NCSA HTTPd.
NCSA HTTPd 1.5 has support for HTTP Basic Authentication (Basic), as well as the proposed Message Digest Authentication (MD5). Most, if not all, current browsers should support HTTP Basic Authentication, but not all browsers support MD5. Some browsers that do include NCSA Mosaic/X 2.7 and Spyglass Mosaic
General Information
There are two levels at which authentication information can be passed to the server: the global access configuration file and the per-directory configuration files. This tutorial primarily covers per-directory configuration. See the NCSA HTTPd documentation for information on global configuration.
Per-directory configuration means that users with write access to part of the filesystem that is being served (the Document Tree) can control access to their files as they wish. They need not have root access on the system or write access to the server’s primary configuration files. Also, the per-directory configuration files are read and parsed by the server on each access, allowing run-time re-configuration. The global configuration files are only parsed on start-up or restart, which usually requires root authority. There is a speed penalty associated with using the per-directory configuration files, but that’s the trade-off you have to take.
Access control for a given directory is controlled by a specific file in the directory with a filename as specified by the AccessFileName directive. The default filename is .htaccess
How Secure Is It?
In Basic HTTP Authentication, the password is passed over the network not encrypted but not as plain text — it is “uuencoded.” Anyone watching packet traffic on the network will not see the password in the clear, but the password will be easily decoded by anyone who happens to catch the right network packet.
So basically this method of authentication is roughly as safe as telnet-style username and password security — if you trust your machine to be on the Internet, open to attempts to telnet in by anyone who wants to try, then you have no reason not to trust this method also.
In MD5 Message Digest Authentication, the password is not passed over the network at all. Instead, a series of numbers is generated based on the password and other information about the request, and these numbers are then hashed using MD5. The resulting “digest” is then sent over the network, and it is combined with other items on the server to test against the saved digest on the server. This method is more secure over the network, but it has a penalty. The comparison digest on the server must be stored in a fashion that it is retrievable. Basic Authentication stores the password using the one way crypt() function. When the password comes across, the server uudecodes it and then crypts it to check against the stored value. There is no way to get the password from the crypted value. In MD5, you need the information that is stored, so you can’t use a one way hashing function to store it. This means that MD5 requires more rigorous security on the server machine. It is possible, but non-trivial, to implement this type of security under the UnixTM security model.
Basic ByPassword Authentication: Step By Step
This should help you set up protection on a directory via the Basic HTTP Authentication method. This method also uses the standard plaintext password file. If you have a large user base, NCSA HTTPd supports a DBM based password file for faster access.
So let’s suppose you want to restrict files in a directory called turkey to username pumpkin and password pie. Here’s what to do:
Create a file called .htaccess in directory turkey that looks like this:
AuthUserFile /otherdir/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
require user pumpkin
Note that the password file will be in another directory (/otherdir).
AuthUserFile must be the full Unix pathname of the password file.
Also note that in this case there is no group file, so we specify /dev/null (the standard Unix way to say “this file doesn’t exist”).
AuthName can be anything you want. The AuthName field gives the Realm name for which the protection is provided. This name is usually given when a browser prompts for a password, and is also usually used by a browser in correlation with the URL to save the password information you enter so that it can authenticate automatically on the next challenge. Note: You should set this to something, otherwise it will default to ByPassword, which is both non-descriptive and too common.
AuthType should be set to Basic, since we are using Basic HTTP Authentication. Other possibilities for NCSA HTTPd 1.5 are PEM, PGP, KerberosV4, KerberosV5, or Digest. These other types of authentication will be discussed later.
In this example, only the method GET is restricted using the LIMIT directive. To limit other methods (particularly in CGI directories), you can specify them separated by spaces in the LIMIT directive. For example:
require user pumpkin
If you only use GET protection for a CGI script, you may be finding that the REMOTE_USER environment variable is not getting set when using METHOD=”POST”, obviously because the directory isn’t protected against POST.
Create the password file /otherdir/.htpasswd
The easiest way to do this is to use the htpasswd program distributed with NCSA HTTPd. Do this:
htpasswd -c /otherdir/.htpasswd pumpkin
Type the password — pie — twice as instructed.
Check the resulting file to get a warm feeling of self-satisfaction; it should look like this:
pumpkin:y1ia3tjWkhCK2
That’s all. Now try to access a file in directory turkey — your browser should demand a username and password, and not give you access to the file if you don’t enter pumpkin and pie. If you are using a browser that doesn’t handle authentication, you will not be able to access the document at all.
Multiple Usernames/Passwords
If you want to give access to a directory to more than one username/password pair, follow the same steps as for a single username/password with the following additions:
Add additional users to the directory’s .htpasswd file.
Use the htpasswd command without the -c flag to add additional users; e.g.:
htpasswd /otherdir/.htpasswd peanuts
htpasswd /otherdir/.htpasswd almonds
htpasswd /otherdir/.htpasswd walnuts
Create a group file.
Call it /otherdir/.htgroup and have it look something like this:
my-users: pumpkin peanuts almonds walnuts
… where pumpkin, peanuts, almonds, and walnuts are the usernames.
Then modify the .htaccess file in the directory to look like this:
AuthUserFile /otherdir/.htpasswd
AuthGroupFile /otherdir/.htgroup
AuthName ByPassword
AuthType Basic
require group my-users
Note that AuthGroupFile now points to your group file and that group my-users (rather than individual user pumpkin) is now required for access.
That’s it. Now any user in group my-users can use his/her individual username and password to gain access to directory turkey.
Prepared Examples
Following are several examples of the range of access authorization capabilities available through Mosaic and NCSA HTTPd. The examples are served from a system at NCSA.
Simple protection by password.
This document is accessible only to user fido with password bones.
Important Note: There is no correspondence between usernames and passwords on specific Unix systems (e.g. in an /etc/passwd file) and usernames and passwords in the authentication schemes we’re discussing for use in the Web. As illustrated in the examples, Web-based authentication uses similar but wholly distinct password files; a user need never have an actual account on a given Unix system in order to be validated for access to files being served from that system and protected with HTTP-based authentication.
Protection by password; multiple users allowed.
This document is accessible to user rover with password bacon and user jumpy with password kibbles.
Protection by network domain.
This document is only accessible to clients running on machines inside domain ncsa.uiuc.edu.
Note for non-NCSA readers: The .htaccess file used in this case is as follows:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName ExampleAllowFromNCSA
AuthType Basic
order deny,allow
deny from all
allow from .ncsa.uiuc.edu
Protection by network domain — exclusion.
This document is accessible to clients running on machines anywhere but inside domain ncsa.uiuc.edu.
Note for NCSA readers: The .htaccess file used in this case is as follows:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName ExampleDenyFromNCSA
AuthType Basic
order allow,deny
allow from all
deny from .ncsa.uiuc.edu
