The following T-SQL code will generate a list of supported collations on your server.
SELECT name, description FROM ::fn_helpcollations();
// CrashMAG
All posts by crashmag
Resetting the root/postgres password for PostgreSQL
The following is required to reset the root/postgres user password for PostgreSQL. The distribution used in my example is CentOS 5.5 and PostgreSQL 8.4.
Note: By default there’s no password for the postgres user.
In step 2 and 5 you will most likely not be using “ident” but rather “password” or “md5″.
1. Shut down PostgreSQL
# service postgresql stop
2. Reset the authentication mechanism (assuming defaults are already being used)
Edit the /usr/lib/pgsql/data/pg_hba.conf file
# nano /usr/lib/pgsql/data/pg_hba.conf
Navigate down to the line that says
local all all ident
Edit it to
local all postgres trust
And now save the file.
3. Start PostgreSQL
# service postgresql start
4. Log in and change the password
# su - postgres
$ psql -d template1 -U postgres
alter user postgres with password 'new_password';
Or alternatively do it all in one go with the following command
> psql -U postgres template1 -c "alter user postgres with password 'new_password';"
5. Reverse the actions you did in step 2
Edit the /usr/lib/pgsql/data/pg_hba.conf file
# nano /usr/lib/pgsql/data/pg_hba.conf
Navigate down to the line that says
local all all trust
Edit it to
local all postgres ident
And now save the file.
6. Start PostgreSQL
# service postgresql start
Success!
// CrashMAG
Changing the default PostgreSQL data folder (PGDATA)
Installing the PostgreSQL server on RHEL, CentOS, Scientific Linux or Fedora installs the PostgreSQL databases and configuration files in “/var/lib/pgsql/data”.
This may or may not be desirable. Let’s assume for a moment you have a separately crafted partition for PostgreSQL to use, let’s say a RAID10 volume. You’d want to change this.
Change the defaults
Use your favorite text editor, in my case nano to create the following file (must be the same as the name of the service)
# nano /etc/sysconfig/pgsql/postgresql
Add the following
PGDATA=/postgresql/data
Optionally you can also add the following to change the default port (example is the default port)
PGPORT=5432
Adjusting SELinux to permit the new data folder (pgdata) location
Should the following command output “Permissive” or “Disabled” then you may skip the details for SELinux.
# getenforce
Run the semanage command to add a context mapping for /opt/postgresql and any other directories/files within it.
# semanage fcontext -a -t postgresql_db_t "/postgresql/data(/.*)?"
Now use the restorecon command to apply this context mapping to the running system
# restorecon -Rv /postgresql/data
Starting PostgreSQL
# chkconfig --levels 345 postgresql on
# service postgresql initdb
# service postgresql start
You’re all set to go! Keep in mind that PostgreSQL listens to ‘localhost’ by default. To change this you need to alter the “listen_address” parameter in “/var/lib/pgsql/data/postgresql.conf” (change will require restart).
// CrashMAG
RHEL/Centos 5 minimal installation
There’s no option during the CentOS 5 install, for a minimal installation. The purpose is quite simple, to keep the attack surface as small as possible.
A minimal installation is performed by doing the following
- During the category/task selection, deselect all package categories, and choose the “Customize now” option at the bottom of screen.
- During the customized package selection, deselect everything ( including the Base group ).
This will yield you 234 packages with the Centos 5.5 installation media. I’ve attached a .txt file containing all the packages for your leisure.
Link: installed-packages
// CrashMAG
Configuring BIND DNS Server to listen only on a specific IP address
This is a short example driven howto on how you can configure BIND to listen on certain IP addresses which can also be an implicit network interface. IPv6 is also included in the examples. You could also say that this how you disable IPv6 for BIND/named, but it’s implicit to the operation.
listen-on default syntax
Note the “-v6″ syntax for IPv6.
IPv4
listen-on port 53 { 127.0.0.1; };
IPv6
listen-on-v6 port 53 { ::1; };
you can also combine several IP addresses
listen-on port 53 { 127.0.0.1; 192.168.0.1; };
From the man page
listen-on [ port integer ] { address_match_element; ... };
listen-on-v6 [ port integer ] { address_match_element; ... };
To listen on all interfaces and IP addresses
listen-on { any;};
listen-on-v6 { any;};
That’s all. A few short tips.
// CrashMAG
Disabling email alerts for cron
Having the cron daemon send email alerts could be a useful feature, but it could also get very tiresome depending on your setup. To disable this feature do the following.
Edit /etc/crontab with your favorite text editor, modify or insert the following line
MAILTO=""
Should you have crontabs set up for different users, use
crontab -e
and insert/edit the relevant configuration parameter as seen above.
Or should you want to disable output for certain jobs you could add
0 1 5 10 * /path/script.sh &> /dev/null
// CrashMAG
Public key authentication with SSH. Both with and without a password.
This article will run through quick and easy examples for setting up public key authentication with SSH. I will include one example that requires a password and one that does not. Typically used for scripts.
I will assume you know why you want to either use the one or the other. Public key authentication can only be set up on a per user/system basis, keep that in mind.
Public key authentication without a password
This the least secure option. It all boils down to how well secured your private key is. (.ssh/id_dsa)
- Create a key pair. (Private & public key)
- Copy the public key to the remote system.
- Log on the remote system.
Create a key pair
[user@localsystem ~]$ ssh-keygen -t dsa
Here’s what you’ll see when you run through this procedure. (“Press [ENTER]” are my comments)
[user@localsystem ~]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER] Created directory '/home/usr/.ssh'. Enter passphrase (empty for no passphrase): Press [ENTER] Enter same passphrase again: Press [ENTER] Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: 29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem The key's randomart image is: +--[ DSA 1024]----+ | .o.. | | o+o . | | ..*.. | | = o | | . E | | * | | . o o | | . .+.+ | | ...*+. | +-----------------+
Copy the public key to the remote system
[user@localsystem ~]$ ssh user@remotesystem
If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.
[user@remotesystem ~]$ mkdir .ssh [user@remotesystem ~]$ touch .ssh/authorized_keys [user@remotesystem ~]$ chmod -R u=rwx,go= .ssh [user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys
Enter your password when asked, and you’re done.
Log on the remote system
[user@localsystem ~]$ ssh user@remotesystem
Public key authentication with password
This is the route you want to go. Once done, you should also disable logins with passwords only. Do this by editing the /etc/ssh/sshd_config file and add/modify the following parameter “PasswordAuthentication no”. Also make sure “PubkeyAuthentication” is set to “yes”.
- Create a key pair. (Private & public key)
- Copy the public key to the remote system.
- Log on the remote system.
Create the key pair
[user@localsystem ~]$ ssh-keygen -t dsa
Here’s what you’ll see when you run through this procedure. (“[Your Password]” and “Press [ENTER]” are my comments)
[user@localsystem ~]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER] Created directory '/home/usr/.ssh'. Enter passphrase (empty for no passphrase): [Your Password] Enter same passphrase again: [Your Password] Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: 29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem The key's randomart image is: +--[ DSA 1024]----+ | .o.. | | o+o . | | ..*.. | | = o | | . E | | * | | . o o | | . .+.+ | | ...*+. | +-----------------+
Copy the public key to the remote system
[user@localsystem ~]$ ssh user@remotesystem
If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.
[user@remotesystem ~]$ mkdir .ssh [user@remotesystem ~]$ touch .ssh/authorized_keys [user@remotesystem ~]$ chmod -R u=rwx,go= .ssh [user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys
Enter your password when asked, and you’re done.
Log on the remote system
[user@localsystem ~]$ ssh user@remotesystem
Tip
You can later change the password for your keys by using
[user@localsystem ~]$ ssh-keygen -p
// CrashMAG
Guide and hardning tips for RHEL/CentOS 5 from NSA
As I was looking to see if NSA had updated their guides for RHEL 6 and it turns out they haven’t. I decided it would be a good idea to post about them to give them some better coverage.
This is just a small tip of free and useful information in regards to securing your RHEL/CentOS installation. A lot of the information is general in nature and can therefore be applied to any Linux distribution. It’s definitely worth your time.
I take no credit, the credit goes to NSA for creating the documents to begin with.
Guide to the Secure Configuration of Red Hat Enterprise Linux 5
www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Red Hat Linux 5 Hardening Tips
www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf
I just love how just about every section starts with “Disable ‘insert your service here’ if possible…” 
// CrashMAG
Setting up sSMTP with GMail
Let me introduce you to the “extremely simple MTA to get mail off the system to a mailhub”. Particularly useful when you don’t want systems to have a full blown MTA installed. Such as Postfix, Exim or Sendmail. I find ssmtp extremely helpful on standalone servers that use Logwatch.
Getting this up and running requires 4 steps.
- Installing SSMTP
- Configuring SSMTP
- Changing the MTA on your system
- Testing
Installing the daemon, ssmtp.
Use your favorite package manager, in my example I’ll be using YUM. (Fedora/CentOS/RHEL/Scientific Linux). For Centos/RHEL/Scientific Linux 5.5 or 5.6 you need access to the EPEL repository to install sSMTP. Add EPEL to your system using the following command.
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
You can find eventual new links from http://download.fedora.redhat.com/pub/epel/5/i386/repoview/epel-release.html
yum install ssmtp
Configuring SSMTP
Edit /etc/ssmtp/ssmtp.conf with your favorite text editor. I’ll be using nano.
nano /etc/ssmtp/ssmtp.conf
Remove all the entries and replace it with the ones beneath.
root=insert_your_email_address here mailhub=smtp.gmail.com:587 UseTLS=YES UseSTARTTLS=YES AuthUser=your_gmail_username_which_you'll_be_using_to_send AuthPass=password
Changing the MTA
For CentOS/Fedora/RHEL
alternatives --config mta
Press the number that equals /usr/sbin/sendmail.ssmtp and you’re done.
Testing
I’m testing this using the verbose mode just to be able to see the dialogue with the Google SMTP server.
cat random_file | sendmail -v your_email_address
// CrashMAG
Managing /etc with etckeeper and git
The following was done on Fedora 14. Keep in mind that the Etckeeper and git specific actions will be similar on whatever platform you’re on.
Simply put, Etckeeper automatically revisions your /etc folder. Allows you to compare, commit and revert the changes that have been made. It’ll also allow you to restore files, should you be unlucky and delete them. Once etckeeper is installed, it will work together with your package manager and cron to do its work. To manage all this you’ll use the commands that your chosen VCS (Version Control System).
Etckeeper supports Git, Bazaar, Darcs and Mercurial.
Use of Etckeeper
Installation
yum install etckeeper
Initialization
etckeeper init
Initial commit
etckeeper commit "initial commit"
Once this is done, etckeeper will make sure that every time you use the package manager (YUM) changes will be recorded. There are however a few git related commands you should be aware of.
Useful and necessary commands
Note: All of these commands assumes your current path is /etc
Viewing the Git log
git log
Check if there’s any modified files
git status
Complete status overview
git log --stat --summary
Revert a change
git revert
View changes you haven’t commited yet
git diff
List different commits, each on one line.
git log --pretty=oneline
Revert to latest change-set, discarding changes
git reset --hard
Re-enter commit message
git commit --amend
Have at it folks!
// CrashMAG