Linux security

User accounts

  • Since the beginning of the course, all the examples presented were run
  • using a user account.
  • A user account consists of a username and a password. This identifies the
  • user on the system and, hence, maintains security and accountability.
  • Linux also creates groupsfor each user account. A group may contain one or
  • more users, all of them sharing the same permissions.
  • The system administrator account, sometimes called the superuser, is the
  • root. This is the most important account on the system. It must be owned by
  • as a few users as possible because of the vast powers it provides.

The /etc/passwd file

  • This is one of the most important and highly protected system file. It contains various information about the user accounts on the system.
  • Each user account information is contained on a single line. A colon (:) is used to separate different fields from each other. Let’s have a quick look at each one in turn:
    • Username: the string that the user uses for identification. It is a friendly name that is chosen by the system administrator (root) to identify the user. By convention, it is all lowercase characters, it may contain numbers (but cannot start with one), special characters dash (-), udnerscore (_), and – in some distros – the dollar sign ($) at the end.
    • Password: a secret group of characters that should be known only to it’s owner. The /etc/passwd file places an x in this field, indicating that the encrypted password is stored in /etc/shadow file (more on that later).

UID and GID

  • UID: it is short for user id. This is a unique number that identifies the user account on the system. As a matter of fact, Linux security system does not care about the username of the user account; it works by examining the its UID to provide the appropriate permissions and access rights. Since there are user accounts that are reserved for system accounts, those are assigned UID numbers from 0 (which is the root account) up till 500 (they reach 1000 in some systems). The higher numbers are assigned to normal (non-system) user accounts.
  • GID: short for group id, it is the unique number that identifies a group account. A group contain one or more users that share similar access rights. The main purpose of the existence of groups is to provide certain users with access to specific files and directories while preventing others. Think of a directory on which a team of users are working. Putting those users in a group ensures that all of them will have the same permissions.

The comment and the home directory

  • The comment field normally includes the user’s real name. For example, when a username is jdoe, the real name in the comment could be John Doe. It may also contain other personal information like the phone number, address and others.
  • The home directory field contains the path to the user’s home directory. Only the user is the owner of his/her home directory. At the command line, a home directory can be referred to as tilde ~. For example, cd ~ will make you navigate to your home directory.

The default shell

  • We have mentioned before that bash is not the only shell available for Linux. There are other shells that are available for Linux like ksh, zsh, tsh and so on. The shell field contains the path to the binary file of the specific shell. For example, /bin/bash.
  • The default shell is a matter of choice. A user can change hi/her default shell.
  • Since all users (including system accounts) must have a default shell. But system accounts – by nature – do not (and should not) have login access to the system. Accordingly, the default shell of such accounts is set to /sbin/nologin. Setting the default shell to /bin/nologin prints a friendly message explaining that logins with this account are not available. Setting it to /bin/false denies login without displaying that message.

The /etc/shadow file

  • You might think that a file named /etc/passwd should be the one containing the hashed passwords of the users on the system.
  • Actually this was the case long ago. But for security reasons, and since /etc/passwd file must be readiable by all users on the system to be able to authenticate them, the hashed password was removed from that file and placed in a more secured file: /etc/shadow .This file has higher level of protection and access restrictions.
  • It contains the following information:
    • The salt: this is a random input that helps make the password more protected
    • The hash: the result of an irreversible mathematical operation. It is performed on the password and the salt combined. To authenticate a user, a hash is computed for the entered password, with the salt input added to it. If both hashes are identical the user is authenticated.
    • Password history: these are some variables that help increase user security. For example, the password must be changed after a specific number of days (configured by the system administrator).

