Why?


Search This Blog

Wednesday, August 26, 2015

Passwordless root SSH Public Key Authentication on CentOS 6

Jacked this from: http://www.firedaemon.com/blog/passwordless-root-ssh-public-key-authentication-on-centos-6

I am using Centos 6.6 as my client and Centos 7 as the server i am ssh'ing to. I did not have the selinux problem as mentioned at the end of this wiki

Passwordless root SSH Public Key Authentication on CentOS 6

It's often useful to be able to SSH to other machines without being prompted for a password. Additionally, if you using tools such as Parallel SSH you will need to setup Public Key SSH Authentication. To set it up is relatively straight forward:

On the client machine (ie. the one you are SSH'ing from) you will need to create an SSH RSA key. So run the following command - ensure you don't supply a password:

[root@node01 ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
c6:66:93:16:73:0b:bf:46:46:28:7d:a5:38:a3:4d:6d root@node01
The key's randomart image is:
+--[ RSA 2048]----+
|            .    |
|       . + o     |
|      . @ E      |
|       * & .     |
|      . S =      |
|       = + .     |
|          o      |
|         .       |
|                 |
+-----------------+

This will generate the following files:

[root@node01 ~]# cd ~/.ssh
[root@node02 .ssh]# ls -l
total 8
-rw-------. 1 root root 1675 Jul 27 15:01 id_rsa
-rw-r--r--. 1 root root  406 Jul 27 15:01 id_rsa.pub

On the client machine tighten up file system permissions thus:

[root@node01 ~]# chmod 700 ~/.ssh
[root@node01 ~]# chmod 600 ~/.ssh/*
[root@node01 ~]# ls -ld ~/.ssh & ls -l ~/.ssh
drwx------. 2 root root 4096 Jul 27 15:01 /root/.ssh
-rw-------. 1 root root 1675 Jul 27 15:01 id_rsa
-rw-------. 1 root root  406 Jul 27 15:01 id_rsa.pub

Now copy the public key to the machine you want to SSH and fix permissions (you will be prompted for the root password):

[root@node01 ~]# ssh root@node02 'mkdir -p /root/.ssh'
[root@node01 ~]# scp /root/.ssh/id_rsa.pub root@node02:/root/.ssh/authorized_keys
[root@node01 ~]# ssh root@node02 'chmod  700 /root/.ssh'
[root@node01 ~]# ssh root@node02 'chmod  600 /root/.ssh/*'

You can also use the utility ssh-copy-id to do the above steps. If you don't have scp on the remote machine you will need to install it:

[root@node01 ~]# ssh root@node02 'yum install openssh-clients'

You should now be able to ssh directory from node01 to node02 without providing a password:

[root@node01 ~]# ssh node02
Last login: Wed Jul 27 15:41:56 2011 from 10.255.5.57
[root@node ~]#

IMPORTANT There is a bug in CentOS 6 / SELinux that results in all client presented certificates to be ignored when SELinux is set to Enforcing. To fix this simply:

[root@node01 ~]# ssh root@node02 'restorecon -R -v /root/.ssh'
restorecon reset /root/.ssh context system_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0

C

Saturday, August 22, 2015

SSL on Centos 7 with Apache 2



SSL on Centos 7 with Apache 2

I jacked this from https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-apache-for-centos-7

Step One — Install Mod SSL

In order to set up the self-signed certificate, we first have to be sure that mod_ssl, an Apache module that provides support for SSL encryption, is installed on our VPS. We can install mod_ssl with the yum command:

yum install mod_ssl

The module will automatically be enabled during installation, and Apache will be able to start using an SSL certificate after it is restarted. You don't need to take any additional steps for mod_ssl to be ready for use.
Step Two — Create a New Certificate

Now that Apache is ready to use encryption, we can move on to generating a new SSL certificate. The certificate will store some basic information about your site, and will be accompanied by a key file that allows the server to securely handle encrypted data.

First, we need to create a new directory where we will store the server key and certificate:

mkdir /etc/httpd/ssl

Now that we have a location to place our files, we can create the SSL key and certificate files with openssl:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/apache.key -out /etc/httpd/ssl/apache.crt

After you enter the request, you will be taken to a prompt where you can enter information about your website. Before we go over that, let's take a look at what is happening in the command we are issuing:

    openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
    req -x509: This specifies that we want to use X.509 certificate signing request (CSR) management. The "X.509" is a public key infrastructure standard that SSL and TLS adhere to for key and certificate management.
    -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Apache to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening, since we would have to enter it after every restart.
    -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
    -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
    -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
    -out: This tells OpenSSL where to place the certificate that we are creating.

Fill out the prompts appropriately. The most important line is the one that requests the Common Name. You need to enter the domain name that you want to be associated with your server. You can enter the public IP address instead if you do not have a domain name.

The full list of prompts will look something like this:

Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Example
Locality Name (eg, city) [Default City]:Example
Organization Name (eg, company) [Default Company Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Example Dept
Common Name (eg, your name or your server's hostname) []:example.com
Email Address []:webmaster@example.com

Step Three — Set Up the Certificate

We now have all of the required components of the finished interface. The next thing to do is to set up the virtual hosts to display the new certificate.

Open Apache's SSL configuration file in your text editor with root privileges:

vi /etc/httpd/conf.d/ssl.conf

Find the section that begins with <VirtualHost _default_:443>. We need to make a few changes here to ensure that our SSL certificate is correctly applied to our site.

First, uncomment the DocumentRoot line and edit the address in quotes to the location of your site's document root. By default, this will be in /var/www/html, and you don't need to change this line if you have not changed the document root for your site. However, if you followed a guide like our Apache virtual hosts setup guide, your site's document root may be different.

DocumentRoot "/var/www/example.com/public_html"

Next, uncomment the ServerName line and replace www.example.com with your domain name or server IP address (whichever one you put as the common name in your certificate):

 ServerName www.example.com:443

Find the SSLCertificateFile and SSLCertificateKeyFile lines and change them to the directory we made at /etc/httpd/ssl:

SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key

When you are finished making these changes, you can save and close the file.
Step Four — Activate the Certificate

By now, you have created an SSL certificate and configured your web server to apply it to your site. To apply all of these changes and start using your SSL encryption, you can restart the Apache server to reload its configurations and modules:

apachectl restart

In your web browser, try visiting your domain name or IP with https:// to see your new certificate in action.

https://example.com/

Your web browser will likely warn you that the site's security certificate is not trusted. Since your certificate isn't signed by a certificate authority that the browser trusts, the browser is unable to verify the identity of the server that you are trying to connect to. We created a self-signed certificate instead of a trusted CA-signed certificate, so this makes perfect sense.

Once you add an exception to the browser's identity verification, you will be allowed to proceed to your newly secured site.

Thursday, August 20, 2015

Centos 7 and Asterisk using fail2ban



Centos 7 and Asterisk using fail2ban

I punched holes in my firewall for SIP and RTP so I could get to my asterisk server off net on my softphone. I quickly noticed I was getting attacked. Although I am using very cryptic passwords for my extensions, best practices is to not let this go on, and I have limited bandwidth at my house with COX home service 50/5.

At the time of this post I am behind a Linksys EA5400 router. I have a new pfSense I built the other day on a fanless mini ITX platform but I want to play with it more before I move it in front of my COX MTA. Yes I have COX home as well J

Replacing the router will not affect my network or Asterisk setup as I will use the same IP’s as the Linksys when I replace it, and yes, add the port forward rules for SIP and RTP.

Install iptables

# systemctl stop firewalld
# systemctl mask firewalld
# yum –y install iptables-services
# systemctl enable iptables

Edit the /etc/sysconfig/iptables file. Below is mine. Very basic allowing for web, ssh, SIP, and RTP.

# vi /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [214:43782]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
-A INPUT -i lo -j ACCEPT
COMMIT

Start iptables with:

# systemctl restart iptables

Make sure it is running with:

# systemctl status iptables

Check your rules with:

# iptables –L

Install fail2ban

Make sure you have the epel for Centos 7 installed for use in yum. As user root:

# yum –y install fail2ban

Setup conf file. Don’t use jail.conf, but rather jail.local
 
# vi /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 21600
maxretry = 3
backend = auto
 
[asterisk-iptables]
# if more than 4 attempts are made within 6 hours, ban for 24 hours
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=all]
              sendmail[name=ASTERISK, dest=you@yourmail.co.uk, sender=fail2ban@local.local]
logpath  = /var/log/asterisk/messages
maxretry = 4
findtime = 21600
bantime = 86400
 
Make sure your logpath is correct under the [asterisk-iptables] context above. If not it will not be able to read log and ban the bad guys.

Enable fail2ban and start service:

# systemctl enable fail2ban
# systemctl start fail2ban
# systemctl status fail2ban

Log file is /var/log/fail2ban.log

Enjoy!

Tuesday, August 18, 2015

Asterisk behind NAT - on home network with dynamic IP

Asterisk behind NAT - on home network with dynamic IP

Here is what I did to get my Asterisk 100% functional behind NAT in my home network, without static IP.

First a little background. I am running Asterisk 13.4.0 on Centos 7. It uses 192.168.10.100 behind a Cisco/Linksys EA5400 router. Internet is provided by COX communications with 50 down and 5 up. this is a residential COX account so I do not get a static IP. My Asterisk is using a SIP Trunk to Vitelity. I have a few phones attached to my asterisk but for this wiki I will use the Yealink T19 I have and set it up as extension 100, and IP 192.168.10.2, for simplicity. I have the latest firmware on this Yealink as of 8/18/2015, version 31.72.0.75. My DID i got from Vitelity is 480-555-2222 (That's fake, but you get it)

From your PC go to http://checkip.amazonaws.com/ and get your external IP. You will need this IP later.

In my EA5400 router I did a few port forwards to my Asterisk server. They are:

SIP 5060 - 5062 UDP
RTP 10000 - 20000 UDP

Make sure the RTP range matches up with your Asterisk server. You can see this in rtp.conf. I also rebooted my router after this port forwarding was added.


Setup Asterisk with the Vitelity SIP Trunk. In sip.conf I made the following entry:

[general]
register => myaccount:mypassword@inbound32.vitelity.net:5060
alwaysauthreject=yes 
nat=yes
externip=x.x.x.x                                       ;Your real external IP goes here
localnet=192.168.10.0/255.255.255.0     ;Your real local net goes here with /subnet_mask
transport=udp
context=internal                                      ; Default context for incoming calls. Defaults to 'default'

[vitel-outbound]
type=friend
dtmfmode=auto
host=outbound.vitelity.net
username=myaccount
fromuser=myaccount
secret=mypassword
trustrpid=yes
sendrpid=yes
allow=all
canreinvite=no

A sip reload from the Asterisk console and then check things.

CLI> sip reload
CLI> sip show peers
vitel-outbound/myaccount   64.2.142.17                       Yes        Yes            5060     Unmonitored
CLI> sip show registry
inbound32.vitelity.net:5060     N      myaccount      45 Registered           Tue, 18 Aug 2015 14:40:39

As you can see we have both inbound and outbound set for Vitelity now.

For the phone setup for extension 100 I added the following in sip.conf:

[100]
type=friend
callerid=100
secret=myphoneregverysecretpassword
context=internal
host=dynamic
allow=all
dtmfmode=rfc2833
canreinvite=no


In the extensions.conf file I made the following entries:

[internal]
;used for in-bound DID to go to extension 100. If no answer then go to voicemail.
;after voice mail i play the goodbye message and then hangup
exten => 4805552222,1,Dial(SIP/100,20)
exten => 4805552222,n,VoiceMail(100@internal,u)
exten => 4805552222,n,Playback(vm-goodbye)
exten => 4805552222,n,Hangup

;used for extension to extension dialing
exten => 100,1,Dial(SIP/100,15)
exten => 100,n,VoiceMail(100@internal,u)
exten => 100,n,Playback(vm-goodbye)
exten => 100,n,Hangup
; used to dial outside line through our vitelity SIP Trunk
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@vitel-outbound)


Do a "core reload" from the asterisk console and you should be operational at this point for both in-bound/out-bound calls and have two way audio on your extension 100.

Now lets cover what happens when your external IP changes, as it will if you don't have a static IP, and how do you get an external client registered (like your soft phone when your outside your LAN). We fix these issues with a free service from duckdns.org and a couple scripts that run in cron every 5 minutes.

Since we don't have a static IP we can use an IP address for off net client registrations. We need to use a fqdn and make sure that is resolved to whatever IP COX has given us for that day/week/month.

Go to http://www.duckdns.org and sign up. Its free and takes like 5 seconds. From there you can chose a name for your domain. lets say you choose myhomeasterisk, then your fqdn will be myhomeasterisk.duckdns.org. After you have done this then click install at the top of there page, choose Linux cron, then select your domain you just created. You now get the script to run and all the instructions for getting it to run in cron. I wont redo the instructions here. They are really simple though.

With the duckdns solution in place we can now set our off net clients to register to our new domain we got with duckdns. If COX changes the IP on us then it will be updated within 5 minutes for us. Cox normally sets a lease time for a week, and then it is in the evening, so you should really never have a problem with this.

One last thing though. If COX changes the IP on us, and they will :) . Then we need to also update the Asterisk server sip.conf with our new external IP. I searched the web and found a script for this. Just a few mods to make it work for default Asterisk installs and it works like a charm.

In your /etc/asterisk directory create a file named updateexternalip.sh with the contents of:

#!/bin/bash

ip_url="http://checkip.amazonaws.com/"

oldip=`grep externip /etc/asterisk/sip.conf |sed 's/;.*//' |grep -v ^$ |sed s/.*=\ *//`
ip=`curl -s "$ip_url" |head -n 1`

echo $oldip
echo $ip

if [ "$oldip" != "$ip" ]
then
        echo "Updating IP"
        sed -i "s/externip=$oldip/externip=$ip/" /etc/asterisk/sip.conf
        asterisk -r -x "core reload"

fi


Set this file as executable with:

# chmod +x /etc/asterisk/updateexternalip.sh

Run this file for a test with:

# /etc/asterisk/updateexternalip.sh

It should echo your externip from sip.conf and also show you what your real external IP is. If these are different it will update your sip.conf file and reload asterisk for you.

To get this to run automatically every 5 minutes just add it to your contab file. The line to insert for this would be:

*/5 * * * * /etc/asterisk/updateexternalip.sh >/dev/null 2>&1

That's it. Enjoy !