PublicationsNetworking |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
Recent Comments
tron on htpasswd Password Tutoria… htaccess on Basics of password protecting …
International Computer Science Institue Networking Articles
March 8, 2009 — FastservePerl CGI Script to manage multiple usernames/passwords
March 4, 2009 — FastserveNOTE: Not Freeware.
.htaccess manager : New Version 3.3
This is a perl CGI script used to manage multiple usernames/passwords for .htaccess/.htpasswd directory protection. This works on most web sites and can be used to handle many password protected folders. In addition to storing the username and encrypted password, you may add additional info for your members such as name, e-mail and comments to help you manage who has access to your “members only” web site. New features include setting an expiration date for a user, keyword search of your members’ list and batch removal of users.
FEATURES
Adding a New user
The “Add User” function is the first that appears after logging into the script. You just need to supply a username and password then click “Add User”. All the other fields are optional. Even the password field can be left blank and the program will pick one at random. You can also supply the member’s name, e-mail address and a short comments field. If you check the box “Check to email new entry to user”, this will tell the program to send out an email with pre-configured text welcoming the user as a new member to your password protected area. If you do check this box, then you can also provide additional text in the large “Extra E-mail Text” box which will be passed along in the email sent out.
You can now add an expiration date for the user, enter it in the format YYYYMMDD (20030631 for example). The script does not automatically delete users but you have the option of sorting your user list by expiration date. This field is optional and you do not have to enter an expiration date.
View, Modify and Delete Users
The “List User” screen does three things, it provides a list of all your members, allows you to delete a member and modify any information for a particular member. The user list shows “Username – Member Name – Email address – comments”. You can easily control the size of this box by changing the scrollsize option in the program settings. To delete a user all you have to do is highlight then click the delete button. To Modify a user, you also highlight the record then you can modify the password, name, email and comments field. You can even check the box to resend their confirmation email. If one of your members forgets their password, you just come to this screen, highlight them, enter a new password, check the “e-mail” box and click “Modify User”.
Sort By Expiration : Will sort all of your members by expiration date in ascending order.
Sort by username : Sorts the list by username (the default view)
Keyword Search : Will search the username, name, email, comments and expiration field for whatever you type in
Change Directory
“Change Protected Directory” screen allows you to manage password protection on another folder. This also makes it easier than going back to the login screen. This screen displays the path you have setup where your password protected directories will be located. You just type in the new folder name and click “Change Directory”. This way you can use the script to manage as many password protected folders as you like. If you are protecting a folder within another folder then you type in for example : member_area/secure1 and then the script will manage the “secure1″ folder located in the “member_area” folder. You will also find two additional buttons on this screen. One is to view the .htaccess file and the other for the .htpasswd file. This is a good thing to do every now and then so you can make backups of your member database.
Generate .htaccess File
When you first setup password protection on a folder, you need to create a .htaccess file inside it. You can either do this manually or have the script create this file for you. You do not need to do this every time you add a user. Once a .htaccess file has been created in a folder, you don’t need to run this function again. The Directory field will display the folder name you are about to generate a .htaccess file for. The Realm is for the message that will be displayed in the pop-up box that appears when a user tries to login to your secure area. If you want the script to create the file, then check the “Create .htaccess file on Server”. As for the format you want, the majority of unix servers use “.htaccess file for apache” Some web hosting companies use Cobalt RAQ or Zeus.
Password Retrieval (Version 3.2+)
You can now have your members generate new passwords for themselves if they forget their login information. To activate this feature in the script, send your users to :
http://www.yourdomain.com/admin.cgi?action=F&targetdir=dirname
Where “dirname” is the name of the directory you are protecting (same directory you type in when accessing admin.cgi)
If a member forgets their username, they just type in their email address and it will be sent to them. If they forget their password, they just type in their e-mail and username then a new password will be generated.
Version 3.3 just added the option for users to select their own new password if they supply their username and their old password.
Extract E-mails
Extract E-mails allows you to export a list of all your members’ email addresses. The list will be formatted one email address per line. Some email programs require that each address have a comma after it which you can select when exporting. The addresses will appear on the next page which you can then copy/paste into Eudora/Outlook etc.
Mass E-mails (Version 3.2+)
Allows you to send a broadcast email message to all members. E-mails can be configured to send specific information about each user using the %tag%.
Example : Hello %name%,
Your userid is : %username%
Your email is : %email%
Your account expires on : %expiration%
Comments about your account : %comments%
Manual Import
If you have a large list of usernames that you want to add as members in just one click then the Manual Import feature will handle this. All you do is copy/paste or type the list into the large text box. Here is a sample of what the list would look like :
username,password
joe,joe123
jack,jack887
jane,janepass
You can also import the additional fields :
username, password, name, email, comments, expiration
joe,joe123,Joe Smith,joe@smith.com,friend
jack,jack887,Jack Smith,jack@smith.com,
Also, you can even leave the password field blank to have the script automatically generate it for you :
joe,,Joe Smith,joe@smith.com
jack,,Jack Smith,jack@smith.com
(note the two commas after eachother)
You can also automatically send an email to each member that you import by checking the “Send E-mail” box. Even the comments field can be sent if you wish.
Whenever you run the import, the script will always check to make sure that the username doesn’t already exits. If any username in your list exists, no records will be imported.
Import From File
The import from file feature is if you have a list of members too large to fit in the manual import box or maybe you have another program that exports the list of usernames/passwords to a file that need to be imported later. By default, the name of the file that the program looks for is called htimport.txt and will be located in the directory you are protecting. The format for records to be imported is the same as the manual import :
username,password
or
username,password,name,email,comments, expiration
or
username,,name,email,comments
Whenever you run the import, the script will always check to make sure that the username doesn’t already exits. If any username in your list exists, no records will be imported.
Change Program Settings
This screen allows you to update configurations in the program without having to manually edit the admin.cgi script. The settings you can change are :
Base directory : The physical server path to where your protected folder or folders are located. (Not to be confused with the URL or domain name to your web site). example : /www/yourdomain/htdocs/
Password : The master password to access the admin.cgi script with.
Sendmail : The path to sendmail for your server.
Scroll Size : The number of members that will be displayed in the “List Users” screen before it scrolls.
Email From : Your e-mail address goes here. This is also the address used when sending email confirmations to your new members, they will see this in the From field. You can also add your name in parenthesis : joe@smith.com (Joe Smith)
Email Subject : The subject of the emails which are sent out to new members.
Top of Email : The text that will appear in the email sent to users. After this text will come the username and password.
Bottom of Email : The text that will appear after the username/password and the end of the email.
The data for all these variables is stored in a file called adminvars.cgi
You do not need to create this file on the server. If the file is not there it will be created with default settings. If for some reason your script does not have permission to create the file, you may need to upload a blank one and chmod it to 777. The default admin password is test.
FAQ
In the majority of cases, if it’s unix and runs the apache server then yes. The best way to find out is by uploading a .htaccess file to a subdirectory on your server then access it with your browser and see if it asks you for a login.
- Here’s one you can use on your site : .htaccess upload this file to a directory on your server (in ASCII mode), example : yourdomain.com/members/ then rename it to .htaccess (yes, that’s a period infront of “htaccess”)
- Then using your browser, go to http://www.yourdomain.com/members/ If you’re prompted to enter a username and password, then it will work!
No, the way .htaccess works, is it protects all files in the directory it is in. So once a user is authenticated, they have access to everything in that folder. But if a user bookmarks a page in the secure area, they will be required to re-enter the user/pass if they shut down their web browser and restart.
Yes, in this case, you would have the admin.cgi script only manage one of the directories for you, then all you would need to do is copy the same .htaccess file over to the new directory you want to protect. If you look in the .htaccess file, it says right there the full path to the .htpasswd file it will look for to authenticate users AuthUserFile /home/secure/.htpasswd.
Yes, in this case, you just run the admin.cgi script and tell it to refresh to a new directory to access that list of users. By doing this, each directory will have its own .htpasswd and .htaccess file.
Yes, 90% of the time it will. Just as long as the directory you are protecting is setup as a regular directory in frontpage and not a “subweb”. The idea is to tell Frontpage not to overwrite the .htaccess file that admin.cgi creates
Yes, this feature is available as of version 3.2. Just provide a link for your members to admin.cgi?action=F&targetdir=dirname. They just have to supply their e-mail address and username then the script will generate a new password and e-mail it to them.
When you add a new user, you have the option of sending them an e-mail with their new username/password (saves you the time of having to do it manually each time). You can configure the subject of the emails, the sender’s name and e-mail address (you) and the text in the body of the email. These settings can be changed by logging into admin.cgi and scrolling down to the section labeled “Change Program Settings”. You can read about this in the Features page.
This is what the Manual Import feature does. After running the script, scroll down to “Manual Import” and you’ll see a large TEXT box, this is where you can copy/paste your list of users. See the Features page.
No.
Not a problem, we’ll install the script for you. When you place your order, be sure to provide your URL (http://….) ftp username and password. Almost all installs are completed the same day you place your order.
We will not charge your credit card until the program works successfully on your web hosting account/server. Credit cards are usually processed a few days after you submit your order.
File Permission Security on Shared Web Hosting
October 28, 2008 — FastserveSome web hosts allows you to create multiple users per account. Each user can have domain assigned to its home home directory accessible via FTP or SSH/SCP. The problem with multiple users on the same account is that they share the same default unix group, and default permissions allow their files to be easily modified by the members of this group. Usually this doesn’t pose a problem as each user is probably trusted by account owner to not to mess with others files, but if one of the users have their web application hacked then all other users on the same account will be in danger.
By default (on DreamHost) all files in your account are created with 644 privileges and directories are with 775. That means any user can read your files and any user from the same account can move and add files in your freshly made directories. Your home directory is different, though. By default it carries 751 attribute meaning that only members of your group can see your files, but can’t add any new. These group access schemes are possible, because every user in your account has its primary/default group set to “pgxxxxxx”, which is assigned to every new file you create by default. The normal way to secure users from web-intrusion is to assign a separate group to the web-server user, removing it from default group. This way, exploited scripts will not be able to traverse into home directories of other users on your account. To allow account users to update centralized web-site they could be added to web-site group explicitly. But this “normal way” doesn’t work with DreamHost, because you can’t delete web-user from the default group and unless you set access for every new file explicitly, it will be possible for an intruder to read it.
To make managing privileges easier in interactive sessions “umask 007″ command can be specified in your .bash_profile – this makes all new files carry xx0 mask. You also need to control your scripts (web based or cron/shell) so that they set mask for critical files explicitly. To secure account users from access by means of hacked user script you would also like to define another group for every user in your account and change group ownership of the user’s home directory to that group with “set gid” bit set (and optional umask 007 in .bash_profile).
- Add a separate user and group for every domain where apache will be running
- Add a separate group for other user accounts
- Change the default group for new files created by your users by changing the group of their home directory and setting set gid bit for it (it is impossible to do this with FTP accounts, therefore you will need to login in each account via SSH)
- Add users who need access to web-site into the web-user group
- Optionally set umask 007 in .bash_profile for every user to tweak default DreamHost 775/664 permissions to something like 770/660 for directories and files that are not meant to be read by Apache (660 could also be used for all web scripts including .php as they are not read by dhapache CGI, but merely executed)
Apache Security
All your web files that need to be read by Apache should be readable by everyone as Apache itself is run under dhapache user. However, executable scripts like .php are executed under your own user and do not have to be world readable as they are not actually read by Apache, but executed via suEXEC. Quite the opposite – to prevent your code or database settings from being messed by any third-parties you SHOULD set permissions to these files explicitly to something like 640 or even 600 depending on who do you trust.
Multiuser security setup example
For our example, we will create a example_www user and a new_webroot group for serving web files with apache and setup a example user with a ‘rfrc group to manage mail and keep other files on DH privately. Since these records already exist, you will need to subsitute your own names.
- Login to DreamHost panel and create the users example_www and example with shell access.
- From groups tab create two groups – new_webroot and rfrc. Note that users created in previous step are still members of the same default pgxxxxxx group.
- Add example_www to ‘the ‘new_webroot group and example to both the new_webroot and rfrc groups
- Move your domain to example_www account (mine is example.org)
- Now login to SSH with your example_www user and change the default group for your home directory with “sgid” bit set to make all current and new files/directories created in this directory have the same new_webroot group.
$ chgrp -R new_webroot . $ chmod 2751 . $ chmod 2771 example.org
By setting 2771 the directory will be writable by the owner, the group and will be only executable by others. The contents of an executable only directory cannot be listed, but the files inside it can be read (if the permissions of the file allow it). It is important that the directory can be executable in order to allow static content (e.g. .html files) inside it to be read. Remember that directories you don’t want anyone to have web access to, should be 0770 (writable by the owner and group, or 0750 writable by the owner and readable by group). Such strict permissions should by applied to password files, php include files or databases files (such as SQLite, BDB, etc).
- Do the same for example user, but specify rfrc group instead.
chgrp -R rfrc .
chmod 2751 .
- Optionally modify umask in .bash_profile in user’s home to 007 to make all files created by this user have 660 permissions set by default. If you want that newly created files by accessible by the web, you need to manually setup it’s permissions to 664.
Now I can login as the user “example” and update the web-site in the ../example_www/example.org directory. There is one more setup needed. Because files copied from other accounts can have 644 permissions set instead of 664, you need a script which will update permissions to 664 or 660 to allow other group members modify such files.
Automatic Post-commit Checkout
October 27, 2008 — FastserveSubversion can be a very useful tool for developing Web sites or Web-based applications. You may wonder, though, how that would work. After you commit your changes to your repository, how do you have them reflected on your site? The easiest method is to have your site’s directory on the server be a working copy checked out from your Subversion repository. If you elect to do this be certain to modify your site’s .htaccess to prevent users from browsing Subversion’s control files. Something simple in the root of your site such as the following will suffice.
RedirectMatch 403 /\.svn.*$
Additionally you can configure your site to automatically check out the current sources from your repository by using Subversion’s “hook scripts“. In short, the script called hooks/post-commit will be executed by the web server each time new sources are checked into your repository. Be advised that when the web server executes this script it is running in the security context of the dhapache user — this user does not and should not (for security reasons) have the necessary permissions to modify the files in your web site’s directory. As such we need to arrange for the post-commit script to run the update in the security context of a user with the privileges necessary to update your site.
Users familiar with UNIX systems will recognize that this is a task for a setuid binary. Unfortunately the DreamHost /home/ directories are NFS filesystems which are, for security reasons, mounted with setuid disabled. Fortunately the workaround is trivial — simply set up your update script as a CGI script and have the Subversion post-commit hook invoke this script. Instructions follow.
1. Create a private directory on your website to host your updater script such as /home/username/mysite.com/cgi-bin/pri
1b. And set its permissions so that only the user has write access to it.
chmod 755 pri
2. Secure the private directory by creating a .htaccess file with contents similar to the following.
AuthName "Dialog prompt" AuthType Basic AuthUserFile /home/username/mysite.com/cgi-bin/pri/.htpasswd Require valid-user
3. Using the htpasswd utility create the .htpasswd file by running the following command in your /home/username/mysite.com/cgi-bin/pri directory. For security reasons make up a new username and password and do not re-use the username and password of a user you have created on your server or a user you have given access to your subversion repository.
htpasswd -bc .htpasswd someuser somepasswd
4. Now that you have created and secured a directory for this special CGI script to live in, create a script in that directory called do_update.cgi with the following contents.
#!/bin/sh set -f echo "Content-type: text/plain; charset=iso-8859-1" echo /usr/bin/svn update /home/username/mysite.com
4b. Don’t forget to give execution privilege to your file. Only the user can have write access to it.
chmod 755 do_update.cgi
5. Finally, modify your /home/username/svn/projectname/hooks/post-commit to invoke your CGI script so your site will update after each commit.
#!/bin/bash wget --http-user=someuser --http-passwd=somepasswd -O - http://mysite.com/cgi-bin/pri/do_update.cgi
5b. Don’t forget to give execution privilege to your file. Again, only the user can have write access to it.
chmod 755 post-commit
Blocking Abuse by IP Address
September 21, 2008 — FastserveIP Abuse Detection Script
This shell script checks the access and error logs generated by apache for a particular domain, looking for the IP addresses that have connected to your site the most. It checks for IP addresses that trigger a Concurrent Connection Limit Exceeded error, which is a good sign they are an automated bot of some kind, making over 20 requests to your site at the same time. This script also checks for Internal Recursion Errors which can have very negative effects on your speed and resources, and are basically internal looping problems generally caused by improperly configured Htaccess setups.
Once the script finishes scanning your logs for those events, it automatically generates .htaccess code that you may add to your sites root .htaccess file to block those IP addresses the script identified as abusive. The only IP addresses included in the generated .htaccess file are those that have no reverse dns.
Installation
- Log in to your account using SSH
- Save this code in your $HOME directory as ip-abuse-lookup.sh
- Run pico $HOME/ip-abuse-lookup.sh
- Copy the code to the screen by clicking the right-mouse-button
- Hold down the Ctrl button and then press x to save
- Run the command dos2unix -dv $HOME/ip-abuse-lookup.sh to fix line break issues
- Run the command chmod -v 744 $HOME/ip-abuse-lookup.sh to make executable
Running the Script
From your $HOME directory (cd $HOME), run ./ip-abuse-lookup.sh to execute the program.
Example Generated .htaccess
This script will also generate code that you can place in your .htaccess file to block specific abusers.
## IP-ABUSE-LOOKUP Order Allow,Deny Allow from All Deny from 6.132.177.129 27.67.117.178 6.135.166.102 8.93.225.133 Deny from 21.194.136.15 22.120.61.3 6.252.139.246 9.64.50.83 Deny from 8.123.144.98 21.249.83.87 29.85.238.28 25.214.237.62 Deny from 22.115.130.23 13.57.156.241 14.121.4.82 6.208.172.177
ip-abuse-lookup.sh
#!/bin/sh # Version 0.2, 2008-04-20 # User-contributed script. Not sponsored by DreamHost. # Script created 2008-01-16 by AskApache ### SHELL OPTIONS set +o noclobber # allowed to clobber files set +o noglob # globbing on set +o xtrace # change to - to enable tracing set +o verbose # change to - to enable verbose debugging set -e # abort on first error
The full script is here, but the authors has an updated Ip Abuse Blocking with .htaccess page.
Apache mod_auth_digest authentication
August 12, 2008 — FastserveDigest authentication is described in RFC 2617.
Directives
# AuthDBGroupFile
# AuthDBUserFile
# AuthDBAuthoritative
# AuthDBMGroupFile
# AuthDBMUserFile
# AuthDBMAuthoritative
# AuthDigestFile
# AuthDigestGroupFile
# AuthDigestQop
# AuthDigestNonceLifetime
# AuthDigestNonceFormat
# AuthDigestNcCheck
# AuthDigestAlgorithm
# AuthDigestDomain
# Using Digest Authentication
Using Digest Authentication
Using MD5 Digest authentication is very simple. Simply set up authentication normally, using “AuthType Digest” and “AuthDigestFile” instead of the normal “AuthType Basic” and “AuthUserFile”; also, replace any “AuthGroupFile” with “AuthDigestGroupFile”. Then add a “AuthDigestDomain” directive containing at least the root URI(s) for this protection space. Example:
AuthType DigestAuthName "private area"AuthDigestDomain /private/ http://mirror.my.dom/private2/AuthDigestFile /web/auth/.digest_pw Require valid-userNote: Digest authentication is more secure than Basic authentication, but only works with supporting browsers. As of September 2004, major browsers that support digest authentication include Amaya, Konqueror, MS Internet Explorer for Mac OS X and Windows (although the Windows version fails when used with a query string — see “Working with MS Internet Explorer” below for a workaround), Mozilla, Netscape 7, Opera, and Safari. lynx does not support digest authentication. Since digest authentication is not as widely implemented as basic authentication, you should use it only in environments where all users will have supporting browsers.
Some 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:
