OPS535-lab-spf

OPS535 Lab 7

Purpose

In this lab you will learn to configure mail servers to use extra security to filter unwanted and suspicious email. You will also learn to configure DNS servers to provide extra records to allow mail servers to authenticate incoming mail.

Pre-Requisites

Your network must be part of the class network, with a functioning connection to the outside world. You also need a functioning DNS domain in order for mail to be properly transported between your machines (and ppotentially to other domains). You need a basic knowledge of the SMTP protocol (covered in lab 5) in order to perform most steps in this lab.

Investigation 1: Configuring Postfix to use Restrictions

Perform the following steps as root on your VM1

1. Using the nc command and the smtp commands you already learned, connect to VM3 and send an email to your root user. Make sure to use the address and hostnames of your own machines.

   > nc 192.168.83.3 25
   220 vm3.pcallagh.ops ESMTP Postfix
   helo host.pcallagh.ops
   250 vm3.pcallagh.ops
   mail from: root@host.pcallagh.ops
   250 2.1.0 Ok
   rcpt to:root@vm3.pcallagh.ops
   250 2.1.5 Ok
   data
   354 End data with <CR><LF>.<CR><LF>
   test
   .
   250 2.0.0 Ok: queued as 728CB82ECF6
   quit
   221 2.0.0 Bye

2. Send another email, but this time skip the HELO command.
   • Notice that the email is accepted anyway.
3. Edit the /etc/posftfix/main.cf file on vm3 and add the following line (restarting once you have done so):

   smtpd_helo_required = yes

4. Try sending an email without the HELO command again.
   • Notice that it is immediately rejected.
   • This simple step will filter out a surprising amount of spam, as many spam email servers skip the helo step in order to save time when sending massive amounts of email.
5. Send another email using nc, this time include the helo command, but just put junk in it.
   • smtpd_helo_required doesn’t do anything to check the data in the helo command, it just requires that the connecting server says helo.
6. Edit the /etc/posftfix/main.cf file on vm3 and add the following line (restarting once you have done so):

   smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, permit

   • Send another email, again using junk in the helo command.
   • Notice that the email does get rejected on the basis of the non-fully-qualified hostname, but that it does not happen until you try to use the rcpt to command.
   • By default, most rejections will behave this way, gathering as much information as possible about the potentially malicious machine, but preventing it from actually sending the mail.By default, most rejections will behave this way, gathering as much information as possible

   about the potentially malicious machine, but preventing it from actually sending the mail.

7. We will force rejections to happen immediately, so that you can see the effects of each parameter as we add them.
   • Edit the /etc/posftfix/main.cf file on vm3 and add the following line:

   smtpd_delay_reject = no

   • I am going to stop reminding you to restart the service after changing every parameter, just assume that you should do so anytime you make a change to the configuration file.
8. try to send your email again.
   • This time you should see the rejection message as soon as you try to use the malformed helo command.
   • There are other restrictions you can use to filter mail based on the contents of the helo command, but I will let you explore those yourself.
9. You can also filter mail based on the client machine attempting to connect to you. For example, if it doesn’t have an A or PTR records in DNS, then it almost certainly is not a legitimate email server.
   • Edit the /etc/posftfix/main.cf file on vm3 and add the following line:

   smtpd_client_restrictions = reject_unknown_client_hostname, permit

   • Checking the effects of this might be more complicated, as you will need a machine that doesn’t exist in DNS.
     • Use the ip command to remove the expected ip address from your vm2, and to give it a different address in the same network.
     • Try to connect with nc again. You should get rejected immediately.
   • Edit the smtpd_client_restrictions line you just added to /etc/posftfix/main.cf file on vm3:

   smtpd_client_restrictions = permit_mynetworks,
   reject_unknown_client_hostname, permit

   • Try to connect with nc again. This time you are allowed to connect. Because you are in a network defined in the servers mynetworks parameter (that is, your other machine is ‘trusted’), you pass this check and are not subject to the reject_unknown_client_hostname restriction.
10. You can also filter mail based on the sender’s address. For example, if it isn’t a properly formatted email address, it is probably spam.
    • dit the /etc/posftfix/main.cf file on vm3 and add the following line:

    smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit

    • These will reject email if the sender’s address provided in the mail from command is not a fully qualified email address, or if the sending email address does not have an MX record that matches it (this is why your emails to Seneca’s servers in OPS335 often failed).
    • Notice the inclusion of two settings we also used in previous restrictions, particularly permit_mynetworks, exempting your own machines from these checks.
    • Back on vm2, us the nc command to try to send emails that will pass and fail this restriction.
11. You can filter mail based on the recipient’s address as well. For example, if it isn’t a properly formatted email address, it is possibly spam.
    • Edit the /etc/posftfix/main.cf file on vm3 and add the following line:

    smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_recipient, reject_unauth_destination, permit

    • These will reject email if the recipient address provided in the rcpt to command is not a fully qualified email address, or if email address it is being sent to would not match your mydestination parameter.
    • Notice the inclusion of two settings we also used in previous restrictions, particularly permit_mynetworks, exempting your own machines from these checks.
    • Back on vm2, us the nc command to try to send emails that will pass and fail this restriction.
12. There are even restrictions you can place on email that you are relaying to another server. These are governed by the smtpd_relay_restrictions parameter.
    • Edit the /etc/posftfix/main.cf file on vm3 and add the following line:

    smtpd_relay_restrictions = reject_unauth_destination, reject_unknown_recipient_domain, permit

    • These restrictions will reject that the sending MTA tried to relay through your server if the destination is not in relay_domains, or if the domain has no MX record.
    • Note that the reject_unauth_destination setting can show up here and in recipient restrictions. It is the same parameter, but has a different effect.
13. There are more restrictions that you can place on incoming email, but the checks you have added in this investigation will eliminate the vast majority of spam. Anything that is not following the RFCs properly (e.g. skipping the helo command) will be blocked. One thing you will notice about the checks related to DNS records is that they are only checking that therecords are there, not that they are correct, or that the server sending us mail actually is the machine it is claiming to be.

Completing the Lab

Your DNS and email servers are now cooperating to filter email and prevent malicious email from being sent to your users. They are also providing information making it difficult for others to impersonate your domain. There are more restrictions that can be used, and situations where your spf records would look different, but this is a good basis for any domain.

Follow the instructions on blackboard to submit the lab.