TLDR

1. Update the servers local firewall to only allow HTTP/HTTPS traffic from the following subnet: 10.137.9.0/24.

2. We recommend that you configure your servers local firewall only to allow incoming http/https traffic from the Web Application Firewall. This can be done using the following Uncomplicated Firewall (UFW) Linux command: 

   sudo ufw allow from 10.137.9.0/24 proto tcp to any port 80

   sudo ufw allow from 10.137.9.0/24 proto tcp to any port 443

   Remember to delete the existing rule allowing http/https traffic to your firewall, 

   as the above commands are additional rules to UFW. 

   Otherwise, you could end up having an open firewall allowing ingoing http/https traffic from elsewhere.

   Below is an example of a correctly configured UFW:
   
   To Action From
   -- ------ ----
   80/tcp ALLOW 10.137.9.0/24
   443/tcp ALLOW 10.137.9.0/24

   (Please only copy/paste the above if you are familiar with UFW 

   and already have existing UFW rules.)

   Please contact servicedesk@sdu.dk  if you need assistance setting up your local firewall.

3. Change your web server’s configuration to use the X-Forwarded-For header as the originating client IP. This ensures that the correct originating client IP is displayed in the server’s web logs.

   We have created to following guides on how to setup XFF:

   • Apache2
   • NGINX

Q: What is a Web Application Firewall

A web application firewall is like a security guard for your website or online application. It stands between your website and the internet, just like a security guard stands between your house and the outside world. Its job is to keep an eye on all the incoming and outgoing traffic to your website.

The web application firewall watches out for any suspicious or dangerous activity. It checks every request that comes to your website, looking for signs of hackers or attackers trying to break in. It also inspects the data that goes out from your website to make sure no sensitive or harmful information is leaking.

When the web application firewall detects something fishy, it takes action to protect your website. It can block suspicious requests, filter out malicious data, or even alert you about the potential threat. It acts as a shield, defending your website from various attacks like hacking attempts, data breaches, or unauthorized access.

In summary, a web application firewall is like a security guard that monitors and protects your website from bad guys on the internet. It’s a special tool that keeps your website safe and secure.

Q: Why is it necessary?

Protecting SDU, its research and researchers is of utmost importance. Web servers are a primary target for hackers and bad actors trying to compromise SDU. As a response SDU IT provides a Web Application Firewall to better protect SDU’s web servers and resources.

A web application firewall is necessary for several reasons:

1. Protection against attacks: Websites and online applications are frequent targets for hackers and malicious activities. A web application firewall acts as a barrier between your website and potential threats, blocking known attack patterns and defending against various types of attacks like SQL injection, cross-site scripting (XSS), and distributed denial-of-service (DDoS) attacks. It helps safeguard your website and the sensitive data it handles.

2. Vulnerability mitigation: Web applications can have vulnerabilities or weaknesses that attackers exploit to gain unauthorized access or manipulate data. A web application firewall can identify and mitigate these vulnerabilities by applying security rules and patches, preventing attackers from exploiting them. It acts as an additional layer of defense, reducing the risk of successful attacks.

3. Traffic filtering: Web application firewalls analyze incoming and outgoing web traffic, inspecting requests and responses to ensure they meet certain security criteria. They can filter out malicious traffic, such as suspicious requests, malformed data, or payloads containing malware or viruses. By blocking or flagging such traffic, the firewall helps prevent harmful content from reaching your website or its users.

4. Protection of sensitive data: Many web applications handle sensitive user information like passwords and personal data. A web application firewall can monitor data transmission and enforce security measures to safeguard this information. It can detect and prevent unauthorized access or data leakage, protecting the privacy and integrity of sensitive data.

Overall, a web application firewall is necessary to ensure the security, availability, and integrity of your website or online application. It helps defend against attacks, mitigate vulnerabilities, filter malicious traffic, protect sensitive data, and maintain regulatory compliance.

Q: Do I need to change anything?

