| کانال امنیت و شبکه |

خیلی وقت‌ها روی سرور فقط به پسورد قوی اکتفا می‌شود، اما لاگ‌گیری درست از لاگین‌های SSH نصف امنیت ماجراست. چند خط تنظیم ساده در Linux کمک می‌کند سریع‌تر brute-force و لاگین‌های مشکوک را ببینی و به‌موقع واکنش نشان بدهی. 🔍 ۱️⃣ فعال‌سازی لاگ دقیق برای sshd به‌صورت پیش‌فرض، لاگ‌ها در /var/log/auth.log (روی Debian/Ubuntu) یا /var/log/secure (روی CentOS/RHEL) می‌آیند، ولی سطح جزئیات را می‌شود بالاتر برد. در فایل تنظیمات SSH: sudo nano /etc/ssh/sshd_config این خطوط را اضافه یا اصلاح کن: LogLevel VERBOSE UseDNS no سپس: sudo systemctl restart sshd LogLevel VERBOSE باعث می‌شود حتی key fingerprint ها و تلاش‌های لاگین ناموفق با جزئیات ثبت شوند. این برای incident response و تحلیل حملات خیلی کمک می‌کند. 🔐 ۲️⃣ فیلتر ساده لاگین‌های ناموفق یک مثال سریع برای دیدن آی‌پی‌های پرریسک: sudo grep "Failed password" /var/log/auth.log \ | awk '{print $(NF-3)}' \ | sort | uniq -c | sort -nr | head این دستور آی‌پی‌هایی را که بیشترین تلاش ناموفق داشته‌اند نشان می‌دهد و می‌شود آن‌ها را در فایروال بلاک کرد یا به fail2ban سپرد. ۳️⃣ چند نکته‌ عملی • همیشه PasswordAuthentication را روی no قرار بده و از SSH Key استفاده کن. • لاگ‌ها را روی یک remote syslog / SIEM هم ارسال کن تا اگر سرور compromise شد، attacker نتواند لاگها را پاک کند. • rotation و retention لاگ‌ها را با logrotate درست تنظیم کن تا هم دیسک پر نشود هم دادهٔ تاریخی کافی داشته باشی. برای جزئیات بیشتر تنظیمات sshd می‌شود مستندات رسمی OpenSSH را دید: https://man.openbsd.org/sshd_config امتحان این تنظیم‌ها روی یک test server شروع خوبی برای ساختن یک baseline امن برای SSH است. 🚀 🔖 #Security #امنیت #SSH #Logging #Linux #Security #Network #Hardening 👤 Developix 💎 Channel: @DevelopixNetwork

یکی از ساده‌ترین راه‌ها برای بالا بردن امنیت سرور لینوکسی اینه که لاگ‌های ssh رو جدی بگیریم و به شکل هوشمند بررسی‌شون کنیم تا الگوی لاگین مشکوک و حملات Brute Force زود شناسایی بشه. 🔍 با یک اسکریپت خیلی سبک می‌شه توی لاگ‌ها گشت و IPهایی که تعداد زیادی Login Fail دارن رو پیدا کرد و بعداً اون‌ها رو توی firewall بلاک یا محدود کرد (مثلاً با iptables یا UFW یا حتی Fail2ban). نمونه‌کد زیر روی لاگ پیش‌فرض Debian/Ubuntu یعنی /var/log/auth.log کار می‌کنه و IPهایی که بیشتر از ۵ بار لاگین ناموفق داشتن رو چاپ می‌کنه: #!/usr/bin/env python3 import re from collections import Counter LOG_FILE = "/var/log/auth.log" FAILED_THRESHOLD = 5 pattern = re.compile(r"Failed password for .* from (\d+\.\d+\.\d+\.\d+)") ips = [] with open(LOG_FILE, "r", encoding="utf-8", errors="ignore") as f: for line in f: match = pattern.search(line) if match: ips.append(match.group(1)) counts = Counter(ips) for ip, c in counts.items(): if c >= FAILED_THRESHOLD: print(f"{ip} - failed logins: {c}") 👨‍💻 چند نکته کاربردی: • این اسکریپت رو با کران (cron) زمان‌بندی می‌شه دوره‌ای اجرا کرد و خروجی رو لاگ یا برای ادمین ایمیل کرد. • روی توزیع‌هایی مثل CentOS/RHEL مسیر لاگ ssh معمولاً /var/log/secure هست، فقط همون رو عوض کن. • بعد از شناسایی IP مشکوک، می‌شه به‌صورت خودکار ruleهای firewall تولید کرد یا این منطق رو به ابزارهایی مثل Fail2ban سپرد تا به شکل استاندارد و امن Ban انجام بشه. این رویکرد کمک می‌کنه رفتار مهاجم قبل از موفق شدن شناسایی بشه و در کنار تنظیمات درست ssh (مثل غیرفعال کردن Login با پسورد و استفاده از Key) یک لایه دفاعی مهم اضافه می‌کنه. 🔐 برای مطالعه عمیق‌تر روی لاگ‌گیری و مانیتور امنیتی روی ssh می‌شه بخش مربوط به Brute Force در OWASP Cheat Sheet رو دید: OWASP Authentication Cheat Sheet 🔖 #Security #امنیت #SSH #BruteForce #Logging #Linux #Security #Python 👤 Developix 💎 Channel: @DevelopixNetwork

