Ubuntu 16.04环境下Apache2多用户虚拟主机安全风险咨询

Great question—this is a common setup for student project environments, and while your core plan is solid, there are critical configuration details and additional safeguards you need to implement to prevent cross-user and server-wide compromises. Let’s break this down step by step:

Your approach (VirtualHost + SFTP chroot + isolated accounts) provides a baseline of isolation, but it’s not inherently secure without strict configuration. Here’s where risks can creep in, and how to mitigate them:

1. SFTP & User Account Risks #

Weak passwords and misconfigured chroots are the biggest threats here:

• Chroot Permission Lockdown: When setting up SFTP chroots, ensure the top-level chroot directory is owned by root:root with permissions 755. The student’s web subdirectory (e.g., /home/student1/web) should be owned by the student’s user/group. If the student owns the chroot directory itself, attackers can exploit this to break out of the chroot jail and access other parts of the server.
• Restrict SSH Access: Configure sshd_config to only allow SFTP for student accounts, not full shell access. Add these lines for each student’s group or individual account:

  Match Group sftp-students
      ForceCommand internal-sftp
      PasswordAuthentication yes
      ChrootDirectory /home/%u
      PermitTunnel no
      AllowAgentForwarding no
      AllowTcpForwarding no
      X11Forwarding no
  

• Combat Weak Passwords: Enforce strong password policies (minimum length, complexity) via pam_cracklib in /etc/pam.d/common-password. Additionally, install fail2ban to block IPs that attempt brute-force attacks on SFTP/SSH.

2. Apache Virtual Host Isolation Gaps #

Disabling .htaccess is a good start, but there are other ways attackers can bypass VirtualHost boundaries:

• PHP Execution Isolation: Do NOT use mod_php—it runs all PHP code as the www-data user, meaning a compromised student’s PHP code can read/write other students’ files. Instead, use PHP-FPM with individual pools for each student. Each pool runs as the student’s system user, so even if their code is exploited, the attacker is limited to that student’s directory. Configure each pool with:

  [student1]
  user = student1
  group = student1
  listen = /run/php/php7.0-fpm-student1.sock
  listen.owner = www-data
  listen.group = www-data
  php_admin_value[open_basedir] = /home/student1/web:/tmp
  php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen
  

  Then point each VirtualHost to its corresponding PHP-FPM socket.
• Symlink Protection: Add Options -FollowSymLinks +SymLinksIfOwnerMatch to each VirtualHost. This prevents students from creating symlinks to other users’ directories (only symlinks where the owner matches the target file’s owner are allowed).
• Directory Traversal Mitigation: The open_basedir setting in PHP-FPM (mentioned above) restricts PHP to only access the student’s web directory and /tmp, blocking directory traversal attacks that try to read system files or other students’ data.

3. MySQL/MariaDB Isolation #

Don’t overlook database security—students’ weak code or passwords can expose other databases:

• Per-Student Database Users: Create a unique MySQL user for each student, and only grant them full permissions on their own database:

  CREATE DATABASE student1_db;
  CREATE USER 'student1'@'localhost' IDENTIFIED BY 'strong_password';
  GRANT ALL PRIVILEGES ON student1_db.* TO 'student1'@'localhost';
  FLUSH PRIVILEGES;
  

  Never grant global privileges (e.g., GRANT ALL ON *.*).
• Block Remote MySQL Access: Ensure MySQL is configured to only listen on localhost (check bind-address = 127.0.0.1 in /etc/mysql/my.cnf). This prevents attackers from connecting directly to the database from outside the server.
• Harden Root Account: Change the MySQL root password to a strong, unique value, and avoid using it for student projects.

4. Safeguards Against Insecure/Old Code #

Since students may upload vulnerable code, add these layers of protection:

• ModSecurity WAF: Install Apache’s ModSecurity module with the Core Rule Set (CRS). This will automatically block common attacks like SQL injection, XSS, and remote code execution, even if the student’s code has unpatched vulnerabilities.
• File Upload Restrictions: Configure Apache and PHP to limit uploads to safe file types (e.g., images, PDFs) and block executable files (.php, .phtml, .sh). In PHP, set upload_max_filesize and restrict allowed extensions via php.ini or PHP-FPM pool config.
• Malware Scanning: Use tools like maldet (Linux Malware Detect) or ClamAV to regularly scan student web directories for webshells or malicious scripts. Set up automated scans and alerts.

5. Server-Level Hardening #

Secure the underlying Ubuntu 16.04 system to reduce overall attack surface:

• Firewall Configuration: Use ufw to allow only necessary ports:

  ufw allow 80/tcp
  ufw allow 443/tcp
  ufw allow 22/tcp
  ufw enable
  

• Disable Root SSH Login: Edit sshd_config to set PermitRootLogin no, and create a dedicated admin account with sudo privileges for server management.
• Regular Updates: Enable automatic security updates (via unattended-upgrades) to ensure critical system patches are applied quickly:

  apt install unattended-upgrades
  dpkg-reconfigure -plow unattended-upgrades
  

• Log Monitoring: Set up log rotation and regularly review Apache access/error logs, SFTP logs (/var/log/auth.log), and MySQL logs to spot unusual activity (e.g., repeated failed logins, unexpected file access).

Your plan is viable if you implement all the above safeguards. The biggest risks come from misconfigured chroots, shared PHP execution contexts, and unhardened databases. By locking down each layer—user accounts, web server, PHP, databases, and the system itself—you’ll minimize the chance of one student’s mistake compromising others or the entire server.

内容的提问来源于stack exchange，提问作者Samew