This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I'll release the Meeting Planner code as open-source examples you can learn from. I'll also address startup-related business issues as they arise.

The production server for Meeting Planner currently runs at Digital Ocean (see other tutorials about them at Envato Tuts+.) In today's episode, we'll dive into the basics of web server security. I'll cover securing the Linux VPS running Meeting Planner and some basic Yii security. In the next episode, I'll dive more into programmatic Yii application security.

I do participate in the comment threads below, so please share your feedback. Please let me know if there are security topics you feel that I missed. I'm also open to new feature ideas and topic suggestions for future tutorials.

As a reminder, all of the code for Meeting Planner is written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out our parallel series Programming With Yii2.

If you haven't yet, try out Meeting Planner right now by scheduling your first meeting. Feel free to post feedback about your experience in the comments below. 

Hosting and VPS Security

Common Resources

If you're running a generic Linux VPS, you may want to review my earlier Envato Tuts+ tutorial, Securing Your Server Login. It covers a number of steps which we'll revisit today, including SSH security and firewalls.

Digital Ocean is also a great resource for security practices. An Introduction to Securing your Linux VPS is one of the best overviews that they offer. Plus, they have cool graphics.

Here are three other articles they offer which I utilized for the background in this tutorial:

• 7 Security Measures to Protect Your Servers
• UFW Essentials: Common Firewall Rules and Commands
• How To Protect an Apache Server with Fail2Ban on Ubuntu 14.04
  

Keeping the Server Updated

Firstly, it's vital that you keep your server up to date with regular updates and upgrades. This integrates security patches from software (and open source) providers that you're using.

Here are the basic steps—you'll likely be familiar with them:

$ sudo apt-get update
Get:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB]
Get:2 http://security.ubuntu.com trusty-security/main Sources [118 kB]
Get:3 http://security.ubuntu.com trusty-security/universe Sources [38.0 kB]
...
Ign http://mirrors.digitalocean.com trusty/universe Translation-en_US
Fetched 5,298 kB in 10s (526 kB/s)
Reading package lists... Done

Dist-upgrade uses some intelligence to manage the interdependencies of updated packages:

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-headers-3.13.0-85 linux-headers-3.13.0-85-generic
  linux-headers-3.13.0-86 linux-headers-3.13.0-86-generic
 ...
Setting up cloud-init (0.7.5-0ubuntu1.19) ...
Leaving 'diversion of /etc/init/ureadahead.conf to /etc/init/ureadahead.conf.disabled by cloud-init'
Processing triggers for libc-bin (2.19-0ubuntu6.9) ...

To ensure that it takes full effect, you may need to reboot on occasion. I always stop my database and then restart:

$ sudo service mysql stop
mysql stop/waiting
$ sudo reboot
$
Broadcast message from meetingplanner.io
    (/dev/pts/0) at 13:51 ...
The system is going down for reboot NOW!
Connection to meetingplanner.io closed by remote host.
Connection to meetingplanner.io closed.

When Meeting Planner has more users, more elaborate restart mechanisms may be needed.

Configuring SSH Login

You have the option of using your private key when creating a Digital Ocean droplet. When I set up Meeting Planner, I repeated the steps I outlined here: Securing Your Server Login.

I also moved SSH login to a custom port, not the commonly used (and attacked) port 22.

Setting Up a Firewall

Next, I installed UFW, the uncomplicated firewall:

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)?

However, I did not say yes to that request. The warning reminded me to double-check all of my SSH requirements.

For example, I turned off the default SSH port and turned on the one that I am using:

$sudo ufw allow 31345
$sudo ufw deny 22

Then, I set a sudo request for the future to disable UFW in case my settings weren't correct:

$sudo at now +5 minutes
warning: commands will be executed using /bin/sh
at> sudo ufw disable
at> <EOT>
job 9 at Mon Jul 18 16:14:00 2016

Then, I enabled UFW and ran through my remaining settings:

$sudo ufw default deny incoming
$sudo ufw default allow outgoing
$sudo ufw allow http
$sudo ufw allow https
$sudo ufw deny mysql
$sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Here are the results:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
31345                      ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         DENY        Anywhere
3306                       DENY        Anywhere
31345 (v6)                 ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
22 (v6)                    DENY        Anywhere (v6)
3306 (v6)                  DENY        Anywhere (v6)

