الان تقریبا سه چهار ترمه که تی‌ای امنیتم و صرفا واسه تمرین یک که سوالات pwn هست سوال طرح می‌کنم. حقیقتا وقتی می‌بینم ملت سوالای تمرین یک رو حل می‌کنن و عشق می‌کنن بعد از حلش خیلی ذوق می‌کنم. همینکه بشه علاقه یه نفرو به این فیلد جذب کرد واقعا برام کار با ارزشیه.

ولی خب مسئله اصلی اینه که اینقدر دانشکده دیگه شده فقط هوش، اصلا کسی نیست توی امنیت که مثلا اون بیاد سال بعد وایسه سوال طرح کنه یا ملت رو route کنه که ببینید بابا این فیلد هم هست. از طرفی هم یک حرکت گله‌ای شکل گرفته توی همه که عه بریم هوش بریم هوش چرا چون همه دارن میرن هوش.

حقیقتا ایرانی درست نمیشه. یعنی ایرانم درست شه ایرانی درست نمیشه.

shadPS4 is an early PlayStation 4 emulator for Windows, Linux and macOS written in C++.

https://github.com/shadps4-emu/shadPS4

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

یکی از راه‌هایی که میشه جلوی حمله‌ی DNS Cache Poisoning رو گرفت، دادن درخواست با ترکیب بزرگ و کوچک حروف هست. مثلا به جای درخواست google.com بدیم GoOGle.cOm.

توی این لینک توضیح داده شده که این عمل چجوری جلوی این حمله رو می‌گیره:
https://hypothetical.me/short/dns-0x20/

چجوری کلادفلر آنالیز ۱ میلیون درخواست بر ثانیه رو هندل می‌کنه؟

https://blog.cloudflare.com/how-cloudflare-analyzes-1m-dns-queries-per-second/

Barry Schwartz - Why We Work

به‌نظرم کتاب خیلی مناسبی برای خوندن توی بازه‌ی سنی ماست. بعضی جاها مخاطب‌هاش مستقیما مدیرها بودن و بعضی جاها هم انگار خیلی شعارزده بود اما درکل خیلی پیشنهاد می‌کنم. سه فصل اولش ۴۰ صفحه هم نمی‌شه.

اگر خواستید بدونید که AS یک آدرس IP چه کسی یا سازمانی هست:
https://bgp.tools/

امروز یه مسئله بامزه raise شد.

شما فرض کنید که یک کمپانی هست که حدود ۲ ۳ ترا دیتا داره روی mysql. زجری که این کمپانی می‌کشه اینه که با هر آپدیت گنده‌ای که میخواد روی دیتابیسش بره، چیزی حدود ۱ ساعت down عه. چون حجم دیتا زیاده و مثلا یه تغییر جنس یه فیلد روی چندتا تیبل یه downtime یک ساعتی داره براشون. چرا؟ چون برای اپدیت تیبل‌ها، اون تیبل‌ها لاک می‌شن و کوئری‌های write بسته می‌شن. حتی بعضا توی mysql، کوئری‌های read هم بسته می‌شن. دغدغه اینجاس که چجوری این کمپانی می‌تونه بدون هیچ downtimeای، دیتابیسشو آپدیت کنه.

این ما رو به این داشت که شرکت‌های بزرگ چکار می‌کنن؟ مثلا گوگل که نمیاد بگه عزیزان لطفا امروز سرچ نکنید ما downاین تا ما این تیبل‌هامونو اپدیت کنیم که. حالا در ادامه (نه دقیقا همین الان) یه سری چیز میز که چجوری شرکتای گنده بدون downtime می‌تونم دیتابیس‌ و تیبل‌ها و داده‌های گنده رو آپدیت کنن رو می‌گم. خیلی بامزه‌ن.

فیبر نوری خونه رو راه انداختم. صرفا جهت شوعاف.

این یه نمونه واسه دیتابیس‌های schemeless عه.

https://www.cockroachlabs.com/blog/how-to-update-database-schema/

پیرو این مسئله، امروز چون یکم وقت داشتم گفتم بنویسم. حقیقتش اینه که شرکتای بزرگ عموما آپدیت‌های اینشکلی روی تیبل‌ها نمی‌رن. به عبارتی شرکتایی مثل گوگل، متا، آمازون و کلا حالا زیر سرویس‌های این‌ّا که دیتابیس‌های خیلی عظیم الحجمی دارن، کلا آپدیت مثلا فیلد رو انجام نمیدن. عموما مثلا این شکلیه که یک proxy میارن روی کار جلوی سرویس‌شون. یک ستون جدید اضافه می‌کنن که مثلا این ستون قراره همون ستون قبلی باشه که تایپش عوض شده. و از حالا این داده‌ها رو توی ستون جدید می‌نویسن. این عملیات به شکلی جلو میره که داده‌های ستون قبلی دیگه توی هیچ قسمتی مورد استفاده نباشه و همه‌ش منتقل شده باشه و اینجوری دیگه دسترسی سرویس‌هاشون از ستون قبلی رو می‌گیرن و سوییچ می‌کنن به ستون جدید.

البته اینایی که می‌گم خیلی کلیه و دقیقا این نیست. مثلا یکی از هزاران راه اینه. خیلی بسته به محیط و سرویس و دیتابیسی که استفاده میشه و این موارده. مثلا یک راهم همونطور که بچه‌ها زیر پست هم نوشتن، اینه که ما یه نود رپلیکا بیاریم روی کار که با مستر سینک میشه و بعدش سینک رو قطع کنیم روی نود رپلیکا و تغییرات رو انجام بدیم. اصلا حتی اگر تغییرات n ساعت هم طول بکشه، سرویس ما همچنان به نود مستر دیتابیس وصله و کار می‌کنه. اینجا یه بدی خب مثلا هست اینه که داریم دو برابر منابع مصرف می‌کنیم دیگه. ولی مهم‌ترین نکته اینه که زمانی که سینک رپلیکا با مستر قطع شد که بره روش تغییرات ایجاد شه، در این زمان داده‌هایی که روی مستر نوشته میشه چی میشن؟

بحث اینه که واقعا ماهیت دیتابیس‌ها فرق می‌کنه. مثلا زمانی که رپلیکا از مستر برای سینک خارج شه، حالا فرضا تایپ اون ستونی که می‌خواستیم از int شد string. حین این تغییر مثلا داده‌های 1 و 2 و 3 هم نوشته شد روی مستر و از اونجایی که رپلیکا دیگه سینک نیست، پس این داده‌ها روی رپلیکا وجود نداره دیگه. بعد که مجددا بخواد رپلیکا برگرده به مدار، دیتابیس postgre این قابلیت رو داده که بتونه داده‌های 1 و 2 و 3 رو بنویسه توی رپلیکا ولی با تایپ جدید. و حالا می‌تونیم سرویس رو وصل کنیم به رپلیکا و مستر رو شروع کنیم ادیت کردن.

اینم بلاگ قشنگیه که خوندنش پیشنهاد میشه:
https://cloud.google.com/blog/products/databases/how-cloud-sql-maintenance-works-to-keep-instances-updated

ولی این مورد که شرکتای بزرگ عموما مایگریشن نمیزنن وجود داره. یعنی مثلا توی طول عمر سنتری فکر کنم یبار یه مایگریشن بزرگ وجود داشته که توی آپدیت ورژن سنتری مثلا دیتابیس هم باید آپدیت میشده. و اونم مثلا بخاطر این بوده که سنتری اومده از بیخ اصلا معماریش رو کامل عوض کرده.