امنیت

تحلیل لاگ‌های SSH برای شناسایی Brute Force

تحلیل لاگ‌های SSH برای شناسایی Brute Force

مقدمه

SSH یکی از اصلی‌ترین روش‌های مدیریت Remote سرورهای Linux است و به همین دلیل یکی از سرویس‌هایی است که معمولاً هدف تلاش‌های مکرر Authentication قرار می‌گیرد.

اگر SSH از اینترنت قابل دسترسی باشد، ممکن است در Logهای Server تعداد زیادی پیام مشابه موارد زیر مشاهده کنید:

Failed password for root from 203.0.113.50 port 51234 ssh2

یا:

Failed password for invalid user admin from 203.0.113.50 port 51420 ssh2

وجود چند Failed Login طبیعی است، اما تعداد زیاد تلاش‌های تکراری می‌تواند نشان‌دهنده:

Brute Force
Password Guessing
Password Spraying
Credential Stuffing
Username Enumeration

باشد.

MITRE ATT&CK تکنیک Brute Force را با شناسه T1110 ثبت کرده و Password Guessing، Password Spraying و Credential Stuffing را به‌عنوان Sub-techniqueهای آن معرفی می‌کند. SSH نیز یکی از سرویس‌های رایج هدف Password Guessing است.

در این مقاله بررسی می‌کنیم چگونه با استفاده از:

auth.log
secure
journalctl
grep
awk
sort
uniq
last
lastb
Fail2ban

تلاش‌های Brute Force روی SSH را شناسایی و تحلیل کنیم.

Brute Force روی SSH چیست؟

در ساده‌ترین حالت مهاجم یک Username را انتخاب می‌کند و Passwordهای مختلف را امتحان می‌کند:

root
  |
  +--> Password 1
  +--> Password 2
  +--> Password 3
  +--> Password 4

این رفتار بیشتر با:

Password Guessing

مطابقت دارد.

MITRE این رفتار را در T1110.001 قرار می‌دهد.

Password Spraying چه تفاوتی دارد؟

در Password Spraying معمولاً یک Password یا تعداد کمی Password روی تعداد زیادی User امتحان می‌شود:

Password123
    |
    +--> root
    +--> admin
    +--> deploy
    +--> support
    +--> backup

هدف این روش کاهش احتمال Lock شدن یک Account خاص است.

MITRE این رفتار را با T1110.003 ثبت کرده است.

Credential Stuffing چیست؟

در Credential Stuffing مهاجم از Username و Passwordهایی که قبلاً از منابع دیگری به دست آمده‌اند استفاده می‌کند و آنها را روی SSH امتحان می‌کند.

MITRE آن را با شناسه:

T1110.004

طبقه‌بندی می‌کند.

از روی SSH Log همیشه نمی‌توان با قطعیت تشخیص داد Password از چه منبعی آمده است، اما Pattern تلاش‌ها می‌تواند سرنخ ایجاد کند.

لاگ SSH کجا ذخیره می‌شود؟

مسیر Log به Distribution و Logging Configuration بستگی دارد.

روی Ubuntu و Debian، اگر rsyslog برای Authentication Log استفاده شود، معمولاً:

/var/log/auth.log

را بررسی می‌کنیم.

روی AlmaLinux، Rocky Linux، RHEL و بعضی سیستم‌های مشابه معمولاً:

/var/log/secure

استفاده می‌شود.

روی سیستم‌های مبتنی بر systemd نیز می‌توان مستقیماً Journal را بررسی کرد:

journalctl -u ssh

یا:

journalctl -u sshd

نام Service بسته به Distribution ممکن است ssh یا sshd باشد.

ابتدا نام Service را پیدا کنیم

اجرا کنید:

systemctl status ssh

اگر وجود نداشت:

systemctl status sshd

همچنین:

systemctl list-units --type=service | grep -E 'ssh|sshd'

مشاهده آخرین لاگ‌های SSH با journalctl

روی Ubuntu معمولاً:

journalctl -u ssh -n 100

روی AlmaLinux یا RHEL معمولاً:

journalctl -u sshd -n 100

برای مشاهده Logهای 24 ساعت اخیر:

