Secure your Server! -Free Host,Free Hosting,Web Hosting,Free Web Hosting,Domain,Domain Name,Domain Name Forum,Web Hosting Forum- Web Hosting Tutorials

04-01-2008, 10:00

SSANZ

Member

Join Date: Mar 2008

Posts: 57

Trader Rating: (0)

Points: 5 (Donate)
5 F$/Referral Refer Friends

Secure your Server!

Quote:

Here are 20 things you can do to make your apache configuration more secure.

Disclaimer: The thing about security is that there are no guarantees or absolutes. These suggestions should make your server a bit tighter, but don't think your server is necessarily secure after following these suggestions.

Additionally some of these suggestions may decrease performance, or cause problems due to your environment. It is up to you to determine if any of the changes I suggest are not compatible with your requirements. In other words proceed at your own risk.
First, make sure you've installed latest security patches

There is no sense in putting locks on the windows, if your door is wide open. As such, if you're not patched up there isn't really much point in continuing any longer on this list. Go ahead and bookmark this page so you can come back later, and patch your server.
Hide the Apache Version number, and other sensitive information.

By default many Apache installations tell the world what version of Apache you're running, what operating system/version you're running, and even what Apache Modules are installed on the server. Attackers can use this information to their advantage when performing an attack. It also sends the message that you have left most defaults alone.

There are two directives that you need to add, or edit in your httpd.conf file:

ServerSignature Off
ServerTokens Prod

The ServerSignature appears on the bottom of pages generated by apache such as 404 pages, directory listings, etc.

The ServerTokens directive is used to determine what Apache will put in the Server HTTP response header. By setting it to Prod it sets the HTTP response header as follows:

Server: Apache

If you're super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security (see below).
Make sure apache is running under its own user account and group

Several apache installations have it run as the user nobody. So suppose both Apache, and your mail server were running as nobody an attack through Apache may allow the mail server to also be compromised, and vise versa.

User apache
Group apache

Ensure that files outside the web root are not served

We don't want apache to be able to access any files out side of its web root. So assuming all your web sites are placed under one directory (we will call this /web), you would set it up as follows:

<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>
<Directory /web>
Order Allow,Deny
Allow from all
</Directory>

Note that because we set Options None and AllowOverride None this will turn off all options and overrides for the server. You now have to add them explicitly for each directory that requires an Option or Override.

Turn off directory browsing

You can do this with an Options directive inside a Directory tag. Set Options to either None or -Indexes

Options -Indexes

Turn off server side includes

This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes

Options -Includes

Turn off CGI execution

If you're not using CGI turn it off with the Options directive inside a Directory tag. Set Options to either None or -ExecCGI

Options -ExecCGI

Don't allow apache to follow symbolic links

This can again can be done using the Options directive inside a Directory tag. Set Options to either None or -FollowSymLinks

Options -FollowSymLinks

Turning off multiple Options

If you want to turn off all Options simply use:

Options None

If you only want to turn off some separate each option with a space in your Options directive:

Options -ExecCGI -FollowSymLinks -Indexes

Turn off support for .htaccess files

This is done in a Directory tag but with the AllowOverride directive. Set it to None.

AllowOverride None

If you require Overrides ensure that they cannot be downloaded, and/or change the name to something other than .htaccess. For example we could change it to .httpdoverride, and block all files that start with .ht from being downloaded as follows:

AccessFileName .httpdoverride
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>

Run mod_security

mod_security is a super handy Apache module written by Ivan Ristic, the author of Apache Security from O'Reilly press.

You can do the following with mod_security:

* Simple filtering
* Regular Expression based filtering
* URL Encoding Validation
* Unicode Encoding Validation
* Auditing
* Null byte attack prevention
* Upload memory limits
* Server identity masking
* Built in Chroot support
* And more

Disable any unnecessary modules

Apache typically comes with several modules installed. Go through the apache module documentation and learn what each module you have enabled actually does. Many times you will find that you don't need to have the said module enabled.

Look for lines in your httpd.conf that contain LoadModule. To disable the module you can typically just add a # at the beginning of the line. To search for modules run:

grep LoadModule httpd.conf

Here are some modules that are typically enabled but often not needed: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.
Make sure only root has read access to apache's config and binaries

This can be done assuming your apache installation is located at /usr/local/apache as follows:

chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache

Lower the Timeout value

By default the Timeout directive is set to 300 seconds. You can decrease help mitigate the potential effects of a denial of service attack.

Timeout 45

Limiting large requests

Apache has several directives that allow you to limit the size of a request, this can also be useful for mitigating the effects of a denial of service attack.

A good place to start is the LimitRequestBody directive. This directive is set to unlimited by default. If you are allowing file uploads of no larger than 1MB, you could set this setting to something like:

LimitRequestBody 1048576

If you're not allowing file uploads you can set it even smaller.

Some other directives to look at are LimitRequestFields, LimitRequestFieldSize and LimitRequestLine. These directives are set to a reasonable defaults for most servers, but you may want to tweak them to best fit your needs. See the documentation for more info.
Limiting the size of an XML Body

If you're running mod_dav (typically used with subversion) then you may want to limit the max size of an XML request body. The LimitXMLRequestBody directive is only available on Apache 2, and its default value is 1 million bytes (approx 1mb). Many tutorials will have you set this value to 0 which means files of any size may be uploaded, which may be necessary if you're using WebDAV to upload large files, but if you're simply using it for source control, you can probably get away with setting an upper bound, such as 10mb:

LimitXMLRequestBody 10485760

Limiting Concurrency

Apache has several configuration settings that can be used to adjust handling of concurrent requests. The MaxClients is the maximum number of child processes that will be created to serve requests. This may be set too high if your server doesn't have enough memory to handle a large number of concurrent requests.

Other directives such as MaxSpareServers, MaxRequestsPerChild, and on Apache2 ThreadsPerChild, ServerLimit, and MaxSpareThreads are important to adjust to match your operating system, and hardware.
Restricting Access by IP

If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 176.16 network:

Order Deny,Allow
Deny from all
Allow from 176.16.0.0/16

Or by IP:

Order Deny,Allow
Deny from all
Allow from 127.0.0.1

Adjusting KeepAlive settings

According to the Apache documentation using HTTP Keep Alive's can improve client performance by as much as 50%, so be careful before changing these settings, you will be trading performance for a slight denial of service mitigation.

KeepAlive's are turned on by default and you should leave them on, but you may consider changing the MaxKeepAliveRequests which defaults to 100, and the KeepAliveTimeout which defaults to 15. Analyze your log files to determine the appropriate values.
Run Apache in a Chroot environment

chroot allows you to run a program in its own isolated jail. This prevents a break in on one service from being able to effect anything else on the server.

It can be fairly tricky to set this up using chroot due to library dependencies. I mentioned above that the mod_security module has built in chroot support. It makes the process as simple as adding a mod_security directive to your configuration:

SecChrootDir /chroot/apache

There are however some caveats however, so check out the docs for more info.

http://www.petefreitag.com/item/505.cfm

__________________
Server Systems Administration NZ
SSANZ.NET | Server Security | Hosting Systems
Experienced, Professional & Available 24/7

04-01-2008, 10:02

SSANZ

Member

Join Date: Mar 2008

Posts: 57

Trader Rating: (0)

Points: 5 (Donate)
5 F$/Referral Refer Friends

Quote:

security system is perfect and it is always good to have some forms of intrusion detection just incase somebody does get in you can be notified. Do not immediatly get worried if in an email you get a positive, many of them are false and from upgrades. I would first suggest running "rkhunter -c" from ssh and looking at the errors. If it is a few bad binaries you should check to see what was updated recently. If you have a rootkit detected you should start to worry because it is very uncommon for a false positive on a rootkit or trojan.

Download and unzip rkhunter
-----command-----
cd /usr/local/src/
wget http://downloads.rootkit.nl/rkhunter-1.2.8.tar.gz
tar -zxf rkhunter-1.2.8.tar.gz
cd rkhunter
-----command-----

