سیاوش حسین‌زاده

سندروم تحلیل‌های زرد دوباره بالا گرفته، ولی واقعیت فنی ماجرا چیه؟

گوگل قابلیت Search generative AI control رو توی Search Console رول‌اوت کرده. کارش صرفا یک چیزه، تعیین اینکه محتوای شما توی AI Overviews و AI Mode گوگل بیاد یا Exclude بشه. نه قراره معجزه‌ای بشه و نه ربطی به Train شدن مدل‌های دیگه مثل GPT یا Grok داره. مدیریت دیتای آموزشی هنوز دست Google-Extended هست و این سوییچ حتی سیگنال رنکینگ سئو هم نیست.

از طرفی، حضور توی این نتایج لزوما برای هر بیزنسی برد نیست. اگه سایت فروشگاهی یا محصول Conversion-driven داری، پاسخ‌های جنریتیو اغلب کاربر رو در وضعیت Zero-click نگه می‌دارن! یعنی کاربر دیتای تو رو می‌خونه، خریدش رو جای دیگه می‌کنه و ترافیک ورودی سایتت رسما نابود می‌شه.

تکنولوژی ابزاره، نه ترند برای پز دادن. به جای تصمیم‌های هیجانی، گزارش Generative AI performance رو بررسی کنید و با توجه به مدل درآمدی سایت تصمیم بگیرید، نه ریلزهای چند ثانیه‌ای افرادی که تقریبا ۵ کلمه از مستندات رسمی گوگل رو نمی‌تونن از روش بخونن...

اکثر کاربرا وقتی می‌خوان یه سخت‌افزار قدیمی رو زنده کنن سریع می‌رن سراغ اوبونتو، ولی معمولا نتیجه اون چیزی که فکر می‌کردن نمی‌شه.

سیستم‌عامل FydeOS رویکرد متفاوتی داره. بیسش Chromium OS عه؛ یعنی همون تجربه ChromeOS بدون نیاز به خرید کروم‌بوک‌های گوگل. معماریش کلا بر پایه وب و سرویس‌های کلادی چیده شده، واسه همین روی کانفیگ‌های ضعیف و رم پایین هم خیلی نرم و ریسپانسیو میاد بالا.

قرار نیست جای یه توزیع کامل لینوکس یا سیستم‌عامل دسکتاپ اصلی شما رو بگیره و ورک‌فلو سنگین دولوپری بده. تارگتش وب‌گردی، تسک‌های سبک و مدیاست. ولی برگ برنده‌ش ساپورت روان از Subsystem اندرویده (فعلا تا اندروید ۱۳) که عملا کلی اپ موبایلی رو بدون سربار و لگ امولاتورها بالا میاره.

برای احیای لپ‌تاپ‌های خاک‌خورده و تبدیلشون به یه سیستم دم‌دستی انتخاب هوشمندانه‌ایه.

لینک دانلود: fydeos.io/download

ایمیل با دامین اختصاصی نامحدود روی کلادفلیر روی کاغذ جذابه، ولی ما پول سرویس‌هایی مثل Google Workspace رو برای UI یا ذخیره‌سازی نمی‌دیم؛ برای Deliverability می‌دیم.

پروژه Mailflare از نظر معماری Serverless واقعا تمیز پیاده شده. استک پروژه کاملا روی Edge سواره؛ ترکیب Cloudflare Workers با دیتابیس D1 و آبجکت استوریج R2. یعنی عملا بدون نیاز به مدیریت سرور لینوکسی یا کانتینر، هزینه زیرساخت سمت کاربر در اسکیل پایین تقریبا صفره.

اما چالش مهندسی سیستم‌های ایمیل هیچ‌وقت لایه Receive نبوده. دریافت ایمیل با Email Routing کلادفلیر ساده‌ست؛ چالش اصلی لایه Send، گرم کردن دامین، مدیریت IP Reputation و تنظیم دقیق رکوردهای SPF، DKIM و DMARC برای رد شدن از فیلترهای Spam پرووایدرهای بزرگه. چیزی که صرفا با چندتا ورکر سرورلس تضمین نمی‌شه.