journalctl -u ssh --since "24 hours ago"

یا:

journalctl -u sshd --since "24 hours ago"

journalctl امکان Filter کردن Journal بر اساس Unit و بازه زمانی را فراهم می‌کند.

Failed Password را پیدا کنیم

روی Ubuntu/Debian:

grep "Failed password" /var/log/auth.log

روی AlmaLinux/RHEL:

grep "Failed password" /var/log/secure

مثلاً:

Sep 26 03:21:14 server sshd[18422]: Failed password for root from 203.0.113.50 port 51234 ssh2

اطلاعات مهم این Line عبارت‌اند از:

Time
Username
Source IP
Source Port
Authentication Result

Invalid User چیست؟

ممکن است مهاجم Usernameهایی را امتحان کند که اصلاً روی Server وجود ندارند.

مثلاً:

Failed password for invalid user admin from 203.0.113.50 port 55120 ssh2

یا:

Invalid user oracle from 203.0.113.50

برای بررسی:

grep -E "Invalid user|Failed password for invalid user" \
/var/log/auth.log

روی RHEL-based:

grep -E "Invalid user|Failed password for invalid user" \
/var/log/secure

تعداد زیاد Usernameهای مختلف از یک IP می‌تواند با Username Enumeration یا Password Spraying سازگار باشد.

تعداد Failed Loginها را بشماریم

Ubuntu:

grep -c "Failed password" /var/log/auth.log

AlmaLinux/RHEL:

grep -c "Failed password" /var/log/secure

مثلاً:

1842

این عدد به‌تنهایی چیزی را ثابت نمی‌کند.

باید ببینیم این تلاش‌ها:

از چه IPهایی؟
برای چه Userهایی؟
در چه بازه زمانی؟

انجام شده‌اند.

IPهایی که بیشترین Failed Login دارند

یکی از کاربردی‌ترین بررسی‌ها، شمارش Source IPها است.

Ubuntu:

grep "Failed password" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr |
head -20

روی RHEL:

grep "Failed password" /var/log/secure |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr |
head -20

نمونه:

842 203.0.113.50
417 198.51.100.20
122 192.0.2.44
 18 10.10.10.25

اکنون سریع مشخص می‌شود کدام IP بیشترین تلاش را داشته است.

بررسی یک IP خاص

فرض کنیم IP:

203.0.113.50

مشکوک است.

grep "203.0.113.50" /var/log/auth.log

یا:

grep "203.0.113.50" /var/log/secure

برای Journal:

journalctl -u ssh --since "24 hours ago" |
grep "203.0.113.50"

این کار Timeline فعالیت همان IP را مشخص می‌کند.

Usernameهایی که بیشتر هدف قرار گرفته‌اند

برای استخراج Usernameها از Failed Passwordها:

grep "Failed password" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++) {
        if($i=="for") {
            if($(i+1)=="invalid" && $(i+2)=="user")
                print $(i+3)
            else
                print $(i+1)
        }
    }
}' |
sort |
uniq -c |
sort -nr |
head -20

نمونه:

610 root
341 admin
188 ubuntu
102 test
 94 oracle
 71 deploy

اگر Usernameهای عمومی مانند:

root
admin
test
oracle
user
ubuntu

زیاد دیده شوند، می‌تواند نشان‌دهنده Automated Scanning باشد.

تلاش برای Login به root

برای Root:

grep -E "Failed password for root|Failed password for invalid user root" \
/var/log/auth.log

یا:

grep -E "Failed password for root|Failed password for invalid user root" \
/var/log/secure

اگر Root Login از SSH طبق Policy سازمان نباید استفاده شود، هر تلاش موفق یا مشکوک برای Root اهمیت بیشتری دارد.

Login موفق SSH را بررسی کنیم

فقط Failureها را بررسی نکنید.

مهم‌ترین سؤال بعدی این است:

آیا بعد از این Failها Login موفقی رخ داده است؟

برای Password Login موفق:

grep "Accepted password" /var/log/auth.log

برای Public Key:

grep "Accepted publickey" /var/log/auth.log

برای هر دو:

grep -E "Accepted password|Accepted publickey" \
/var/log/auth.log

