Institutions hosting their own FlightPath installation should take appropriate steps to protect their server from unauthorized access, automated vulnerability scanning, and other malicious traffic.

The following recommendations are intended for system administrators responsible for maintaining a FlightPath installation.

 

Use HTTPS exclusively

All production FlightPath installations should use HTTPS with a valid SSL/TLS certificate. Configure your web server to redirect HTTP requests to HTTPS.

Using Let's Encrypt with certbot on your Linux server is free and probably the easiest way to accomplish this.

 

Protect Against Automated Scanning and Attacks

Publicly accessible web servers routinely receive automated requests looking for vulnerabilities in popular applications, exposed configuration files, and other potentially sensitive resources.

We recommend using Fail2ban or an equivalent security solution to help identify and block repeated suspicious activity.

 

Using Fail2ban

Fail2ban is a server-level security tool that monitors log files for suspicious activity and temporarily blocks offending IP addresses. It operates independently of FlightPath.

The following example is intended for Ubuntu 24+ with Apache 2.4. It provides conservative protection against automated vulnerability scanning without permanently blocking visitors.

1. Install Fail2ban

Connect to your server using SSH and run:

sudo apt update
sudo apt install fail2ban

Enable and start the service:

sudo systemctl enable --now fail2ban

2. Create an Apache Filter

Create a filter that identifies repeated HTTP 403 (Forbidden) and 404 (Not Found) responses in Apache's access logs:

sudo nano /etc/fail2ban/filter.d/apache-flightpath.conf

Add the following contents:

[Definition]
failregex = ^<HOST> \S+ \S+ \[[^\]]+\] "[^"]*" (?:403|404) \S+
ignoreregex =

This filter assumes Apache's standard combined access log format. Administrators using customized logging formats may need to adjust the expression.

3. Configure the Jail

Create a separate jail configuration file:

sudo nano /etc/fail2ban/jail.d/flightpath.conf

Add the following contents:

[apache-flightpath]
enabled = true
filter = apache-flightpath
port = http,https
logpath = /var/log/apache2/*access.log
backend = auto

maxretry = 10
findtime = 15
bantime = 3600

This configuration uses the following limits:

• maxretry = 10: Ban after 10 matching responses.
• findtime = 15: Count responses within a 15-second window.
• bantime = 3600: Ban the IP address for one hour.

These values are intentionally conservative. An occasional missing page or access-denied response will not result in a ban. However, legitimate users generating many errors in a short period could still be blocked.

If your server uses a reverse proxy, CDN, or load balancer, verify that Apache records the actual client IP address before enabling this jail. Otherwise, Fail2ban could ban the proxy rather than the offending visitor.

4. Test the Filter

Before enabling the jail, test the filter against your Apache logs:

sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-flightpath.conf

Review the results to confirm that the filter recognizes the expected 403 and 404 responses.

5. Enable the Configuration

Check the configuration for errors:

sudo fail2ban-client -t

If the configuration is valid, restart Fail2ban:

sudo systemctl restart fail2ban

Check that the jail is running:

sudo fail2ban-client status apache-flightpath

The output should show the number of currently failed requests, total failures, and banned IP addresses.

6. Review and Manage Bans

To view the current status and banned IP addresses:

sudo fail2ban-client status apache-flightpath

To manually unban an IP address:

sudo fail2ban-client set apache-flightpath unbanip 192.0.2.100

Replace 192.0.2.100 with the actual IP address you want to unban.

To monitor Fail2ban activity:

sudo tail -f /var/log/fail2ban.log

Additional Recommendations

• Review banned IP addresses periodically to identify possible false positives.
• Consider excluding trusted administrative IP addresses using Fail2ban's ignoreip setting, if those addresses are static and trusted.
• Ensure that your firewall supports the banning action selected by Fail2ban.
• Adjust the log path if your Apache installation uses a different location or separate virtual-host logs.
• Do not enable multiple overlapping Fail2ban jails without understanding how their rules interact.

These instructions provide a starting point, not a complete security solution. Administrators should review the configuration and adapt it to their hosting environment.

 

Block Common Vulnerability Scans

Apache administrators may also use rewrite rules to reject requests for resources that are not part of FlightPath, such as WordPress administration pages, exposed environment files, Git repository metadata, and known debugging endpoints.

There are such rules already in place in the .htaccess file included with FlightPath.

These rules can prevent unnecessary requests from reaching FlightPath's PHP application and reduce the resources consumed by automated scanners.

Administrators should ensure that any blocking rules are compatible with their installation and do not interfere with legitimate FlightPath functionality.

 

Restrict Access to Sensitive Files

Ensure that configuration files, private uploaded files, backups, and other sensitive resources cannot be downloaded directly through the web server.

File and directory permissions should follow the principle of least privilege. Avoid granting unnecessary write access to the web server process.

If Git is used to deploy FlightPath, ensure that the .git directory is not publicly accessible.

 

Configure a Firewall

Use a server firewall or cloud-provider security group to restrict incoming connections to necessary services. Typically, public access should be limited to HTTP and HTTPS, with administrative access such as SSH restricted whenever practical.

 

Maintain Regular Backups

Maintain regular backups of the FlightPath database, configuration files, and uploaded files. Backups should be stored securely, preferably in a separate location from the production server.

Periodically test backup restoration procedures to ensure that data can be recovered when needed.

 

Monitor Your Server

Review web server logs, PHP error logs, and FlightPath's application logs for unusual activity or recurring errors.

Monitoring can help administrators identify configuration problems, attempted attacks, and performance issues before they become more serious.

 

Additional Considerations

These recommendations are not a complete server security checklist. Each institution should follow its own security policies and applicable requirements for protecting student information.

Institutions that prefer not to maintain their own servers can learn about professional hosting and support through FlightPath Academics.