خواستم یه فضایی باشه که بتونم informal تر از LinkedIn و formal تر از 4chan و reddit حرفامُ بزنم این شد که اینجا استارت خورد :)

دیشب برای اولین بار Arch نصب کردم.
تجربه جالبیه اول اینکه ArchWiki خیلی جامع و بدرد بخوره البته که الان توی عصر AI به سر میبریم و...
برای کسایی که همنشینی با سیتمشون رو به اکثر فعالیتهای دیگه ترجیح میدن قطعا تجربه لذت بخشیه و حتی میتونه کلی چیزای مختلف و جدید راجع به Linux یاد بده و باعث میشه سیستمتون رو بهتر بشناسید ولی خب طبیعتا میتونه خیلی هم زمان بر باشه...
حس کردم که شاید برتری خاصی نسبت به باقی distro ها برای ricing و customization نداشته باشه... مگر در موارد خاص...
شخصا نتونستم خودم رو تصور کنم که ازش به عنوان main OS استفاده کنم حداقل نه تا آینده ای نامعلوم، بعد از کلی distro hopping دلم میخواد برگردم به Mint و بس بشینم و دیگه تکون نخورم! ولی حداقل تونستم برای چند ساعتی بگم "I use Arch btw"

نمیدونم هنوزم هستش یا نه ولی توی دوره مدرسه رفتن ما یه کتاب بود به اسم گام به گام که به علاوه توضیح دروس و چیزای دیگه جواب تمرینات روهم داشت!
یادمه قبل از بعضی کلاس ها اونایی که گام به گام داشتن کتاب رو میذاشتن وسط و با چنتا از دوستاشون تند تند مینوشتن.
خلاصه که طبيعی بود با اون وضع تمرین نوشتن قرار نبود اون مفاهیم رو یاد بگیریم! صرفا موضوع رفع تکلیف بود و بس....
الانم اگه از AI به درستی استفاده نکنیم میتونه همین شکلی مشکل ساز شه.

مثلا چند وقت پیش Primeagen داشت از یه نفر (که یادم نیست کی) نقل میکرد که زمانی که با مشکلی توی کد مواجع میشی حداقل تا یه ربع در صورت حل نشدنش به AI مراجعه نکن لاگ ارور رو بخون و سعی کن خودت حلش کنی...

اره پیشرفت AI دروازه ای رو باز کرد که دیگه نمیشه بستش اما باید تمام تلاشمون رو کنیم که از ابزار ها هوشمندانه استفاده کنیم.

یادگرفتن زبان هایی که Manual memory management یاد نمیدن قبل از C مثل خوردن هله هوله قبل از یه وعده سالمه!
وقتی مزه‌اش زیر دندون بره سخت میشه بعدش وقت گذاشت برای یاد گرفتن یه سری اصول خسته کننده.
مثلا وقتی سعی میکنید به یه نفر راجع به Garbage Collector یاد بدید وقتی ذهنیت درستی راجع به Memory نداره طبیعیه که موضوع براش خوب جا نیفته چون Context خوب تعریف نشده...
مثل اینه که جواب یه سوال رو بدون تعریف کردن اون سوال یاد بدید...

قطعا در چند وقت اخیر بهترین پادکستی بوده که Released شده


https://youtu.be/tNZnLkRBYA8?si=QJEX4_Allndd4g2s

میخوای Data Structure هارو جوری یاد بگیری که دیگه هیچوقت فراموش نکنی؟
با زبان C پیاده سازیش کن.
البته میشه از هر زبان دیگه ای استفاده کرد ولی C ترجیح خودمه.
فکر میکنم بعد از اینکه یبار یکی از ساختمان های داده‌رو از صفر بسازی و براش عملیات های پایه ای رو تعریف کنی و با Time&Space Complexity هرکدوم آشنا شی برای همیشه توی حافظه میمونه.
اینم یه لیست از ساختمان داده هایی که خوبه بهشون مسلط باشی:
Stack, Queue, Graph, Tree, HashTable, LinkedList

"هیچوقت به input کاربر اعتماد نکن"
اگه به عنوان یه Developer همین یه جمله ساده رو رعایت کنی جلوی کلی از آسیب پذیری های رایج Web رو میگیری.

یکی از قدیمی‌ترین آسیب‌پذیری‌های وب SQLi هست.
خودش چند نوع اصلی داره، مثل:
In-band,Blind,Out-of-band

اصولاً به هر SQLi که در اون هم برای حمله هم برای تخلیه دیتا از یک کانال استفاده میشه In-band میگیم.
که In-band هم خودش دو حالت داره:

Error-Based, Union-Based



باهم Error-Based رو بررسی کنیم:
توی این مدل حمله، مهاجم اول یه نقطه ورود (Injection Point) آسیب‌پذیر پیدا می‌کنه. این نقطه می‌تونه هر جایی توی برنامه باشه که اطلاعات کاربر رو بدون چک کردن درست و حسابی یا پاک‌سازی، صاف می‌فرسته قاطی کوئری‌های SQL. مثلاً پارامترهای URL، چیزایی که تو فرم‌های HTML می‌نویسیم، هدرهای HTTP (مثل Cookie یا User-Agent)، یا حتی اطلاعاتی که تو JSON یا XML برای APIها می‌فرستیم.

