Saturday 13 September 2014

UNIX Servers and Secure Access


Nobody has access until explicitly granted.

A UNIX firewall will be in place to limit traffic and to drop a possible mass attack.
Port monitoring and IP blocking tool will be installed for suspected mis-use.
All insecure or plain text tools are not available for use.
These include telnet, ftp, rsh, rexec etc.
The open ports on any server are locked down to a bare minimum.
22 - ssh for remote access and data transfer
25 - mail
143/587 - mail server
80 - standard web server
443 - secure web server
3306 - data base access with ssl/ssh
other ports only on demand.
Security on the open ports.
3306 - only open to other database and backup servers
443 - open to the world, but monitored
80 - open to the world, but monitored
25 - open only for outgoing mail as standard
        if incoming mail is required (Jira) open, but monitored
22 - open for approved staff and configured for certificate only (see below)
143/587 - open for registered mail users.
other ports will be added if opened.
Where possible, http will be redirected to https.
A virus filter to protect the Windows users will be in place for servers with mail and upload access.
Servers with VNC access requirements will have this accessible via localhost and SSH certificate only.
Root log-in is locked down and replaced with sudo access after SSH connection.
No user will have access to the ROOT password.
User access is granted via a 2048bit SSH key.
No password log-in is available.
After 3 failed SSH handshake attempts the account will be locked and the IP blocked with the tool see 3.
The public key has to be registered on the server before access can happen.
The user cannot change the access credential or the protected SSH certificate.
Every server access, successful or fail, will be logged in a audit file.
Every sudo command is audited.
Every web site access will be logged and presented in a daily report.
Server and data backup will be in place and stored in a secure location.  
on web facing servers the denyhosts tool is installed to block IP's after repeated failed attempts.


The default access permission to for servers is defined in the file:


/etc/hosts.deny

ALL:   ALL


Then put IP addresses with access permission in this file:


/etc/hosts.allow

# Office IP
ALL: nnn
#
# Remote server
ALL: nnn
#
# 24x7 support IPx
ALL: nnn


since all web servers for obvious reason are open access and therefore not adhering to the hosts.deny rules an iptables firewall need to be put in place.

UNIX Mail server


A no-frills Mail Server running on Cent-OS / Fedora

preliminaries