Install it
-----command-----
./installer.sh
-----command-----

Now create a cronjob so it will email you with notifications to the root mailbox:
-----command-----
crontab -e
-----command-----

Now the crontab is going to be created. The first line is an update function so that you can be assured your rkhunter has the latest rules before it scans your system. The second line will run the actual scan an email root the results. At the bottom add the following line
10 0 * * * /usr/local/bin/rkhunter --update > /dev/null 2>&1
25 0 * * * /usr/local/bin/rkhunter -c --nocolors --cronjob --report-mode --createlogfile --skip-keypress --quiet

Press control x to save

http://www.eth0.us/rkhunter

Quote:

A firewall is a very good idea for a server. Though many people think that a firewall is instant protection that will do everything it really is not. A firewall will help prevent some things but it is not going to stop everything. It is just one piece of the security network that is being woven. I recommend advanced protection firewall (APF) by rfxnetworks. APF will block unused outgoing and incoming ports. It can also be configured to use information from some block lists. The below port list will work for cPanel. For the other control panels you will need to add in the administration ports.

http://www.rfxnetworks.com/apf.php

-----command-----
cd /usr/local/src
wget http://rfxnetworks.com/downloads/apf-current.tar.gz
tar -zxf apf-current.tar.gz
cd apf-0.*
./install.sh
-----command-----

Now edit config file
-----command-----
pico -w /etc/apf/conf.apf
-----command-----

Scroll down to the "Common ingress (inbound) TCP ports section. At this point you need to find the correct configuration for your control panel.

-----cPanel -----
IG_TCP_CPORTS="20,21,22,25,26,53,80,110,143,443,465,993,995,2082, 2083,2086,2087,2095,2096"
IG_UDP_CPORTS="21,53,873"

EGF="1"
EG_TCP_CPORTS="21,22,25,26,27,37,43,53,80,110,113,443,465,873,208 9"
EG_UDP_CPORTS="20,21,37,53,873"

----Ensim -----
IG_TCP_CPORTS="21,22,25,53,80,110,143,443,19638"
IG_UDP_CPORTS="53"

EGF="1"
EG_TCP_CPORTS="21,22,25,53,80,110,443"
EG_UDP_CPORTS="20,21,53"

----Plesk -----

IG_TCP_CPORTS="20,21,22,25,53,80,110,143,443,465,993,995,8443"
IG_UDP_CPORTS="37,53,873"

EGF="1"
EG_TCP_CPORTS="20,21,22,25,53,37,43,80,113,443,465,873,5224"
EG_UDP_CPORTS="53,873"

Save the file and start apf via.
-----command-----
apf -s
-----command-----

If everything still works then edit the config file and turn dev mode off. Make sure you can start a new ssh session before changing dev mode off. If you are kicked out you need to go back and look at what caused the problem!
DEVEL_MODE="0"

Now restart APF
-----command-----
apf -r
-----command-----

http://www.eth0.us/apf

Quote:

Miscellaneous system tweaks

In this guide I am going to go over some basic system tweaks that will help the security of your server. None of are that big of a deal but every little bit helps secure your server more.

Updated Feb 18 to include enabling syncookies

The first thing we are going to do is to enable tcp_syncookies by simply typing the following command.

-----command-----
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
-----command-----

For an explanation of syncookies please refer to this website: http://cr.yp.to/syncookies.html Basically it will allow the server to distinguish SOME legitimate connections from those that are meant to be malicous. It will help with a few different types of DOS style attacks.

Next we are going to do is harden resolv.conf because if improperly configured it can be used to spoof or create a DOS attack. First go ahead and open up the config file:

-----command-----
pico -w /etc/resolv.conf
-----command-----

You should see something like "nameserver xxx.xxx.xxx.xxx" and maybe "search xxx.com". The important thing is that 127.0.0.1 is NOT listed. At the top you should have your servers internet ip address. This will function basically the same as 127.0.0.1 as many servers were configured with but it is less prone to attacks. You can also remove the search line as it is not needed. Once you are done save out of the config and you are all done.