Note: Because my database is currently running on the same server as Meeting Planner's web services, I can block port 3306. However, as usage for the site scales to multiple servers, changes will be needed.

I also edited the UFW configuration to enable the firewall when the server restarts:

$sudo nano  /etc/ufw/ufw.conf
enabled = on

Because of the delayed disable command, I had to enable UFW again after five minutes.

In addition to my Securing Your Server Login, the Digital Ocean guides UFW Essentials: Common Firewall Rules and Commands and How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server are helpful when configuring UFW.

Setting Up SSL

For the security of people using Meeting Planner, I also set up SSL as described in Using Let's Encrypt SSL With Your WordPress Project.

And, you may notice, I allowed https access on port 443 when setting up the firewall above. Requests to http://meetingplanner.io automatically redirect to https://meetingplanner.io.

Getting Started With Yii2 Application Security

Beyond the Linux security foundation, we also need to be thoughtful about securing the Yii Framework on top of PHP. You may wish to read Programming With Yii2: Security, most of which we'll review in the next episode.

However, today, we'll implement some basic access control features for Meeting Planner.

Access Control

One of the initial benefits of using a PHP MVC framework is that all requests for pages are routed through a single index.php file. As I described in Programming With Yii2: Routing and URL Creation, Yii carefully manages incoming requests for pages and directs them to the appropriate controllers and action methods.

In addition, it's our job to secure controller requests when they come into the application. Primarily, who is this person and do they have the right to access this page?

As discussed in the Yii2 Security tutorial, Yii has a variety of options for managing access. Meeting Planner primarily uses the Access Control capability.

Securing Front-End Application Requests

Here's an example of traffic coming into the Meeting Controller which users commonly access:

class MeetingController extends Controller
{
  public function behaviors()
  {
    return [
    ...
    'access' => [
        'class' => \common\filters\MeetingControl::className(), // \yii\filters\AccessControl::className(),
        'only' => ['index','view','create','update','delete', 'decline','cancel','command','download','wizard','trash','late'],
        'rules' => [
          // allow authenticated users
           [
               'allow' => true,
               'actions'=>['create','index','view','update','delete', 'decline','cancel','command','download','wizard','trash','late'],
               'roles' => ['@'],
           ],
          [
              'allow' => true,
              'actions'=>['command'],
              'roles' => ['?'],
          ],
          // everything else is denied
        ],
    ],
  ];
  }

The access behavior safeguards all the methods mentioned in 'only'. The actions listed with roles '@' require authenticated users—in other words, only users that have logged in can see these pages. Users that aren't logged in are redirected to the default home page. However, pages with roles '?' are open to the public.

So, for example, only an authenticated user can create a meeting, but anyone can enter the application through the meeting/command URL. That's because we use the command URL widely in emails, and it has another layer of authentication, described in the Delivering Invitations tutorial. 

The command URL allows users that aren't logged in (and even meeting participants that have never been to the site before) to securely access specific pages.

Securing Back-End Application Requests

For the back-end system of Meeting Planner, only administrators can access these pages. Because administrators are denoted in our User table in a custom, application-specific way, I had to build a custom Access rule to verify them. Yii's basic roles only support authenticated @ and unauthenticated ?.

Let's look at the back-end MessageController for sending site-wide email updates to our users:

class MessageController extends Controller
{
    /**
     * @inheritdoc
     */
    public function behaviors()
    {
      return [
        'access' => [
          'class' => AccessControl::className(),
          'rules' => [
            [
              'allow' => true,
              'matchCallback' => function ($rule, $action) {
                  return (!\Yii::$app->user->isGuest
                    && \common\models\User::findOne(Yii::$app->user->getId())->isAdmin());
                }
            ],
          ],
        ],

The custom rule ensures that the user is not a guest and passes isAdmin() before forwarding them to the proper action. Other users are redirected to the back-end login page.

We've accomplished a lot today, but there's still a lot to do.

Looking Ahead

If you run a server, you've probably appreciated today's review of basic Linux and hosting security. In the next episode, we'll explore security steps related more closely to the Yii Framework and the Meeting Planner application.

Watch for upcoming tutorials in the Building Your Startup With PHP series. There are a few more big features coming up.

Related Links

• Meeting Planner
• Follow Meeting Planner's Funding Profile
• Securing Your Server Login
  
• Programming With Yii2 Series (Envato Tuts+) 
• The Yii2 Developer Exchange