در RHEL-based نیز همین الگو را روی:

/var/log/secure

استفاده کنید.

مهم‌ترین Pattern: Fail و سپس Success

فرض کنید:

03:20 Failed password for root from 203.0.113.50
03:20 Failed password for root from 203.0.113.50
03:21 Failed password for root from 203.0.113.50
03:22 Accepted password for root from 203.0.113.50

این Pattern اهمیت زیادی دارد.

MITRE نیز در Detection Strategy مرتبط با Brute Force، تعداد زیاد Authentication Failure و سپس Success از همان IP یا User را یکی از الگوهای مهم Detection معرفی می‌کند.

Fail و Success یک IP را کنار هم ببینیم

grep -E "Failed password|Accepted password|Accepted publickey" \
/var/log/auth.log |
grep "203.0.113.50"

مثلاً:

Failed password for root from 203.0.113.50
Failed password for root from 203.0.113.50
Accepted password for root from 203.0.113.50

در این حالت Investigation باید ادامه پیدا کند.

User Loginهای موفق را بررسی کنیم

با دستور:

last

می‌توان Loginهای ثبت‌شده در wtmp را مشاهده کرد.

مثلاً:

root pts/0 203.0.113.50 Fri Sep 26 03:22

برای نمایش IP در انتهای Line:

last -a

همچنین:

lastlog

آخرین Login مربوط به Userها را نمایش می‌دهد.

Failed Loginهای btmp

در بسیاری از Linux Serverها Failed Loginها در Database مربوط به:

/var/log/btmp

نیز قابل مشاهده هستند.

برای خواندن آن:

lastb

یا:

lastb -a

مثلاً:

root ssh:notty 203.0.113.50 Fri Sep 26 03:21

اگر lastb خروجی نداشت، ممکن است btmp وجود نداشته باشد یا Logging مربوطه فعال نباشد.

Top IP با lastb

برای بررسی سریع:

lastb -a |
head -100

برای استخراج IPها ممکن است بسته به Format سیستم نیاز به Parsing متفاوت باشد، بنابراین برای تحلیل دقیق‌تر معمولاً Logهای sshd گزینه بهتری هستند.

بررسی Logهای Rotate شده

حمله ممکن است چند روز قبل رخ داده باشد.

فقط:

auth.log

را بررسی نکنید.

ممکن است فایل‌هایی مانند:

auth.log.1
auth.log.2.gz
auth.log.3.gz

وجود داشته باشند.

بررسی:

ls -lah /var/log/auth.log*

روی RHEL:

ls -lah /var/log/secure*

جستجو داخل Logهای فشرده

برای Ubuntu:

zgrep -h "Failed password" \
/var/log/auth.log* \
2>/dev/null

روی AlmaLinux/RHEL:

zgrep -h "Failed password" \
/var/log/secure* \
2>/dev/null

این روش Logهای قدیمی و فشرده را نیز بررسی می‌کند.

Top IP در تمام Logهای Rotate شده

Ubuntu:

zgrep -h "Failed password" \
/var/log/auth.log* \
2>/dev/null |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr |
head -20

برای /var/log/secure* نیز همین ساختار قابل استفاده است.

بررسی تعداد Attemptها در هر دقیقه

برای شناسایی Attackهای سریع می‌توان تعداد Failها را براساس Timestamp Group کرد.

مثلاً برای Format رایج syslog:

grep "Failed password" /var/log/auth.log |
awk '{print $1,$2,substr($3,1,5)}' |
sort |
uniq -c |
sort -nr |
head

ممکن است خروجی مشابه زیر باشد:

146 Sep 26 03:21
132 Sep 26 03:22
 91 Sep 26 03:20

این Spike می‌تواند نشان‌دهنده Automated Brute Force باشد.

Brute Force آهسته را فراموش نکنید

همه Attackها صدها Attempt در دقیقه ندارند.

ممکن است مهاجم:

هر چند دقیقه
یا
هر چند ساعت

یک Attempt انجام دهد تا Thresholdهای ساده را دور بزند.

بنابراین بررسی فقط حجم زیاد در یک Minute کافی نیست.

MITRE Detection Strategy نیز روی Correlation در بازه‌های زمانی و بررسی Pattern میان User و IP تأکید دارد.

