http://www.bumblehead.com

********************** *************************
Installing and Configuring the Ultra 10 as a Linux/Apache/PostgreSQL Server
Compiled and edited by Chris DePauw

  1. Introduction
  2. Pre-Installation
  3. Valuable Commands
  4. Apache2
  5. Psad
  6. Iptables
  7. Ssh
  8. Postgresql
  9. Proftpd
  10. Ssmtp
  11. Ddclient
  12. Bastille
  13. Maintenance

********************** *************************
01. Introduction

You might want to know why this document exists. This guide is mostly a compilation of information that is found throughout the Internet, but it contains some information that makes it unique and necessary.

This information found here is presented in a comprehensive manner. Someone with a basic knowledge of linux and bash should be able to succeed in executing the goals of this document with precise obedience.

This information (2008/2/26) is more current than most of the information that it references. While gathering this information, I found much of the content out there to be dated and misleading. This document presents that information, corrected.

You will find details here that are not found elsewhere online. There were discussions that occurred in obscure irc channels during the late hours and some experimentation happened as well. Those things produced solutions that work and are presented here.

This guide focuses its presentation on server software. Each important software has its own chapter. Follow these chapters in any order.

********************** *************************
02. Pre-Installation

There are a few things that are unique to SPARC installations and server installations. Here it is.

The only linux distributions currently supporting SPARC are Debian and Gentoo. This guide uses Gentoo but avoids being gentoo-specific.

DO NOT include PAX in your kernel. PAX is for x86. PAX is totally unnecessary on SPARC and enabling it will break your installation.

Disk-formatting rquires the creation of a sun disk label. Fdisk's auto disk-label function is terrible and you'll have to use fdisk's manual configuration. Its not hard. Fdisk requires you to input values that represent how many heads, sectors, and cylinders are on the disk.

example:

Each specific value was important once upon a time, but here, the only thing that is important is the product of these three numbers. The product, or 'complete sectors', must be less than the disk's LBA size, which is found with 'hdparm'.

example:

If hdparm reports an LBA size of '234441648' then you might input the following three values: 16, 255, 57459. The product of those numbers is 234432720. 234432720 < 234441648. Perfect.

When partitioning the disk, give generous amounts of space to /var. By default, apache and postgresql use /var to store the information that they present. You could specify another directory, I'm just letting you know that /var is the default.

Secure the server (security is covered in this document). Do not expose the server if it hasn't been hardened and secured. I hosted with a soft server once and one day all of the directories in it were rm'd except for two or three root directories that had been internally rm'd.

The APC-brand PSU's are an overwhelming favorite in the tech community. APC PSU's are officially OK for recieving electricity from non-proprietary extension cord.

********************** *************************
03. Valuable Commands

SetGID
Allow multiple users to create and share permissions for the same directories.

chmod -v 2775 /my/directory
chmod -v 3775 /my/directory

If you aren't familiar with setgid, you'll need more information before using it.
To fully understand setigd, please read a section from this book here;
link

Create users in the system:

$ useradd -m -G users,audio,wheel username
$ passwd john

NMAP,
network mapper. NMAP is good for determining what ports and services are available on a server from other machines on the network (security testing).

$nmap -P0 -O 10.0.2.10

