Week 04 - HTTP and Web Services¶

Topic¶

Setting up Apache web server with virtual hosts, deploying a static company website, reverse proxying a Python API with bearer token authorization, deploying WordPress, and configuring Apache modules (forensic logging, ModSecurity).

Company Requests¶

Ticket #401: Company Front Page

"Marketing has prepared a static website for Tartu Bubbles. Deploy an Apache web server and host it at <vm_name>.sysadm.ee. Replace the placeholder contact addresses with ones using your VM name."

Ticket #402: Inventory API

"The warehouse team built a small Python inventory API. Deploy it behind Apache at inventory.<vm_name>.sysadm.ee. Access must be restricted — only requests with the correct bearer token should get through."

Ticket #403: Company Blog

"We need a blog for the marketing team. Set up WordPress at blog.<vm_name>.sysadm.ee. Make sure the database is secure."

Ticket #404: Security & Compliance

"The security team requires forensic logging on all websites and a web application firewall to block common attack patterns."

Scoring Checks¶

• Check 4.1: Port 80 is open and reachable from the scoring server.
  • Method: The scoring server opens a TCP connection to your VM on port 80.
  • Expected: Connection succeeds.
• Check 4.2: <vm_name>.sysadm.ee returns the front page containing the VM name.
  • Method: The scoring server sends an HTTP request to your VM's IP with the Host: <vm_name>.sysadm.ee header.
  • Expected: HTTP 200 response with the body containing your VM's short name (e.g. if your VM is student-xyz.cloud.ut.ee, the page must contain student-xyz).
• Check 4.3: inventory.<vm_name>.sysadm.ee denies requests without credentials (HTTP 401/403) and allows requests with the correct bearer token (HTTP 200).
  • Method: The scoring server sends two HTTP requests to inventory.<vm_name>.sysadm.ee/api/v1/inventory:
    • One without an Authorization header.
    • One with the header Authorization: Bearer 845e6732f32b81dd778972703474ccbb.
  • Expected: HTTP 401 or 403 for the first request, HTTP 200 for the second.
• Check 4.4: blog.<vm_name>.sysadm.ee serves a WordPress site.
  • Method: The scoring server sends an HTTP request to your VM's IP with the Host: blog.<vm_name>.sysadm.ee header.
  • Expected: HTTP response body contains wordpress, wp-content, or wp-includes.
• Check 4.5: Forensic logging module is loaded and configured.
  • Method: The scoring server logs in via SSH and checks that mod_log_forensic is loaded (httpd -M) and that a ForensicLog directive exists in the Apache configuration.
  • Expected: mod_log_forensic is loaded, and a ForensicLog directive exists.
• Check 4.6: ModSecurity blocks requests to /etc/passwd (HTTP 403 or 406).
  • Method: The scoring server sends an HTTP request to http://<vm_name>.sysadm.ee/etc/passwd.
  • Expected: HTTP response code 403 or 406 (ModSecurity block).

Tasks¶

Task 1: Install and Configure Apache¶

Reference: Technologies: Apache HTTPD

Task 2: Deploy the Front Page¶

The marketing team has prepared a static site. You need to deploy it and customize it for your VM.

Reference: SOP: Web Server Management - Create a Virtual Host

Task 3: Deploy the Inventory API¶

The warehouse team's Python API needs to be deployed behind Apache with bearer token authorization.

Reference: SOP: Web Server Management - Set Up a Reverse Proxy, SOP: Web Server Management - Configure Bearer Token Authorization, SOP: Service Management - Create a Custom systemd Unit File

Task 4: Deploy WordPress¶

The marketing team needs a blog, and they have decided to use WordPress, which you'll need to install and configure.

Reference: Technologies: WordPress, Technologies: MariaDB

Task 5: Configure Forensic Logging¶

Reference: SOP: Web Server Management - Configure Forensic Logging, Concepts: Web Application Security - Forensic Logging

Task 6: Configure ModSecurity¶

The security team wants to defend against a certain attack related to being able to download a file through the web server. You'll need to block it to make them happy.

Reference: SOP: Web Server Management - Configure ModSecurity Rules, Concepts: Web Application Security

Ansible Tips¶

This section covers tips for automating the tasks in this lab with Ansible. You are not required to automate everything this week, but starting early will save you time later.

Tags¶

Use tags to run specific roles instead of the whole playbook:

- { role: apache, tags: apache }
- { role: wordpress, tags: wordpress }

Run only the Apache role: ansible-playbook --tags=apache playbook.yml

See the Ansible documentation on tags for more.

Handlers¶

Use handlers to restart services only when configuration actually changes. Define a handler in roles/<rolename>/handlers/main.yml:

- name: restart httpd
  systemd:
    daemon_reload: yes
    name: httpd
    state: restarted
    enabled: yes

Notify the handler from any task that modifies an Apache config file:

- name: Deploy virtual host config
  template:
    src: vhost.conf.j2
    dest: /etc/httpd/conf.d/site.conf
  notify: restart httpd

Apache will only be restarted when the config file actually changes — not on every playbook run.

WordPress wp-config.php Template¶

Instead of using the web-based installer, create wp-config.php as an Ansible template. Start from the sample file and use Jinja2 variables for the database settings:

{# wp-config.php.j2 — key lines to template #}
define( 'DB_NAME', '{{ wp_db_name }}' );
define( 'DB_USER', '{{ wp_db_user }}' );
define( 'DB_PASSWORD', '{{ wp_db_password }}' );
define( 'DB_HOST', 'localhost' );

Deploy it with the template module:

- name: Deploy wp-config.php
  template:
    src: wp-config.php.j2
    dest: /var/www/html/wordpress/wp-config.php
    owner: apache
    group: apache
    mode: '0640'

See also Technologies: WordPress — Manual wp-config.php Creation for the manual approach.

Automating mysql_secure_installation¶

The interactive mysql_secure_installation script cannot be run from Ansible directly. Instead, use the mysql_user and mysql_db modules to achieve the same result:

- name: Remove anonymous MySQL users
  mysql_user:
    name: ''
    host_all: yes
    state: absent

- name: Remove test database
  mysql_db:
    name: test
    state: absent

- name: Create WordPress database
  mysql_db:
    name: wordpress
    state: present

- name: Create WordPress database user
  mysql_user:
    name: admin
    password: "{{ wp_db_password }}"
    priv: "wordpress.*:ALL"
    state: present

Useful Modules¶

These Ansible modules map directly to tasks in this lab:

• dnf — install packages
• pip — install Python packages (Flask)
• template — deploy configuration files with variables (virtual hosts, wp-config.php, systemd units)
• copy / unarchive — deploy static files or extract archives (WordPress tarball)
• mysql_db / mysql_user — manage databases and users
• seboolean — set SELinux booleans (e.g. httpd_can_network_connect)
• sefcontext — set SELinux file contexts (e.g. httpd_sys_rw_content_t)
• systemd — manage services
• file — set ownership and permissions