Next we will look at the /etc/hosts to ensure that it is properly setup and remove additional entries.

-----command-----
pico -w /etc/hosts
-----command-----

You should only have 2 lines listed. One of them should be 127.0.0.1 and to the right of it should be localhost. The second line should have yout servers internet ip and to the right of it should be your servers hostname beside your servers full hostname + domainname (example hostname.domain.com and hostname). If you have any entires that are still there you can go ahead and remove them as they are not needed. Save out and you are done.

Next we will secure sshd.

-----command-----
pico -w /etc/ssh/sshd_config
-----command-----

Locate the line with "Protocol" in it and change it so that it reads "Protocol 2". This will let ssh only connect on protocol 2 which is more secure and is compatible with any modern client. If for some reason your current client does not support protocol 2 Putty is free and supports it.

Another very good option is to disable root logins. **NOTE** If you do this you need to make sure that you have added a user to the wheel group and have ensured that they are able to "su -" root. Do not turn this feature on without testing that you can first login as another user and gain root access, you have been warned! Look for "PermitRootLogin" and change it to read "PermitRootLogin no".

Save and restart sshd via "service sshd restart".

Many php exploit scritps use common *nix tools to download rootkits or backdoors. By simply chmod'ing the files so that no none-wheel or root user can use them we can eliminate many possible problems. The downside to doing this is that shell users will be inconvenienced by not being able to use the the commands below. This may cause some problem if your users are trying to use commands such as wget which is very popular with shell users. If you use mod_security these programs should be blocked out from access to apache which is the main concern.

-----command-----
chmod 750 /usr/bin/rcp
chmod 750 /usr/bin/wget
chmod 750 /usr/bin/lynx
chmod 750 /usr/bin/links
chmod 750 /usr/bin/scp
-----command-----

http://www.eth0.us/node/6

__________________
Server Systems Administration NZ
SSANZ.NET | Server Security | Hosting Systems
Experienced, Professional & Available 24/7

04-01-2008, 10:02

SSANZ

Member

Join Date: Mar 2008

Posts: 57

Trader Rating: (0)

Points: 5 (Donate)
5 F$/Referral Refer Friends

Quote:

Php by nature is unfortunatly very insecure by default. There are many ways to help make it more secure for a shared hosting enviroment by running modules like mod_security. Another way to do this is by disabling the actual functions that many of these exploits call on. This can be done by simply editing the php.ini and restarting apache. Though you should not have any trouble with the disabled functions if webpages do start to have problems you can always add the function back. Most times you will get an error on a webpage that will tell you exactly which is causing the problem.

Updated August 9th to include even more php functions to disable.

First we need to locate the php.ini file.
-----command-----
locate php.ini
-----command-----

For cPanel the correct file is /usr/local/lib/php.ini. The standard location for most other servers is /etc/php.ini. Go ahead and open the php.ini file.

-----command-----
pico -w /etc/php.ini
-----command-----

or for cPanel
-----command-----
pico -w /usr/local/lib/php.ini
-----command-----

Scroll down until you see "disabled_functions" ;. Go ahead and comment the line out with a ";" and replace it with the following:

disable_functions = "system,exec"

Though not for everybody you can also take a more extreme step and disable even more php functions. In a shared hosting enviroment this may be too much but it is worth a try. If a user complains of trouble with a photo gallery make sure they are using GD and not imagemagik. If they are using GD they can manipulate images via php, imagemagik requires running external commands. Only add the following if you are sure of what you are doing! If you have any trouble simply remove them and restart apache. Here are the commands that may work for you:

disable_functions = "exec,system,passthru,readfile,shell_exec,escapeshe llarg,escapeshellcmd,proc_close,proc_open,ini_alte r,dl,popen,parse_ini_file,show_source,curl_exec"

Now go ahead save and restart apache. To change what is disabled simply remove the function that you want to be running. In my opinion the most important functions to keep disabled are the system and exec functions as they tend to cause the most problems and are used for many php exploits.

http://www.eth0.us/php

