Tag: security

How to secure your PHP Web App with a simple Firewall

How to secure your PHP Web App with a simple Firewall

I was trying to find a simple way to secure my PHP Web App when I realized how difficult it could be. Securing it the easy way cost more money than I’m willing to spend, so I decided to build my own solution.

old school firewall

What are your options?

Compiling nginx with ModSecurity isn’t easy, and I don’t think your WAF (Web Application Firewall) should be tied into your web server. If you want to simplify things, you could use Cloudflare or Sucuri, but that can be expensive. While Cloudflare works great and is fast, shouldn’t you have your own WAF? These services do offer more than just a WAF, so be sure to do your own research before committing¬†to any one solution.

Elite Hacker desktop

PHP Web App Firewall

I’m writing my PHP WAF in Go. The criteria I set for this project is fairly simple.


  • It needs to be uber fast
  • Handle XSS and SQL Injections
  • Work with Docker

The Journey

Two weeks ago I sketched the idea out on the back of an envelope. If nginx could talk to my Go service, and my Go service could talk to PHP-FPM, then this might be a pretty easy solution. I know that nginx has the proxy_pass config option and that Go can handle HTTP traffic. But how can Go talk to PHP-FPM? I did some research and tried out a few different FastCGI client packages for Go until I found one that suited my needs. Now I have two ends of the stick figured out, but I’ve yet to even think about what happens in the middle.

I ended up finding a Go package that does an excellent job at filtering XSS. I then wrote some middleware for HTTP and used that Go package to filter any requests that contain an XSS attempt.

But what about SQL injection? Well, I found some regular expressions that match common SQL injection and implemented those into my HTTP Request analyzer. If any SQL injection is detected, it kills the request and your PHP Web App never sees it. At the time of writing this, I still need to implement more security measures.

I’ve also built a Docker container that runs this Go app as a service and is pretty easy to set up. While I haven’t used this for anything in production, I have tested it and it was able to handle several thousand requests a second.


This code should actually work with any language that can use FastCGI as a means of communication, but I haven’t tested it. I’m looking for people to help me finish this project since I’m just now learning Go. Please feel free to fork my repo if you can contribute in any way.


Securing a Server

Securing a Server

This post will cover securing a Linux server. Back in the day, I started with Red Hat 6 and Slackware 4; I still have a book from when I was learning Red Hat 6. I also ended up learning FreeBSD, but I’ll save that story for another post.

I’m not claiming to be an expert in server security, but if you follow these tips, it’ll be a good start in the right direction. I don’t recommend you learning these things on a production server, because I have locked myself out several times, probably more than I can count. You try these out on a test server; you can create a new DigitalOcean droplet for free if you don’t already have an account.

SSH keys

Ideally, your server is on a speedy network, and the specs are decent. However, this also may help people brute force your passwords. An alternative to using a password is to use an SSH key, they are even more secure that passwords.

An SSH key is much harder, if not nearly impossible, to crack. Quantum computing may change how all encryption and security works, but we don’t need to worry about that right now. Your SSH key can be protected with a passphrase, it will help prevent anyone being able to use your key, or you can have one without a passphrase. It’s a personal preference you may decide which way to do it. They would actually need your private key (file) even to attempt to use it, so don’t give out your private key.

If you want to get access to a server, you can send someone your public key without worrying about any consequences. Before, you would have to call someone or email them your password which can be risky.

Here is a good tutorial on how to setup SSH keys.


Some people prefer to use ed25519 keys since they are smaller and faster. These are designed to work with ECDH (Elliptic Curve Diffie-Hellman) key agreement scheme.

I am not a fan of the ECC (Elliptic Curve Cryptography), even though I use it every day. If I recall correctly, a few companies and the NSA all claim they own the patent rights for ECC. I don’t trust something that is faster and smaller that is supposedly more secure. I’ve done quite a bit of research on this, and I understand how it can be smaller and quicker. I don’t have any evidence that it isn’t secure, it’s just speculation.

Change your SSH port

Changing the port SSH listens on can help tremendously. There are lots of botnets that run port scans on the internet every day. They look for standard open ports, like port 22, which is what SSH uses. If they scan your server and see you have that port open, they will then try to brute force your server. If they don’t know what port you’re listening on, then they generally move on.

DigitalOcean has an excellent tutorial on changing your SSH port.


If they don’t move on and they continue to hammer your server, you should create a firewall rule that blocks them. It’s probably impossible to monitor your server(s) 24 hours a day, so I highly suggest you use fail2ban to do it for you. You can configure it to block an IP address after X amount of attempts and for how long. It is highly customizable and one of my favorite things to keep an eye on. When I check my fail2ban stats and see the number of bans, it makes me happy.

This works along with the firewall iptables. Here is a helpful tutorial on getting fail2ban setup on CentOS.


You should employ these suggestions, and I encourage you to research these things on your own. Come to your own conclusions on what is best for you and your infrastructure.

If you decide the methods above are helpful, then that is awesome, but you may require more. You might need to be PCI or HIPAA compliant, and that’ll take more work, so keep researching these topics.

If you’re interested in learning more about ECC, check out this overview of cryptography by Gary Kessler.


These are suggestions and not fool-proof methods to protect your server. These are some of the things I do when I’m setting up a new server.