خیلی وقت‌ها روی backend فقط remote_addr رو لاگ می‌گیریم و فکر می‌کنیم IP واقعی کاربره؛ اما پشت Nginx / Proxy / Load Balancer، این IP معمولاً IP همون Proxy هست، نه کلاینت 🎯 راه‌حل استاندارد استفاده از هدر X-Forwarded-For (یا X-Real-IP) و تنظیم درست اپلیکیشن و Reverse Proxy ـه. این کار برای تحلیل Incident، تشخیص حملات و Alert کردن روی IP خیلی مهمه. مثال ساده با Flask پشت Nginx: from flask import Flask, request app = Flask(__name__) TRUSTED_PROXIES = {"127.0.0.1", "10.0.0.1"} # IP های Nginx / LB @app.before_request def log_real_ip(): remote = request.remote_addr xff = request.headers.get("X-Forwarded-For", "") if remote in TRUSTED_PROXIES and xff: # اولین IP معمولا نزدیک‌ترین کلاینت است real_ip = xff.split(",")[0].strip() else: real_ip = remote app.logger.info(f"real_ip={real_ip} path={request.path}") @app.route("/") def index(): return "OK" if __name__ == "__main__": app.run() نکات مهم ✅ • فقط وقتی به X-Forwarded-For اعتماد کن که درخواست از Proxyهای شناخته‌شده می‌آد (مثل لیست بالا). هدر رو کاربر نهایی هم می‌تونه جعل کنه. • روی Nginx مطمئن شو real_ip_header و set_real_ip_from درست ست شدن تا remote_addr سمت اپ منطقی باشه. • IP واقعی در لاگ‌ها برای Rate Limit، تشخیص حملات Brute Force و Audit لاگ‌ها حیاتی است. مناسب‌ترین رفرنس برای Best Practice لاگ‌گیری و هدرها در اپ‌های وب: OWASP Logging Cheat Sheet امتحان این الگو روی یک سرویس تستی پشت Nginx کمک می‌کند قبل از رفتن به محیط Production، رفتار لاگ‌گیری IP را دقیق ببینی و تنظیمات را سفت و تمیز کنی 🔍 🔖 #Security #امنیت #Logging #X_Forwarded_For #Reverse_Proxy #OWASP #Flask #Nginx #Security #Network 👤 Developix 💎 Channel: @DevelopixNetwork

وقتی حرف از امنیت شبکه میاد، یکی از اولین ابزارهایی که تقریباً همه سراغش می‌رن، Nmap هست. یه ابزار سبک، قدرتمند و کاملاً رایگان که اگر درست استفاده بشه، نصف راه Vulnerability Assessment رو رفتی ✔️ اینجا یه سناریوی واقعی رو در نظر بگیر: روی یه سرور تازه‌راه‌اندازی‌شده دسترسی گرفتی و می‌خوای مطمئن بشی فقط همون سرویس‌هایی باز هستن که واقعاً لازم داری. قبل از این‌که یه Attacker برات اسکن بزنه، خودت با Nmap این کار رو می‌کنی 😄 منبع اصلی آموزش که این نکات ازش الهام گرفته شده: nmap.org/book/man.html ۱️⃣ اسکن سریع پورت‌های مهم برای شروع، معمولاً همین که بدونی روی Target چه پورت‌های معروفی بازه، کلی کمک می‌کنه: nmap -Pn -sS -F 192.168.1.10 🔸 -Pn: از Ping اولیه رد می‌شه (مواقعی که ICMP بسته شده). 🔸 -sS: TCP SYN scan؛ هم سریع‌تره هم کم‌سر و صدا‌تر از Connect Scan. 🔸 -F: فقط پورت‌های معروف (Top Ports) رو اسکن می‌کنه، برای یه چک سریع عالیه. ۲️⃣ فهمیدن دقیق سرویس‌ها و نسخه‌ها فقط دونستن «پورت 80 بازه» کافی نیست. این‌که اون پشت Apache هست یا Nginx و چه نسخه‌ای، برای Exploit و Patch خیلی مهمه: nmap -sV 192.168.1.10 🔹 اینجا -sV تلاش می‌کنه نوع و Version سرویس‌ها رو تشخیص بده؛ مثلاً: Apache httpd 2.4.57 ۳️⃣ اسکن با اسکریپت‌های امنیتی Nmap (NSE) Nmap یه موتور اسکریپت‌نویسی قوی به اسم NSE داره که کلی اسکریپت آماده برای Security داره. مثلاً برای پیدا کردن ضعف‌های HTTP: nmap --script http-vuln* -p80,443 192.168.1.10 🔸 با این کار کلی چک امنیتی مرتبط با HTTP انجام می‌شه (وابسته به اسکریپت‌ها و Database موجود). ۴️⃣ اسکن Stealth روی کل یک Subnet وقتی روی شبکه داخلی هستی و می‌خوای سریعاً ببینی چه سیستم‌هایی چه پورت‌هایی دارن: nmap -sS -T2 192.168.1.0/24 🔹 -T2: سرعت متوسط و نسبتاً آروم، که کمتر جلب توجه کنه و همزمان شبکه رو هم خفه نکنه. ۵️⃣ چند نکته مهم و حرفه‌ای 🧠 • همیشه روی سیستم خودت و سیستم‌هایی که اجازه کتبی/رسمی داری اسکن انجام بده؛ هر چیز دیگه‌ای می‌تونه وارد حریم قانونی بشه. • بعد از هر اسکن، لیست پورت‌های باز رو با Policy سازمان یا Best Practiceها (مثلاً NIST یا CIS Benchmarks) مقایسه کن. • برای سرویس‌هایی که لازم نیست، سرویس رو ببند یا پشت Firewall محدودش کن؛ Nmap فقط «وضعیت