بررسی یک User در طول زمان

مثلاً برای:

deploy
grep -E "Failed password.*for (invalid user )?deploy .* from" \
/var/log/auth.log

سپس Loginهای موفق:

grep -E "Accepted (password|publickey) for deploy " \
/var/log/auth.log

این دو خروجی را از نظر:

Time
Source IP
Authentication Method

مقایسه کنید.

Password Authentication یا Public Key؟

برای مشاهده Authentication Methodهای موفق:

grep "Accepted " /var/log/auth.log

ممکن است ببینید:

Accepted password for admin from ...

یا:

Accepted publickey for deploy from ...

Public Key Authentication معمولاً سطح Attack Surface مربوط به Password Guessing را کاهش می‌دهد، به شرط آنکه Password Authentication واقعاً غیرفعال و Keyها به‌درستی مدیریت شوند.

Configuration واقعی SSH را بررسی کنیم

فایل اصلی معمولاً:

/etc/ssh/sshd_config

است و sshd تنظیمات خود را از آن یا فایل تعیین‌شده با -f می‌خواند.

اما به‌دلیل:

Include
Match
Distribution defaults

بهتر است Effective Configuration را ببینیم:

sshd -T

برای تنظیمات مهم:

sshd -T |
grep -E \
'passwordauthentication|permitrootlogin|maxauthtries|maxstartups|allowusers|allowgroups|loglevel'

PasswordAuthentication

برای بررسی:

sshd -T | grep passwordauthentication

OpenSSH گزینه PasswordAuthentication را برای فعال یا غیرفعال کردن Password Login ارائه می‌کند.

اگر Infrastructure شما اجازه می‌دهد، استفاده از Public Key Authentication و غیرفعال کردن Password Authentication می‌تواند حملات Password Guessing را به‌شدت محدود کند.

قبل از تغییر، حتماً Public Key Login را در یک Session جداگانه Test کنید تا دسترسی مدیریتی خود را از دست ندهید.

PermitRootLogin

بررسی:

sshd -T | grep permitrootlogin

OpenSSH برای PermitRootLogin مقادیری مانند:

yes
prohibit-password
forced-commands-only
no

را پشتیبانی می‌کند و مقدار پیش‌فرض مستندشده در OpenSSH فعلی prohibit-password است.

در بسیاری از Environmentها بهتر است Login مستقیم Root محدود و Administration از User مشخص به همراه sudo انجام شود.

MaxAuthTries

بررسی:

sshd -T | grep maxauthtries

MaxAuthTries تعداد Attemptهای Authentication مجاز در هر Connection را کنترل می‌کند و مقدار پیش‌فرض مستندشده OpenSSH برابر 6 است.

این گزینه جلوی همه Brute Forceها را نمی‌گیرد، چون مهاجم می‌تواند Connection جدید ایجاد کند، اما می‌تواند تعداد Attemptها در هر Connection را محدود کند.

MaxStartups

بررسی:

sshd -T | grep maxstartups

این Option تعداد Connectionهای همزمانی را که هنوز Authenticate نشده‌اند کنترل می‌کند. OpenSSH در صورت عبور از Threshold می‌تواند Connectionهای اضافی را Drop کند.

این تنظیم بیشتر برای کنترل Connection Flood و منابع sshd مفید است.

AllowUsers و AllowGroups

OpenSSH می‌تواند Login را فقط به User یا Groupهای مشخص محدود کند.

برای بررسی:

sshd -T | grep -E 'allowusers|allowgroups'

AllowUsers و AllowGroups باعث می‌شوند تنها User یا Groupهای Match شده اجازه Login داشته باشند.

این قابلیت می‌تواند Attack Surface مربوط به Accountهای غیرضروری را کاهش دهد.

LogLevel

بررسی:

sshd -T | grep loglevel

OpenSSH برای LogLevel سطوحی مانند:

QUIET
FATAL
ERROR
INFO
VERBOSE
DEBUG
DEBUG1
DEBUG2
DEBUG3