برای MVP، سایدپروژه‌ها یا تست ایده‌هایی که توجیه نداره براشون اکانت دلاری تهیه بشه، یک گزینه فوق‌العاده‌ست. ولی برای پروداکشن بیزینس و ایمیل‌های Transactional حساس، ریسک بالایی داره.

سورس پروژه روی گیت‌هاب: https://github.com/hieunc229/mailflare

اختلال گسترده‌ای که الان تو چندتا هاستینگ و سرویس مختلف می‌بینیم: (پارس‌پک، سون‌ هاست، لیموهاست، ایران‌سرور… حتی ترب و بعضی پنل‌های پیامکی) بیشتر از هر چیز نشون می‌ده تیم‌های فنی دارن با یه شرایط خارج از کنترل خودشون می‌جنگن. وقتی برق چندتا دیتاسنتر مثل های‌وب هم‌زمان می‌پره، هیچ معماری‌ای صددرصد آماده نیست!

اینجور لحظه‌ها تیم‌ها دارن با دست‌های بسته سرویس رو روی هوا نگه می‌دارن و همزمان Recovery رو جلو می‌برن. فشار کاریشون وحشتناکه و سطح استرس بسیار بالاست.

ارسال تیکت و تماس تو این شرایط فقط تمرکز رو از بین می‌بره و هر دقیقه‌ای که ازشون گرفته می‌شه یعنی چند دقیقه تأخیر بیشتر تو برگشت سرویس.

اگه دسترسی مستقیم دارید به هاستتون، فقط بکاپ بگیرید و کنار بکشید، بذارید تیم‌ها با تمرکز و بدون استرس اضافه کار رو جمع کنند.

شب‌های سختِ زیرساخت همیشه روی دوش همین آدم‌هاست و واقعا باید پشتشون باشیم.

امیدوارم هرچه زودتر این مشکل برطرف بشه.

داستان اینجاست که Anthropic توی Claude Code چندتا سوتی سنگین داده بود که عملا با یک git clone ساده، سیستم دیپلوی‌منت و API Key هاتون به باد می‌رفت. مشکل از فایل‌های کانفیگ مثل settings.json شروع می‌شه. جایی که مهاجم می‌تونه با ست کردن ANTHROPIC_BASE_URL کل ترافیک و توکن‌های شما رو به سرور خودش Redirect کنه، اونم قبل از اینکه حتی دکمه تایید رو بزنید.

بحث فنی‌تر اینجاست که وقتی به AI اجازه دسترسی به Terminal و MCP (Model Context Protocol) میدی، فایل‌های کانفیگ دیگه فقط دیتا نیستن، بخشی از Execution Layer حساب می‌شن. یعنی باز کردن یک Repo غریبه مساوی با اجرای کد مخرب روی لوکال.

خلاصه اینکه توی دنیای AI-Driven Development، دیگه فقط نباید نگران پکیج‌های npm باشیم، حالا باید حواسمون به فایل‌های تنظیمات ابزارهای کدزنی هم باشه. امنیت Supply Chain از اونی که فکر می‌کردیم پیچیده‌تر شده اگه قرار باشه با AI زندگی کنیم.

وقتی ابزاری مثل n8n رو وسط سازمان میارید که به همه‌جا، از APIهای LLM گرفته تا سیستم‌های IAM و دیتای فروش دسترسی داره، عملا دارید یک Skeleton Key به نفوذگر می‌دید. با افشای CVE-2026-1470 با امتیاز ۹.۹، مشخص شد که دور زدن Sandbox و رسیدن به RCE از اون چیزی که فکر می‌کردیم راحت‌تره.