__________________
Server Systems Administration NZ
SSANZ.NET | Server Security | Hosting Systems
Experienced, Professional & Available 24/7

04-01-2008, 10:05

SSANZ

Member

Join Date: Mar 2008

Posts: 57

Trader Rating: (0)

Points: 5 (Donate)
5 F$/Referral Refer Friends

Quote:

Introduction: What is Tripwire

Tripwire is a program that helps Linux Administrators detect "unauthorized activity" on their computers by creating a database of all the files on the computer, including information about each file's size and last modification date. The Administrator sets up regular times to check the files on the computer against the records in the database and uses the generated information to determine if any of those changes require further investigation.

Setting up Tripwire

Starting point: you have a recent Linux distribution loaded on your computer, and root access to it.

Tripwire comes already loaded (but not installed) on RedHat Linux beginning with version 7.1.

Supplemental research:

man tripwire
tuxslare.org/docs/tripwire.shtml

Setting up tripwire is a multi-step process (the following are internal links):

* Essential Preparation for First Run (choose passwords, edit configuration file)
* Initial Installation (create passwords, write binary scripts)
/etc/tripwire/twinstall.sh
* Database Initialization (compare your file system with the defaults in sample files)
tripwire --init same as tripwire -m -i
* Generate a List of Errors
tripwire --check same as tripwire -m c
* Edit Policy File (manually adjust the policy file to correctly reflect the architecture of the files on your computer)
* Update Policies (creates a binary file to be used by tripwire from the text policy file)
tripwire --update-policy -Z low /etc/tripwire/twpol.txt
same as tripwire -m p -Z low /etc/tripwire/twpol.txt
* Additions, Modifications, Customization (tweak policy and configuration files to your special needs)
tripwire --update-policy -Z low /etc/tripwire/twpol.txt
same as tripwire -m p -Z low /etc/tripwire/twpol.txt
and possibly
tripwire --test --email user@domain.com
same as tripwire -m t -e user@domain.com

Essential Preparation before the First Use of Tripwire
You need to be root to set up tripwire.

In the tripwire directory:
cd /etc/tripwire
you will find both the default configuration file: twcfg.txt; and the default policy file: twpol.txt. During the installation process, (./twinstall.sh), these text files will be used to create binary files. The tripwire utility uses the binary files for database checking rather than plain text files, for security reasons. If you make incorrect edits to either of the text files, you will have to restore from back-up or tripwire will not be able to create its database.

You should make a modification to the configuration file before installing tripwire. Make a copy first, of course.

cp twcfg.txt twcft_original.txt

Now change:

LOOSEDIRECTORYCHECKING =false
to
LOOSEDIRECTORYCHECKING =true

This change is necessary to prepare for the first time the script is run because whatever is on your computer will not match the default sample file exactly. After the install is successfully completed and the policy file edited, LOOSEDIRECTORYCHECKING should be restored to "false".

Edits to the policy file, twpol.txt, are trickier. It might be best to initialize tripwire without making any changes to this file the first time. However, if your installation hangs, or takes more than a couple of hours and if you have multiple error messages about missing files in the same directory, terminate the process Control-c. Find those files on your computer and correct the directory structure in twpol.txt and rerun your first installation. If, on general examination, you already know that your computer's directory structure is different from the mapping in twpol.txt, then correct that mapping now. Pay special attention to punctuation (commas, parentheses, brackets) in this file. Adding a comma where it doesn't belong or removing one where it does could make it unrunnable.

I recommend not writing any additional file listings nor mailing instructions to the policy file, twpol.txt, until after the first run. The longer you have waited since you first installed RedHat before running tripwire for the first time, the longer the process will take. If you have an older computer, running tripwire may use a large percentage of its resources.

You are going to be asked to create 2 passwords ('keyfile passphases'):

1. a site keyfile passphrase (used for exits to configuration and policy files)
2. and a local keyfile passphrase (used to run the tripwire utility)

These need to be well-formed passwords. They will be used to 'digitally sign' files that tripwire creates and to verify the origin and integrity of files.

