آموزش افزایش امنیت سرور MTA در لینوکس

“`html

راه‌اندازی سرور MTA روی VPS فقط به نصب فایل‌های سرور و باز کردن پورت‌ها محدود نمی‌شود. یک سرور عمومی از لحظه‌ای که IP آن در اینترنت قابل دسترسی باشد، ممکن است با اسکن پورت، تلاش برای ورود به SSH، حملات Brute Force، Resourceهای آلوده، دسترسی‌های اشتباه و حملات شبکه روبه‌رو شود.

برای افزایش امنیت سرور MTA باید هم سیستم‌عامل Linux و هم تنظیمات خود MTA را بررسی کنیم. SSH، Firewall، کاربران Linux، Fail2Ban، Permission فایل‌ها، ACL داخلی MTA، Resourceها، Logها و پورت‌های باز همگی بخشی از امنیت نهایی سرور هستند.

در این آموزش مراحل امن‌سازی یک سرور MTA روی Ubuntu/Debian را قدم‌به‌قدم بررسی می‌کنیم. قبل از اجرای هر دستور، مخصوصاً تغییرات SSH و Firewall، مطمئن شوید به Console یا پنل اضطراری VPS دسترسی دارید تا در صورت اشتباه از سرور قفل نشوید.

مهم‌ترین تهدیدهای امنیتی سرور MTA چیست؟

حملات Brute Force روی SSH
استفاده مستقیم از حساب root
رمز عبور ضعیف
باز بودن پورت‌های غیرضروری
Firewall تنظیم‌نشده
Resourceهای ناشناس یا آلوده
دسترسی بیش از حد Resourceها در ACL
اجرای MTA با کاربر root
Permission اشتباه فایل‌ها مانند 777
لو رفتن اطلاعات MySQL و API Keyها
WebAdmin بدون کنترل مناسب
به‌روز نبودن سیستم‌عامل یا MTA
نگهداری Backup در محل عمومی
نادیده گرفتن Logهای امنیتی
حملات شبکه و DDoS

قبل از شروع امنیت سرور یک Backup بگیرید

قبل از تغییر SSH، Firewall، Permission فایل‌ها یا تنظیمات MTA بهتر است از فایل‌های مهم سرور Backup داشته باشید.

mtaserver.conf
acl.xml
accounts.xml در صورت استفاده
Resourceها
فایل‌های Lua اختصاصی
دیتابیس MySQL یا MariaDB
فایل Service مربوط به systemd

قبل از فعال‌کردن Firewall یا غیرفعال‌کردن Password Authentication در SSH، حتماً یک اتصال SSH دوم باز نگه دارید و دسترسی Console دیتاسنتر را بررسی کنید.

به‌روزرسانی Linux قبل از امن‌سازی MTA

ابتدا فهرست Packageها را به‌روز کنید:

sudo apt update

Packageهای قابل ارتقا را مشاهده کنید:

apt list --upgradable

سپس در زمان Maintenance سیستم را ارتقا دهید:

sudo apt upgrade

به‌روزرسانی‌های امنیتی سیستم‌عامل اهمیت زیادی دارند، اما روی سرور Production بهتر است قبل از Upgrade گسترده Backup داشته باشید و بعد از ارتقا عملکرد MTA، MySQL و Serviceها را بررسی کنید.

سرور MTA را با root اجرا نکنید

یکی از مهم‌ترین اصول امنیتی این است که Process سرور MTA با حساب root اجرا نشود. اگر یک Resource، کتابخانه یا آسیب‌پذیری بتواند Process را تحت کنترل بگیرد، اجرای MTA با root سطح خسارت احتمالی را بسیار بیشتر می‌کند.

برای بررسی User فعلی Process:

ps -o user,pid,ppid,%cpu,%mem,cmd -C mta-server64

اگر ستون USER مقدار root را نشان می‌دهد، بهتر است یک User اختصاصی برای MTA ایجاد کنید.

ساخت کاربر اختصاصی برای MTA

اگر قبلاً User با نام mta ساخته نشده است:

sudo adduser mta

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

/home/mta/multitheftauto_linux_x64

مالکیت آن‌ها را به User مربوط به MTA بدهید:

sudo chown -R mta:mta \
/home/mta/multitheftauto_linux_x64

فایل اصلی Server باید قابل اجرا باشد:

chmod 750 \
/home/mta/multitheftauto_linux_x64/mta-server64

از chmod 777 برای MTA استفاده نکنید

یکی از اشتباهات رایج هنگام حل مشکل Permission این است که کل پوشه سرور با 777 باز شود.

chmod -R 777 /home/mta/...

این روش معمولاً راه‌حل مناسبی نیست زیرا امکان Write را برای همه کاربران سیستم فراهم می‌کند.

بهتر است ابتدا Owner و Group فایل‌ها را درست تنظیم کنید و فقط Permission موردنیاز هر فایل یا پوشه را بدهید.

برای مثال mtaserver.conf معمولاً نیازی ندارد توسط سایر کاربران سیستم خوانده یا ویرایش شود:

chmod 640 \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/mtaserver.conf

بررسی اجرای MTA با systemd

اگر در آموزش قبلی MTA را به‌صورت Service راه‌اندازی کرده‌اید، فایل Service را بررسی کنید:

sudo systemctl cat mtaserver

در بخش Service بهتر است Process با User اختصاصی اجرا شود:

[Service]
User=mta
Group=mta

پس از تغییر فایل Service:

sudo systemctl daemon-reload
sudo systemctl restart mtaserver

راهنمای کامل این بخش در مقاله آموزش اجرای خودکار سرور MTA با systemd توضیح داده شده است.

امن‌سازی SSH سرور MTA

SSH یکی از مهم‌ترین نقاط ورود مدیریتی VPS است. اگر SSH به‌درستی امن نشود، حتی کانفیگ مناسب MTA نیز امنیت کل سرور را تضمین نمی‌کند.

استفاده از SSH Key
غیرفعال‌کردن Login مستقیم root
غیرفعال‌کردن Password Login پس از تست Key
محدودکردن تلاش‌های ورود
استفاده از Fail2Ban
بررسی Logهای ورود

ساخت SSH Key

روی کامپیوتر شخصی خود می‌توانید یک Key از نوع Ed25519 ایجاد کنید:

ssh-keygen -t ed25519

برای امنیت بیشتر برای Private Key یک Passphrase مناسب تعیین کنید.

در Linux و سیستم‌هایی که ssh-copy-id دارند می‌توان Public Key را به سرور منتقل کرد:

ssh-copy-id username@SERVER_IP

قبل از غیرفعال‌کردن Password Login، یک Terminal جدید باز کنید و مطمئن شوید ورود با Key بدون مشکل انجام می‌شود.

غیرفعال‌کردن ورود مستقیم root با SSH

فایل تنظیمات OpenSSH را باز کنید:

sudo nano /etc/ssh/sshd_config

مقدار زیر را تنظیم کنید:

PermitRootLogin no

قبل از انجام این کار مطمئن شوید یک User معمولی با دسترسی sudo دارید و ورود آن به سرور آزمایش شده است.

غیرفعال‌کردن Password Authentication

بعد از اینکه SSH Key را کاملاً تست کردید می‌توانید ورود با Password را غیرفعال کنید:

PasswordAuthentication no
PubkeyAuthentication yes

در صورت عدم نیاز به Keyboard Interactive Authentication می‌توان آن را نیز غیرفعال کرد:

KbdInteractiveAuthentication no

PasswordAuthentication را تا زمانی که ورود با SSH Key را در یک Session جدید تست نکرده‌اید غیرفعال نکنید.

بررسی تنظیمات SSH قبل از Reload

قبل از اعمال تغییرات، Syntax فایل SSH را بررسی کنید:

sudo sshd -t

اگر هیچ Error نمایش داده نشد، Service را Reload کنید:

sudo systemctl reload ssh

برای مشاهده تنظیمات مؤثر SSH:

sudo sshd -T | \
grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'

آیا تغییر پورت SSH باعث امنیت بیشتر می‌شود؟

تغییر پورت SSH می‌تواند مقدار زیادی از Scan و Botهای ساده‌ای که فقط پورت 22 را هدف قرار می‌دهند کم کند، اما جایگزین SSH Key، Firewall و Fail2Ban نیست.

اگر پورت SSH را تغییر می‌دهید، قبل از Restart یا Reload حتماً پورت جدید را در Firewall باز کنید. همچنین تنظیم Fail2Ban باید با پورت جدید هماهنگ شود.

نصب و تنظیم UFW برای سرور MTA

در Ubuntu می‌توان برای مدیریت Firewall از UFW استفاده کرد.

ابتدا وضعیت فعلی را بررسی کنید:

sudo ufw status verbose

سیاست پایه پیشنهادی برای یک VPS معمولی:

sudo ufw default deny incoming
sudo ufw default allow outgoing

قبل از فعال‌کردن UFW پورت SSH را باز کنید

اگر SSH روی پورت استاندارد 22 اجرا می‌شود:

sudo ufw allow 22/tcp

یا در Ubuntu می‌توانید از Profile مربوط به OpenSSH استفاده کنید:

sudo ufw allow OpenSSH

اگر SSH روی پورت سفارشی مثلاً 2222 است:

sudo ufw allow 2222/tcp

اگر قبل از ufw enable اجازه SSH را اضافه نکنید، احتمال دارد اتصال Remote خود را از دست بدهید.

پورت‌های موردنیاز MTA

در تنظیمات پیش‌فرض MTA معمولاً سه پورت اصلی مطرح هستند:

پورت	Protocol	کاربرد
22003	UDP	اتصال اصلی بازیکنان به سرور
22005	TCP	HTTP Server داخلی MTA
22126	UDP	ASE / Server Browser در تنظیم پیش‌فرض

اگر serverport را تغییر داده‌اید، شماره واقعی موجود در mtaserver.conf را مبنا قرار دهید.

باز کردن پورت اصلی MTA در UFW

sudo ufw allow 22003/udp

باز کردن پورت HTTP سرور MTA

sudo ufw allow 22005/tcp

این Rule را زمانی ایجاد کنید که HTTP Server داخلی MTA موردنیاز است. اگر HTTP Server را عمداً غیرفعال کرده‌اید، نیازی به باز نگه داشتن پورت مربوط به آن نیست.

باز کردن ASE Port

sudo ufw allow 22126/udp

در حالت serverport پیش‌فرض 22003، پورت ASE برابر 22126 است. اگر تنظیمات سرور تغییر کرده‌اند، مقدار واقعی را براساس کانفیگ MTA بررسی کنید.

فعال‌کردن UFW

بعد از اینکه SSH و تمام پورت‌های ضروری را اضافه کردید:

sudo ufw enable

سپس وضعیت را بررسی کنید:

sudo ufw status numbered

نمونه Ruleهای موردنیاز یک سرور MTA استاندارد می‌تواند شامل موارد زیر باشد:

22/tcp      ALLOW
22003/udp   ALLOW
22005/tcp   ALLOW
22126/udp   ALLOW

باز بودن هر پورت باید دلیل مشخص داشته باشد. سرویس‌هایی مانند MySQL نباید بدون نیاز واقعی مستقیماً برای کل اینترنت باز شوند.

بررسی تمام پورت‌های Listen شده روی VPS

sudo ss -lntup

این خروجی را بررسی کنید و ببینید چه Serviceهایی در حال Listen هستند. هر پورت ناشناس را قبل از بستن، به Process مربوط به آن نسبت دهید.

بررسی پورت UDP اصلی MTA

sudo ss -lunp | grep 22003

بررسی پورت HTTP

sudo ss -ltnp | grep 22005

استفاده از openports در Console سرور MTA

MTA دستور داخلی برای بررسی وضعیت پورت‌های موردنیاز دارد. در Console سرور اجرا کنید:

openports

اگر Process روی پورت Listen می‌کند اما openports مشکل نشان می‌دهد، علاوه بر UFW باید Firewall پنل VPS، Security Group دیتاسنتر، NAT و تنظیمات شبکه را نیز بررسی کنید.

Firewall دیتاسنتر را فراموش نکنید

بعضی ارائه‌دهندگان VPS علاوه بر Firewall سیستم‌عامل، یک Firewall در پنل کاربری دارند. در چنین شرایطی بازکردن پورت فقط در UFW کافی نیست.

SSH TCP
MTA Game Port روی UDP
HTTP Port در صورت استفاده
ASE Port در صورت فعال بودن

باید در Firewall دیتاسنتر نیز مطابق نیاز Server اجازه داده شوند.

نصب Fail2Ban برای محافظت از SSH

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

برای نصب:

sudo apt update
sudo apt install fail2ban -y

ساخت Jail برای SSH

به‌جای ویرایش مستقیم jail.conf می‌توان یک فایل Local ایجاد کرد:

sudo nano /etc/fail2ban/jail.d/sshd.local

نمونه تنظیم:

[sshd]
enabled = true
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h

در این مثال اگر یک IP در بازه تعریف‌شده تعداد زیادی Authentication Failure ایجاد کند، Fail2Ban می‌تواند آن را به‌صورت موقت Ban کند.

اگر SSH روی پورت سفارشی مثلاً 2222 قرار دارد، مقدار port را متناسب با آن تغییر دهید:

port = 2222

فعال‌کردن Fail2Ban

sudo systemctl enable --now fail2ban

وضعیت Service:

sudo systemctl status fail2ban

وضعیت Jailها:

sudo fail2ban-client status

وضعیت SSH:

sudo fail2ban-client status sshd

اگر Fail2Ban لاگ SSH را پیدا نکرد چه کنیم؟

روش ثبت Log بین Distributionها و نسخه‌های Linux متفاوت است. اگر Jail مربوط به sshd نمی‌تواند Log مناسب را پیدا کند و سیستم از systemd Journal استفاده می‌کند، می‌توان Backend را بررسی و در صورت نیاز برای Jail مربوطه systemd تعیین کرد:

[sshd]
enabled = true
backend = systemd
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h

پس از تغییر تنظیمات Fail2Ban، Log سرویس را بررسی کنید:

sudo journalctl -u fail2ban -n 100 --no-pager

بررسی تلاش‌های ورود به SSH

برای مشاهده Log سرویس SSH در سیستم‌های مبتنی بر systemd:

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

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

last -a | head -20

در سیستم‌هایی که failed loginها در btmp ثبت می‌شوند:

sudo lastb -a | head -20

امنیت ACL در MTA

MTA سیستم Access Control List داخلی دارد که مشخص می‌کند کاربران و Resourceها به چه Commandها و Functionهایی دسترسی داشته باشند.

یکی از اشتباهات خطرناک این است که برای حل سریع یک خطای Permission، یک Resource ناشناس را مستقیماً عضو Admin کنید یا دسترسی‌های بسیار گسترده به آن بدهید.

فقط Permission موردنیاز Resource را فعال کنید.
به Resource ناشناس دسترسی Admin کامل ندهید.
درخواست‌های ACL یک Resource را قبل از تأیید بررسی کنید.
acl.xml را قبل از تغییر Backup بگیرید.
دسترسی کاربران Admin را محدود نگه دارید.

بررسی ACL Request یک Resource

Resourceهای جدید MTA می‌توانند Permissionهای موردنیاز خود را در meta.xml درخواست کنند. قبل از Allow کردن درخواست‌ها بهتر است بدانید هر Permission چه کاری انجام می‌دهد.

در Console می‌توان درخواست‌ها را بررسی کرد:

aclrequest list

یا برای Resource مشخص:

aclrequest list resource-name

درخواست ACL را فقط به این دلیل که Resource بدون آن Start نمی‌شود تأیید نکنید. ابتدا مشخص کنید Resource چرا به آن Function نیاز دارد.

Resource ناشناس را مستقیم روی سرور Production نصب نکنید

Resource یک مجموعه فایل ساده نیست. کد Server-side آن روی سرور اجرا می‌شود و بسته به Permission می‌تواند به بخش‌های مختلف پروژه دسترسی داشته باشد.

قبل از نصب Resource دانلودشده از منابع ناشناس:

فایل‌های Lua را بررسی کنید.
meta.xml را بخوانید.
ACL Requestها را بررسی کنید.
اتصال‌های HTTP خارجی را بررسی کنید.
کدهای Obfuscated ناشناس را با احتیاط استفاده کنید.
در محیط Test اجرا کنید.
CPU و Network را قبل و بعد از Start مقایسه کنید.

برای مشاهده تغییر مصرف Resourceها می‌توانید از مقاله آموزش مانیتورینگ سرور MTA در لینوکس استفاده کنید.

هر Resource را Admin نکنید

اصل Least Privilege یعنی هر User یا Resource فقط دسترسی‌هایی را داشته باشد که واقعاً برای عملکرد خود نیاز دارد.

اگر یک Resource فقط به یک Function مدیریتی مشخص نیاز دارد، دادن مجموعه بزرگی از Permissionهای Admin به آن کار مناسبی نیست.

امنیت WebAdmin در MTA

Web Interface داخلی MTA امکان مدیریت بخش‌هایی از سرور را از طریق Browser فراهم می‌کند. اگر از این قابلیت استفاده می‌کنید:

برای Account مدیریتی Password قوی و منحصربه‌فرد انتخاب کنید.
Accountهای قدیمی را حذف کنید.
دسترسی Admin را فقط به افراد موردنیاز بدهید.
ACL کاربران مدیریتی را دوره‌ای بررسی کنید.
از اشتراک‌گذاری حساب Admin بین چند نفر خودداری کنید.
در صورت عدم نیاز به WebAdmin، Resourceهای مدیریتی غیرضروری را فعال نگه ندارید.

اطلاعات MySQL را در Resource عمومی قرار ندهید

اگر Resource سرور به MySQL متصل می‌شود، اطلاعاتی مانند Username، Password، Host و نام Database نباید در Repository عمومی، فایل قابل دانلود یا محتوای Client-side قرار بگیرند.

همچنین برای اتصال MTA به دیتابیس بهتر است یک User اختصاصی Database با دسترسی موردنیاز همان پروژه ساخته شود، نه اینکه از root دیتابیس استفاده شود.

برای تنظیم کامل Database مقاله آموزش اتصال سرور MTA به MySQL و رفع خطاهای دیتابیس را مطالعه کنید.

آیا باید پورت MySQL را روی اینترنت باز کنیم؟

اگر MySQL روی همان VPS اجرا می‌شود و MTA به‌صورت Local به آن متصل است، معمولاً دلیلی برای بازکردن پورت Database برای تمام اینترنت وجود ندارد.

قبل از بازکردن هر Port دیتابیس مشخص کنید چه سیستم یا IP مشخصی واقعاً باید به آن متصل شود. دسترسی عمومی غیرضروری سطح حمله سرور را افزایش می‌دهد.

Backupها را در مسیر Public قرار ندهید

Backup دیتابیس، فایل‌های ZIP پروژه، فایل‌های Config و نسخه‌های قدیمی Resource ممکن است شامل Password، Token، اطلاعات کاربران یا کدهای اختصاصی باشند.

Backup را داخل Web Root عمومی قرار ندهید.
Permission فایل Backup را محدود کنید.
Backupهای قدیمی را براساس Retention حذف کنید.
در صورت انتقال Backup از کانال امن استفاده کنید.
از Backupها نیز در برابر دسترسی غیرمجاز محافظت کنید.

بررسی Log داخلی سرور MTA

Logها یکی از اولین منابع برای تشخیص رفتار غیرعادی هستند.

tail -f \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

برای جست‌وجوی پیام‌های مهم:

grep -Ei \
'error|warning|failed|denied|ban|login' \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/logs/server.log

بررسی Journal سرویس MTA

sudo journalctl \
-u mtaserver.service \
-n 100 \
--no-pager

برای مشاهده زنده:

sudo journalctl \
-u mtaserver.service \
-f

بررسی Userهایی که به VPS دسترسی دارند

فهرست Userهای سیستم:

cut -d: -f1 /etc/passwd

Userهایی که دیگر برای مدیریت پروژه نیاز نیستند باید بررسی و در صورت اطمینان حذف یا دسترسی آن‌ها محدود شود.

برای مشاهده اعضای گروه sudo:

getent group sudo

هر User اضافی با دسترسی sudo می‌تواند سطح ریسک سرور را افزایش دهد.

بررسی SSH Keyهای مجاز

برای هر User مدیریتی فایل زیر را بررسی کنید:

~/.ssh/authorized_keys

Keyهایی که صاحب آن‌ها را نمی‌شناسید یا دیگر مورد استفاده نیستند باید بعد از بررسی حذف شوند.

محدودکردن Permission فایل SSH

Permission نامناسب روی فایل‌های SSH می‌تواند باعث مشکل امنیتی یا حتی ردشدن Key توسط OpenSSH شود.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

امنیت Passwordهای MTA

برای حساب‌های Admin، Moderator و سایر کاربران دارای Permission ویژه از Passwordهای طولانی و منحصربه‌فرد استفاده کنید.

Password را در چند سرویس تکرار نکنید.
Password را داخل Resource یا فایل عمومی ذخیره نکنید.
حساب Admin مشترک بین چند نفر نسازید.
بعد از قطع همکاری یک مدیر، دسترسی او را حذف کنید.
ACL و حساب‌های مدیریتی را دوره‌ای Audit کنید.

آیا UFW و Fail2Ban جلوی DDoS را می‌گیرند؟

Firewall سیستم‌عامل و Fail2Ban برای محدودکردن دسترسی‌ها و بسیاری از حملات ساده بسیار مفید هستند، اما نباید آن‌ها را جایگزین سیستم Anti-DDoS دیتاسنتر دانست.

اگر حجم حمله آن‌قدر زیاد باشد که پهنای باند VPS یا لینک دیتاسنتر را اشباع کند، Packetها قبل از اینکه Firewall داخل VPS بتواند مشکل را حل کند به شبکه رسیده‌اند.

برای سرورهای MTA عمومی با Player زیاد، کیفیت شبکه و Anti-DDoS ارائه‌دهنده VPS نیز بخشی از انتخاب Hosting است.

برای انتخاب VPS مناسب می‌توانید مقاله VPS مناسب سرور MTA چه مشخصاتی باید داشته باشد؟ را مطالعه کنید.

نشانه‌های احتمالی مشکل امنیتی در سرور

Process ناشناس با CPU بالا
پورت جدیدی که قبلاً Listen نمی‌کرده است
User ناشناس در Linux
SSH Key ناشناس
تغییر بدون دلیل در Resourceها
فایل‌های جدید ناشناس
مصرف غیرعادی Network
Login از IPهای ناشناس
تغییر ACL بدون هماهنگی
Crash یا Restart غیرعادی
افزایش ناگهانی Load
ارسال ترافیک غیرعادی از VPS

اگر به نفوذ مشکوک شدیم چه کار کنیم؟

بدون بررسی فوری Logها را حذف نکنید.
Loginهای اخیر را بررسی کنید.
Processهای فعال را ثبت کنید.
پورت‌های Listen شده را ثبت کنید.
SSH Keyها و Userها را بررسی کنید.
فایل‌های تغییرکرده پروژه را بررسی کنید.
Credentialهای مهم را از یک سیستم امن تغییر دهید.
Resourceهای مشکوک را از محیط Production خارج کنید.
Backup سالم را بررسی کنید.
در نفوذ جدی، Rebuild کامل VPS از یک سیستم‌عامل سالم معمولاً مطمئن‌تر از اعتماد مجدد به سیستم آلوده است.

دستورهای سریع برای Audit امنیتی VPS

پورت‌های باز:

sudo ss -lntup

وضعیت Firewall:

sudo ufw status numbered

Processهای پرمصرف:

ps aux --sort=-%cpu | head

Processهای پرمصرف RAM:

ps aux --sort=-%mem | head

Loginهای اخیر:

last -a | head -20

وضعیت Fail2Ban:

sudo fail2ban-client status sshd

وضعیت MTA:

sudo systemctl status mtaserver

اشتباهات رایج امنیتی سرور MTA

اجرای MTA با root
استفاده از Password ساده برای SSH
باز گذاشتن Password Login بدون نیاز
فعال‌کردن UFW قبل از Allow کردن SSH
بازکردن تمام Portها برای حل مشکل اتصال
بازکردن MySQL برای کل اینترنت بدون نیاز
استفاده از chmod 777
دادن ACL Admin به تمام Resourceها
نصب Resource ناشناس روی Production
قرار دادن Credential در Client Script
قرار دادن Backup در Web Root
نادیده گرفتن Logهای SSH
نادیده گرفتن Logهای MTA
نبود Backup قبل از تغییرات مهم
اعتماد کامل به Firewall برای مقابله با DDoS

چک‌لیست امنیت سرور MTA

MTA با User غیر root اجرا می‌شود.
سیستم‌عامل به‌روز است.
SSH Key فعال است.
ورود مستقیم root غیرفعال شده است.
Password Authentication پس از تست Key غیرفعال شده است.
Firewall فعال است.
SSH در Firewall مجاز است.
فقط پورت‌های ضروری MTA باز هستند.
پورت‌های غیرضروری بسته هستند.
Fail2Ban فعال است.
Jail مربوط به SSH فعال است.
Loginهای SSH بررسی می‌شوند.
Resourceهای ناشناس قبل از نصب بررسی می‌شوند.
ACL Resourceها محدود شده است.
Accountهای Admin بررسی شده‌اند.
اطلاعات MySQL عمومی نیست.
Backupها در مسیر Public قرار ندارند.
Permission فایل‌ها بررسی شده است.
server.log بررسی می‌شود.
Journal سرویس MTA بررسی می‌شود.
پورت‌های Listen شده دوره‌ای Audit می‌شوند.

ترتیب پیشنهادی امن‌سازی یک MTA Server جدید

سیستم‌عامل را به‌روز کنید.
User اختصاصی MTA بسازید.
MTA را با root اجرا نکنید.
SSH Key راه‌اندازی کنید.
Login با Key را تست کنید.
ورود root را غیرفعال کنید.
Password Login را در صورت امکان غیرفعال کنید.
SSH را قبل از Firewall مجاز کنید.
فقط پورت‌های ضروری MTA را باز کنید.
UFW را فعال کنید.
Fail2Ban را نصب کنید.
ACLهای MTA را بررسی کنید.
Resourceها را Audit کنید.
Permission فایل‌ها را بررسی کنید.
Backup ایجاد کنید.
Log و Monitoring دوره‌ای داشته باشید.

امنیت و مانیتورینگ باید در کنار هم باشند

امن‌سازی Server یک کار یک‌باره نیست. حتی بعد از تنظیم SSH، Firewall و Fail2Ban باید رفتار سیستم را مانیتور کنید.

افزایش ناگهانی CPU، RAM، Network، تعداد Connectionها یا ایجاد Processهای ناشناس می‌تواند نیازمند بررسی باشد.

برای این بخش مقاله آموزش مانیتورینگ سرور MTA در لینوکس؛ بررسی CPU، RAM و شبکه را مطالعه کنید.

جمع‌بندی

امنیت سرور MTA فقط نصب Firewall نیست. برای ساخت یک Server امن باید Linux، SSH، Userها، Permission فایل‌ها، Firewall، Fail2Ban، پورت‌های MTA، ACL، Resourceها، Database، Backup و Logها در کنار یکدیگر بررسی شوند.

مهم‌ترین قدم‌ها شامل اجرای MTA با User غیر root، استفاده از SSH Key، بستن پورت‌های غیرضروری، فعال‌کردن UFW، نصب Fail2Ban و محدودکردن دسترسی Resourceها براساس اصل Least Privilege هستند.

اگر سرور با وجود تنظیمات مناسب دچار لگ یا مصرف غیرعادی منابع است، مقاله علت لگ سرور MTA و روش‌های رفع آن و راهنمای مانیتورینگ سرور MTA در لینوکس را بررسی کنید.

برای راه‌اندازی، بهینه‌سازی و امن‌سازی پروژه نیز می‌توانید از خدمات پشتیبانی فنی گیم‌سرور و راه‌اندازی و کانفیگ سرور MTA کیمیا گیم استفاده کنید.

پرسش‌های متداول

برای سرور MTA چه پورت‌هایی باید در Firewall باز باشند؟

در تنظیمات پیش‌فرض، پورت اصلی بازی 22003 روی UDP، پورت HTTP برابر 22005 روی TCP و ASE برابر 22126 روی UDP است. اگر mtaserver.conf را تغییر داده‌اید، مقادیر واقعی Server خود را مبنا قرار دهید.

آیا سرور MTA را با root اجرا کنیم؟

بهتر است MTA با یک User اختصاصی و دسترسی محدود اجرا شود تا در صورت بروز مشکل امنیتی، Process سرور دسترسی کامل root به سیستم نداشته باشد.

آیا Fail2Ban برای سرور MTA لازم است؟

Fail2Ban به‌خصوص برای سرویس‌هایی مانند SSH مفید است و می‌تواند IPهایی را که تلاش‌های ورود ناموفق تکراری ایجاد می‌کنند موقتاً مسدود کند.

آیا تغییر پورت SSH کافی است؟

خیر. تغییر پورت ممکن است Scanهای ساده را کاهش دهد، اما جایگزین SSH Key، محدودکردن root Login، Firewall، Password مناسب و Fail2Ban نیست.

آیا chmod 777 برای رفع خطای Permission مناسب است؟

استفاده گسترده از 777 توصیه نمی‌شود. بهتر است Owner، Group و Permission واقعی موردنیاز فایل یا پوشه مشخص و فقط همان دسترسی داده شود.

چگونه بفهمیم چه پورت‌هایی روی VPS باز هستند؟

برای مشاهده Serviceهایی که روی سیستم Listen می‌کنند از sudo ss -lntup استفاده کنید و برای بررسی Ruleهای UFW دستور sudo ufw status numbered را اجرا کنید.

آیا UFW جلوی DDoS سرور MTA را می‌گیرد؟

UFW برای کنترل ترافیک ورودی و محدودکردن Portها مناسب است، اما برای حملات DDoS حجمی باید محافظت شبکه و Anti-DDoS ارائه‌دهنده VPS نیز در نظر گرفته شود.

منابع رسمی مرتبط

“`