The Sysadminosaurus' IT blog: May 2014

Class A:
0.0.0.0 - 127.255.255.255 default subnet mask: 255.0.0.0 (or /8, 8 network bits and 24 host bits)
Class B:
128.0.0.0 - 191.255.255.255 default subnet mask: 255.255.0.0 (or /16, 16 network bits and 16 host bits)
Class C:
192.0.0.0 - 223.255.255.255 default subnet mask: 255.255.255.0 (or /24, 24 network bits and 8 host bits)
Class D: (Used for multicasting, not used for IP addressing)
224.0.0.0 - 239.255.255.255
Class E: (Unused)
240.0.0.0 - 255.255.255.255

Subnetting based on the number of networks:

Example A:

Say that our assigned network is 213.213.213.0 and we need to divide it into 5 networks.

Let's consult a table for our decimal to binary conversion to find what 5 is in binary. We work with 8 bits and we start from 0, so we work from 2⁰ to 2⁷:

2⁷	2⁶	2⁵	2⁴	2³	2²	2¹	2⁰
128	64	32	16	8	4	2	1
0	0	0	0	0	1	0	1

That means we need 3 bits to represent number 5 (2² is the 3rd bit, we start from 0). That also means we need to borrow 3 host bits for our network.

That means that in reality we will have 2³=8 networks.

Class C subnet mask: 255.255.255.0 (/24) or in binary:   11111111 11111111 11111111 00000000
Our subnet mask will be the default mask with the number of host bits that we are required to borrow. In our case, we need to borrow 3 host bits and move them as network bits. Note that we always borrow the first available network bits, so:

Our subnet mask:      11111111 11111111 11111111 11100000
In other words     :    255         255         255           224   (/27, since we have 27 network bits enabled)

So now, the number of our hosts will be the remaining host bits. In our case 32.
The number of usable hosts in our network though will be the remaining host bits minus the network address and the broadcast address, so 2 to the power of our remaining host bits minus 2.

So, in our case (2⁵)-2=32-2=30. We will have 30 hosts in 8 networks.

A faster way to find this number is with what Cisco refers to as the interesting part. The interesting part is
the part of the subnet mask which is not 255. We subtract this number from 256 and that will be our IP address increment.

This in our case is the fourth part of the IP address. So, In our case, 256-224=32.

Another way to find our IP address increment is to find out the least number where "1" was put in our subnet mask (in our case that was the third place from the end) which corresponds to "32" if we do a lookup on our binary table.

So our first IP allocation will be 213.213.213.32. Just write the increments and fill the spaces in-between.

213.213.213.0
213.213.213.32
213.213.213.64
213.213.213.96
etc.

So our network is:

213.213.213.0 - 213.213.213.31
213.213.213.32 - 213.213.213.63
213.213.213.64 - 213.213.213.95
etc.
.....

Example B:

We are given the network 130.130.0.0 and we want to divide it into 900 networks.

The sum of our 8-bit table (128 to 1) amounts to 255 (obviously). 8 bits are not enough. We need more entries:

1024	512	.................
0	1	.................

No need to calculate any more, we are sure that this is the correct bit, we go over after that.
So we need to borrow 10 host bits. 2¹⁰=1024 networks.

This is a Class B network so its network mask looks like this:

11111111 11111111 00000000 00000000

So borrowing 10 host bits, our netmask looks like this:

11111111 11111111 11111111 11000000 (/26)
255 255 255 192

256-192=64. So we have 64 hosts per network, 62 usable ones and our IP allocation
increments go like so:

130.130.130.0
130.130.130.64
130.130.130.128
etc.

Our IP ranges are:

130.130.130.0 - 130.130.130.63
130.130.130.64 - 130.130.130.127
etc.
.....

Example C:

We have the network 10.0.0.0 and we want to split it into 500 networks.

Let's consult a table for our decimal to binary conversion to find how 500 is represented:

The sum of our 8-bit table (128 to 1) amounts to 255 (obviously). 8 bits are not enough. We need one more entry:

256	128	64	32	16	8	4	2	1
1	1	1	1	1	0	1	0	0

That means that we need to borrow 9 host bits.

This is a class A address and its network mask looks like this:

11111111 00000000 00000000 00000000

So adding 9 bits makes our netmask like so:

11111111 11111111 10000000 00000000 (/17) or:
255 255 128 0

2⁹=512, so we have 512 networks.
256-128=128, so we have 128 hosts in total and 126 usable hosts per network,so our IP allocation increments and our ranges are the following:

10.0.0.0 - 10.0.127.255
10.0.128.0 - 10.0.255.255
10.1.0.0 - 10.1.127.255
10.1.128.0 - 10.1.255.255
10.2.0.0 - 10.2.127.255
10.2.128.0 - 10.2.255.255
.......

Now that we've gone through the basics and learned how to subnet, we need to note:
It's always a good idea to subtract one when trying to subnet based on networks just in case our number is on a binary calculation boundary (e.g. 128,64,32,16,8,4,2,1).

Let's go over an example again with our new method:

We have the network 192.168.0.0 and we need to divide it into 16 networks.

We need to subtract one so instead of calculating for 16, we calculate for 16-1=15:

128	64	32	16	8	4	2	1
0	0	0	0	1	1	1	1

We need 4 bits, so 2⁴; that means we will have 16 networks.

Class C so:

11111111 11111111 11111111 11110000
255 255 255 240 or /28 in CIDR notation.

And 2⁴=16 IP addresses and 14 usable hosts. Our IP allocation is arranged by 256-240=16 increments.

192.168.0.0 - 192.168.0.15
192.168.0.16 - 192.168.0.31
192.168.0.32 - 192.168.0.63
etc.

If we had done the calculation without subtracting one, we would have provisioned for 32 networks.

Let me quote from PCI-DSS questionaire D, for merchants:

1.2.1(a): Is inbound and outbound traffic restricted to that which is necessary for the cardholder data environment?
1.2.1(b): Is all other inbound and outbound traffic specifically denied (for example by using an explicit “deny all” or an implicit deny after allow statement)?

1.3.3: Are direct connections prohibited for inbound or outbound traffic between the Internet and the cardholder data environment?

10.5.5: Is file-integrity monitoring or change-detection software used on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert)?

10.6.1(a): Are written policies and procedures defined for reviewing the following at least daily, either manually or via log tools?
- All security events
- Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD
- Logs of all critical system components
- Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
10.6.1(b) Are the above logs and security events reviewed at least daily?

So, having these prerequisites in mind we can assume that a few of the things that PCI-DSS requires us to do are:

a) Deny all direct connections from the internet to the cardholder environment.
b) Deny all internet traffic from our servers to the internet unless this traffic is a response to a valid request.
c) Install an IDS on our system.
d) Check our systems' log files every single day.

So something like the network above would fit the bill. An isolated cardholder environment, with our load balancer being our systems' default gateway. A few iptables rules here and there and unsolicited internet access is denied from and to our cardholder environment. Cool.

Wait a minute. What did you just say? Did you just tell me that I have to log in manually onto every single server in my network and check the log files? Since my servers can't be connected to the internet there's no other way to do this, right? I will have to spend my entire day SSHing from host to host, looking at log files. What a dream job. All right, here's the real problem, so let's try to find ways to solve it.

Ideally, you want to have your systems mail you reports. How are my network interfaces? Are they all up? How about my IDS? Have any critical files changed? How are my RAID arrays? etc.

If your systems email you reports instead of having to manually logging in and checking a bunch of log files, you're looking of spending about 15 minutes every morning instead of countless hours.

So the core of the problem is exactly this:

How do we go about sending emails from my systems that are not directly connected to the internet to myself?

Image taken from http://debian-handbook.info/browse/stable/network-services.html

