प्रोडक्शन सर्वर सिक्योरिटी हार्डनिंग: एक व्यापक चेकलिस्ट

डेटा उल्लंघन की पहचान करने का औसत समय 204 दिन है। उत्पादन सर्वर सख्त होने से आपके हमले की सतह कम हो जाती है जिससे उल्लंघनों को शुरू करना कठिन हो जाता है और तेजी से पता लगाया जा सकता है। यह मार्गदर्शिका उन ठोस सुरक्षा उपायों को शामिल करती है जिन्हें प्रत्येक उत्पादन सर्वर को एसएसएच कॉन्फ़िगरेशन से लेकर वेब एप्लिकेशन फ़ायरवॉल तक लागू करना चाहिए।

मुख्य बातें

SSH कुंजी-केवल प्रमाणीकरण और गैर-मानक पोर्ट 99% स्वचालित ब्रूट-फोर्स हमलों को रोकते हैं

एक उचित रूप से कॉन्फ़िगर किया गया फ़ायरवॉल हमले की सतह को हजारों प्रवेश बिंदुओं से घटाकर दस से भी कम कर देता है

वेब एप्लिकेशन फ़ायरवॉल नेटवर्क परत पर SQL इंजेक्शन, XSS और अन्य OWASP शीर्ष 10 हमलों को रोकता है

स्वचालित पैचिंग यह सुनिश्चित करती है कि कमजोरियाँ प्रकटीकरण के कुछ घंटों के भीतर ठीक हो जाएं, हफ्तों में नहीं

एसएसएच सख्त होना

कॉन्फ़िगरेशन

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

फ़ायरवॉल कॉन्फ़िगरेशन

यूएफडब्ल्यू (उबंटू)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

AWS सुरक्षा समूह

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

Nginx सुरक्षा हेडर

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

एसएसएल/टीएलएस कॉन्फ़िगरेशन

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

स्वचालित प्रमाणपत्र नवीनीकरण

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

कंटेनर सुरक्षा

यदि डॉकर को उत्पादन में चलाया जा रहा है, तो इन अतिरिक्त सख्त उपायों को लागू करें:

डॉकर डेमन सुरक्षा

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

कंटेनर रनटाइम प्रतिबंध

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

प्रमुख सिद्धांत:

सभी क्षमताएं छोड़ें और केवल वही जोड़ें जो आवश्यक है
केवल पढ़ने योग्य फ़ाइल सिस्टम हमलावरों को कंटेनर सामग्री को संशोधित करने से रोकता है
कोई नया विशेषाधिकार नहीं कंटेनरों के अंदर विशेषाधिकार वृद्धि को रोकता है
डॉकरफ़ाइल में गैर-रूट उपयोगकर्ता (हमारी डॉकर परिनियोजन मार्गदर्शिका देखें)

छवि सुरक्षा

आधिकारिक, न्यूनतम आधार छवियों का उपयोग करें (अल्पाइन वेरिएंट)
छवि संस्करण पिन करें (उत्पादन में कभी भी :latest का उपयोग न करें)
ट्रिवी या ग्रिप के साथ कमजोरियों के लिए छवियों को स्कैन करें
डॉकर कंटेंट ट्रस्ट के साथ छवियों पर हस्ताक्षर करें
अभिगम नियंत्रण के साथ एक निजी रजिस्ट्री का उपयोग करें

डेटाबेस सुरक्षा

पोस्टग्रेएसक्यूएल हार्डनिंग

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

PostgreSQL को कभी भी सार्वजनिक इंटरनेट पर उजागर न करें
न्यूनतम आवश्यक अनुमतियों के साथ समर्पित डेटाबेस उपयोगकर्ताओं का उपयोग करें
कनेक्शन एन्क्रिप्शन सक्षम करें (एसएसएल)
मजबूत पासवर्ड नीतियां सेट करें
नियमित बैकअप सत्यापन (हमारी आपदा पुनर्प्राप्ति मार्गदर्शिका देखें)

घुसपैठ का पता लगाना

ओएसएसईसी कॉन्फ़िगरेशन

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

एडब्ल्यूएस गार्डड्यूटी

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

स्वचालित सुरक्षा पैचिंग

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

सुरक्षा सख्त करने वाली चेकलिस्ट

सर्वर स्तर

SSH कुंजी-केवल प्रमाणीकरण, रूट लॉगिन अक्षम
फ़ायरवॉल को डिफॉल्ट-बाय-डिफ़ॉल्ट नीति के साथ कॉन्फ़िगर किया गया है
Fail2Ban SSH और वेब सर्वर पर सक्रिय है
स्वचालित सुरक्षा अद्यतन सक्षम
गैर-आवश्यक सेवाएँ अक्षम
फ़ाइल अखंडता निगरानी (ओएसएसईसी या समकक्ष)
ऑडिट लॉगिंग सक्षम (ऑडिट)

आवेदन स्तर

