پروڈکشن سرور سیکیورٹی سخت: ایک جامع چیک لسٹ

**ڈیٹا کی خلاف ورزی کی نشاندہی کرنے کا اوسط وقت 204 دن ہے۔ ** پروڈکشن سرور کی سختی آپ کے حملے کی سطح کو کم کر دیتی ہے تاکہ خلاف ورزیوں کو شروع کرنا مشکل اور تیزی سے پتہ لگایا جائے۔ یہ گائیڈ ان ٹھوس حفاظتی اقدامات کا احاطہ کرتا ہے جو ہر پروڈکشن سرور کو SSH کنفیگریشن سے لے کر ویب ایپلیکیشن فائر والز تک لاگو کرنا چاہیے۔

اہم ٹیک ویز

• SSH کلیدی توثیق اور غیر معیاری بندرگاہیں 99 فیصد خودکار بروٹ فورس حملوں کو روکتی ہیں
• مناسب طریقے سے تشکیل شدہ فائر وال حملے کی سطح کو ہزاروں انٹری پوائنٹس سے کم کر کے دس سے کم کر دیتی ہے۔
• ویب ایپلیکیشن فائر والز نیٹ ورک پرت پر SQL انجیکشن، XSS، اور دیگر OWASP ٹاپ 10 حملوں کو روکتے ہیں
• خودکار پیچنگ اس بات کو یقینی بناتی ہے کہ افشاء کے چند گھنٹوں میں کمزوریاں ٹھیک ہو جائیں، ہفتوں میں نہیں۔

---

SSH سخت ہونا

کنفیگریشن

# /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

---

فائر وال کنفیگریشن

UFW (اوبنٹو)

# 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;
    }
}

---

SSL/TLS کنفیگریشن

# 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 استعمال نہ کریں)
• Trivy یا Grype کے ساتھ کمزوریوں کے لیے تصاویر کو اسکین کریں۔
• ڈاکر کنٹینٹ ٹرسٹ کے ساتھ تصاویر پر دستخط کریں۔
• رسائی کنٹرول کے ساتھ نجی رجسٹری کا استعمال کریں۔

---

ڈیٹا بیس سیکیورٹی

PostgreSQL سخت ہونا

# 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 کو کبھی بھی ظاہر نہ کریں۔
• کم از کم مطلوبہ اجازتوں کے ساتھ سرشار ڈیٹا بیس صارفین کا استعمال کریں۔
• کنکشن کی خفیہ کاری کو فعال کریں (SSL)
• مضبوط پاس ورڈ کی پالیسیاں مرتب کریں۔
• بیک اپ کی باقاعدہ تصدیق (ہماری ڈیزاسٹر ریکوری گائیڈ دیکھیں)

---

دخل اندازی کا پتہ لگانا

OSSEC کنفیگریشن

<!-- /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>

AWS گارڈ ڈیوٹی

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 کلید کی توثیق، روٹ لاگ ان غیر فعال
• فائر وال کو پہلے سے طے شدہ انکار کی پالیسی کے ساتھ ترتیب دیا گیا ہے۔ SSH اور ویب سرور پر Fail2Ban فعال ہے۔
• خودکار سیکیورٹی اپ ڈیٹس فعال ہیں۔
• غیر ضروری خدمات غیر فعال
• فائل کی سالمیت کی نگرانی (OSSEC یا مساوی)
• آڈٹ لاگنگ فعال (آڈٹ)

درخواست کی سطح

• تمام اینڈ پوائنٹس پر TLS 1.2+، HSTS فعال ہے۔
• سیکیورٹی ہیڈر کنفیگر کیے گئے (CSP، X-Frame-Options، وغیرہ)
• تمام عوامی اختتامی مقامات پر شرح محدود
• ان پٹ کی توثیق اور پیرامیٹرائزڈ سوالات (نہیں sql.raw())
• صرف Http، تصدیق کے لیے محفوظ کوکیز
• CORS معلوم ماخذ تک محدود ہے۔
• خرابی کے جوابات اسٹیک کے نشانات کو لیک نہیں کرتے ہیں۔

نیٹ ورک کی سطح