update your OS with
yum -y update
fix all errors, if any and in case of kernel updates you need to run
shutdown -r now ( or later if someone else is using the box )
erase to good `ol sendmail and if it is installed for some reason exim with
yum -y erase sendmail exim
install Postfix the Mail Transfer Agent, Dovecot the Mail Delivery Agent and Clamav the Virus checker to protect or Windows community. We start with these two
yum -y install postfix dovecot
Spam could be a worry if we open the mail delivery to the server to the world. Since we only accept mail from white-listed senders we don't need to worry.

configuration


configure Postfix
cd /etc/postfix
fix the aliases file
create a my_networks file
create a body_checks file
create a header_checks file
set-up the main.cf file
set-up the master.cf file
now check the configs with
postfix check
then, if everything is fixed run
service postfix start
configure dovecot
cd /etc/dovecot
change the settings in dovecot.conf
cd conf.d
adjust all required *.conf files to suit
start dovecot and check the mail logs
service dovecot start
next set-up mail users, in our case for gitlab, jira and confluence and a postmaster account
add the users, ideally with the same id(s) as on other servers
create passwords for the mail set-up within the application
create home directories and set-up the Maildir within.
test the mail delivery to the postmaster account
and next test the out-going mail too
now you are ready to add the mail box details to the application and ensure to fully test the configuration. Once fully tested and working you can forget the passwords as changing passwords is a manual process on server and application.
as everything is working with the basics we add the Virus checking and the SSL certificates.
First we install and configure the Virus checker tools with
yum -y install clamav clamav-data clamav-filesystem clamav-lib clamav-server clamav-update clamsmtp
The configuration is needed for regular updates and Postfix integration
set-up the clamd.server config
set-up the freshclam.conf file
set-up the camsmtp.conf file
add the filter to the postfix main.cf and master.cf
now get the first clam database with
/bin/freshclam --verbose
service clamd.server start
service clamsmtp start
postfix stop
postfix start
re-test mail sending and receiving via the virus checker and watch
tail -f /var/log/maillog
fix any errors
lastly we can add the optional SSL certificates for sending and downloading email in non-clear text.
create the certs and place the into /etc/postfix/ssl
then add the certs and smtpd setting into the mail.cf and the dovecot configs
then restart postfix and dovecot and re-test the mail send/receive
service dovecote restart
postfix stop
postfix start
tail -f /var/log/maillog
fix any errors
When the SSL certs are installed and show no errors, the application(s) need to be changed to pop3 over SSL and send with TLS/SSL. It should just work or else more fixing.
Lastly inform users where send mail to and how to use the mail functionality in the application.

MySQL - Master to Passive Master Replication


This replication is only working behind HAproxy!

The manual needs to be followed word by word...
as usual ... no warranties ...

Set-up:

on both server simultaneously

install MySQL directly from download.mysql.com
copy a my.conf from gitlab in place
create the following:
mkdir -p /data/mysql
mkdir -p /data/log
chmod 750 /data/mysql /data/log
chown -R mysql:mysql /data/mysql /data/log
mkdir -p /var/run/mysqld
chown mysql:mysql /var/run/mysqld
mkdir -p /var/log/mysqld
chown mysql:mysql /var/log/mysqld
ln -s  /var/run/mysqld/mysql.sock /var/lib/mysql/mysql.sock
run as root:   mysql_install_db
check this is empty:   /var/log/mysqld/mysql.err
run as root:   systemctl start mysqld
check the logs in  /var/log/mysqld  are identical
run as root:   mysql -p   (no password)
set-up the main database:   use mysql;
then run this script:
use mysql;
delete from user where user='';
delete from user where user='root' and host not in ('localhost');
update user set password=PASSWORD("xxx") where user='root';
drop database IF EXISTS test;
delete from db where db='test' or db='test\\_%';
create user 'addi'@'%' identified by 'xxx';
create user 'iang'@'%' identified by 'xxx';
create user 'nagios'@'%' identified by 'read_only';
grant ALL on *.* to 'addi'@'%';
grant ALL on *.* to 'iang'@'%';
grant SUPER on *.* to 'addi'@'%';
grant SUPER on *.* to 'iang'@'%';
grant GRANT OPTION on *.* to 'addi'@'%';
grant GRANT OPTION on *.* to 'iang'@'%';
grant SELECT on *.* to 'nagios'@'%';
grant PROCESS on *.* to 'nagios'@'%';
grant REPLICATION CLIENT on *.* to 'nagios'@'%';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'%' IDENTIFIED BY 'xxx';
flush privileges;
select user,host,password from user;

now to the wicket-tricky stuff
replication set-up
check that this is identical on both servers:  
show variables where Variable_Name IN ("server_id", "log_bin", "relay_log", "log_slave_updates");
show master status;
log in from A to B:   mysql -h db-02 -u replicator -p****
log in from B to A:   mysql -h db-01 -u replicator -p****
fix it or restart if something does not work !!!

add the replication details:
CHANGE MASTER TO MASTER_HOST='<the other server>',
-> MASTER_USER='replicator',
-> MASTER_PASSWORD='***',
-> MASTER_LOG_FILE='mysql-bin.<file from master status>',
-> MASTER_LOG_POS=<pos from master status>;
on second server first:
SLAVE START;
SHOW SLAVE STATUS\G
ensure NO errors !!!

on first server:
SLAVE START;
SHOW SLAVE STATUS\G
ensure NO errors !!!



Checking the Replication.

from the first server:
create this:
create database important;
use important;
create table stuff(
id int(16) auto_increment,
details varchar(200),
PRIMARY KEY (id));
now do this:   INSERT INTO important.stuff SET details='Gift from A to B';

on the second server:
check this:
select * from important.stuff\G
you see:   'Gift from A to B

now do this on the second server:
INSERT INTO important.stuff SET details='Gift from B to A';

back on the first server:
check this:
select * from important.stuff\G
you see the 2nd record:   'Gift from B to A


The Replication is working successfully if you haven't seen any errors  !!!


enjoy life !!!
Addi

MySQL - Master to Passive Master Replication and fail-over


with the help of HAproxy.


The manual needs to be followed word by word...
as usual ... no warranties ...

Set-up

this set-up is for 2 haproxy servers with a VIP and keepalived running
Check that the Master and the Passive Master Databases are Healthy
Insert another row into the IMPORTANT database:
alter table stuff add happened TIMESTAMP AFTER details;
insert into important.stuff set details = 'Replicating Primary to Secondary';
check here:   select * from important.stuff order by id desc limit 1;

go to the second server and log into mysll
check here:   select * from important.stuff order by id desc limit 1;

Result :  identical !!!

Check the second server now:
insert into important.stuff set details = 'Replicating Secondary to Primary';
do the same checks on both servers.
you should see the identical results.

Now it is time to create the Application user(s) and database(s); well and some very-very-very-long-secure-password(s) ...
on server 1 ( replication is taking care of the rest )
use mysql;
create database <name1>
create database <name2>
GRANT ALL on <name1>.* TO '<name1>'@'%' IDENTIFIED BY PASSWORD '<name1>_pass';
GRANT ALL on <name2>.* TO '<name2>'@'%' IDENTIFIED BY PASSWORD '<name2>_pass';
GRANT ALL on important.* TO 'haproxy'@'%';  ( no password for haproxy checks )
check with:
show databases;
select user, host, password from user;
check that all is fine
from the proxy servers all accounts need testing
log on to each proxy cluster member and every account on every database server:
mysql <database> -h <db-server> -u <user-name> -p<password>
ensure every log-in is working before continuing

Configure HAproxy for the first time.
Create a basic haproxy config on all haproxy servers for the first tests. Use this example basic_haproxy.cfg
replace the default config /etc/haproxy/haproxy.cfg with the example (amend server names)
start the service on all servers:  service haproxy restart
now check the access from every proxy server several times:
mysql  -h localhost  -u haproxy -e'show variables like "server_id";'
you will see round robin database responses, then all is fine.
now check the output of:
echo "show stat" | socat stdio /var/lib/haproxy/stats
you should see the status print; if not fix it !!!
next go to one or more servers that will need connection to the database
check for several times via the VIP and via the individual proxy servers:
mysql  -h <proxy-vip>  -u haproxy -e'show variables like "server_id";'
you will see round robin database responses, then all is fine; if not fix it !!!  ( iptables, firewall et al )

Set up a Health Check
add details to the haproxy.cfg:
add this line above the server Primary line:  option mysql-check user haproxy
add after each port number (3306) the word:  check
restart the service: service haproxy restart
check the difference in the output of
echo "show stat" | socat stdio /var/lib/haproxy/stats
you should see the status print with mysql status checks and mysql version; if not fix it !!!
from now on we use the filtered status check:
echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
run it and see the output.

Configure HAProxy to be Active-Passive
all we need to do is to add the following:
add to the server Secondary <server-name>:3306 check, the word  "backup"  at the end
restart the service: service haproxy restart
all connection will go to the primary server
run the status check
echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
explanation: MySQL,Primary is active (1,0) and MySQL,Secondary is backup (0,1)

Job done - Active Passive is now running


Test Fail-over by taking the Primary Down
log-on to the primary server and run:
service mysqld stop
back on any of the proxy servers run:
echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
and see MySQL,Primary,DOWN,1,0
check the MySQL connection, all goes to the Secondary, after a short delay.

Job done - Fail-over to Secondary is working


Enabling the Maintenance Mode
This needs a small addendum to all Proxy server configs:
add to the end of stats socket line:  level admin
restart the service on all servers:  service haproxy restart
To enable the maintenance mode a message needs to be sent to the stats socket:
echo "disable server MySQL/Primary" | socat stdio /var/lib/haproxy/stats
run: echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
and it shows:  MySQL,Primary,MAINT,1,0
all traffic is routed to the secondary without any health check traffic

Now stop both slaves, Primary first, then Secondary.
take a  FULL BACK-UP !!!
then do Maintenance, Updates, Changes etc.

Once finished start the slave on the Primary to get the data changes from the slave.
Activate the Primary Database as required with:
echo "enable server MySQL/Primary" | socat stdio /var/lib/haproxy/stats
run: echo "show stat" | socat stdio /var/lib/haproxy/stats | cut -d, -f1,2,18,20,21
and it shows:  MySQL,Primary,UP,1,0
all traffic is routed to the primary, again with health check traffic
Lastly start the slave on the secondary to apply the changes.

Job done - Maintenance mode is available



Quote:
Don't take the author's word for anything; prove it to yourself.
Do the exercises and invent your own.
—James Hague

NSCA  -  Nagios push service


The home page of NSCA is here

Compile from source.
current version
untar, configure and make all
nsca is the server
send_nsca is the client
nsca.cfg is the config file for both server and client

Install the server:
copy nsca from compile directory to /usr/bin/
install yum install xinetd
enable and start the xinetd service
in the syslog you should see: xinetd[...] Started working: 0 available services
add this to the /etc/services
nsca            5667/tcp    # NSCA

add the xinetd configuration file:
/etc/xinetd.d/nsca-server
#
# description: NSCA server
#
service nsca
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = nagios
group = nagios
server = /usr/bin/nsca
server_args = -c /etc/nagios/nsca.cgf --inetd
log_on_failure += USERID
#only_from = <ipaddress1> <ipaddress2> ...   <<<---  white listing !!!
}
chmod 600 /etc/xinetd.d/nsca-server

create the nsca configuration file:
log_facility=daemon
pid_file=/var/run/nsca.pid
server_port=5667
server_address=188.40.84.214
nsca_user=nagios
nsca_group=nagios
debug=1
command_file=/var/spool/nagios/cmd/nagios.cmd
alternate_dump_file=/var/spool/nagios/cmd/nsca.dump
aggregate_writes=0
append_to_file=0
max_packet_age=30
password=BLA BLA BLA
decryption_method=3
chown nagios:nagios /etc/nagios/nsca.cfg

restart the service
in the syslog you should see: xinetd[...] Started working: 1 available services

The NSCA server is ready to accept push notifications from the client.
Next configure a Nagios Server config and install the NSCA client.

Monday 24 March 2014

Install Confluence on CentOS 6.5 and/or Fedora 19

This should help to install Confluence (Wiki) with some useful customisation.
The installation documentation will work for either CentOS 6.5 or Fedora 19 with MySQL/MariaDB 5..5.35+.
Some of the steps are duplicated if JIRA is already installed on the server.

  1. download the latest version of Confluence from Atlassian
     
  2. install and configure an up-to-date version of Java.
    i.e. java -version   --->>  java version "1.7.0_51"
  3. download the Java Connector version > 5.1.28 from Oracle (see git install)
     
  4. GOTCHA !!!   remove all previous Confluence accounts, groups and installations unless you want to upgrade !!!
     
  5. copy both to the destination machine
    change permissions to 755 on confluence binary package
     
  6. install the Java Connector into the /usr/share/java/
    and replace old links of mysql-connector-java.jar (see git install)
     
  7. prepare the database (local or different db server)
    CREATE USER 'wiki'@'localhost(remote host)' IDENTIFIED BY 'supersecret';
    CREATE DATABASE IF NOT EXISTS `wiki_db` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
    GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `wiki_db`.* TO 'wiki'@'localhost (or other hostname)';
     
  8. prepare a data directory/file-system i.e. on a storage device for easier back-up.
    i.e. /data/wiki
     
  9. prepare a directory for central logging /var/log/wiki
     
  10. decide which tomcat ports you want to use; this is not needed when you run Confluence on its own server.
     
  11. next still as superuser, execute the confluence binary
     
  12. GOTCHA !!!   before starting Confluence or logging onto the gui for the remaining configuration, you have to copy the java-connector
    GOTCHA !!!   it has to be a "copy" linking does not work with Confluence
    cd /opt/atlassian/confluence/lib  (the default installation)
    cp -p /usr/share/java/mysql-connector-java-5.1.28/mysql-connector-java-5.1.28-bin.jar mysql-connector-java.jar
    Without this copy or link you will not see the database.
     
  13. Questions / Prompts during install:
    1. This will install Confluence 5.4 on your computer   --->  press Enter
    2. Choose the appropriate installation or upgrade option   --->    2 + Enter
    3. Where should Confluence 5.4 be installed?   --->  press Enter
    4. Default location for Wiki data (see item 6.)   --->  /data/wiki  + Enter
    5. Configure which ports Confluence will use (see item 8)   --->  select option and Enter
    6. Install Confluence as Service? (silly question)   --->  press Enter
    7. Finishing installation ...
       
  14. Now is the time for item 10. !!!
     
  15. Enter the database connection details into the file: /data/wiki/confluence.cfg.xml
     
  16. Also do Item 7.now.
    1. mv /data/wiki/logs/atlassian-confluence.log  /var/log/wiki/
    2. rmdir /data/wiki/logs
    3. ln -s /var/log/wiki /data/wiki/logs
    4. cd /opt/atlassian/confluence
    5. mv logs/* /var/log/wiki/
    6. rmdir logs
    7. ln -s /var/log/wiki logs
       
  17. Restart JIRA and log-in to the gui to configure the admin user and the database.
     
  18. lastly configure Apache or nginx as the gateway.

Thursday 20 March 2014

Install Jira on CentOS 6.5 and/or Fedora 19

This should help to install JIRA with some useful customisation.
The installation documentation will work for either CentOS 6.5 or Fedora 19 with MySQL/MariaDB 5..5.35+.

Some of the steps are duplicated if Confluence is already installed on the server.

  1. download the latest version of JIRA from Atlassian
     
  2. install and configure an up-to-date version of Java.
    i.e. java -version   --->>  java version "1.7.0_51"
  3. download the Java Connector version > 5.1.28 from Oracle (see git install)
     
  4. GOTCHA !!!   remove all previous JIRA accounts, groups and installations unless you want to upgrade !!!
     
  5. copy both to the destination machine
    change permissions to 755 on JIRA
     
  6. install the Java Connector into the /usr/share/java/
    and replace old links of mysql-connector-java.jar (see git install)
     
  7. prepare the database (local or different db server)
    CREATE USER 'jira'@'localhost(remote host)' IDENTIFIED BY 'supersecret';CREATE DATABASE IF NOT EXISTS `jira_db` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
    GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `jira_db`.* TO 'jira'@'localhost (or other hostname)';
     
  8. prepare a data directory/file-system i.e. on a storage device for easier back-up.
    i.e. /data/jira
     
  9. prepare a directory for central logging /var/log/jira
     
  10. decide which tomcat ports you want to use; this is not needed when you run JIRA on its own server.
     
  11. next still as superuser, execute the JIRA binary
     
  12. GOTCHA !!!   before starting JIRA or logging onto the gui for the remaining configuration, you have to create a link (or copy) the java-connector
    cd /opt/atlassian/jira/lib  (the default installation)
    ln -s /usr/share/java/mysql-connector-java-5.1.28/mysql-connector-java-5.1.28-bin.jar mysql-connector-java.jar
    Without this copy or link you will not see the database.
     
  13. Questions / Prompts during install:
    1. This will install JIRA 6.2 on your computer   --->  press Enter
    2. Choose the appropriate installation or upgrade option   --->    2 + Enter
    3. Where should JIRA 6.2 be installed?   --->  press Enter
    4. Default location for JIRA data (see item 6.)   --->  /data/jira  + Enter
    5. Configure which ports JIRA will use (see item 8)   --->  select option and Enter
    6. Install JIRA as Service? (silly question)   --->  press Enter
    7. Finishing installation ...
       
  14. Now is the time for item 10. !!!
  15. Enter the database connection details into the file: /data/jira/dbconfig.xml
  16. Also do Item 7.now.
    1. mv /data/jira/log/atlassian-jira.log  /var/log/jira/
    2. rmdir /data/jira/log
    3. ln -s /var/log/jira /data/jira/log
    4. cd /opt/atlassian/jira
    5. mv logs/* /var/log/jira/
    6. rmdir logs
    7. ln -s /var/log/jira logs
       
  17. Restart JIRA and log-in to the gui to configure the admin user and the database.
     
  18. lastly configure Apache or nginx as the gateway.