🛡 راه‌اندازی فایروال عملی با iptables روی لینوکس یکی از ساده‌ترین و در عین حال قدرتمندترین کارها برای بالا بردن امنیت سرور لینوکسی، تنظیم درست iptables است. روی خیلی از VPSها، پیش‌فرض تقریباً همه پورت‌ها باز است و همین یعنی یک سطح حمله خیلی بزرگ. توی این پست، بر اساس داکیومنت رسمی کرنل لینوکس و راهنمای Arch & Debian، یک سناریوی واقعی رو می‌ریم جلو: سروری که فقط SSH و وب (HTTP/HTTPS) باید براش باز باشه و بقیه پورت‌ها Drop بشن. 🔥 ایده‌ی اصلی تصور کن یک سرور Ubuntu/Debian داری که روی اینترنت پابلیکه: • فقط پورت ۲۲ برای SSH • پورت ۸۰ برای HTTP • پورت ۴۴۳ برای HTTPS بقیه‌ی ترافیک ورودی باید رد بشه، ولی اتصال‌های جاری (مثل SSH در حال استفاده) نباید قطع بشن. این دقیقاً کاریه که با iptables و stateful firewall انجام می‌دیم. 🔧 چند نکته قبل از شروع • این کار نیاز به دسترسی root یا sudo داره. • قبل از تغییرات جدی، بهتره یک جلسه SSH دوم باز نگه داری تا اگر اشتباهی همه چیز رو بستی، بتونی برگردونی. • برای جزئیات بیشتر، از راهنمای iptables استفاده کن: https://www.netfilter.org/documentation/index.html 📌 مثال واقعی: پالیسی امن پایه کد زیر یک ست قانون ساده و کاربردیه: sudo iptables -F sudo iptables -X # اجازه به ترافیک لوکال sudo iptables -A INPUT -i lo -j ACCEPT # اجازه به کانکشن‌های جاری و مرتبط sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # اجازه به SSH روی پورت 22 sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT # اجازه به HTTP sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT # اجازه به HTTPS sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT # Drop کردن بقیه ترافیک ورودی sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT ACCEPT 💡 این قوانین چه کار می‌کنند؟ • با ESTABLISHED,RELATED، فقط ترافیک مربوط به کانکشن‌های مجاز قبلی اجازه عبور می‌گیرند؛ این هم امن است، هم باعث نمی‌شود اتصال‌های فعلی‌ات قطع شوند. • lo را باز می‌گذاریم تا سرویس‌هایی که با خود سیستم حرف می‌زنند (مثل دیتابیس لوکال) از کار نیفتند. • با DROP کردن پالیسی INPUT و FORWARD، عملاً فقط پورت‌هایی که صراحتاً Allow شده‌اند باز می‌مانن

🔒 ساده‌ترین ارتقا امنیت: غیرفعال کردن TLS قدیمی روی Nginx خیلی از سرورهای وب هنوز TLS 1.0 و TLS 1.1 را روشن نگه می‌دارند، درحالی‌که این نسخه‌ها سال‌هاست ناامن و Deprecated شده‌اند 🚨 و امکان Downgrade Attack و ضعف در Cipherها را زیاد می‌کنند. اگر روی سرور لینوکسی از Nginx استفاده می‌کنی، با یک تنظیم کوتاه می‌شود فقط نسخه‌های امن‌تر را فعال نگه داشت، یعنی TLS 1.2 و TLS 1.3 ✅ در یکی از بلاک‌های server (یا در تنظیمات عمومی) این بخش را اضافه یا اصلاح کن: ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; بعد از ویرایش کانفیگ: sudo nginx -t sudo systemctl reload nginx این کار: • سطح پایه امنیت ارتباطات HTTPS را بالا می‌برد 🔐 • با استانداردهای جدید مثل توصیه‌های NIST و مرورگرهای مدرن هم‌راستا است ✅ برای چک کردن نسخه‌های فعال TLS روی سرورت می‌توان از سرویس‌هایی مثل SSL Labs Server Test استفاده کرد. 📚 مرجع رسمی (Nginx): https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols امتحان این تنظیم روی محیط تست، قبل از محیط Production، همیشه ایده خوبی است 😉 🔖 #Security #امنیت #Nginx #TLS #Network_Security #TLS_1_2 #TLS_1_3 #Hardening 👤 Developix 💎 Channel: @DevelopixNetwork