Yes.

WAF is transparent by design, however it requires changes to logging and local firewall configuration.

1. Update the servers local firewall toonly allow HTTP/HTTPS traffic from the following subnet:10.137.9.0/24. Please contact servicedesk if you need assistance configuring the servers local firewall.

2. Use the X-Forwarded-For header to identify the originating client connecting to the web server.

Q: Do I still need to update and secure my server, when it is now protected by WAF?

Yes.

You still need to keep your server, containers and/or apps up-to-date. WAF is not a “fix it all” solution. We always recommend keeping all aspects of your web server up-to-date.

While a web application firewall provides an essential layer of security, it is not foolproof and cannot guarantee protection against all types of attacks. It helps defend against common attack vectors and known vulnerabilities, but new and sophisticated attacks may bypass certain security measures. It is crucial to keep your web applications and server up to date.

Please contact servicedesk if you have any questions regarding the security of your web server.

I cannot login nor connect to my server anymore

Generally speaking all servers protected by the Web Application Firewall will have a separate.srvDNS record created. Please use the.srvDNS record when connecting to the server on any service other thanWEB. There will be exceptions to the general rule. Please contact servicedesk if you have any questions or need assistance.

Technical explanation

The Web Application Firewall requires a reserved DNS record(s) to point it’s virtual server (Virtual IP). If a separate.srvDNS record is not createdSSHtraffic will not be answered as the virtual server is not configured to answer SSH traffic.

test.sdu.dk (HTTPS)

1. Client initiates HTTPS (443/tcp) traffic to DNStest.sdu.dk.
2. DNS resolves the recordtest.sdu.dkto WAF virtual server IP: 10.137.8.10. The WAF virtual server is only configured to answer traffic initiated to port443/tcp.
3. WAF forwards the request to the server on port 80 (SSL Offloading) or 443.
4. Traffic reaches the server.

test.sdu.dk (SSH)

1. Client initiates SSH (22/tcp) traffic to DNStest.sdu.dk.
2. DNS resolves the recordtest.sdu.dkto WAF virtual server IP: 10.137.8.10. The WAF virtual server is only configured to answer traffic initiated to port443/tcp.
3. WAFrejects the request as it is does not allow traffic on the requested port.
4. Traffic does not reach the server.

test.srv.sdu.dk (SSH)

1. Client initiates SSH (22/tcp) traffic to DNStest.srv.sdu.dk.
2. DNS resolves the recordtest.srv.sdu.dkto the servers own IP: 10.137.9.110.
3. Traffic reaches the server.

Why am I seeing a “Access Denied” or “Forbidden” error when accessing my website?

This error indicates that the web application firewall has blocked your access due to suspicious or unauthorized activity. It could be triggered by various factors, such as an incorrect login attempt, accessing restricted areas, or triggering security rules. Please contact servicedesk to investigate and resolve the issue.

Can the web application firewall block legitimate users or traffic?

While web application firewalls strive to block malicious traffic, there is a possibility of false positives where legitimate users or activities get flagged or blocked. This can happen if the firewall’s security rules are too strict or if the firewall is not properly configured. If you believe your access is being erroneously blocked, reach out to servicedesk to investigate and resolve the issue.

Why are Larger Than 30 MB Uploads Restricted?

When employing a Web Application Firewall (WAF) to fortify your web application, it’s essential to limit file uploads to 30 MB or less. In this scenario, the manual approval of larger files by website administrators isn’t an option. Instead, administrators must supply the upload URI/URL to be whitelisted within the WAF. Here’s why this approach is imperative for protecting the WAF itself:

WAF Protection:

The foremost reason for capping file uploads at 30 MB is to safeguard the Web Application Firewall (WAF) from potential denial of service (DoS) attacks. Allowing excessively large file uploads can be exploited by malicious actors to flood the WAF with data, potentially overwhelming its resources and rendering it ineffective in mitigating attacks.