را پشتیبانی می‌کند و مقدار پیش‌فرض آن INFO است. همچنین مستندات OpenSSH هشدار می‌دهد استفاده دائمی از DEBUG می‌تواند اطلاعات حساس‌تری ثبت کند و برای استفاده معمول توصیه نمی‌شود.

بعد از تغییر sshd_config چه کنیم؟

قبل از Restart:

sshd -t

اگر Command خروجی نداد، معمولاً Syntax Configuration معتبر است.

سپس بسته به Distribution:

systemctl restart ssh

یا:

systemctl restart sshd

در تغییرات Remote SSH بهتر است Session فعلی را باز نگه دارید و Login جدید را قبل از بستن Session قبلی Test کنید.

Fail2ban چیست؟

Fail2ban می‌تواند Logهای Authentication مانند SSH را بررسی کند و IPهایی را که تعداد مشخصی Failure دارند برای مدت تعیین‌شده Block کند.

Repository رسمی Fail2ban آن را ابزاری معرفی می‌کند که Logهایی مانند /var/log/auth.log را بررسی و IPهایی با Authentication Errorهای متعدد را از طریق Firewall Ban می‌کند؛ خود پروژه نیز تأکید می‌کند Fail2ban جای Authentication قوی را نمی‌گیرد.

بررسی وضعیت Fail2ban

اگر نصب است:

systemctl status fail2ban

و:

fail2ban-client status

برای SSH Jail:

fail2ban-client status sshd

تنظیمات Fail2ban را کجا بررسی کنیم؟

معمولاً:

/etc/fail2ban/

و فایل‌هایی مانند:

jail.local
jail.d/*.local

استفاده می‌شوند.

پروژه Fail2ban توصیه می‌کند فایل‌های .conf اصلی تغییر داده نشوند و Customization در فایل‌های .local انجام شود تا Updateها تنظیمات را Overwrite نکنند.

SSH Jail

Fail2ban دارای Filter مخصوص:

sshd

است.

در Configuration رسمی پروژه نیز Section مربوط به:

[sshd]

وجود دارد.

وضعیت:

fail2ban-client status sshd

ممکن است اطلاعاتی مانند:

Currently failed
Total failed
Currently banned
Total banned
Banned IP list

نمایش دهد.

Fail2ban Log

بسته به Configuration:

tail -100 /var/log/fail2ban.log

ممکن است Banهایی شبیه زیر نمایش داده شوند:

Ban 203.0.113.50

یا:

Unban 203.0.113.50

اگر فایل Log وجود ندارد، Journal را بررسی کنید:

journalctl -u fail2ban

آیا Fail2ban کافی است؟

خیر.

Fail2ban می‌تواند Automated Noise و Attack Rate را کاهش دهد، اما نباید جایگزین موارد زیر شود:

SSH Keys
Strong Authentication
Restricted Firewall
VPN
Allowlist
MFA where applicable
Monitoring

خود پروژه Fail2ban نیز تصریح می‌کند که Ban کردن Sourceها خطر Authentication ضعیف را از بین نمی‌برد.

تغییر Port SSH چطور؟

تغییر Port پیش‌فرض SSH می‌تواند حجم Automated Scanهای ساده را کاهش دهد، اما نباید به‌عنوان کنترل امنیتی اصلی در نظر گرفته شود.

مهاجم همچنان می‌تواند Portهای باز Server را Scan کند.

کنترل‌های اصلی باید روی:

Authentication
Access Control
Firewall
Monitoring
Patch Management

تمرکز داشته باشند.

یک Workflow عملی برای تحلیل Brute Force

فرض کنیم Server تعداد زیادی SSH Failed Login دارد.

مرحله اول: بررسی Service

systemctl status ssh

یا:

systemctl status sshd

مرحله دوم: Failed Passwordها

Ubuntu:

grep "Failed password" /var/log/auth.log

RHEL:

grep "Failed password" /var/log/secure

مرحله سوم: Top Source IP

grep "Failed password" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr |
head -20

مرحله چهارم: Top Username

grep "Failed password" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++) {
        if($i=="for") {
            if($(i+1)=="invalid" && $(i+2)=="user")
                print $(i+3)
            else
                print $(i+1)
        }
    }
}' |
sort |
uniq -c |
sort -nr |
head -20

مرحله پنجم: Invalid Userها

grep "invalid user" /var/log/auth.log

مرحله ششم: Successful Loginها

grep -E "Accepted password|Accepted publickey" \
/var/log/auth.log

مرحله هفتم: Correlation یک IP

grep -E "Failed password|Accepted password|Accepted publickey" \
/var/log/auth.log |
grep "203.0.113.50"

مرحله هشتم: last و lastb

last -a

و:

lastb -a

مرحله نهم: SSH Effective Config

sshd -T |
grep -E \
'passwordauthentication|permitrootlogin|maxauthtries|maxstartups|allowusers|allowgroups'

مرحله دهم: Fail2ban

fail2ban-client status sshd

در صورت نصب بودن.

یک Audit سریع

برای Ubuntu/Debian:

LOG="/var/log/auth.log"

echo "=== TOP FAILED IPs ==="

grep "Failed password" "$LOG" |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr |
head -20


echo
echo "=== TOP USERNAMES ==="

grep "Failed password" "$LOG" |
awk '{
    for(i=1;i<=NF;i++) {
        if($i=="for") {
            if($(i+1)=="invalid" && $(i+2)=="user")
                print $(i+3)
            else
                print $(i+1)
        }
    }
}' |
sort |
uniq -c |
sort -nr |
head -20


echo
echo "=== SUCCESSFUL LOGINS ==="

grep -E "Accepted password|Accepted publickey" "$LOG"


echo
echo "=== CURRENT SSH CONFIG ==="

sshd -T |
grep -E \
'passwordauthentication|permitrootlogin|maxauthtries|maxstartups'

برای RHEL-based فقط مقدار:

LOG="/var/log/secure"

را تغییر دهید.

حمله Distributed را چگونه تشخیص دهیم؟

همیشه یک IP صدها Request ایجاد نمی‌کند.

ممکن است:

IP1 -> root
IP2 -> root
IP3 -> root
IP4 -> root
IP5 -> root

در این حالت Count هر IP پایین است، ولی یک Username از تعداد زیادی IP هدف گرفته شده است.

بنابراین علاوه بر Top IP باید:

Top Username
Unique IP per Username
Time Window

را نیز بررسی کنید.

تعداد IPهای یکتا برای یک User

مثلاً برای root:

grep "Failed password for root from" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort -u |
wc -l

اگر تعداد IPهای یکتا زیاد باشد، ممکن است Activity توزیع‌شده باشد.

یک IP با Usernameهای مختلف

برای IP مشکوک:

grep "203.0.113.50" /var/log/auth.log |
grep "Failed password"

اگر مشاهده کنید:

root
admin
ubuntu
mysql
oracle
deploy
test

هدف قرار گرفته‌اند، احتمال Automated Username Guessing بیشتر می‌شود.

بعد از Login موفق مشکوک چه کنیم؟

اگر Source IP پس از چند Failure موفق به Login شده است، بررسی SSH Log کافی نیست.

باید بعد از Timestamp Login موارد زیر بررسی شوند:

Shell History
Processes
Network Connections
Cron Jobs
systemd Services
SSH Keys
Users
sudo
Modified Files

مثلاً:

last -a
ps auxf
ss -plant
crontab -l
systemctl list-unit-files \
--type=service \
--state=enabled

و:

find /root /home \
-path '*/.ssh/authorized_keys' \
-type f \
-print

PowerShell History نداریم؛ Bash History را بررسی کنیم

برای User مشکوک ممکن است:

~/.bash_history

وجود داشته باشد.

مثلاً:

cat /root/.bash_history

اما History نباید به‌عنوان Evidence کامل در نظر گرفته شود، زیرا ممکن است Disable، پاک یا دستکاری شده باشد.

فایل‌های تغییرکرده بعد از Login را بررسی کنیم

فرض کنید Login مشکوک ساعت:

03:22

رخ داده است.

می‌توان فایل‌های تغییرکرده بعد از آن را بررسی کرد:

find /etc /var/www /root /home /tmp /var/tmp /dev/shm \
-type f \
-newermt "2026-09-26 03:22:00" \
-ls 2>/dev/null