/etc/shadow fields

  • The username: this is the username of the user and not the UID. It is what links /etc/passwd with /etc/shadow
  • The password: the salted hash of the user password. If this field contains as asterisk or an exclamation mark, this means that the account is locked.
  • Last password change: this is the date of the last password change. The UNIX timestamp is used here. UNIX timestamp is a date/time measurement method. It is the amount of time that passed since POSIX time (1/1/1970 at midnight). This field contains the number of days that passed since POSIX time.
  • The number of days till a password can be changed. This is another security measure that prevents users from changing their passwords (as per policy) and then quickly setting it back to the original one.
  • The number of days before a user must change the current password. This is sometimes referred to as password age.
  • The number of warning days before a password expires. During those days, a warning message will be displayed to the users whose account will expire soon.
  • Days between expiration and deactivation: if configured, the account can be deactivated after it’s expired. The difference is that when the account expires, the password is not erased and the account can be activated again by the system administrator or by the user logging in and changing the password. But if the account is deactivated, the password is deleted and only the system administrator can reactivate the account.
  • Expiration date: the date when the account expires, expressed as the number of days since POSIX time.
  • Special flag: this field is currently not used. It is reserved for future use.
  • Notice that some day fields may contain either -1 or 9999, which effectively means that the relevant feature is disabled
Tagged : /

Joomla Website Security

  1. Check your template’s index.php file, I’m going to guess that code was inserted there. Check what time it was modified, then go through your access logs for that time and see what requests were made. Hacking requests generally stand out.
  2. set the default permissions the files (644) and directories (755).
  3. If you want to set permissions for files and directories your host should use from root and your username the following commands:

 

find -type d -exec chmod 755 {} \;
find -type f -exec chmod 644 {} \;

 

There is a feature in Site –> Global Configuration –> Server to set all folder and file permissions at once.

 

 

 

Online Scanner:

Free and effective malware cleanup directly from your browser

http://www.bitdefender.com/scanner/online/free.html

 

This type of infection is much more common with the password however. For that reason, you should follow these steps:

1. Scan your local computer, the clients computer, and any computer from which you have accessed the account using an up to date virus scanner such as http://malwarebytes.org CRITICAL!

2. Update the cPanel/FTP password with a password that is not easily guessable. Use 12-digits and something like example (!) &G5s#!K-|%H1

3. Submit your site for a rescan using your Google Webmaster account. If you do not already have an account please follow the instructions on this page to obtain one: http://www.google.com/support/webmaster … swer=45432

4. Read the information provided below about this type of viral infection and how to further prevent it.

What are malicious iframes and what causes them?

Over the years hackers found it hard to trick people into visiting suspicious sites so they’re now targeting legit sites and using them to infect unknowing customers. In most cases an FTP account’s password is obtained through key logging malware, then legit website files are modified to distribute the malware and gather more passwords. If your PC has been infected with one of these trojans, your bank account, email accounts, and FTP accounts may no longer be secure.

What to do if you find malicious iframes on your PC?

1. Use the following online vulnerability scanner and ensure your software is up-to-date: http://secunia.com/vulnerability_scanni … ?task=load
2. Download antivirus and fully scan your PC for malcious files. Here are some free online scanners:
http://housecall.trendmicro.com/
http://www.bitdefender.com/scan8/ie.html
http://www.kaspersky.com/virusscanner
http://support.f-secure.com/enu/home/ols.shtml
3. Update all passwords that may have been obtained. Do not use old passwords, generate new ones (see above)
4. Upload older versions of the files or contact support for assistance removing the malicious iframes.

Prevention measurements

– Ensure you use the latest browser version
– Disable javascript if possible
– Use Firefox with addon “noscript” (!)
– Download and install some free antivirus software, make sure it stays updated
– Use http://www.avg.com.au/index.cfm?section … onlinescan to test suspicious links you are given in emails or find online.

Others