وقتی که مهاجم نقطه تزریق رو پیدا کرد با فرستادن ورودی‌های دستکاری‌شده کاری می‌کنه که پایگاه داده ارور بده. این ارورها جوری هستن که یه تیکه‌هایی از اطلاعاتی که می‌خوایم یا حتی ساختار پایگاه داده رو توی خودِ متن ارور نشون میدن. مهاجم این کار رو می‌تونه با خراب کردن سینتکس کوئری (مثلا با اضافه کردن ' ) انجام بده، یا اینکه از متدها و دستورهای خاصی توی پایگاه داده استفاده کنه که اگه بهشون ورودی ناجور بدی یا مشکلی پیش بیاد، اطلاعات رو لو میدن. مثلاً سعی می‌کنه یه چیزی که رشته هست (مثل نتیجه یه ساب‌کوئری) رو به زور تبدیل به عدد کنه، یا از متدهای کار با XML (مثل ExtractValue یا UpdateXML توی MySQL و چیزای شبیه به این تو بقیه پایگاه‌داده‌ها) با ورودی‌های دستکاری شده که توش یه ساب‌کوئری جاسازی کرده، استفاده می‌کنه.

اگه برنامه همچین اروری رو نشون بده، خب یعنی به SQLi مبتنی بر خطا آسیب‌پذیره!
البته اینکه ارور چقدر اطلاعات میده و چه شکلیه، به تنظیمات پایگاه داده و خود برنامه بستگی داره. بهترین حالت برای مهاجم اینه که ارورهای Verbose (یعنی پرحرف) بگیره که کلی جزئیات مثل نسخه پایگاه داده، اسم جدول‌ها، ستون‌ها یا حتی یه تیکه از خود کوئری رو بهش میده. اینم مهمه که بدونیم روش‌های ارور درآوردن و شکل خود ارورها خیلی به نوع پایگاه داده‌ای که استفاده میشه (مثلاً MySQL، SQL Server، Oracle، PostgreSQL) ربط داره.

از اینجا به بعد، مهاجم با درست کردن و فرستادن کوئری‌های آلوده و با برنامه، پله پله کل پایگاه داده رو شناسایی و به اصطلاح Enumerate می‌کنه. این Enumerate کردن معمولاً یعنی درآوردن نسخه پایگاه داده، کاربر فعلی، اسم پایگاه‌داده‌ها، بعدش جدول‌های توی یه پایگاه داده، ستون‌های توی اون جدول‌ها، و آخر سر هم کش رفتن اطلاعات حساس از این ستون‌ها. همه این اطلاعات رو هم از طریق همون پیام‌های اروری که پایگاه داده میده، به دست میاره.

می‌گفتش که:
"بهترین زبان برنامه نویسی همونه که بابت استفاده ازش بهت پول میدن"

یکی از راه‌های خوب برای اینکه موقع چک کردن اخبار کمتر حواست پرت بشه استفاده از Feedly هست.
می‌تونی باهاش برای خودت Category مختلف از فیدهای شخصی‌سازی‌شده درست کنی و بدون اینکه پست‌های نامربوط تمرکزت رو به هم بزنن اطلاعاتت رو به‌ روز نگه‌ داری.
مثلاً یه متخصص امنیت که سرش شلوغه می‌تونه همه‌ی منابع خبری مورد نیازش رو توی یه فید جمع کنه.
یا مثلاً می‌شه یه فید برای خبرهای AI ساخت تا به موقع بدونیم قراره کدوم LLM شغلمون رو تصاحب کنه:)

شاید تا حالا اسم Fail2Ban به گوشتون خورده باشه خودم امروز وقتی داشتم یه CTF انجام میدادم باهاش آشنا شدم.
این ابزار در واقع یه IPS به حساب میاد که کارش اینه جلوی حملاتی مثل Brute Force رو بگیره. مثلاً اگه یه نفر هی بخواد پسورد سرور شما رو حدس بزنه Fail2Ban می‌فهمه و IP اون شخص رو بلاک می‌کنه تا دیگه نتونه حمله کنه. خیلی ابزار باحالیه برای بالابردن امنیت سرور.
اما یه نکته خیلی مهم و خطرناک وجود داره که اگه اجازه‌های دسترسی (Permissions) فایل‌ها و پوشه‌ها در سطح سیستم عامل (OS) درست تنظیم نشن همین Fail2Ban که قراره جلوی حمله رو بگیره خودش می‌تونه تبدیل به یه راه برای Privilege Escalation (بالابردن سطح دسترسی از یه کاربر عادی به کاربر روت) بشه!
یعنی چی؟ یعنی اگه یه مهاجم بتونه به فایل‌های تنظیمات Fail2Ban دسترسی پیدا کنه و اونا رو تغییر بده می‌تونه کاری کنه که Fail2Ban به جای محافظت یه کد مخرب رو با دسترسی روت اجرا کنه و در نهایت به مهاجم دسترسی کامل بده. این دیگه تقصیر خود Fail2Ban نیست بلکه برمی‌گرده به تنظیمات غلطی که در سطح OS روی پرمیشن‌ها اعمال شده.
اگه دوست دارید دقیق‌تر بدونید چطور می‌شه از این نقطه ضعف استفاده کرد و Fail2Ban رو برای Privilege Escalation اکسپلویت کرد این مقاله رو حتماً بخونید.
https://juggernaut-sec.com/fail2ban-lpe

ای بابا APT ها تنبل شدن خب چه کاریه چهارتا mac mini می‌گرفتید deepSeek رو self host میکردید دیگه😁
https://thehackernews.com/2025/06/openai-bans-chatgpt-accounts-used-by.html?m=1