Efficient Resource Allocation:

WAFs are resource-intensive applications designed to analyze and filter incoming traffic for security threats. Large file uploads can consume a significant amount of these resources, affecting the WAF’s ability to efficiently protect your web application. By imposing a size limit, you ensure that the WAF allocates its resources judiciously.

Security Optimization:

Smaller file sizes facilitate faster and more precise security inspections. Malicious code or threats hidden within larger files can be more challenging to detect quickly. A reasonable file size limit streamlines the WAF’s analysis process, reducing the risk of security breaches.

Administrative Control:

To facilitate secure handling of larger files, website administrators are required to communicate the upload URI/URL that necessitates larger file sizes. This information enables security teams to whitelist specific locations within the WAF, ensuring that legitimate larger file uploads are accommodated while preserving the WAF’s protective capabilities.

In summary,

limiting file uploads to 30 MB when protected by a Web Application Firewall is primarily a precautionary measure to safeguard the WAF itself. To handle larger files securely, administrators must provide the upload URI/URL to be whitelisted within the WAF, allowing for the protection of the WAF from potential DoS attacks while maintaining the security and functionality of your web application.

Websocket and HTTP2 support

WebSocket and HTTP/2 are both advanced protocols that offer significant benefits over their predecessors, but they require specific settings in an F5 Big IP setup to function optimally. The need for these specific settings largely depends on whether your web server requires HTTP/2 or WebSocket support. There for it is necessary that we are informed if your web server requires these functions.

WebSocket:

WebSocket is a protocol that provides full-duplex, bidirectional communication over a single TCP connection. It is commonly used for real-time applications like chat, online gaming, and financial trading platforms. To support WebSocket effectively, F5 Big IP requires specific configurations:

1. SSL Offloading: If your web server uses HTTPS for WebSocket communication (which is common), F5 Big IP must be configured to handle SSL termination (SSL offloading). This means that F5 terminates the SSL connection from clients and establishes a new secure connection to your web server. This is essential for inspecting and managing WebSocket traffic.

2. HTTP Profile Settings: WebSocket traffic is initially an HTTP request, but the server and client can then upgrade this connection to a WebSocket connection. F5 Big IP should be configured with an appropriate HTTP profile that allows WebSocket upgrade requests to pass through. Make sure WebSocket-specific headers, such as the Connection: Upgrade and Upgrade: websocket headers, are handled correctly.

3. Persistence Profiles: WebSocket connections can be long-lived, and it’s important to ensure that client requests are consistently routed to the same backend server to maintain the WebSocket connection’s integrity. F5’s persistence profiles can help achieve this.

HTTP/2:

HTTP/2 is the latest version of the HTTP protocol, designed to improve website performance by allowing multiple requests and responses to be multiplexed over a single TCP connection. To support HTTP/2, F5 Big IP needs specific settings:

1. SSL/TLS Support: Like WebSocket, HTTP/2 often relies on secure connections (HTTPS). Therefore, F5 Big IP should be configured to handle SSL/TLS termination and encryption to ensure secure communication between clients and the F5 device.

2. HTTP/2 Profile: F5 Big IP should be configured with an HTTP/2 profile that understands and manages HTTP/2 connections. This includes handling features like header compression, prioritization, and stream multiplexing that are unique to HTTP/2.

3. ALPN Protocol Negotiation: ALPN (Application-Layer Protocol Negotiation) is a TLS extension that allows the client and server to negotiate the application protocol to be used within the SSL/TLS connection. For HTTP/2, the ALPN settings should be configured to indicate that HTTP/2 is supported.

In summary

The specific settings required in an F5 Big IP setup for WebSocket and HTTP/2 support are critical to ensuring the proper functioning and performance of these advanced protocols. It’s crucial to understand whether your web server requires these protocols and configure your F5 Big IP accordingly. Proper configuration not only ensures compatibility but also enhances security, load balancing, and overall application performance.