📡 تحلیل ترافیک شبکه با tcpdump؛ از صفر تا یک ابزار حرفه‌ای توی دنیای Network & Security یکی از مهم‌ترین مهارت‌ها اینه که بتونی ترافیک واقعی شبکه رو ببینی و بفهمی چی داره رد و بدل می‌شه. اینجاست که ابزار خط فرمانیِ tcpdump می‌درخشه✨ این پست بر اساس مستندات رسمی tcpdump و man page لینوکسه و کاملاً قابل تست روی هر سیستم Linux/Unix هست: tcpdump.org/manpages/tcpdump.1 🔍 tcpdump دقیقاً به چه درد می‌خوره؟ مثل یک «دوربین مداربسته» برای شبکه‌ست. باهاش می‌شه: • ترافیک مشکوک روی یک پورت خاص رو دید (مثلاً حمله brute force روی SSH) • ببینی کدوم سرویس واقعاً روی شبکه صحبت می‌کنه، نه فقط چی روی سیستم نصبه • موقع عیب‌یابی (troubleshooting) بفهمی مشکل از شبکه‌ست یا از برنامه ⚙️ نصب سریع tcpdump روی اکثر توزیع‌های لینوکسی به‌صورت پیش‌فرض هست، ولی اگر نبود: sudo apt install tcpdump # روی Debian/Ubuntu sudo yum install tcpdump # روی CentOS/RHEL قدیمی sudo dnf install tcpdump # روی Fedora/RHEL جدید 👁‍🗨 اولین تست: دیدن همه‌چیز روی یک اینترفیس فرض کن اینترفیس شبکه‌ات eth0 است: sudo tcpdump -i eth0 • این دستور همه‌ی بسته‌ها رو روی eth0 نشون می‌ده • خروجی خیلی شلوغ می‌شه، پس برای کار جدی حتماً فیلتر بذار 🎯 فیلتر کردن ترافیک SSH برای تشخیص brute force حالا یک سناریوی امنیتی واقعی 👇 فرض کن روی سرورت login های مشکوک روی SSH می‌بینی. می‌خوای ببینی از چه IPهایی ترافیک زیادی روی پورت 22 میاد. sudo tcpdump -i eth0 tcp port 22 and 'tcp[tcpflags] & (tcp-syn) != 0' این یعنی: • فقط ترافیک TCP روی پورت 22 (SSH) • فقط بسته‌هایی که فلگ SYN دارن (شروع اتصال جدید) اگر از یک IP خاص مدام SYN ببینی، احتمال brute force یا اسکن بالا می‌ره. 🧪 نمونه‌ی کاربردی با ذخیره در فایل pcap برای تحلیل حرفه‌ای‌تر با Wireshark، خروجی رو توی فایل ذخیره کن: sudo tcpdump -i eth0 port 22 -w ssh_traffic.pcap بعداً می‌تونی این فایل رو روی سیستم دسکتاپ با Wireshark باز کنی و عمیق‌تر آنالیز کنی. 🧵 چند نکته‌ی ریز ولی مهم • روی سرورهای شلوغ حتماً از گزینه -c برای محدود کردن تعداد پکت استفاده کن، مثلاً: sudo tcpdump -i eth0 port 22 -c 200 • اگر فقط هدرها رو می‌خوای و نه payload کامل، از -s 96 یا

🚨 اسکن امنیتی وب‌سرور با Nikto (روی Kali) خیلی وقت‌ها یه وب‌سرور بالا آوردیم (مثلاً Apache یا Nginx) و خیال‌مون راحته که چون «جواب می‌ده»، پس اوضاع امنه. اما تو دنیای واقعی، کلی misconfig ساده و باگ قدیمی هست که فقط منتظر یه اسکنر مثل Nikto نشسته 🙂 Nikto یه Web Server Scanner اوپن‌سورس و قدیمیه که هنوزم تو Kali Linux و خیلی از تست‌های OWASP به‌صورت جدی استفاده می‌شه: https://cirt.net/Nikto2 تو این پست، روی خود Kali یه اسکن واقعی روی یه تارگت تست (یا لَب داخلی) انجام می‌دیم و خروجی رو طوری می‌خونیم که واقعاً به درد Hardening بخوره. 🔧 نصب و اجرای پایه روی Kali روی Kali معمولاً Nikto از قبل نصبه، ولی برای اطمینان: sudo apt update sudo apt install nikto حالا یه اسکن ساده روی یه تارگت تست (مثلاً یه لَب داخلی روی 192.168.1.10): nikto -h http://192.168.1.10 Nikto شروع می‌کنه به چک‌کردن: • نسخه و بنر وب‌سرور • فایل‌ها و دایرکتوری‌های معروف (مثل /phpmyadmin/ یا backup ها) • misconfigهای رایج و vulnerabilityهای شناخته‌شده (طبق DB داخلی خودش) 💡 چند گزینه خیلی کاربردی ۱️⃣ مشخص‌کردن پورت خاص (مثلاً 8080): nikto -h 192.168.1.10 -p 8080 ۲️⃣ خروجی به فرمت HTML برای گزارش: nikto -h 192.168.1.10 \ -o report.html -Format html بعداً همین فایل رو می‌شه برای تیم یا مدیر شبکه فرستاد که دقیق ببینه چه چیزهایی پیدا شده. ۳️⃣ اسکن با Virtual Host (وقتی چند سایت روی یه IP هست): nikto -h 192.168.1.10 -vhost example.com ⚠️ چند نکته مهم (و کاملاً واقعی) • Nikto صدای زیادی روی لاگ‌ها تولید می‌کنه؛ برای تست نفوذ قانونی عالیه، برای تست «مخفی» اصلاً مناسب نیست. • حتماً فقط روی سیستم‌هایی که اجازه مکتوب داری اجرا بشه؛ لاگ وب‌سرور به‌وضوح نشون می‌ده یه اسکن گسترده انجام شده. • نتیجه Nikto «Final Verdict» نیست؛ بیشتر یه لیست «چیزهایی که باید چک کنی». هر Finding رو باید با مستندات رسمی (مثلاً Apache, Nginx یا OWASP) تطبیق بدی. 📌 چرا برای ادمین‌ها و DevOpsها مهمه؟ چون خیلی وقت‌ها تیم Dev یه Feature رو سریع بالا می‌آره و چیزهایی مثل directory listing باز می‌مونه، یا نسخه یه CMS قدیمی عوض نمی‌شه. یه اسکن ساده Nikto قبل از پابلیک‌کردن سرویس، می‌تونه کلی ریسک رو زود شناسایی کنه. امتحانش روی یه ل