During the install, you must re-enter the site passphrase to create the default configuration file and then the policy file (which lists which files you want "protected"). The text copy of the configuration file twpol.txt may now be edited and the updates made. I recommend keeping a copy of the old twpol.txt file, renamed.

Initial Installation
Run the install script:

./twinstall.sh

This script will require both your passwords and will create binary files (tw.cfg and tw.pol) from the text files (twcfg.txt and twpol.txt).

Database Installation
This next step produces the initial checksum database for your file system. Warning, this command will take a while to process (usually less than an hour):

tripwire --init same as tripwire -m -i

You will need to enter your local key passphrase. File system error warnings will be printed when a file is either missing or when the directory path is different from what the sample policy file, twpol.txt, expects. The checksum database will be written to

/var/lib/tripwire/host.twd (where "host" is your hostname)

The files that tripwire writes into /var/lib/tripwire and /var/lib/tripwire/reports are binary files.

Make sure this file exists before going further. If the file has not been created, you will need to figure out what went wrong, make whatever modifications are necessary and rerun your installation, and configuration. Also, if the initialization process takes a long time and doesn't seem to be progressing, there might be a problem. One good way to troubleshoot this process is by running the --init command in the verbose mode.

tripwire -m i -v

Generate a List of Errors
You can use either the error messages generated by the output from the installation (unless you used verbose mode), or this command:

tripwire --check same as tripwire -m c

to generate a list of errors. Use the error list to assist your manual editing of the policy file (remember to make a backup copy before editing). The tripwire -m c command may also take some time to complete, but less time than tripwire -m i did.

Edit Policy File
Search for the files on your computer that tripwire could not find. If several of them all have a similar directory path, it is a good bet that the files are all together in a slightly different path. Also, unless you have installed all the options that came along with your version of RedHat, there is a good chance that you won't have all the files that the original sample policy file, twpol.txt is trying to find. If those files aren't on your computer, you can comment out the lines that reference them from your policy file.

cp /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.bak
vi /etc/tripwire/twpol.txt

Update Policies
After editing the text version of your policy file, twpol.txt, you will want to write those changes to the binary database so they will be used the next time you run tripwire --check.

tripwire --update-policy -Z low /etc/tripwire/twpol.txt
same as tripwire -m p -Z low /etc/tripwire/twpol.txt

You will be asked for your local passphrase and then your site passphrase. Notice the -Z low switch on this command. If you don't use this option, tripwire will operate in high security mode, which will result in a report being generated, but an error message at the end of the report will inform you that the (binary) policy file has not been updated.
Policy update failed: policy and database files were not altered.

Repeat the Generate List of Errors, Edit Policies and Update Policies as many times as required to remove all errors. If Update Policies does not work, you can try re-installing twinstall.sh.

When you are free of errors, you can restore the twcfg.txt from:

LOOSEDIRECTORYCHECKING =true
to
LOOSEDIRECTORYCHECKING =false

Use the update-policy command after restoring twcfg.txt.

tripwire --update-policy -Z low /etc/tripwire/twpol.txt
same as tripwire -m p -Z low /etc/tripwire/twpol.txt

Additions, Modifications, Customization
There are other edits you might want to make on your policy file: For example, add your email address to the file to get notices about severe file changes in your mailbox. Use the following command to test emailing from your tripwire utility:

tripwire --test --email user@domain.com
same as tripwire -m t -e user@domain.com

To substitute your hostname for "localhost" find this line:

HOSTNAME=localhost;

You might also want to add more directories to the list of frequently updated directories that should not have permissions or owners changed frequently. For those above changes, you will want to edit the policy file, and then run:

tripwire --update-policy -Z low /etc/tripwire/twpol.txt
same as tripwire -m p -Z low /etc/tripwire/twpol.txt

Using Tripwire for Security

(the following are internal links):

* Periodic Checks (to inform yourself about unauthorized activity)
tripwire --check same as tripwire -m c
* Regular Updates (to readjust your database after you have made changes to your filesystem) tripwire --update -Z low same as tripwire -m u -Z low
* Tips (recommendations to improve utilization)