این بررسی می‌تواند Persistence یا Payloadهای ایجادشده را پیدا کند.

آیا IP را فوراً Block کنیم؟

اگر Attack در حال انجام است، محدود کردن Source می‌تواند بخشی از Containment باشد.

اما فقط Block کردن یک IP کافی نیست.

ممکن است:

  • IP تغییر کند.
  • حمله Distributed باشد.
  • Credential از قبل Compromise شده باشد.
  • Login موفق رخ داده باشد.

بنابراین Block باید همراه با Investigation انجام شود.

کاهش Attack Surface با Firewall

اگر فقط IPهای مشخصی باید SSH داشته باشند، بهترین کار محدود کردن Source در Firewall است.

برای مثال به‌جای:

0.0.0.0/0 -> SSH

از:

Admin IP / VPN Network -> SSH

استفاده کنید.

برای Serverهای مدیریتی، VPN یا Bastion Host معمولاً امن‌تر از SSH کاملاً Public است.

SSH Key Authentication

اگر امکان‌پذیر است، Login با Public Key را جایگزین Password Authentication کنید.

ابتدا Key Login را تست کنید.

سپس Effective Configuration را بررسی کنید:

sshd -T | grep passwordauthentication

و بعد از تغییر:

sshd -t

را اجرا کنید.

قطع Password Authentication قبل از تست Public Key می‌تواند باعث Lockout مدیریتی شود.

Logها را مرکزی کنید

اگر Authentication Log فقط روی Server باقی بماند، مهاجم دارای Root Access ممکن است آن را حذف یا تغییر دهد.

برای Serverهای مهم بهتر است SSH Logها به:

SIEM
Central Syslog
Wazuh
Log Server

ارسال شوند.

این کار Investigation بعد از Compromise را قابل اعتمادتر می‌کند.

اشتباهات رایج

برخی اشتباهات رایج هنگام تحلیل SSH Brute Force عبارت‌اند از:

  • بررسی فقط تعداد Failed Login
  • بررسی نکردن Source IP
  • بررسی نکردن Usernameهای هدف
  • نادیده گرفتن Invalid Userها
  • بررسی نکردن Logهای Rotate شده
  • بررسی نکردن Successful Login
  • بررسی نکردن Public Key Loginها
  • تمرکز فقط روی یک IP
  • نادیده گرفتن Distributed Attack
  • نادیده گرفتن Attackهای آهسته
  • اعتماد کامل به Fail2ban
  • تغییر SSH Port به‌عنوان تنها کنترل امنیتی
  • Block کردن IP بدون بررسی Login موفق
  • بررسی نکردن Persistence بعد از Login مشکوک

بهترین روش‌ها

برای کاهش ریسک SSH Brute Force:

  • Password Authentication را در صورت امکان غیرفعال کنید.
  • Public Key Authentication استفاده کنید.
  • Direct Root Login را محدود کنید.
  • SSH را به IPهای مدیریتی محدود کنید.
  • VPN یا Bastion استفاده کنید.
  • AllowUsers یا AllowGroups را در صورت نیاز تعریف کنید.
  • MaxAuthTries را متناسب با محیط تنظیم کنید.
  • Fail2ban یا کنترل مشابه استفاده کنید.
  • Authentication Logها را مانیتور کنید.
  • Fail و Success را Correlate کنید.
  • Loginهای Root و Accountهای مدیریتی Alert شوند.
  • Logها به SIEM ارسال شوند.
  • SSH و سیستم‌عامل به‌روز نگه داشته شوند.

چک‌لیست