🛡️ فعال‌سازی HSTS؛ قفل‌کردن سایت روی HTTPS خیلی وقت‌ها کاربر یک بار با HTTP به سایت وصل می‌شود و اگر وسط راه مهاجم وارد شود، می‌تواند ترافیک را به سمت خودش هدایت کند (SSL Stripping). با HSTS به مرورگر می‌گوییم از این به بعد فقط و فقط با HTTPS وصل شود. 🔐 📌 ایده: یک هدر ساده سمت وب‌سرور اضافه می‌شود و ریسک Downgrade Attack را کم می‌کند. مثال برای Nginx: add_header Strict-Transport-Security \ "max-age=31536000; includeSubDomains; preload" always; نکات مهم ✅ • فقط وقتی گواهی TLS درست و پایدار دارید این هدر را فعال کنید. • مقدار max-age هرچه بزرگ‌تر باشد، مرورگر مدت بیش‌تری فقط روی HTTPS قفل می‌ماند. • پارامتر includeSubDomains یعنی تمام ساب‌دامین‌ها هم باید HTTPS باشند. • قبل از اضافه‌کردن preload حتما مطمئن باشید همه چیز روی HTTPS بدون خطاست، چون برگشت از آن سخت است. برای جزئیات بیش‌تر: MDN: Strict-Transport-Security امتحان این هدر روی محیط تست، یک قدم کوچک ولی مؤثر برای بالا بردن Security سطح وب‌سرویس است. 🚀 🔖 #Security #امنیت #HSTS #HTTPS #Web_Security #Nginx #TLS 👤 Developix 💎 Channel: @DevelopixNetwork

🔐 جلوگیری از SQL Injection با Prepared Statement یکی از ساده‌ترین و مؤثرترین کارها برای امن‌کردن برنامه‌ تحت شبکه (API, Web App) استفاده از Prepared Statement / Parameterized Query است. این کار جلوی خیلی از SQL Injectionها را می‌گیرد حتی اگر validation سمت کلاینت دور زده شود. ⚠️ ایده‌اش این است که query و دادهٔ ورودی کاربر از هم جدا شوند؛ دیتابیس ورودی را فقط به‌عنوان داده می‌بیند، نه بخشی از دستور SQL. نمونهٔ ساده در Python با کتابخانهٔ psycopg2 برای PostgreSQL: import psycopg2 conn = psycopg2.connect(...) cur = conn.cursor() # ❌ اشتباه (ساخت query با string) username = input("username: ") q_bad = f"SELECT * FROM users WHERE username = '{username}'" cur.execute(q_bad) # آسیب‌پذیر به SQL Injection # ✅ درست (استفاده از placeholder) q_ok = "SELECT * FROM users WHERE username = %s" cur.execute(q_ok, (username,)) # پارامتر جدا ارسال می‌شود rows = cur.fetchall() نکته‌ها: • همیشه از placeholder مخصوص همان driver استفاده شود (مثل %s در psycopg2 یا ? در بعضی driverها). • حتی روی internal panelها و سرویس‌های داخلی هم این عادت را رعایت کنید؛ اغلب حمله‌ها از داخل شبکه شروع می‌شود. 🚪 مرجع معتبر 👇 OWASP - SQL Injection Prevention 🔖 #Security #امنیت #SQL_Injection #Prepared_Statement #OWASP #Database_Security #Application_Security #Network_Security 👤 Developix 💎 Channel: @DevelopixNetwork