(Note: The default option is -sS. However, when the system being scanned is running a firewall, such as iptables, it won't work, as firewalls that block icmp traffic will also block the subsequent scan and the results will be meaningless. The -P0 option disables pinging the host before scanning it, The -O (as in “oh” rather than zero) is to enable nmap’s operating system detection via the network stack fingerprint.)

link

NETSTAT
Find which ports are being used and find the associating program or PID. (note: running as the super-user or root is necessary for the program to work properly):

$ netstat -l -n -p -t -u -w
$ netstat -plant

Understanding the output from netstat is pretty simple. The first field is the protocol, and you will notice that when the protocol is udp, there is no state (as obviously udp is stateless unlike tcp). The next interesting field is the Address field. 0.0.0.0:80 means that the server will respond to any IPs on port 80, while 127.0.0.1:80 means that the server is only listening to the loop back device.

Use this, for example, if a service refuses to start because the port is already in use. This will identify processess running and the ports they are using.

link

********************** *************************
04. Apache2

default port: 80

The default apache configuration is just fine and will be operational. Configuration is handled in /etc/apache2/httpd.conf and /etc/apache2/vhosts.d/00_default_vhost.conf.

httpd.conf - specify apache's port (default is port 80).
vhost.conf - specify apache's index-page location.

To test apache2, navigate your local browser to http://localhost/. The apache insert page appears if everything is configured properly.

Relevant Apache from the Gentoo Documents
link

For security reasons, running the server as an unprivileged user and group is strongly encouraged. Create the following group and user using the following commands (as root):

$ groupadd apache
$ useradd -g apache apache

do NOT change the default ServerRoot setting.

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but also the directories and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

$ mkdir /usr/local/apache
$ cd /usr/local/apache
$ mkdir bin conf logs
$ chown 0 . bin conf logs
$ chgrp 0 . bin conf logs
$ chmod 755 . bin conf logs

********************** *************************
05. PSAD

Port Scan Attack Detector

With psad you can:

psad requires only an iptables firewall with logging enabled. To enable logging, add to the end of your firewall script:

$ iptables -A INPUT -j LOG
$ iptables -A FORWARD -j LOG

From the Gentoo Documentation:

When you start psad with the command /etc/rc.d/psad start, you actually start psad and its two helper daemons, kmsgsd and psadwatchd. kmsgsd parses out all of the iptables-related messages that the kernel receives and sends them to psad's data file /var/log/psad/fwdata. The psadwatchd daemon runs every five seconds to make sure that both psad and kmsgsd are running. If they are not, it restarts them and sends an email alerting the system administrator to this fact.

To view a status report, use the command /etc/rc.d/psad status. The report shows the amount of resources each of the daemons uses, along with information about any scans psad detects. A status report looks something like this:

[+] psadwatchd (pid: 4246) %CPU: 0.0 %MEM: 0.1
Running since: Tue Apr 5 09:45:11 2005

[+] kmsgsd (pid: 4244) %CPU: 0.0 %MEM: 0.1
Running since: Tue Apr 5 09:45:11 2005

[+] psad (pid: 4242) %CPU: 2.8 %MEM: 3.3
Running since: Tue Apr 5 09:45:11 2005
Command line arguments: [none specified]
Alert email address(es): root@test.internal root@test.internal.

From the Linux.com:
link

One interesting feature of psad is its ability to block port scans in real time. To do this, edit the configuration file and change the parameter:

ENABLE_AUTO_IDS N;

to

ENABLE_AUTO_IDS Y;

This feature is disabled by default because it is likely the port scans are coming from a spoofed IP address. However, with psad it is possible to only block an IP after a certain number of offending packets have been received by using a danger level. Danger levels are defined in the configuration file. To set a danger level for when to automatically block an IP address, set the parameter:

AUTO_IDS_DANGER_LEVEL;

to

AUTO_IDS_DANGER_LEVEL 5;

This will block an IP address after it reaches danger level 5, which occurs after 10,000 packets have been received from the same IP address.

Another feature of psad is the ability to detect application layer attacks using Snort rulesets and the iptables string match extension, by using the companion program fwsnort. fwsnort builds iptables rulesets that are equivalent to Snort's using the iptables string match extension. This works for approximately 70% of Snort rules. This option is available only if you are running a 2.4 series kernel, because the string match extension has yet to be ported to the 2.6 kernel.

psad sends email alerts to the system administrator whenever it detects suspicious activity. By default, it sends alerts whenever two or more of your ports are scanned. You can make these alerts less sensitive by changing the parameter:

PORT_RANGE_SCAN_THRESHOLD 1;

********************** *************************
06. IPTABLES

Iptables are enabled in your kernel. In case you need it, here is iptable kernel configuration information:

Kernel Configuration:

Networking --->
Networking options --->
[*] Network packet filtering framework (Netfilter) --->

Core Netfilter Configuration --->
<*> Netfilter netlink interface
   <*> Netfilter NFQUEUE over NFNETLINK interface
   <*> Netfilter LOG over NFNETLINK interface
[*] Connection tracking flow accounting
[*] Connection mark tracking support
[*] Connection tracking events (EXPERIMENTAL)
<*> Connection tracking netlink interface (EXPERIMENTAL)
<*> Netfilter Xtables support (required for ip_tables)
   <*> "connbytes" per-connection counter match support
   <*> "connmark" connection mark match support
   <*> "conntrack" connection tracking match support
   <*> "state" match support
   <*> "helper" match support

IP: Netfilter Configuration --->
<*> IPv4 connection tracking support (required for NAT)
   [*] proc/sysctl compatibility with old connection tracking
<*> IP tables support (required for filtering/masq/NAT)
   < > ECN match support
   <*> Packet filtering
     <*> REJECT target support
   <*> LOG target support
   <*> Full NAT
<*> MASQUERADE target support

"iptables" command:

iptables rules are stored in:

Configuration File:

/etc/conf.d/iptables

# /etc/conf.d/iptables

# Location in which iptables initscript will save set rules on
# service shutdown
IPTABLES_SAVE="/var/lib/iptables/rules-save"

# Options to pass to iptables-save and iptables-restore
SAVE_RESTORE_OPTIONS="-c"

# Save state on stopping iptables
SAVE_ON_STOP="yes"

Quick Configuration: Apply iptables directly without the use of scripting.

This section comes to us from documentation in the Arch Linux wiki.

This HOWTO assumes that there are currently no iptables rules set. To check this, try the command

$ iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0K packets, 0 bytes)
pkts bytes target prot opt in out source destination