مشکل اینجاست که خیلیا فکر می‌کنن چون n8n محیط Low-code داره، پس هر کسی با دو تا درگ‌-اند-دراپ می‌تونه معمار اتوماسیون سازمان باشه! (یا مثلا متخصص اتوماسیون با هوش مصنوعی 😂) فاجعه دقیقا از همین‌جا شروع می‌شه. سپردن زیرساخت اتوماسیون به آدم‌هایی که درک عمیقی از معماری نرم‌افزار و چالش‌های امنیتی ندارن، یعنی فاجعه...

توی این گزارش جدید، محقق‌های JFrog نشون دادن که حتی با وجود لایه‌های کنترلی مبتنی بر AST و لیست‌های سیاه، باز هم می‌شه از قابلیت‌های Deprecated شده یا رفتارهای خاص Interpreterها استفاده کرد و از زندان Sandbox فرار کرد. این یعنی امنیت در سطح کد، تضمین‌کننده نیست.

بزرگترین اشتباه استراتژیک، استفاده از Internal Mode در محیط Production است. n8n صراحتا هشدار داده که برای ایزوله‌سازی باید از External Mode استفاده بشه، اما آمار Shadowserver نشون می‌ده که هنوز بیش از ۳۹,۰۰۰ Instance آسیب‌پذیر توی اینترنت رها شدن. این یعنی فقر دانش زیرساختی در تیم‌هایی که ادعای اتوماسیون دارن.

باید قبول کنیم که مدیریت امنیت در زبان‌های داینامیک مثل Python و JS برای محیط‌های Multi-tenant کابوسه. اگر تیم شما تخصص مدیریت Task Runnerها و ایزوله‌سازی فرآیندها در سطح سیستم‌عامل رو نداره، همین الان دسترسی‌های n8n رو محدود کنید.

اتوماسیون بدون امنیت، فقط سرعت بخشیدن به نابودی سازمانتونه. اگه معمار زیرساخت سر پروژه نیست، n8n رو برای کارهای حساس لانچ نکنید.

وقتی گوگل‌بات به خاطر اختلالات شبکه یا اختلال در اینترکانکت نمی‌تونه دیتاسنترهای داخلی رو درست Crawl کنه، عملا فرقی با Down بودن سایت نداره. راه‌حل این روزها برای فرار از افت رتبه، استفاده از یک کپی Mirror روی هاست خارج (مثلا اروپا) و بازی با NSهاست.

با ست کردن نیم‌سرورهای ایران و خارج در کنار هم، یه جور Failover دستی ایجاد می‌کنید. اینطوری وقتی دسترسی گوگل از بیرون به ایران مختل می‌شه، گوگل بات می‌ره سراغ هاست اروپا و ایندکس متوقف نمی‌شه. برای کاربر داخل هم همچنان Latency پایین هاست ایران رو داریم.

فقط یادتون باشه این یه Dirty Hack برای بقاست، نه یه استراتژی تمیز! اگه سایت فروشگاهی دارید، حتما روی نسخه خارج، درگاه پرداخت و ثبت‌نام رو ببندید تا دیتابیس‌هاتون ناهمگام (Out of sync) نشه. سئو مهمه، ولی Integrity دیتا از اون هم مهم‌تره.

در این مدت که اینترنت ملی هستش، اگر از سرویس های میزبانی وب داخل کشور استفاده کنید، سایتتون در دسترس قرارداره و کاربرانتون بدون مشکل و با سرعت و کیفیت مناسب میتونن از خدماتتون استفاده کنن. درگاه های پرداخت هم مجددا فعال شدند و بصورت کلی برای سایت های داخلی مشکلی وجود نداره.

اگر در این بازه زمانی، کسب و کارتون باید آنلاین باشه حتما چکلیست زیر رو رعایت کنید.

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

1- تهیه هاست با لوکیشن داخل کشور و عدم استفاده از CDN های خارج از کشور با ابر یا پراکسی روشن.