BACKUP & DOWNLOAD (!) your site and database! Use either your cPanel features or use Joomlapack (http://www.joomlapack.net)….whatever you use: BACKUP!

Hope this helps!

 

 

 

How can I check my Joomla! installation’s overall security and health?

1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

Project Home: http://joomlacode.org/gf/project/jts/

 

 

CHANGE JOOMLA USER NAME AND PASSWORD

 

The Owner of the file wI know this isn’t as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure “7” settings can be reset back to something more secure. For example:

Files = 644
Directories = 755

ould have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

 

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (” / “) of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

 

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

 

How do I move confidential files outside of public_html?

One challenge in Joomla! is ensuring that certain PHP files in public_html containing executable code or confidential data are protected from direct Internet access.

There are various ways to protect such files, but most are not optimal. Many users and developer groups, such as Gallery2 and Apache.org strongly recommend against keeping vulnerable files and confidential data inside public_html.

The following method seems to be the simplest and most elegant way to protect read-only files that, for whatever reason, must be stored in public_html. In this example, we protect configuration.php, perhaps the most confidential file of any Joomla! site.

Using this method, even if the Web server somehow delivers the contents of PHP files, for example due to a misconfiguration, nobody can see the contents of the real configuration file.

Directions

1. Move configuration.php to a safe directory outside of public_html and rename it whatever you want. We use the name joomla.conf in this example.

2. Create a new configuration.php file containing only the following code (See Important Notes below.):

<?php
require( dirname( __FILE__ ) . '/../joomla.conf' );

3. Make sure the new configuration.php file is not writable, so that it can not be overwritten by the Joomla! Web admin interface.

4. If you need to change configuration settings, do so manually in the relocated joomla.conf.

Important Notes!

In the above code example, do not include blank lines or any characters (including blank spaces) before the php start tag. If you do, you will very likely see the following error.

Warning: Cannot modify header information - headers already sent by (output started at
/home/xxxxx/public_html/configuration.php:2) in /home/xxxxx/public_html/index.php on line 250

Note that leaving out the PHP end tag ( ?> ) in the above code example is intentional. This ensure that any blank lines at the end of the file will NOT be interpreted as HTML, which would cause an error. Leaving the PHP end tag out is an accepted method for avoiding such conflicts. This works because the PHP interpreter automatically halts PHP interpretation at the end of every file. The only time you actually need the PHP end tag is if HTML code follows the PHP code in the same file.

See also How to adjust Joomla 1.5 defines

 

How do I block direct access to critical files using .htaccess?

  1. Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
  2. Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.
<Files .htaccess>
order allow,deny
deny from all
</Files>
<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

 

How do I recursively adjust file and directory permissions?

Using Joomla! Administration

In the Back-end, go to Site –> Global Configuration –> Server.

Using the UNIX shell

Note: The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

Notes:

  1. Test all third party extensions after changing permissions.
  2. You may need to reset write permissions to install more extensions.

 

Site Recovery

Make websites offline

Clean your Local PC from Updated Antivirus/Anti –maleware/Spyware

Change all relevant passwords: Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, Host Password and the database account.

Check raw logs: Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.

 

List recently modified files: Before making any changes to your site, generate a list of recently modified files. Here’s a php script that will list the files for you. Remove this script as soon as you have your list and don’t publish a link to it!

 

Note suspicious newly-created files: Use this list to identify new files that don’t belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.

 

Note suspicious recently-modified files: Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.

 

Check for bogus CRON Jobs: Hacked cron jobs can be setup to reinfect your site over and over again.

 

Coordinate with your host: If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.

 

Delete the entire public_html directory: This is the best way to guarantee that every potential vulnerability in that site is removed.

Delete related database records: This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.

 

Reinstall everything: Use pre-crack backups. If you don’t have good backups, go on to step 10.

 

Reset critical passwords again: You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.

 

Review security processes: Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.

 

Review backup processes: If you don’t already have one, add a dependable backup process to your site administration practices

 

Stay watchful: Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

 

 

Create Strong .htaccess

 

Restore Backup files

 

If backup is not there, Follow following things…

  1. Download Infected SITE into local
  2. Replace All Joomla Core Files/Component/Modules/Plugins files from Fresh Installation.
  3. Find the Infected Code Syntax and search using Windows Grip and check whether you have any files still infected or remaning.
  4. Test it properly in local and upload to SITES.

 

TIPS:

  1. Weekly Backup – This can happened using FTP or JoomlaPack component.
  2. Change FTP/Host/DB password  twice in month
  3. Update Security patches
  4. Check Extension and their feedback before installation.

Find exploit attempts using the *NIX shell FAQ

Potential Exploit Checking Script….

 

Links:

http://docs.joomla.org/Security_and_Performance_FAQs#Help.21_My_site.27s_been_compromised._Now_what.3F

 

How can I check my Joomla! installation’s overall security and health?

Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

 

Project Home: http://joomlacode.org/gf/project/jts/

How do I move confidential files outside of public_html?

One challenge in Joomla! is ensuring that certain PHP files in public_html containing executable code or confidential data are protected from direct Internet access.

There are various ways to protect such files, but most are not optimal. Many users and developer groups, such as Gallery2 and Apache.org strongly recommend against keeping vulnerable files and confidential data inside public_html.

The following method seems to be the simplest and most elegant way to protect read-only files that, for whatever reason, must be stored in public_html. In this example, we protect configuration.php, perhaps the most confidential file of any Joomla! site.

Using this method, even if the Web server somehow delivers the contents of PHP files, for example due to a misconfiguration, nobody can see the contents of the real configuration file.

Directions

1. Move configuration.php to a safe directory outside of public_html and rename it whatever you want. We use the name joomla.conf in this example.

2. Create a new configuration.php file containing only the following code (See Important Notes below.):

<?php
require( dirname( __FILE__ ) . '/../joomla.conf' );

3. Make sure the new configuration.php file is not writable, so that it can not be overwritten by the Joomla! Web admin interface.

4. If you need to change configuration settings, do so manually in the relocated joomla.conf.

Important Notes!

In the above code example, do not include blank lines or any characters (including blank spaces) before the php start tag. If you do, you will very likely see the following error.

Warning: Cannot modify header information - headers already sent by (output started at
/home/xxxxx/public_html/configuration.php:2) in /home/xxxxx/public_html/index.php on line 250

Note that leaving out the PHP end tag ( ?> ) in the above code example is intentional. This ensure that any blank lines at the end of the file will NOT be interpreted as HTML, which would cause an error. Leaving the PHP end tag out is an accepted method for avoiding such conflicts. This works because the PHP interpreter automatically halts PHP interpretation at the end of every file. The only time you actually need the PHP end tag is if HTML code follows the PHP code in the same file.

See also How to adjust Joomla 1.5 defines

How do I block direct access to critical files using .htaccess?

  1. Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
  2. Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.
<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

How do I recursively adjust file and directory permissions?

Using Joomla! Administration

In the Back-end, go to Site –> Global Configuration –> Server.

Using the UNIX shell

Note: The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

The Vulnerable Extensions List is a valuable source of information on what NOT to install.

http://docs.joomla.org/Vulnerable_Extensions_List

 

How do I block directory scans using .htaccess?

Directions

Add Apache rewrite rules to your .htaccess file. For example, the following will redirect all attempts to access files with names starting with, “phpMyAdmin” to index.php.

Sample Apache Rewrite Rule

RewriteRule ^/phpMyAdmin.*$ /index.php

Some Regular Expression Tips

^ Means start of filename
. Means any character other than newlines
* Means one or more of the previous character

 

How can I change PHP settings using .htaccess?

Introduction

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

Directions

1. Open the .htaccess file located in your site’s home directory, or if you don’t have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it’s own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off
php_flag allow_url_fopen off
php_flag magic_quotes_gpc on

Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.

3. Save the .htaccess file in your site’s home directory.

4. Test your site’s front end and back end.

How can I check if mod_rewrite is enabled?

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file.

     Options +FollowSymLinks
     Redirect /joomla.html http://www.joomla.org

4. Point your browser to: http://www.mysite.com/joomla.html

(Replace ‘mysite.com’ with your site’s actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a sub-domain, for example “test” you need to modify .htaccess as follows:

     Options +FollowSymLinks
     Redirect /test/joomla.html http://www.joomla.org

 

How do I switch to PHP5 using .htaccess?

Overview

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

IMPORTANT CAVEAT: One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

Requirements

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host. 2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host. 3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

Directions

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don’t have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don’t leave backups of .htaccess files in public directories.

How do I password protect directories using .htaccess?

Overview

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

Caveat (From Apache.org)

Basic authentication should not be considered secure for any particularly rigorous definition of secure. Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don’t use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

Directions

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first. Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it’s probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you’ve read the always current and official documentation at Apache.org, we’ll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don’t forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you can not use the Apache htpasswd utility, here’s a free, online script that creates the necessary files for you. You’ll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you’ll need to edit the resulting files.

.htaccess Generator: http://www.webmaster-toolkit.com/htaccess-generator.shtml

How do I restrict directory access by IP address using .htaccess?

Overview

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

Directions

  1. In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
  2. Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:
Order Deny,Allow
Deny from all
Allow from 100.100.100.100

 

  • Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.
  • Optional: You can add multiple addresses by separating them with comma’s.
100.100.100.101, 100.100.100.102

 

How do I block direct hot linking to image files using .htaccess?

Caveats

  1. Your server must allow .htaccess files for this technique to work.
  2. If you do not have a .htaccess file in your root directory, see the related FAQ first.
  3. Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
  4. Hot linked images can only be replaced by other images, not with HTML pages.
  5. As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

Directions

  1. Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
  2. Place the following code in the .htaccess file of your root directory.
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]

Explanation

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means “No Case”, which means, match upper and lower case characters. The third line allows empty referrals. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image. Block hot linking from specific domains

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?livejournal\.com/ [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means “Or Next”, as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

Display a 403 forbidden code

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]

http://joomlacode.org/gf/project/jts/

Joomla! Tools Suite (JTS) is a Joomla!
environment audit, maintenance and
diagnostic application written in PHP.
The JTS suite of tools can diagnose,
report and advise on common
installation, health and security
issues, including performing several
common performance and recovery
actions.

Tagged : / / / / / /

10 Fast and Free Security Enhancements

10 Fast and Free Security Enhancements

PC magazine.

 

Before you spend a dime on security, there are many precautions you can take that will protect you against the most common threats.

 

1. Check Windows Update and Office Update regularly (_http://office.microsoft.com/productupdates); have your Office CD ready. Windows Me, 2000, and XP users can configure automatic updates. Click on the Automatic Updates tab in the System control panel and choose the appropriate options.

 

2. Install a personal firewall. Both SyGate (_www.sygate.com) and ZoneAlarm (_www.zonelabs.com) offer free versions.

 

 

3. Install a free spyware blocker. Our Editors’ Choice (“Spyware,” April 22) was SpyBot Search & Destroy (_http://security.kolla.de). SpyBot is also paranoid and ruthless in hunting out tracking cookies.

 

4. Block pop-up spam messages in Windows NT, 2000, or XP by disabling the Windows Messenger service (this is unrelated to the instant messaging program). Open Control Panel | Administrative Tools | Services and you’ll see Messenger. Right-click and go to Properties. Set Start-up Type to Disabled and press the Stop button. Bye-bye, spam pop-ups! Any good firewall will also stop them.

 

5. Use strong passwords and change them periodically. Passwords should have at least seven characters; use letters and numbers and have at least one symbol. A decent example would be f8izKro@l. This will make it much harder for anyone to gain access to your accounts.

 

6. If you’re using Outlook or Outlook Express, use the current version or one with the Outlook Security Update installed. The update and current versions patch numerous vulnerabilities.

 

7. Buy antivirus software and keep it up to date. If you’re not willing to pay, try Grisoft AVG Free Edition (Grisoft Inc., w*w.grisoft.com). And doublecheck your AV with the free, online-only scanners available at w*w.pandasoftware.com/activescan and _http://housecall.trendmicro.com.

 

8. If you have a wireless network, turn on the security features: Use MAC filtering, turn off SSID broadcast, and even use WEP with the biggest key you can get. For more, check out our wireless section or see the expanded coverage in Your Unwired World in our next issue.

 

9. Join a respectable e-mail security list, such as the one found at our own Security Supersite at _http://security.ziffdavis.com, so that you learn about emerging threats quickly and can take proper precautions.

 

10. Be skeptical of things on the Internet. Don’t assume that e-mail “From:” a particular person is actually from that person until you have further reason to believe it’s that person. Don’t assume that an attachment is what it says it is. Don’t give out your password to anyone, even if that person claims to be from “support.”

 

 

www.BangaloreOrbit.com

 

One Stop online Portal for Bangalore and Karnataka People                                                                                 n

Tourist Destination | Pilgrims Destination | News | Forum | Games | Jobs |  Groups |

Taste of Kannada | Bangalore Darshan | Latest Event |

Tagged : / / / / / /