برای تحلیل SSH Brute Force موارد زیر را بررسی کنید:

  • Service واقعی SSH مشخص شده است.
  • auth.log یا secure بررسی شده است.
  • systemd Journal بررسی شده است.
  • Failed Passwordها استخراج شده‌اند.
  • Invalid Userها استخراج شده‌اند.
  • Top Source IPها مشخص شده‌اند.
  • Top Usernameها مشخص شده‌اند.
  • Root Login Attemptها بررسی شده‌اند.
  • Attemptها بر اساس زمان بررسی شده‌اند.
  • Logهای Rotate شده بررسی شده‌اند.
  • Successful Password Loginها بررسی شده‌اند.
  • Successful Public Key Loginها بررسی شده‌اند.
  • Fail و Success از یک Source Correlate شده‌اند.
  • last بررسی شده است.
  • lastb بررسی شده است.
  • Distributed Attack بررسی شده است.
  • Attack آهسته بررسی شده است.
  • Effective SSH Config با sshd -T بررسی شده است.
  • PasswordAuthentication بررسی شده است.
  • PermitRootLogin بررسی شده است.
  • MaxAuthTries بررسی شده است.
  • MaxStartups بررسی شده است.
  • AllowUsers و AllowGroups بررسی شده‌اند.
  • Fail2ban در صورت وجود بررسی شده است.
  • Login موفق مشکوک از نظر Persistence بررسی شده است.
  • Firewall Exposure بررسی شده است.
  • Root Cause مشخص شده است.

مطالعات بیشتر

MITRE ATT&CK – Brute Force (T1110)
تعریف Brute Force و Sub-techniqueهای Password Guessing، Password Spraying و Credential Stuffing. MITRE ATT&CK – Brute Force

MITRE ATT&CK – Password Guessing
جزئیات Password Guessing و Detection رفتارهای تکراری Authentication روی سرویس‌هایی مانند SSH. MITRE ATT&CK – Password Guessing

MITRE ATT&CK – Password Spraying
توضیح Password Spraying و تلاش روی تعداد زیادی Account با Passwordهای محدود. MITRE ATT&CK – Password Spraying

OpenSSH – sshd_config
مرجع تنظیمات PasswordAuthentication، PermitRootLogin، AllowUsers، MaxAuthTries و MaxStartups. Linux Manual – sshd_config

Linux Manual – journalctl
مرجع بررسی Logهای systemd و Filter کردن بر اساس Service و Time Range. Linux Manual – journalctl

Fail2ban
Repository رسمی Fail2ban و توضیح نحوه شناسایی Failureهای Authentication و Ban کردن Sourceها. Fail2ban – GitHub

جمع‌بندی

تحلیل SSH Brute Force فقط شمارش تعداد:

Failed password

نیست.

اولین مرحله پیدا کردن Login Failureها است:

grep "Failed password" /var/log/auth.log

یا روی RHEL-based:

grep "Failed password" /var/log/secure

سپس Source IPها باید Group شوند:

grep "Failed password" /var/log/auth.log |
awk '{
    for(i=1;i<=NF;i++)
        if($i=="from")
            print $(i+1)
}' |
sort |
uniq -c |
sort -nr

Usernameهای هدف نیز باید بررسی شوند تا مشخص شود Attack روی یک Account متمرکز است یا چندین User هدف قرار گرفته‌اند.

اما مهم‌ترین مرحله Correlation میان Failure و Success است:

Failed
Failed
Failed
   |
   v
Accepted

MITRE نیز تعداد زیاد Authentication Failure و سپس Login موفق از همان Source یا User را یکی از Detection Patternهای مهم Brute Force معرفی می‌کند.

اگر Login موفق مشکوکی پیدا شد، Investigation نباید در SSH Log متوقف شود.

باید:

Processes
Network
SSH Keys
Cron
systemd
Users
sudo
Modified Files

در Timeline بعد از Login بررسی شوند.

برای Hardening نیز Effective Configuration را با:

sshd -T

بررسی کنید و مواردی مانند:

PasswordAuthentication
PermitRootLogin
MaxAuthTries
MaxStartups
AllowUsers
AllowGroups

را متناسب با نیاز Server تنظیم کنید. OpenSSH این کنترل‌ها را مستقیماً در sshd_config ارائه می‌کند.

در نهایت، یک IP پرتکرار به‌تنهایی Attack را اثبات نمی‌کند. تشخیص معتبر زمانی شکل می‌گیرد که:

Source IP
+
Username
+
Failure Count
+
Time Pattern
+
Successful Login
+
Post-Login Activity

در کنار یکدیگر تحلیل شوند.

کیان پور

نظرات خود را بنویسید...

اشتراک گذاری این مقاله

تحلیل لاگ‌های SSH برای شناسایی Brute Force

کپی کردن لینک

سلام