🚧 تانل EoIP 🔻 یه نوعی از تانلینگه که برخلاف اکثر پروتکل‌های دیگه، لایه ۲ رو حمل می‌کنه. یعنی فریم‌های لایه ۲ رو داخل یه بسته IP می‌ذاریم، از روی شبکه لایه ۳ روتش می‌کنیم و آخر مسیر دوباره همون فریم لایه ۲ رو سالم تحویل می‌گیریم. 🌀 حالا شاید براتون سوال شه که خب به چه دردی میخوره؟ به‌هرحال ما که داریم بسته رو می‌رسونیم به مقصد، چه فرقی می‌کنه چه لایه‌ای باشه؟ عرضم به خدمتتون که خیلی فرق می‌کنه. یه مثال کوچیک بخوام بزنم: در شبکه‌های مبتنی بر PPPoE، مثل خیلی از سرویس‌های xDSL، ارتباط بین کلاینت و PPPoE Server باید در نهایت در قالب لایه ۲ برقرار بشه، چون PPPoE ذاتاً یک پروتکل لایه ۲ هست. حالا ممکنه بین مسیر به هزار و یک دلیل، مثل مدیریت راحت‌تر یا وجود تجهیزات مسیریاب، مجبور باشیم ترافیک رو از روی یک شبکه لایه ۳ عبور بدیم. اینجاست که EoIP به کمکمون میاد؛ فریم‌های لایه ۲ رو داخل بسته‌های IP کپسوله می‌کنه، از مسیر لایه ۳ عبورشون میده و در سمت مقابل دوباره همون فریم‌های لایه ۲ رو تحویل میده، طوری که از دید PPPoE Server انگار کلاینت همچنان روی همون شبکه لایه ۲ قرار داره. 🔅البته EoIP فقط برای PPPoE نیست و هر جا که نیاز داشته باشیم دو شبکه لایه ۲ رو از طریق یک بستر IP به هم متصل کنیم یا Bridge رو بین دو نقطه گسترش بدیم، می‌تونه کاربرد داشته باشه. انتقال VLAN، عبور Broadcast و Multicast یا جابه‌جایی ترافیک وابسته به MAC Address از جمله کاربردهای رایج اون هستند. ❎ این پروتکل علیرغم امکاناتی که در اختیارمون قرار میده و سادگی در راه‌اندازی، معایبی هم داره؛ مثل اینکه اختصاصی تجهیزات MikroTik هست و اگه یک طرف ارتباطتون سیسکویی یا وندور دیگه‌ای باشه، عملاً نمی‌تونید ازش استفاده کنید. همچنین به صورت پیش‌فرض هیچ رمزنگاری‌ای انجام نمی‌ده، بنابراین اگر امنیت ارتباط براتون مهمه، بهتره اون رو همراه با IPsec یا یک VPN امن دیگه استفاده کنید. علاوه بر این، به دلیل سربار ناشی از کپسوله‌سازی، ممکنه MTU کاهش پیدا کنه و در بعضی سناریوها نیاز به تنظیم MTU یا MSS داشته باشید. 🔖 #Network, #شبکه 👤 Drwcsi 💎 Channel: @DevelopixNetwork

🟪 مکانیزم BFD در OSPF چیست؟ مکانیزمی برای تشخیص خیلی سریع افتادن همسایگی. 👈🏻 یعنی چی؟ یعنی در حالت عادی قطعا یک روتینگ پروتکل داینامیک، روشی برای تشخیص قطعی داره که اگر سه تا پکت hello در یک بازه زمانی مشخص (dead timer) بیاد و جوابی از طرف همسایه داده نشه، یعنی ارتباط قطع شده و میره سراغ مسیر جایگزین. اما BFD روشی بسیار سریعه که علاوه بر مزیت کاهش تشخیص مسیر جایگرین از چند ثانیه به چند میلی ثانیه، باعث میشه بار رویِ دوشِ روتینگ پروتکلمون هم سبک تر بشه، چون بخشی از پردازش مورد نیازش در یک پروتکل خارجی در حال انجام هست. ♥️ کانفیگش در سیسکو چجوریه؟ زیر اینترفیس میزنید: bfd interval 50 min_rx 50 multiplier 3 ip ospf bfd همین. ⚙️ ترجمه کامندی که گفتیم؟ هر ۵۰ میلی ثانیه یک بسته bfd ارسال میشه، حداقل زمان دریافت ۵۰ میلی ثانیه است و اگر ۳ بسته متوالی دریافت نشه، لینک Down در نظر گرفته میشه. پس در این مثال حدودا در ۱۵۰ میلی ثانیه تشخیص خرابی اتفاق میفته . - البته در ios های xr و xe کانفیگش متفاوته. میکروتیک هم میتونید برید سرچ کنید چون من دوست ندارم بریم میکروتیک کانفیگ کنیم :))) 😵‍💫 شاید براتون سوال شه خب چه کاریه، میایم همون مکانیزم hello/dead رو کاستومایز میکنیم و تایمش رو کاهش میدیم که زودتر قطعی رو بفهمیم. اما این مکانیزم روی اکثر دیوایس ها قابلیت تغییر به میلی ثانیه نداره و در حداقلی ترین حالت میتونی در ۳ ثانیه Down شدن لینک رو تشخیص بدی در حالی که با bfd در ۱۵۰ میلی ثانیه انجام میشه. همچنین با استفاده از BFD بار روی OSPF کاهش پیدا میکنه. البته این به معنای حذف پکت های hello نیست، صرفا فرض کنید اگه بخوایم برای افزایش سرعت، زمان dead رو از ۱۰ ثانیه به ۱ ثانیه تغییر بدیم در واقع داریم پکت های helloمون رو ۱۰ برابر میکنیم، بجای این کار، کارش رو برون سپاری می‌کنیم. 🎴سوال بعدی‌ای که پیش میاد اینه که اگه PLR داشته باشیم باعث نمیشه دائما بین مسیرها سوئیچ بشیم و بهره‌وری پائین بیاد؟ در واقع سوال اینه که ممکنه ما تاخیر یا پکت لاس داشته باشیم و چون فرصت کوتاهی برای جواب گرفتن از همسایه‌ها داریم، سریع اعلام قطعی بشه و بریم سراغ مسیر بکاپ، و دوباره روی مسیر جدید همین اتفاق تکرار میشه و دچار flap میشیم؛ پس نباید تایم خیلی کم انتخاب کنیم. 🪴 پس اگر بتونیم کانفیگ صحیحی

