Network Security Best Practices
- Network Security Best Practices
This article outlines essential network security best practices for MediaWiki servers. Implementing these practices will significantly reduce the risk of unauthorized access, data breaches, and service disruptions. This guide is geared towards system administrators and server engineers responsible for maintaining a secure MediaWiki environment. It assumes a basic understanding of networking concepts and Linux server administration.
1. Firewall Configuration
A robust firewall is the first line of defense. Properly configured, it restricts network traffic to only necessary ports and protocols.
| Port | Protocol | Description | Recommended Action |
|---|---|---|---|
| 80 | TCP | HTTP (Unencrypted Web Traffic) | Redirect to HTTPS (Port 443) or restrict access to trusted IPs. |
| 443 | TCP | HTTPS (Encrypted Web Traffic) | Allow from all, but monitor for suspicious activity. |
| 22 | TCP | SSH (Secure Shell) | Restrict access to trusted IPs only. Consider disabling password authentication and using SSH keys. |
| 25 | TCP | SMTP (Simple Mail Transfer Protocol) | Only allow if the server is responsible for sending email; otherwise, block. |
| 53 | UDP/TCP | DNS (Domain Name System) | Allow outbound traffic, restrict inbound unless acting as a DNS server. |
Utilize tools like `iptables` or `firewalld` (depending on your Linux distribution) to enforce these rules. Regularly review and update firewall rules as your network infrastructure changes. Consider using a Web Application Firewall (WAF) like ModSecurity for additional protection against web-based attacks. See also Server Hardening.
2. Intrusion Detection and Prevention Systems (IDS/IPS)
IDS/IPS monitor network traffic for malicious activity and can automatically block or alert administrators to potential threats.
- **Snort:** A widely used open-source IDS/IPS.
- **Suricata:** Another powerful open-source IDS/IPS known for its performance.
- **Fail2ban:** Specifically designed to ban IP addresses exhibiting malicious behavior (e.g., repeated failed login attempts). See Fail2ban Configuration.
These systems should be configured with up-to-date rule sets to detect the latest threats. Regularly review IDS/IPS logs for suspicious activity. Ensure that IDS/IPS does not interfere with legitimate traffic.
3. Network Segmentation
Dividing your network into smaller, isolated segments limits the impact of a security breach. If one segment is compromised, the attacker's access is restricted to that segment, preventing them from reaching critical systems like the MediaWiki server.
| Network Segment | Purpose | Security Level |
|---|---|---|
| DMZ (Demilitarized Zone) | Web Server (MediaWiki) | High – Firewall protected, limited access to internal network. |
| Internal Network | Database Server, Application Servers | Medium – Access restricted to authorized personnel and services. |
| Management Network | Server Administration, Monitoring | Very High – Highly restricted access, strong authentication. |
Utilize Virtual LANs (VLANs) and firewalls to create these network segments. Implement strict access control lists (ACLs) to regulate traffic between segments. Consider using a Virtual Private Network (VPN) for remote access.
4. Secure Shell (SSH) Hardening
SSH is a crucial tool for remote server administration, but it can also be a target for attackers.
| Setting | Recommended Value | Explanation |
|---|---|---|
| Port | Change from default (22) | Reduces automated attacks. |
| Password Authentication | Disabled | Forces the use of SSH keys, which are much more secure. |
| Root Login | Disabled | Prevents direct root login, requiring users to log in as a standard user and then use `sudo`. |
| AllowUsers/AllowGroups | Specify authorized users/groups | Restricts SSH access to only authorized personnel. |
| UsePAM | Enabled | Integrates with system authentication mechanisms. |
Always use strong SSH keys and protect the private key file. Regularly review SSH logs for suspicious activity. See also SSH Key Management.
5. Database Security
The MediaWiki database contains sensitive information and must be properly secured.
- **Strong Passwords:** Use strong, unique passwords for all database users.
- **Restricted Access:** Grant database users only the necessary privileges.
- **Firewall Rules:** Restrict database access to only the MediaWiki server.
- **Regular Backups:** Implement a regular database backup schedule. See Database Backup Strategies.
- **Encryption:** Consider encrypting the database at rest and in transit.
Ensure the database server is running the latest security patches. Monitor database logs for suspicious activity. Use a secure connection (e.g., SSL/TLS) between the MediaWiki server and the database server. Refer to the MySQL Security Guide or the PostgreSQL Security Guide depending on your database system.
6. Regular Security Audits and Updates
Regularly audit your network security configuration to identify vulnerabilities. Keep all software (operating system, web server, PHP, MediaWiki, database server) up to date with the latest security patches. Automate updates where possible.
- **Vulnerability Scanners:** Use tools like Nessus or OpenVAS to scan for vulnerabilities.
- **Penetration Testing:** Conduct regular penetration tests to simulate real-world attacks.
- **Log Monitoring:** Regularly review system logs for suspicious activity. Consider using a Security Information and Event Management (SIEM) system.
Staying proactive with security updates and audits is crucial for maintaining a secure MediaWiki environment. See MediaWiki Security Updates for information on security releases.
Special:MyPreferences Help:Contents MediaWiki FAQ Manual:Configuration Manual:Installation Extension:Semantic MediaWiki Admin Guide
Intel-Based Server Configurations
| Configuration | Specifications | Benchmark |
|---|---|---|
| Core i7-6700K/7700 Server | 64 GB DDR4, NVMe SSD 2 x 512 GB | CPU Benchmark: 8046 |
| Core i7-8700 Server | 64 GB DDR4, NVMe SSD 2x1 TB | CPU Benchmark: 13124 |
| Core i9-9900K Server | 128 GB DDR4, NVMe SSD 2 x 1 TB | CPU Benchmark: 49969 |
| Core i9-13900 Server (64GB) | 64 GB RAM, 2x2 TB NVMe SSD | |
| Core i9-13900 Server (128GB) | 128 GB RAM, 2x2 TB NVMe SSD | |
| Core i5-13500 Server (64GB) | 64 GB RAM, 2x500 GB NVMe SSD | |
| Core i5-13500 Server (128GB) | 128 GB RAM, 2x500 GB NVMe SSD | |
| Core i5-13500 Workstation | 64 GB DDR5 RAM, 2 NVMe SSD, NVIDIA RTX 4000 |
AMD-Based Server Configurations
| Configuration | Specifications | Benchmark |
|---|---|---|
| Ryzen 5 3600 Server | 64 GB RAM, 2x480 GB NVMe | CPU Benchmark: 17849 |
| Ryzen 7 7700 Server | 64 GB DDR5 RAM, 2x1 TB NVMe | CPU Benchmark: 35224 |
| Ryzen 9 5950X Server | 128 GB RAM, 2x4 TB NVMe | CPU Benchmark: 46045 |
| Ryzen 9 7950X Server | 128 GB DDR5 ECC, 2x2 TB NVMe | CPU Benchmark: 63561 |
| EPYC 7502P Server (128GB/1TB) | 128 GB RAM, 1 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (128GB/2TB) | 128 GB RAM, 2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (128GB/4TB) | 128 GB RAM, 2x2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (256GB/1TB) | 256 GB RAM, 1 TB NVMe | CPU Benchmark: 48021 |
| EPYC 7502P Server (256GB/4TB) | 256 GB RAM, 2x2 TB NVMe | CPU Benchmark: 48021 |
| EPYC 9454P Server | 256 GB RAM, 2x2 TB NVMe |
Order Your Dedicated Server
Configure and order your ideal server configuration
Need Assistance?
- Telegram: @powervps Servers at a discounted price
⚠️ *Note: All benchmark scores are approximate and may vary based on configuration. Server availability subject to stock.* ⚠️