• ڈیٹا بیس عوامی طور پر قابل رسائی نہیں ہے۔
• نجی سب نیٹس پر داخلی خدمات
• AWS سروسز کے لیے VPC اینڈ پوائنٹس (کوئی عوامی انٹرنیٹ نہیں)
• WAF عوام کے سامنے والے اختتامی مقامات پر
• DDoS تحفظ (Cloudflare، AWS شیلڈ)

نگرانی

• سیکیورٹی ایونٹ الرٹ کنفیگر ہو گیا۔
• کم از کم 90 دنوں تک لاگ برقرار رکھنا
• تصدیق کی ناکام کوششوں کی نگرانی کی گئی۔
• ٹریفک کے غیر معمولی نمونوں کا پتہ چلا

---

اکثر پوچھے گئے سوالات

ہمیں کتنی بار سیکیورٹی آڈٹ کرنا چاہیے؟

سہ ماہی خودکار اسکین (خطرناک اسکیننگ، انحصار آڈٹ) اور سالانہ دستی دخول ٹیسٹ۔ ہائی رسک ایپلی کیشنز (ادائیگی کی پروسیسنگ، ہیلتھ کیئر ڈیٹا) کے ہر 6 ماہ بعد بیرونی دخول کے ٹیسٹ ہونے چاہئیں۔ ہر پروڈکشن کی تعیناتی میں CI/CD پائپ لائن میں خودکار سیکیورٹی اسکیننگ شامل ہونی چاہیے --- ہماری CI/CD بہترین طرز عمل گائیڈ دیکھیں۔

اگر ہمارے پاس پہلے سے ہی شرح محدود ہے تو کیا WAF ضروری ہے؟

جی ہاں شرح کو محدود کرنا غلط استعمال کو روکتا ہے لیکن درخواست کے مواد کا معائنہ نہیں کرتا ہے۔ ایک WAF درخواست پے لوڈز کا تجزیہ کرکے SQL انجیکشن، XSS، اور دیگر ایپلیکیشن لیئر حملوں کو روکتا ہے۔ شرح کو سیلاب سے تحفظ اور WAF کو مواد کے معائنہ کے طور پر محدود کرنے کے بارے میں سوچیں --- آپ کو دونوں کی ضرورت ہے۔

ہم Odoo پروڈکشن سرور کو کیسے محفوظ کرتے ہیں؟

اوپر عام سختی کے علاوہ: پروڈکشن میں ڈیٹا بیس مینیجر کو غیر فعال کریں (list_db = False)، ایک مضبوط admin_passwd سیٹ کریں، ڈیٹا بیس تک رسائی کو محدود کرنے کے لیے dbfilter استعمال کریں، Odoo کو Nginx کے پیچھے چلائیں (Odoo کو براہ راست ظاہر نہ کریں)، اور Odoo اور تمام ماڈیولز کو اپ ڈیٹ رکھیں۔ ECOSIRE ہماری منظم ہوسٹنگ سروسز کے حصے کے طور پر Odoo سیکیورٹی سختی فراہم کرتا ہے۔

سکیورٹی کا واحد سب سے زیادہ مؤثر اقدام کیا ہے؟

تمام انتظامی کھاتوں پر MFA (ملٹی فیکٹر توثیق) کو فعال کرنا۔ یہ واحد کنٹرول 99% اسناد پر مبنی حملوں کو روکتا ہے۔ SSH پر MFA (بذریعہ PAM)، AWS کنسول، ڈیٹا بیس ایڈمن ٹولز، اور ایپلیکیشن ایڈمن پینلز کو سختی کے کسی دوسرے اقدام سے پہلے لاگو کریں۔

---

آگے کیا آتا ہے۔

سیکیورٹی سخت کرنا ایک جاری عمل ہے۔ اسے پتہ لگانے کے لیے مانیٹرنگ اور الرٹ، لچک کے لیے ڈیزاسٹر ریکوری اور روک تھام کے لیے CI/CD سیکیورٹی اسکیننگ کے ساتھ جوڑیں۔

سیکیورٹی سخت کرنے کے مشورے کے لیے ECOSIRE سے رابطہ کریں، یا مکمل انفراسٹرکچر روڈ میپ کے لیے ہماری DevOps گائیڈ کو دریافت کریں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو پیداواری انفراسٹرکچر کو محفوظ بنانے میں مدد کرنا۔