🛡️ راه‌اندازی سریع و امن VPN با WireGuard روی لینوکس WireGuard یکی از سبک‌ترین و امن‌ترین راه‌حل‌های VPN امروزیه؛ هم روی سرور خیلی کم‌حجم و ساده است، هم روی کلاینت‌هات (موبایل، دسکتاپ، روتر) عالی جواب می‌ده. برای سناریوهایی مثل دسترسی امن به پنل‌های داخلی، SSH از بیرون خونه/شرکت یا دور زدن محدودیت آی‌پی روی سرویس‌ها خیلی کاربردیه. در این پست، بر اساس داکیومنت رسمی WireGuard و مستندات Debian/Ubuntu، یه راه‌اندازی عملی و واقعی روی لینوکس رو مرور می‌کنیم: 🔧 سناریو فرض کن یه VPS لینوکسی داری (مثلاً Ubuntu Server) و می‌خوای از هر جایی با لپ‌تاپ یا موبایل، به صورت امن به شبکه داخلی یا سرویس‌های روی اون VPS وصل بشی. ۱️⃣ نصب WireGuard روی Ubuntu/Debian روی سرور (و بعداً روی کلاینت لینوکسی) دستور زیر رو اجرا کن: sudo apt update sudo apt install wireguard -y این بسته طبق داکیومنت رسمی Ubuntu از مخازن خودش میاد و ماژول کرنل WireGuard هم روی کرنل‌های جدید به صورت پیش‌فرض پشتیبانی می‌شه. ۲️⃣ ساخت key pair برای سرور داخل سرور، توی مثلاً /etc/wireguard: cd /etc/wireguard umask 077 wg genkey | tee server_private.key | wg pubkey > server_public.key ۳️⃣ ساخت key pair برای کلاینت روی سیستم خودت (یا حتی روی سرور و بعد انتقال امن به کلاینت): wg genkey | tee client_private.key | wg pubkey > client_public.key حواست باشه private keyها هیچ‌وقت لاگ یا share نشن؛ خیلی‌ها اشتباهشون اینه که همین key رو کپی/پیست می‌فرستن توی چت‌ها 🙂 ۴️⃣ کانفیگ سرور: فایل ‎/etc/wireguard/wg0.conf‎ یه مثال مینیمال (با فرض این‌که آدرس داخلی VPN رو 10.0.0.1/24 برای سرور می‌ذاری و 10.0.0.2 برای کلاینت): [Interface] Address = 10.0.0.1/24 ListenPort = 51820 PrivateKey = <server_private_key_here> [Peer] PublicKey = <client_public_key_here> AllowedIPs = 10.0.0.2/32 پورت 51820/UDP رو توی فایروال و روی VPS باز کن (روی ufw یا فایروال provider). ۵️⃣ کانفیگ کلاینت (مثلاً روی Linux) روی کلاینت، فایل مشابه بساز: [Interface] Address = 10.0.0.2/24 PrivateKey = <client_private_key_here> DNS = 1.1.1.1 [Peer] PublicKey = <server_public_key_here> Endpoint = <your_server_ip>:51820 AllowedIPs = 0.0.0.0/0, ::/0 P

توی خیلی از شبکه‌ها هنوز روی سرورهای SSH پسوردهای ضعیف استفاده می‌شه و همین، در عمل می‌تونه تبدیل بشه به ساده‌ترین راه نفوذ 👀 امروز یه آموزش خیلی کاربردی از Kali Linux و ابزار Hydra رو مرور می‌کنیم که توی دنیای واقعی برای تست password strength سرویس SSH استفاده می‌شه. این کار توی Penetration Test مجاز یا Internal Audit کمک می‌کنه زودتر از Attacker، پسوردهای ضعیف رو پیدا کنی. آموزش مرجع اصلی از خود Kali و ابزار Hydra هست: kali.org/tools/hydra سناریو واقعی 🔍 فرض کن توی شبکه داخلی یه سرور Linux با SSH داری که یوزرهای زیادی روی اون Login می‌کنن. می‌خوای مطمئن شی هیچ یوزری از پسورد ساده مثل 123456 یا password استفاده نکرده. اینجا Hydra بهت اجازه می‌ده با یه Wordlist مشخص، روی SSH Password Brute Force (قانون‌مند) انجام بدی و ببینی کدوم یوزرها پسورد ضعیف دارن. نکته مهم ⚠️ این کار فقط روی سیستم‌هایی انجام می‌شه که اجازه مکتوب برای تست داری (شرکت خودت، لابراتوار، سرور تست و ...). روی سیستم دیگران بدون اجازه، کاملاً غیرقانونی‌ه. نمونه دستور کاربردی Hydra روی SSH 🛠 hydra -L users.txt -P passwords.txt \ -t 4 -W 3 -f -vV ssh://192.168.1.10 توضیح سریع سوییچ‌ها: 🔹 -L users.txt ⇒ لیست یوزرنیم‌ها (هر خط یه user) 🔹 -P passwords.txt ⇒ Wordlist پسوردها؛ می‌تونی از لیست‌های آماده مثل rockyou.txt (توی Kali در مسیر /usr/share/wordlists/) استفاده کنی یا خودت بسازی. 🔹 -t 4 ⇒ تعداد parallel tasks. مقدار خیلی بالا نذار که هم سرویس رو overload نکنه، هم لاگ‌هات مشکوک نشه. 🔹 -W 3 ⇒ Timeout برای هر تلاش (ثانیه). توی شبکه‌های کند، یه مقدار بالاتر کمک می‌کنه. 🔹 -f ⇒ به محض پیدا کردن اولین credential معتبر، کار رو متوقف می‌کنه (برای جلوگیری از فشار اضافه روی سرویس). 🔹 -vV ⇒ خروجی verbose و detailed؛ برای دیباگ و دیدن روند تست خیلی کمک می‌کنه. نکات عملی و امنیتی 🧠 • قبل از اجرا، روی سرور SSH حتماً Account Lockout Policy و Fail2ban رو بررسی کن؛ اگه خیلی aggressive باشن، ممکنه یوزرهای واقعی قفل بشن. • بهتره تست رو توی Maintenance Window یا زمانی که Load سیستم پایینه انجام بدی. • بعد از پیدا شدن پسوردهای ضعیف، حتماً: – User رو مجبور کن پسورد رو عوض کنه. – روی SSH، Password Authe