If the output looks like the above (except the packet counters), there are no rules set and you are good to go. If not, reset the tables like this:

$ iptables -P INPUT ACCEPT
$ iptables -P FORWARD ACCEPT
$ iptables -P OUTPUT ACCEPT
$ iptables -F
$ iptables -X

- Setting up a single machine

- Creating necessary chains

For this basic setup, we will create two custom chains. Their meaning is explained later:

$ iptables -N open
$ iptables -N interfaces

- the INPUT chain

Every packet that is received by any network interface and has one of the local host's IP addresses in the destination header will pass the INPUT chain first. In this chain we make sure that only the packets that we want are accepted.

The first rule will accept all ICMP messages. ICMP means Internet Control Message Protocol. Some ICMP messages are very important, some are less important (like echo requests (pings)). None of them hurts, so it is generally a good idea not to block them:

# iptables -A INPUT -p icmp -j ACCEPT

The next rule will make sure that none of the traffic that belongs to already established connections will be dropped. This can be done with the state match. A package can have one of the four states ESTABLISHED, RELATED, NEW and INVALID. We want to accept all packets that are in state ESTABLISHED or RELATED, hence the name "stateful firewall":

# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

In most cases, we do not want to deny all incoming connections. That's why we set up the two custom chains open and interfaces. For now, we are adding a rule for each of them:

$ iptables -A INPUT -j interfaces
$ iptables -A INPUT -j open

Now, with the last two rules, we drop everything that hasn't been explicitly accepted above. For TCP packets, we deny the connection with a tcp-reset. Incoming UDP packets are answered with an ICMP message. This way, we imitate Linux's default behaviour:

$ iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
$ iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

All other protocols than TCP, UDP and ICMP are dropped (unless they matched the state match above). We do this by setting the policy for the INPUT chain to DROP

$ iptables -P INPUT DROP

- The FORWARD chain

For a single machine, we simply set the policy of the FORWARD chain to DROP and move on:

$ iptables -P FORWARD DROP

- The OUTPUT chain

We have no intention of filtering any outgoing traffic. This would make the setup much more complicated and requires some extra thought. In this simple case, we set the OUTPUT policy to ACCEPT.

$ iptables -P OUTPUT ACCEPT

- The interfaces chain

We use the interfaces chain to accept any traffic from trusted interfaces. The first rule is absolutely necessary:

$ iptables -A interfaces -i lo -j ACCEPT

This accepts every traffic from the loopback interface, which is necessary for many applications to work properly. You can add more interfaces here. For example, if you want to accept all incoming traffic from the interface eth0, add this rule:

$ iptables -A interfaces -i eth0 -j ACCEPT

Incoming connections on other interfaces will be denied, unless they hit another exception in the open chain.

- The open chain

The open chain contains rules for accepting incoming connections on specific ports or protocols. For example, if you want to accept ssh connections on every interface, add this rule:

$ iptables -A open -p tcp --dport 22 -j ACCEPT

To accept incoming HTTP connections on the interface ppp0:

$ iptables -A open -i ppp0 -p tcp --dport 80 -j ACCEPT

To accept all incoming tcp connections with destination ports 65000 to 65005 on interface foo:

$ iptables -A open -i foo -p tcp --dport 65000:65005 -j ACCEPT

The same is of course possible with udp:

$ iptables -A open -i foo -p udp --dport 65000:65005 -j ACCEPT

or with other protocols than tcp and udp:

$ iptables -A open -i foo -p 123 -j ACCEPT

See man iptables for more advanced rules, like matching multiple ports or protocols.

- Saving the rules

Now, the rules are ready and should be saved to your hard drive. First, we edit the configuration file /etc/conf.d/iptables:

# Configuration for iptables rules

IPTABLES=/usr/sbin/iptables

IPTABLES_CONF=/etc/iptables/iptables.rules
IPTABLES_FORWARD=0 # disable IP forwarding!!!

Now, save the rules with the command

# /etc/rc.d/iptables save

and make sure your rules are loaded when you boot by editing /etc/rc.conf:

DAEMONS=(... iptables ...)

********************** *************************
06. Ssh

default port: 22

OpenSSH consists of two parts: a client and a server. The server is run as a daemon and has its initscript in

/etc/init.d/sshd

The configuration file is at

/etc/ssh/sshd_config

Before starting up an ssh server take a look through the configuration file. One thing that you will most likely want set is PermitRootLogin no. This disables logins as root which means that in order to log in, an attacker first must login as a regular user (in the wheel group) and then su. This would require knowing 2 passwords as well as a username with su access making bruteforce attacks nearly impossible.

$ /etc/init.d/sshd start #(Gentoo specific)
$ pgrep sshd
test with
$ ssh localhost

How To Change The TCP Port On Which SSH Listens

If you are afraid of people trying to hack in on a well known TCP port, then you can change port 22 to a location that won't interfere with other applications on your system, such as port 435. This is a rudimentary precaution only, because good network scanning programs can detect SSH running on alternative ports.

What you need to do is:

  1. Use the netstat command to make sure your system isn't listening on port 435, using grep to filter out everything that doesn't have the string "435":
    $ netstat -an | grep 435
  2. No response allows us to proceed. Change the Port line in /etc/ssh/sshd_config to mention 435 and remove the # at the beginning of the line. If port 435 is being used, pick another port and try again.
  3. Restart SSH
  4. Check to ensure SSH is running on the new port:
    $ netstat -an | grep 435
    tcp 0 0 192.168.1.100:435 0.0.0.0:* LISTEN

link

********************** *************************
07. PostgreSQL

This is a very lengthy how-to that comes almost directly from the gentoo wiki. I've updated it with some fixes and imporvements. Just install postgres and go through the motions.

$ passwd postgres
New UNIX password:
Retype new UNIX password:
passwd: password updated successfully

# emerge --config =postgresql-8.x.x
for English locales.
This will install the config files and database files into : /var/lib/postgresql/data . If you want the config and data files somewhere else here is an example of how to use the directory : /data/postgresql/data
# mkdir -p /data/postgresql/data
# chown -R postgres:postgres /data/postgresql/data
# su - postgres
# initdb -D /data/postgresql/data

Then change the PGDATA to the appropriate directory

file: /etc/conf.d/postgresql

PGDATA="/data/postgresql/data"