Setting up X-Forwarded-For as the originating client IP header - Apache2 and NGINX

Apache2

Prerequisites

Apache2 web server installed on your system. Basic familiarity with Apache2 configuration.

Step 1: Enable or ensure that remoteip is enabled

sudo a2enmod remoteip

Step 2: Create or modify /etc/apache2/conf-available/remoteip.conf

Add the following content. This ensures that the X-Forwarded-For header is used as the RemoteIPHeader

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.137.9.5 10.137.9.6 10.137.9.7

Step 3: Enable the new configuration file (if not already):

sudo a2enconf remoteip.conf

Step 4: Change the Apache2 log format in/etc/apache2/apache2.conf:

Edit the apache2 configuration file and change the LogFormat to the following: 

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

%hchanges to%a

Step 5: Syntax check theapache2.conffile:

sudo apache2ctl configtest

The above command should return OK. Otherwise, you will need to solve a configuration syntax problem.

Step 6: Restart Apache2

sudo systemctl restart apache2

Step 7: Verify XFF Configuration

To verify that Apache2 is correctly logging the X-Forwarded-For header as the originating client IP, you can access your web server and check the access logs. The logs are typically located in/var/log/apache2/access.log.

Use a web browser to access your server, and then check the logs:

tail -f /var/log/apache2/access.log

You should see log entries with IP addresses from the X-Forwarded-For header.

Additional Notes:

Ensure that your reverse proxy or load balancer (if applicable) is configured to include the X-Forwarded-For header when forwarding requests to Apache2. This is essential for Apache2 to receive and use the client’s actual IP address.

Depending on your server’s setup, you might have multiple virtual hosts or configurations. Ensure that you apply the XFF configuration to the appropriate virtual host or configuration file.

NGINX

Prerequisites:

NGINX web server installed on your system. A basic understanding of NGINX configuration.

Step 1: Edit NGINX Configuration

Open the NGINX configuration file in a text editor. The location of this file may vary depending on your system but is typically found in/etc/nginx/nginx.confor/etc/nginx/conf/nginx.conf.

sudo nano /etc/nginx/nginx.conf

Inside the configuration file, find the http block, which typically looks like this:

http { ... } https { ... }

Add the following lines within the http/https block to configure NGINX to use X-Forwarded-For:

set_real_ip_from 10.137.9.0/24; 

real_ip_header X-Forwarded-For;

set_real_ip_from specifies the trusted IP address or range of your proxy server(s). This should be the IP address of your reverse proxy or load balancer.

real_ip_header sets the header that NGINX should use to identify the client’s real IP address. In this case, it’s set to X-Forwarded-For.

Save the configuration file and exit the text editor.

Step 2: Test Configuration

Before applying the configuration, it’s a good practice to test it to ensure there are no syntax errors. Run the following command:

sudo nginx -t

If the configuration is error-free, you’ll see a message indicating that the configuration is okay.

Step 3: Apply Configuration

If the configuration test was successful, you can reload NGINX to apply the changes:

sudo systemctl reload nginx

Step 4: Verify X-Forwarded-For Configuration

To verify that NGINX is correctly using the X-Forwarded-For header as the originating client IP, you can check your NGINX access logs. The logs are usually located in/var/log/nginx/access.log. Use the tail command to monitor the logs in real-time:

sudo tail -f /var/log/nginx/access.log

Now, access your web server using a web browser or any HTTP client. You should see log entries with IP addresses from the X-Forwarded-For header.

Glossary

WAF= Web Application Firewall

F5= Company behind the Web Application Firewall product

SSH= Secure Shell

WEB= Web traffic

XFF= The X-Forwarded-For (XFF) request header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server.

Apache2= The Apache HTTP Server is a free and open-source cross-platform web server software, released under the terms of Apache License 2.0. Apache is developed and maintained by an open community of developers under the auspices of the Apache Software Foundation. https://en.wikipedia.org/wiki/Apache_HTTP_Server