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?
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 :
In case you still have a 5.x release:
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:
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:
Now we need to specify that we want to use ssmtp as our MTA (if we have another MTA already installed):
Done!
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 |
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*.rpmIn 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*.rpmInstall SSMTP:
[root@server ~]# yum --enablerepo=epel -y install ssmtpTime 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.
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!
Hiya very nice web site!! Man .. Excellent .. Amazing .. I'll bookmark your website and take the feeds additionally? I am happy to seek out a lot of helpful information here in the put up, we'd like work out extra techniques on this regard, thank you for sharing. . . . . .
ReplyDelete