You probably want to comment out the PGOPTS="-N 40 -B 80" line and either go with what the initdb defaults to in postgresql.conf, or set your own ( the PGOPTS="-N 40 -B 80" sets max connections to 40 and shared_buffers to 640k -- the documentation says that several tens of MB are required for production servers and that the minimum must be the greater of 128 kilobytes or #connections * 16 kilobytes. The initdb on my system defaulted these two values in postgresql.conf to 100 connections and 24MB of shared_buffers) Since lots of additional programs, that depend on or work with postgresql, expect the postgresql configuration files to be located in '/var/lib/postgresql/data' I will create a symbolic link so they work as well. This will save you lots of configuration in the future.

# mkdir -p /var/lib/postgresql
# ln -s /data/postgresql/data/ /var/lib/postgresql/

For '/etc/' Configuration users

Postgresql puts the .conf files into the PGDATA directory instead of '/etc'. For users that are used to edit their configuration files in '/etc' this will help them out.

# mkdir /etc/postgresql

For default

# ln -s /var/lib/postgresql/data/pg_hba.conf /etc/postgresql/pg_hba.conf
# ln -s /var/lib/postgresql/data/postgresql.conf /etc/postgresql/postgresql.conf

For changed PGDATA dir

# ln -s /data/postgresql/data/pg_hba.conf /etc/postgresql/pg_hba.conf
# ln -s /data/postgresql/data/postgresql.conf /etc/postgresql/postgresql.conf

Settings External Connections

File: /var/lib/postgresql/data/postgresql.conf

#------------------------ ------------------------ --------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------ ------------------------ --------------------
# - Connection Settings -
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
#port = 5432
max_connections = 100
# note: increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction). You
# might also need to raise shared_buffers to support more connections.
#superuser_reserved_connections = 2
#unix_socket_directory = ''
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal
#bonjour_name = '' # defaults to the computer name

# - Security & Authentication -

#authentication_timeout = 60 # 1-600, in seconds
ssl = false #we'll change it later
#password_encryption = on
#db_user_namespace = off

Setting Internal Connections

file: /var/lib/postgresql/data/pg_hba.conf

# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all postgres trust
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

This will ensure that all local users must provide a valid password and the password is encrypted by md5 (kerberos encryption is more secure ... but requires additional settings and 'kerberos' to be set in your USE variable). The only exception is 'postgres' user since it needs this in order to create database users and databases for you. This of course dictates to you as database administrator that ALL database users MUST have a password (which is always a good idea). But if you follow this wiki that won't be a problem. Then for external connection add the following line (provided they are ssl encrypted)

hostssl all all * md5

Logging

By default the logging is off. This is not recommended since logs are the only way to properly determine what went wrong in cases of emergency (crashes, slow performance etc). Even if you or your own (written) programs are the only users the postgresql server it is still recommended you set some kind of logging. How much to log is up to you a just keep in mind: The more you log the more likely you are to find your problem but the more time it will take to find it. Here is my default logging configuration which should suffice for most users.

In order for postgres to log to the '/var/log' directory it must first have access to it. Therefore we make a directory and make postgres its owner. You can skip this if you decided to log into (a sub directory) of your PGDATA directory.

# mkdir /var/log/pglog
# chown postgres:postgres -R /var/log/pglog/

File: /var/lib/postgresql/data/postgresql.conf

Make the following changes check also below for full details

#--------------------------- ------------------------ ------------------------
# ERROR REPORTING AND LOGGING
#--------------------------- ------------------------ ------------------------

# - Where to Log -

#log_destination = 'stderr'

# This is used when logging to stderr:
redirect_stderr = on

# These are only used if redirect_stderr is on:
log_directory = '/var/log/pglog'

log_filename = 'pgsql-%Y-%m-%d.log'

#log_truncate_on_rotation = off

#log_rotation_age = 1440

#log_rotation_size = 10240


# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'


# - When to Log -

#client_min_messages = notice

#log_min_messages = notice

#log_error_verbosity = default

log_min_error_statement = error

#log_min_duration_statement = -1

#silent_mode = off

# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
log_connections = on
#log_disconnections = off
#log_duration = off
log_line_prefix = '<%t> '

log_statement = 'ddl'
#log_hostname = off

Log Rotation

After you've decided to configure some kind of logging for Postgresql, the next step is to prevent accumulating log data from taking over all your hard disk space. Postgresql will rotate the log file but doesn't delete obsolete logs (rotate 6 weeks old logs out of existence). When you installed Gentoo you (should) have emerged logrotation to handle your syslog files. I will use this tool to rotate the logfiles of postgresql. You can also make a bash script and load it into your cron daemon however I found it cleaner to keep logrotation in one place and better for maintenance. In case you didn't install logrotation for your syslog, here is how to do it:

emerge logrotate

Main configuration file is /etc/logrotate.conf and additional logrotate files are placed in /etc/logrotate.d/. Then it is time to make our logrotation entry

File: /etc/logrotate.d/postgresql

# Compress postgresql log files
# Provided by DouweQuerty
/var/log/pglog/pglog.tar {
missingok
ifempty
rotate 7
weekly
sharedscripts
prerotate

cd /var/log/pglog/
tar -C /var/log/pglog/ -cp --remove-files --wildcards -f pglog.tar --exclude *$(date +%Y-%m-%d)* *.log
endscript
postrotate
endscript
}

This will collect (tar) all the existing logfiles, except today's logfile, before rotating them. Because the active logfile isn't touched, no reload of postgresql is needed. But we do need to create a dummy tar file else logrotation doesn't do its job.

echo "" > /var/log/pglog/pglog.tar

Then check whether it is working by forcing a logrotation:

logrotate -f /etc/logrotate.conf

Install a Procedural Language

You can install procedural languages, such as postgresql's pl/pgsql, into a template. Using the newly created template will make the procedural languages available to all databases created using that template. This is purely optional and if you don't know or want to know what templates are please skip this section. You can read this section in the future, should the need for procedural languages arise. For those who are interested, here we go: First create a template called 'template1' and include the postgresql's pl/pgsql

# su postgres
# createlang plpgsql template1

Since 'template1' will be automatically added to any new database which will be created we are all done here! If you decided to skip ahead and now want to add the 'pl/pgsql' language to an existing database here is how:

# su postgres
# createlang plpgsql MY_DATABASE

Make sure you replace MY_DATABASE with your own database's name.

# /etc/init.d/postgresql start

Time for a quick test of your newly installed postgresql server. Thus

# psql -U postgres

or, if that fails

# psql -U postgres template1

if all fails, test by

# /etc/init.d/postgresql stop
# su postgres
# postmaster -D /var/lib/postgresql/data

Then enter the following command

select current_date;

The result should look like this :

Welcome to psql 8.1.8, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

postgres=# select current_date;
date
------------
2007-04-02
(1 row)

postgres=# \q

Creating Databases

The first step in database land is creating a database. Since there are 2 ways of doing just that I will show them both. First one :

# createdb -U postgres mydb

This will create a database named 'mydb'. Second way is in the SQL interface of postgresql :

# psql -U postgres
# CREATE DATABASE mydb;
# \q

If for some reason you want to delete the database it won't surprise you there are again 2 ways of doing so. First :

# dropdb -U postgres mydb

This will drop a database named 'mydb'. Second way :

# psql -U postgres
# DROP DATABASE mydb;
# \q

When you have created a database user you can set a database owner for the database. This can be done like this

This will set the owner to 'new_owner' for the database with the name 'mydb'.

# psql -U postgres
# ALTER DATABASE mydb OWNER TO new_owner;
# \q

Second step is to create some database users. Since in the configuration we required every user (except postgres) to be authenticated by md5 we must ensure every database user has a password. Which seems the only sensible thing to do unfortunately postgresql doesn't ask for passwords by default thus we have to make it ask for passwords. Again there are two ways of database user creation and again I will show both. Here is the first one :

# createuser -U postgres –P
Enter name of role to add: joe
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE

If you want the user to be able to create databases or create more database users answer the questions differently than me. Superusers have the ability to create databases and new database users. Then time for the second way :

# psql -U postgres
# CREATE USER joe PASSWORD 'secret' NOSUPERUSER NOCREATEDB NOCREATEROLE;
# \q

If you want the user to be able to create databases remove the 'NO' in the word 'NOCREATEDB' the same goes for database user creation and superuser.

Now you know how to create database users it is time to learn how to delete them. Without more text here is how : First way :

# dropuser -U postgres joe

Second way :

# psql -U postgres
# DROP USER joe;

Getting ssl in postgresql

go back to /var/lib/postgresql/data/postgresql.conf

ssl = true

PostgreSQL has native support for using SSL connections to encrypt client/server communications for increased security. This requires that OpenSSL is installed on both client and server systems and that support in PostgreSQL is enabled at build time (see Chapter 14).

With SSL support compiled in, the PostgreSQL server can be started with SSL enabled by setting the parameter ssl to on in postgresql.conf. When starting in SSL mode, the server will look for the files server.key and server.crt in the data directory, which must contain the server private key and certificate, respectively. These files must be set up correctly before an SSL-enabled server can start. If the private key is protected with a passphrase, the server will prompt for the passphrase and will not start until it has been entered.

The server will listen for both standard and SSL connections on the same TCP port, and will negotiate with any connecting client on whether to use SSL. By default, this is at the client's option; see Section 20.1 about how to set up the server to require use of SSL for some or all connections.

For details on how to create your server private key and certificate, refer to the OpenSSL documentation. A self-signed certificate can be used for testing, but a certificate signed by a certificate authority (CA) (either one of the global CAs or a local one) should be used in production so the client can verify the server's identity. To create a quick self-signed certificate, use the following OpenSSL command:

openssl req -new -text -out server.req

Fill out the information that openssl asks for. Make sure that you enter the local host name as "Common Name"; the challenge password can be left blank. The program will generate a key that is passphrase protected; it will not accept a passphrase that is less than four characters long. To remove the passphrase (as you must if you want automatic start-up of the server), run the commands

openssl rsa -in privkey.pem -out server.key
rm privkey.pem

Enter the old passphrase to unlock the existing key. Now do

openssl req -x509 -in server.req -text -key server.key -out server.crt
chmod og-rwx server.key

to turn the certificate into a self-signed certificate and to copy the key and certificate to where the server will look for them.

If verification of client certificates is required, place the certificates of the CA(s) you wish to check for in the file root.crt in the data directory. When present, a client certificate will be requested from the client during SSL connection startup, and it must have been signed by one of the certificates present in root.crt.

When the root.crt file is not present, client certificates will not be requested or checked. In this mode, SSL provides communication security but not authentication.

The files server.key, server.crt, and root.crt are only examined during server start; so you must restart the server to make changes in them take effect.

Problem

If pg complains because it cannot find the *.crt in /var/libs/postgresql/data, then copy the *.crt there, but make sure that you change the group and file permissions to give ownership to user postgre

chown postgre:postgre *crt

and use

cp -f

to maintain file permissions, as pg will be sensitive to those

Getting ssh in postgresql

One can use SSH to encrypt the network connection between clients and a PostgreSQL server. Done properly, this provides an adequately secure network connection, even for non-SSL-capable clients.

First make sure that an SSH server is running properly on the same machine as the PostgreSQL server and that you can log in using ssh as some user. Then you can establish a secure tunnel with a command like this from the client machine:

ssh -L 3333:foo.com:5432 joe@foo.com

The first number in the -L argument, 3333, is the port number of your end of the tunnel; it can be chosen freely. The second number, 5432, is the remote end of the tunnel: the port number your server is using. The name or IP address between the port numbers is the host with the database server you are going to connect to. In order to connect to the database server using this tunnel, you connect to port 3333 on the local machine:

psql -h localhost -p 3333 postgres

To the database server it will then look as though you are really user joe@foo.com and it will use whatever authentication procedure was configured for connections from this user and host. Note that the server will not think the connection is SSL-encrypted, since in fact it is not encrypted between the SSH server and the PostgreSQL server. This should not pose any extra security risk as long as they are on the same machine.

In order for the tunnel setup to succeed you must be allowed to connect via ssh as joe@foo.com, just as if you had attempted to use ssh to set up a terminal session.

Finish and Start

After you have configured postgresql it is time to fire it up :

#/etc/init.d/postgresql start

The following command will ensure that postgresql is loaded at boot

# rc-update add postgresql default

link
link
link

***********************************************
08. ProFTP

default port: 21

you may beginby using the example conf file

$ cd /etc/proftpd #or /etc/proftpd/proftpd.conf
$ cp proftpd.conf.sample proftpd.conf
$ vim proftpd.conf

# Set the user and group under which the server will run.
User proftp
Group proftp

gentoo will have done this for you already, but here it is anyway...

$ adduser proftpd
$ groupadd proftpd

$ vim proftpd.conf
ServerType standalone
#or
ServerType inetd
#for a smaller page, use inetd

File: /etc/xinetd.d/proftpd

service proftpd
{
...
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#And from two remote locations
only_from = 10.1.1.2 sampleconfig.com
#allow from anywhere
only_from = 0.0.0.0
...
}

#Fast logins
UseReverseDNS off
IdentLookups off

Passive Mode

If you don't set PassivePorts directive, your proftpd will be probably unaccessable from internet, because most clients deny incoming connections. So set ports for passive mode:

PassivePorts min-pasv-port max-pasv-port

Run something like this:

iptables -A INPUT -p tcp -m multiport --destination-ports min-pasv-port:max-pasv-port -j ACCEPT

or you can use something like this:

#IANA-registered ephemeral port range of 49152-65534 for passive transfers
iptables -A INPUT -p tcp -m tcp --dport 49152:65534 --syn -j ACCEPT

and save your iptables state:

/etc/init.d/iptables save

and restart your iptables state:

/etc/init.d/iptables restart

# rc-update add proftpd default
# /etc/init.d/proftpd start

this setup probably doesn't allow access to postgresql, but that's ok because access may be gained via ssh

File /var/lib/iptables/rules-save

-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

( and for passive modes, you will have to add this line: )

-A INPUT -p tcp -m tcp --dport 49152:65534 --syn -j ACCEPT

********************** *************************
09. Ssmtp (not necessary to configure)

Extremely simple MTA to get mail off the system to a Mailhub

To make things look better when you recive emails from root you can edit root's name to something else. However this is completely optional and not needed to make ssmtp work properly.

$ nano /etc/passwd

and change:

root:x:0:0:root:/root:/bin/bash

to:

root:x:0:0:admin:/root:/bin/bash

or simply do:

# usermod -c 'admin' root

File: /etc/ssmtp.conf

# /etc/ssmtp.conf -- a config file for sSMTP sendmail.

# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=

# The place where the mail goes. The actual machine name is required
# no MX records are consulted. Commonly mailhosts are named mail.domain.com
# The example will fit if you are in domain.com and your mailhub is so named.
# This should be your remote smtp email server info

mailhub=smtp.broadband.rogers.com

# Example for SMTP port number 2525
# mailhub=mail.your.domain:2525
# Example for SMTP port number 25 (Standard/RFC)
# mailhub=mail.your.domain
# Example for SSL encrypted connection
# mailhub=mail.your.domain:465
# For GMAIL users: mailhub=gmail.smtp.com:587

# Where will the mail seem to come from?
rewriteDomain=smtp.broadband.rogers.com

# The full hostname
# Gentoo bug #47562
# Commenting the following line will force ssmtp to figure
# out the hostname itself.
# hostname should be your remote email account

hostname=@rogers.com

# auth user must be your remote email username
AuthUser=

# AuthPass must be your remote email password
AuthPass=

# Set this to never rewrite the "From:" line (unless not given) and to
# use that address in the "from line" of the envelope.
FromLineOverride=YES

# Use SSL/TLS to send secure messages to server.
#UseTLS=YES

# With gmail you should use this option insted of the 'UseTLS=YES'
#UseSTARTTLS=YES

# Use SSL/TLS certificate to authenticate against smtp host.
#UseTLSCert=YES

# Use this RSA certificate.
#TLSCert=/etc/ssl/certs/ssmtp.pem

File: /etc/ssmtp/revaliases

# sSMTP aliases
#
# Format: local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.

# with the following example all emails sent from root; when recived
# will show in the from line: From: admin
# in this case is the box name in /etc/conf.d/hostname
# and the domainame in /etc/resolve.conf

root:gentoo@freethinker.net:smtp.broadband.rogers.com

# if a regular user sends an email without a costumized format then
# then the from line would show: From: john@smtp.broadband.rogers.com

# if you wish to have your own regular user sending emails with a better
# looking format like root has, then add something like this for each other user

jack:jack@freethinker.net:smtp.broadband.rogers.com

# what ever you put here <:jack@freethinker.net:> can be costumized
# by your own taste. For a regular user there is no need to change
# anything in /etc/passwd

Testing:

# mail -s "testing ssmtp" someguy@some-isp.com
- press enter and you can type whatever you wish as the message body
- press enter and then ctrl+D
- press enter again and the email should be sent
- check your remote mailbox

********************** *************************
10. Ddclient

Read the directions in the configuration file and make the necessary changes

/etc/ddclient/ddclient.conf

When you're done, testing ddclient locally

$ perl /usr/sbin/ddclient -noquiet -debug -daemon=0 -verbose

********************** *************************
11. Bastille

Bastille is a terrific script that will harden your system for you. It presents information about security problems, one after another, and then presents a remedy for each potential problem. Bastille will auto-implement the directives that it recommends with the user's approval.

********************** *************************
12) Maintenance

Information intended for this section is pending.

^^ To Top