2- عدم استفاده از پلاگین ها و ماژول هایی که نیاز به دسترسی اینترنت بین الملل دارند مثلا API های هوش مصنوعی.

3- انتقال تمامی asset های موردنیاز به ساختار میزبانی داخلی و عدم وابستگی به سرویس هایی مثل CDNjs , Google fonts API و...

4- غیرفعالسازی Google Captcha و مواردی که نیاز به دسترسی اینترنت بین الملل از سمت کاربران شما دارد.

تو دو هفته گذشته این چهارمین باگ Critical هست که از n8n میاد بیرون، ولی این یکی (CVE-2026-21858) فرق داره و بازی رو عوض کرده. چرا؟ چون Unauthenticated هست. یعنی بدون هیچ یوزر و پسوردی، اتکر کل اینستنس رو می‌گیره و تبدیل میشه به ادمین سیستم! اسمش رو گذاشتن Ni8mare و واقعا هم کابوسه.

داستان فنی‌ش یه درس عبرت برای Backend Develope هاست:

باگ توی لاجیک parseRequestBody() و نحوه هندل کردن Content-Type توی Webhookها نهفته‌ست. سیستم بدون اینکه چک کنه هدر ریکوئست واقعا multipart/form-data هست یا نه، به اتکر اجازه میده آبجکت req.body.files رو Override کنه. نتیجه؟ اتکر به جای فایل آپلودی، آدرس فایل‌های حساس لوکال (مثل /home/node/.n8n/database.sqlite یا فایل کانفیگ) رو میده به خورد سیستم و n8n هم دو دستی محتواشون رو برمی‌گردونه.

از اینجا به بعدش سناریوی کلاسیک نفوذه:

۱. دیتابیس SQLite رو می‌خونن و هش پسورد ادمین و Encryption Key رو استخراج می‌کنن.

۲. با این دیتا، کوکی ادمین رو Forge می‌کنن (Session Hijacking).

۳. حالا که ادمین شدن، با یک نود ساده Execute Command دسترسی کامل RCE می‌گیرن.

عملا n8n که قرار بود عصای دست تیم فنی (البته که مارکتینگ تا فنی) باشه و همه‌ی سرویس‌ها (API Keys, DBs, Cloud Tokens) توش متمرکز باشن، تبدیل میشه به Single Point of Failure. اگر اینستنس شما پابلیک باشه، کل کلیدهای زیرساختتون لو رفته.

اگر زیر نسخه 1.121.0 هستید، همین الان آپدیت کنید! و یه قانون کلی: ابزارهای اینترنال و حیاتی مثل n8n رو هیچ‌وقت Raw روی اینترنت اکسپوز نکنید؛ همیشه پشت VPN یا حداقل یک لایه Authelia/Basic Auth بذارید.

قطعا نباید امنیت رو فدای User Experience کنیم! آسیب پذیری جدید Coolify با شناسه CVE-2025-64420 یه کلاس درس کامله از اینکه چطور نباید Credential مدیریت کرد. اسکور CVSS 9.9 گرفته، ولی نه بخاطر یه اکسپلویت پیچیده!

ماجرا اینه که یه یوزر Low-privilege خیلی شیک می‌تونه Private Key روت رو از توی پنل برداره و دانلود کنه!! یعنی عملا دسترسی Root به سرور میزبان، بدون هیچ دردسری دریافت بشه. اینجا با یه RCE عجیب طرف نیستیم؛ رسما کلید گاوصندوق اصلی رو گذاشتن زیر گلدون دمه در! این مدل Information Disclosure که مستقیم ختم میشه به Privilege Escalation، بدترین نوع سهل‌انگاری توی معماری سیستم‌های مدیریت سروره.

اگه از Coolify مخصوصا نسخه‌های بتا تا ۴۳۴ استفاده می‌کنید، فقط آپدیت کردن کافی نیست. فرض رو بر این بذارید که کلیدها همین الان دانلود شدن و سریعا SSH Key Rotation انجام بدید.