Periodic Checks
Installing and configuring tripwire doesn't improve your security unless you follow up with periodic checks. You will need to decide how frequently to run tripwire checks.

tripwire --check same as tripwire -m c

Anacron may already be set up to mail tripwire checks to you (root). If it is, then you (root) have already been receiving emails to inform you that tripwire has not yet been configured (until now). I was strangely surprised when, although there were no email instructions in my policy file twpol.txt, I received emails about tripwire from anacron. After I configured tripwire, tripwire check reports were mailed to me (root) daily, without my having to set up a cron job.

If anacron is not sending you tripwire checks by default, decide if you want your reports to be written to a file or sent in email, and if the checks should be automated by cron. Get accustomed to looking at the reports and following up on a few of the changes that are noted, so that you become familiar with your normal patterns of changes and can determine if any of the changes are unauthorized.

Regular Updates
Along with periodic checks, you will also need to do regular updates to keep your database current with your file system. Do the checks and examine the before making updates. Perform updates regularly (determine your schedule) and also after making any major changes to the file architecture.

tripwire --update -Z low same as tripwire -m u -Z low

This command will compare your database against your current file system and then launch an editor so that you can choose to make changes to your database.

If you try this command but get an error message about a missing report file, the reason is most likely that the last check was not run immediately prior to the update. The report file in the /var/lib/tripwire/report directory is named by hostname, then date (yyyymmdd) then time. If you have recently run a check and want the update to proceed using your most recent report file, then use the -r option and provide the report filename that you want the update to use.

tripwire --update -Z low --twrfile host-yyyymmdd-tttttt.twr same as tripwire -m u -Z low -r host-yyyymmdd-tttttt.twr

Tips
Notice that when you ran

tripwire --check or tripwire -m c

you were not prompted for a passphrase. This was done intentionally so that the command could be run as a cron job without the need of storing your passphrases somewhere in plain text.

It is a very good idea to run tripwire --check regularly and have the results printed to a file or sent to you in an email. It is also recommended that COPIES of these files:

* /var/lib/tripwire/host.twd
* /etc/tripwire/tw.pol
* /etc/tripwire/tw.cfg
* /etc/tripwire/twpol.txt
* /etc/tripwire/twcfg.txt

be stored on separate machine or removable media. It is pretty safe to store the originals on your own computer, as long as you run checks before running updates. The binary files cannot be easily tampered with without tripwire complaining. The plain text files are easier to tamper with, which is why tripwire runs checks from the binaries and not the plain text files.

If you pass a new policy filename to the tripwire --update-policy command, you might have difficulty getting tripwire --check to accept the new filename. If you get into a situation like this, copy the new file into the old name, and run tripwire --init and stick with the original policy filename twpol.txt.

http://www.alwanza.com/howto/linux/tripwire.html

__________________
Server Systems Administration NZ
SSANZ.NET | Server Security | Hosting Systems
Experienced, Professional & Available 24/7

04-16-2008, 12:25

aleeonline

Senior Member

Join Date: Aug 2005

Posts: 197

Trader Rating: (0)

Points: 0 (Donate)
5 F$/Referral Refer Friends

great post ..

security is the basic thing related to servers, and u were simply awesome at teaching it..

very dedicated member, keep such helping coming..

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Server Management - Server Security - Hosting Support -[1 week free trial!]-	SSANZ	Other Offers and Requests	0	03-30-2008 00:37
What Type of Web Hosting is Best For You	admans	Web Hosting Forum	12	12-26-2007 11:55
AHOSING.BIZ DEDICATED SERVER SPECIALS** $189 Intel Pentium Core2Duo E6600 2.4Ghz*	Ahosting.biz	Paid Web Hosting Offers And Requests	0	12-08-2007 02:32
MSSQL or MySQL?	loon	Web Hosting Forum	7	01-29-2007 15:11
Connecting to your SQL Database using Enterprise Manager!	admans	Web Hosting Forum	0	08-09-2005 12:58