Solution a): Install Postfix on every single system
Well, OK I guess. But we'll have to allow access to a DNS server; that means that we'll have to have direct access to that host. It's not exactly "the internet", it's just one (or maybe two) host(s) so I guess we can handle that. And then to our mail server. So for this solution to work we need:
i ) Set up TCP forwarding between these IP addresses on our load balancer.
ii ) Set up exceptions on our iptables.
iii) Install and configure Postfix on all our servers.

Solution b): Install Postfix and a DNS server on the load balancer
This way we can lie to our systems. Essentially we'll be installing a DNS server only to create a split-brain DNS situation. That way, when our server needs to send an email they will use the mail server on our load balancer, which has access to the internet. We need to:
i ) Install and configure something like BIND or PowerDNS on our load balancer.
ii ) Create our zones, forwarders, etc that will be used by our LAN and make sure that our MX record points to the internal IP of our load balancer (192.168.0.10 in my example).
iii) Install and configure Postfix on our load balancer.

Solution c): Install Postfix on our load balancer and use SSMTP on our systems instead of the default mail client.
SSMTP is a mail client replacement that can lie. Awesome. We only need to do the following:
i ) Install and configure Postfix on our load balancer.
ii) Install and configure SSMTP on our systems.

So solution c is the most secure and uses the less resources in comparison to all other solutions. No need to guess which one I'm going to use!

I'm going to be using a RHEL-based distro for our example.

SSMTP can be found in the EPEL repo so if we don't have it let's download and enable it.

This is for release 6.x :

[root@server ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@server ~]# rpm -Uvh epel-release-6*.rpm

In case you still have a 5.x release:

[root@server ~]# wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
[root@server ~]# rpm -Uvh epel-release-5*.rpm

Install SSMTP:

[root@server ~]# yum --enablerepo=epel -y install ssmtp

Time to configure SSMTP. The first file we need to configure is the revaliases file. This maps your users to mail server users. In my example I'll just map the local root account to the mail server postmaster account and the local www-data acount to the mail server no.reply account:

[root@server ~]# vi /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.

root:postmaster@foobar.com:192.168.0.10:25
www-data:no.reply@foobar.com:192.168.0.10:25

The other file we need to configure is the actual configuration file, the ssmtp.conf file. That's where you can specify if your fake mail server IP address, if it needs TLS, etc:

[root@server ~]# vi /etc/ssmtp/ssmtp.conf
#
# /etc/ssmtp.conf -- a config file for sSMTP sendmail.
#
# See the ssmtp.conf(5) man page for a more verbose explanation of the
# available options.
#

root=postmaster@foobar.com #That's where local root account email (such as system notifications) will be sent.
mailhub=192.168.0.10:25 #The IP address of our mailhub, in our case our load balancer.
#RewriteDomain=foobar.com #If you need to rewrite your mail headers so that the source of the IP address and the domain match use this option.
Hostname=smtp.foobar.com #If you need to rewrite the hostname of this system, use this option. domain (foobar.com) is optional.
FromLineOverride=YES #If you need to rewrite the "From:" header use this. Setting this to YES uses the From: value provided by the program that sends the e-mail. 
#UseTLS=YES #If you set up your mail server to use TLS, use this.
#AuthUser=no.reply@foobar.com #The username indicated here should be the username used to log into your mail server.
#AuthPass=password #The password indicated here should be the username used to log into your mail server.

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

# Use this RSA certificate.
#TLSCert=/etc/pki/tls/private/ssmtp.pem

# Get enhanced (*really* enhanced) debugging information in the logs
# If you want to have debugging of the config file parsing, move this option
# to the top of the config file and uncomment
#Debug=YES

Now we need to specify that we want to use ssmtp as our MTA (if we have another MTA already installed):

[root@server ~]# alternatives --config mta
There are 2 programs which provide 'mta'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/sbin/sendmail.postfix
   2           /usr/sbin/sendmail.ssmtp

Enter to keep the current selection[+], or type selection number: 2

Done!

The Sysadminosaurus' IT blog

Sunday, May 25, 2014

Subnetting made easy Part 1

Tuesday, May 13, 2014

Using SSMTP