सभी समापन बिंदुओं पर टीएलएस 1.2+, एचएसटीएस सक्षम
सुरक्षा हेडर कॉन्फ़िगर (सीएसपी, एक्स-फ़्रेम-विकल्प, आदि)
सभी सार्वजनिक समापन बिंदुओं पर दर सीमित करना
इनपुट सत्यापन और पैरामीटरयुक्त क्वेरीज़ (कोई sql.raw() नहीं)
केवल Http, प्रमाणीकरण के लिए सुरक्षित कुकीज़
सीओआरएस ज्ञात मूल तक ही सीमित है
त्रुटि प्रतिक्रियाएँ स्टैक ट्रेस लीक नहीं करती हैं

नेटवर्क स्तर

डेटाबेस सार्वजनिक रूप से पहुंच योग्य नहीं है
निजी सबनेट पर आंतरिक सेवाएँ
AWS सेवाओं के लिए VPC समापन बिंदु (कोई सार्वजनिक इंटरनेट नहीं)
सार्वजनिक-सामना वाले समापन बिंदुओं पर WAF
DDoS सुरक्षा (क्लाउडफ्लेयर, AWS शील्ड)

निगरानी

सुरक्षा ईवेंट अलर्ट कॉन्फ़िगर किया गया
कम से कम 90 दिनों के लिए लॉग अवधारण
विफल प्रमाणीकरण प्रयासों की निगरानी की गई
असामान्य ट्रैफ़िक पैटर्न का पता चला

अक्सर पूछे जाने वाले प्रश्न

हमें कितनी बार सुरक्षा ऑडिट करना चाहिए?

त्रैमासिक स्वचालित स्कैन (भेद्यता स्कैनिंग, निर्भरता ऑडिट) और वार्षिक मैनुअल प्रवेश परीक्षण। उच्च जोखिम वाले अनुप्रयोगों (भुगतान प्रसंस्करण, स्वास्थ्य देखभाल डेटा) में हर 6 महीने में बाहरी प्रवेश परीक्षण होना चाहिए। प्रत्येक उत्पादन परिनियोजन में सीआई/सीडी पाइपलाइन में स्वचालित सुरक्षा स्कैनिंग शामिल होनी चाहिए --- हमारी सीआई/सीडी सर्वोत्तम अभ्यास मार्गदर्शिका देखें।

यदि हमारे पास पहले से ही दर सीमित है तो क्या WAF आवश्यक है?

हाँ। दर सीमित करना दुरुपयोग को रोकता है लेकिन अनुरोध सामग्री का निरीक्षण नहीं करता है। WAF अनुरोध पेलोड का विश्लेषण करके SQL इंजेक्शन, XSS और अन्य एप्लिकेशन-लेयर हमलों को रोकता है। दर सीमित करने को बाढ़ सुरक्षा के रूप में और WAF को सामग्री निरीक्षण के रूप में सोचें --- आपको दोनों की आवश्यकता है।

हम ओडू उत्पादन सर्वर को कैसे सुरक्षित कर सकते हैं?

उपरोक्त सामान्य सख्तता के अलावा: उत्पादन में डेटाबेस प्रबंधक को अक्षम करें (list_db = False), एक मजबूत admin_passwd सेट करें, डेटाबेस पहुंच को प्रतिबंधित करने के लिए dbfilter का उपयोग करें, Odoo को Nginx के पीछे चलाएं (कभी भी Odoo को सीधे उजागर न करें), और Odoo और सभी मॉड्यूल को अपडेट रखें। ECOSIRE हमारी प्रबंधित होस्टिंग सेवाओं के हिस्से के रूप में ओडू सिक्योरिटी हार्डनिंग प्रदान करता है।

सबसे प्रभावशाली सुरक्षा उपाय क्या है?

सभी प्रशासनिक खातों पर एमएफए (मल्टी-फैक्टर प्रमाणीकरण) सक्षम करना। यह एकल नियंत्रण 99% क्रेडेंशियल-आधारित हमलों को रोकता है। किसी भी अन्य सख्त उपाय से पहले एसएसएच (पीएएम के माध्यम से), एडब्ल्यूएस कंसोल, डेटाबेस एडमिन टूल्स और एप्लिकेशन एडमिन पैनल पर एमएफए लागू करें।

आगे क्या आता है

सुरक्षा सख्त करना एक सतत अभ्यास है। इसे पता लगाने के लिए निगरानी और चेतावनी, लचीलेपन के लिए आपदा पुनर्प्राप्ति, और रोकथाम के लिए सीआई/सीडी सुरक्षा स्कैनिंग के साथ संयोजित करें।

सुरक्षा सख्त परामर्श के लिए ECOSIRE से संपर्क करें, या संपूर्ण बुनियादी ढांचे के रोडमैप के लिए हमारे DevOps गाइड को देखें।

ECOSIRE द्वारा प्रकाशित - व्यवसायों को उत्पादन के बुनियादी ढांचे को सुरक्षित करने में मदद करना।

Production Server Security Hardening: A Comprehensive Checklist