🛡 هدرهای امنیتی HTTP؛ دفاع خط اول وب‌اپ خیلی وقت‌ها اپ امن نوشته می‌شه، ولی با چند تا HTTP Security Header ساده می‌شه سطح حمله رو کلی کم کرد؛ بدون تغییر جدی توی کد. این هدرها جلوی کلی XSS، Clickjacking و حملات مشابه رو می‌گیرن. 🚫 چند هدر خیلی کاربردی برای هر وب‌سرور: • Content-Security-Policy (یا CSP): محدودکردن سورس اسکریپت‌ها و استایل‌ها، کاهش ریسک XSS. • X-Frame-Options: جلوگیری از نمایش سایت داخل iframe و کاهش Clickjacking. • X-Content-Type-Options: nosniff: جلوگیری از MIME Sniffing. نمونه تنظیم روی Nginx: 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 Content-Security-Policy \ "default-src 'self'; script-src 'self'; object-src 'none'" always; بعد از تنظیم، با ابزارهایی مثل SecurityHeaders.com می‌شه هدرها رو تست و بهینه کرد. این تغییرها سبک، سریع و برای هر اپ تحت وب جدی، تقریبا ضروری هستن؛ حتی اگه هنوز وقت Harden کامل سرور رو نداشته باشی. 🔐 🔖 #Security #امنیت #HTTP_Headers #Web_Security #CSP #Nginx #Best_Practices 👤 Developix 💎 Channel: @DevelopixNetwork

‏روی هر سرور لینوکسی که سرویس‌هایی مثل SSH یا وب‌سرور در حال اجرا است، حمله Brute Force تقریبا همیشه اتفاق می‌افتد. ربات‌ها مدام پسورد حدس می‌زنند و اگر محدود نشوند هم امنیت را پایین می‌آورند، هم لاگ‌ها را شلوغ می‌کنند و حتی CPU را درگیر می‌کنند. اینجا ابزار Fail2ban به درد می‌خورد؛ لاگ‌ها را مانیتور می‌کند و وقتی چند تلاش لاگین ناموفق از یک IP دید، به‌صورت خودکار آن IP را با iptables یا nftables بلاک می‌کند. 👮‍♂️ 📌 ایده اصلی Fail2ban ابزار Fail2ban روی لاگ‌ها (مثلا /var/log/auth.log یا /var/log/secure) الگوهای مشکوک را جست‌وجو می‌کند. بر اساس یک jail (قانون) تعریف می‌شود که: • چه لاگی را نگاه کند 🧾 • با چه Regex خطاها را تشخیص دهد 🔍 • بعد از چند خطا IP بن شود 🚫 • برای چند دقیقه یا ساعت بن بماند ⏱ ✅ نصب Fail2ban روی Debian/Ubuntu روی توزیع‌های Debian/Ubuntu این دستورها معمولاً کافی است: sudo apt update sudo apt install fail2ban -y # کپی کانفیگ پیش‌فرض برای ویرایش امن sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # فعال‌سازی و استارت سرویس sudo systemctl enable fail2ban sudo systemctl start fail2ban # وضعیت کلی sudo fail2ban-client status در Red Hat / CentOS هم با dnf install fail2ban یا yum install fail2ban قابل نصب است (بسته‌های EPEL را باید فعال کرد). 🔐 نمونه تنظیم Jail برای حفاظت SSH فایل اصلی کانفیگ محلی معمولا /etc/fail2ban/jail.local است. یک نمونه کانفیگ ساده برای SSH: [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 findtime = 600 bantime = 3600 توضیح سریع: • enabled فعال‌کردن این jail است. • maxretry یعنی بعد از ۵ تلاش ناموفق، IP بن شود. • findtime محدوده زمانی بر حسب ثانیه است (اینجا ۱۰ دقیقه). • bantime مدت زمان بن‌شدن IP است (اینجا ۱ ساعت). بعد از ویرایش، سرویس را ریلود کن: sudo systemctl restart fail2ban sudo fail2ban-client status sshd 🧠 چند نکته کاربردی • روی سروری که SSH روی پورت غیرمعمول است، مقدار port را با آن پورت هماهنگ کن. • برای سرویس‌های وب (مثلا nginx) می‌توان از فیلترهای آماده Fail2ban استفاده کرد تا از حملات Login Form یا اسکن بیش‌ازحد جلوگیری شود. • اگر خودت زیاد پ