درون سازوکار impersonate-proxy برای جعل اثرانگشت‌های شبکه

اگر به عنوان یک متخصص امنیت سعی کرده‌اید با اسکریپت‌های پایتون به یک وب‌سایت دسترسی پیدا کنید و بلافاصله توسط دیواره‌های آتش مسدود شده‌اید، دلیلش احتمالاً User-Agent شما نیست. سیستم‌های مدرن تشخیص بات، حالا لایه‌های بسیار عمیق‌تری از دست‌دادن (Handshake) شبکه را تحلیل می‌کنند تا بفهمند شما یک مرورگر واقعی هستید یا یک کد برنامه‌نویسی. محققان امنیتی اکنون می‌توانند با استفاده از impersonate-proxy عمیق‌ترین لایه‌های دست‌دادن شبکه را دستکاری کنند تا سیستم‌های پیچیده تشخیص بات را دور بزنند.

به نقل از مستندات پروژه که در ۱۸ آوریل ۲۰۲۶ منتشر شد، ابزاری به نام impersonate-proxy معرفی شده است که می‌تواند این لایه‌های امنیتی را دور بزند. این ابزار یک پروکسی MITM (مرد وسط) محلی است که اجازه می‌دهد اثرانگشت‌های TLS، تنظیمات HTTP/2 و ترتیب هدرها را از طریق یک فایل پیکربندی YAML تغییر دهید.

دیواره‌های آتش برنامه‌های وب (WAF) دیگر تنها به آدرس IP یا User-Agent تکیه نمی‌کنند. آن‌ها از «اثرانگشت‌گیری» استفاده می‌کنند؛ یعنی تحلیل می‌کنند که یک کلاینت چگونه اتصال TLS را آغاز می‌کند یا فریم‌های HTTP/2 را مدیریت می‌کند تا یک مرورگر واقعی کروم را از یک اسکریپت پایتون تشخیص دهند. از آنجایی که تغییر این الگوهای سطح پایین در کتابخانه‌های استاندارد دشوار است، شبیه‌سازی رفتار مرورگر برای تسترهای امنیتی یک چالش بزرگ بود.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن و زیرساخت‌های شبکه اشاره کردیم، لایه‌های پایین‌تر پروتکل‌ها همیشه نقاط ضعف پنهانی دارند. impersonate-proxy با استفاده از کتابخانه uTLS، ترافیک ابزارهایی مثل curl یا Playwright را می‌گیرد و آن را طوری بازبسته‌بندی می‌کند که دقیقاً شبیه اثرانگشت یک مرورگر هدف شود.

سازوکار عملیاتی پروکسی

این سیستم به عنوان یک پل MITM عمل می‌کند. فرآیند زمانی شروع می‌شود که کلاینت (مانند curl، یک مرورگر یا Playwright) یک درخواست HTTP CONNECT به پروکسی می‌فرستد. سپس پروکسی، اتصال با سرور هدف یا لایه WAF را با استفاده از یک TLS ClientHello سفارشی و فریم‌های HTTP/2 مدیریت می‌کند.

در لایه‌های داخلی، این ابزار از یک هندلر TLS و uTLS برای تولید اثرانگشت‌های JA3 و JA4 استفاده می‌کند. همچنین یک بازنویس هدر برای مدیریت User-Agentها و ترتیب هدرها، و یک فریم‌ساز HTTP/2 برای کنترل SETTINGS، WINDOW_UPDATE و ترتیب شبه-هدرها در اختیار دارد.

کنترل عمیق بر TLS و HTTP/2

این ابزار کنترل دقیقی روی بسته TLS ClientHello فراهم می‌کند که منبع اصلی اثرانگشت‌های JA3 و JA4 است. کاربران می‌توانند از پیش‌فرض‌های آماده برای Chrome، Firefox، Safari، Edge، iOS یا حتی پروفایل‌های تصادفی و golang استفاده کنند یا یک مشخصات کاملاً سفارشی تعریف کنند.

برای دقت مطلق، بخش custom_hello امکان تعریف موارد زیر را می‌دهد:

• مجموعه رمزها (Cipher Suites): لیست و ترتیب دقیق الگوریتم‌های رمزنگاری. کاربران می‌توانند از 0x0a0a به عنوان جایگاه GREASE استفاده کنند که توسط uTLS در هر اتصال به صورت تصادفی تغییر می‌کند.
• افزونه‌ها (Extensions): توالی دقیق شناسه‌های نوع افزونه TLS. این مورد مستقیماً مؤلفه افزونه‌های JA3 را کنترل می‌کند.
• گروه‌های پشتیبانی شده: منحنی‌های بیضوی (مانند X25519، P256، P384، P521) که در طول دست‌دادن اعلام می‌شوند.
• نسخه‌های TLS: محدوده‌ای از نسخه‌ها (مثلاً "1.3" یا "1.2") که کلاینت ادعا می‌کند پشتیبانی می‌کند.

علاوه بر TLS، این پروکسی لایه HTTP/2 را که سیگنال حیاتی دیگری برای WAFهاست، دستکاری می‌کند. این ابزار اجازه می‌دهد ورودی‌های فریم SETTINGS تغییر کنند، جایی که شناسه و ترتیب هر دو بر اثرانگشت اثر می‌گذارند. شناسه‌های پشتیبانی شده شامل موارد زیر است:

• ID 1: HEADER_TABLE_SIZE
• ID 2: ENABLE_PUSH
• ID 3: MAX_CONCURRENT_STREAMS
• ID 4: INITIAL_WINDOW_SIZE
• ID 5: MAX_FRAME_SIZE
• ID 6: MAX_HEADER_LIST_SIZE

همانی‌طور که در مستندات آمده، این ابزار همچنین مقدار افزایش WINDOW_UPDATE در سطح اتصال و ترتیب شبه-هدرها (method, authority, scheme, path) در فریم HEADERS را کنترل می‌کند.

دستکاری هدرها و جعل IP

پروکسی برای اطمینان از تطابق درخواست HTTP با اثرانگشت TLS، لایه اپلیکیشن را نیز مدیریت می‌کند. این ابزار می‌تواند User-Agent را بازنویسی کرده و ترتیب خاصی برای هدرها اعمال کند؛ چرا که ترتیب هدرها اغلب لو دهنده ابزارهای خودکار است. در فایل config.yaml کاربران می‌توانند لیستی از header_order (مثلاً Host, User-Agent, Accept) تعریف کنند تا هدرها دقیقاً با توالی مورد انتظار سرور ارسال شوند.

علاوه بر این، با تنظیم هدرهای X-Forwarded-For و True-Client-IP از جعل IP پشتیبانی می‌کند. با تعیین یک client_ip (مثلاً "1.2.3.4")، پروکسی هر مقدار موجود را که کلاینت ممکن است تنظیم کرده باشد جایگزین می‌کند تا تسترها ببینند WAF ترافیک را بر اساس IPهای منبع مختلف چگونه طبقه‌بندی می‌کند.

مدیریت لحظه‌ای و یکپارچه‌سازی

یکی از کاربردی‌ترین بخش‌ها، افزونه کروم همراه آن است. این ابزار به یک API مدیریتی روی پورت ۸۰۸۱ (که به عنوان mgmt_listen تعریف شده) متصل می‌شود و به کاربر اجازه می‌دهد بدون ری‌استارت کردن پروکسی، پروفایل‌های اثرانگشت را مستقیماً از نوار ابزار مرورگر تغییر دهد.

این API مدیریتی دو نقطه اتصال (Endpoint) اصلی دارد:

• GET /api/config: تنظیمات فعال شامل custom_hello را به صورت JSON برمی‌گرداند.
• POST /api/config: پیش‌فرض TLS، IP کلاینت و User-Agent را در زمان اجرا به‌روز می‌کند.

برای تست‌های خودکار، این پروکسی به‌طور کامل با Playwright یکپارچه می‌شود. توسعه‌دهندگان می‌توانند با هدایت بستر مرورگر به http://127.0.0.1:8080 بررسی کنند که ترکیب‌های مختلف اثرانگشت چگونه توسط سرور هدف طبقه‌بندی می‌شوند. در Node.js، این کار از طریق گزینه proxy در browser.newContext() انجام می‌شود و در پایتون، آرگومان proxy به browser.new_context() پاس داده می‌شود.

نصب و اعتبارسنجی

نصب این ابزار به Go نسخه ۱.۲۲ به بالا در macOS یا Linux (amd64/arm64) نیاز دارد. از آنجایی که نسخه‌های Go موجود در توزیع‌های لینوکس اغلب قدیمی هستند، نویسنده توصیه می‌کند باینری رسمی را مستقیماً نصب کنید. مراحل شامل کلون کردن مخزن، اجرای make build و شروع به کار با make run است.

از آنجایی که این یک پروکسی MITM است، در اولین اجرا گواهینامه‌های CA خود را (ca.crt و ca.key) تولید می‌کند. کاربران باید برای جلوگیری از هشدارهای SSL/TLS، به این گواهینامه اعتماد کنند:

• macOS: استفاده از make trust-ca برای افزودن به Keychain سیستم.
• Linux: کپی کردن ca.crt به مسیر /usr/local/share/ca-certificates/ (در دبیان/اوبونتو) یا /etc/pki/ca-trust/source/anchors/ (در RHEL/Fedora) و به‌روزرسانی ذخیره اعتماد.
• برنامه‌های خاص: تنظیم NODE_EXTRA_CA_CERTS برای Node.js یا REQUESTS_CA_BUNDLE برای پایتون.

برای تأیید عملکرد اثرانگشت، نویسنده استفاده از tls.peet.ws را توصیه می‌کند. این API تحلیل کامل اثرانگشت درخواست ورودی را برمی‌گرداند. فیلدهای کلیدی برای بررسی شامل tls.ja3_hash، tls.ja4، http2.akamai_fingerprint و ترتیب http1.headers است.

محدودیت‌های فنی

کاربران باید به چند محدودیت حیاتی توجه کنند. این پروکسی فقط برای مسیر «پروکسی به سرور» از HTTP/2 پشتیبانی می‌کند؛ مسیر «کلاینت به پروکسی» از HTTP/1.1 و متد CONNECT استفاده می‌کند. همچنین از QUIC یا HTTP/3 پشتیبانی نمی‌شود.

علاوه بر این، پروکسی فقط هدر User-Agent در سطح HTTP را بازنویسی می‌کند و نمی‌تواند ویژگی navigator.userAgent در جاوااسکریپت را تغییر دهد. برای تطابق کامل، باید کروم را با فلگ --user-agent در کنار تنظیمات پروکسی اجرا کنید. همچنین، این ابزار از درخواست‌هایی که بدنه آن‌ها دارای Transfer-Encoding: chunked است پشتیبانی نمی‌کند.

استفاده قانونی و اخلاقی

این ابزار صرفاً برای تست‌های امنیتی مجاز طراحی شده است؛ برای مثال، تست پیکربندی‌های WAF و تشخیص بات روی سیستم‌هایی که متعلق به شماست یا اجازه کتبی برای تست آن‌ها دارید. استفاده از این ابزار علیه سیستم‌هایی که مجوز ندارید، ممکن است منجر به نقض قوانینی مانند Computer Fraud and Abuse Act در آمریکا یا قانون دسترسی غیرمجاز به کامپیوتر در ژاپن شود و نویسندگان هیچ مسئولیتی در قبال سوءاستفاده از آن نمی‌پذیرند.

این ابزار توازن قدرت را در بازی «موش و گربه» تشخیص بات تغییر می‌دهد. با تبدیل اثرانگشت‌های سطح پایین شبکه به چیزی به سادگی یک رشته User-Agent، ارائه‌دهندگان WAF را مجبور می‌کند تا سیگنال‌های استوارتر از الگوهای ساده دست‌دادن پیدا کنند.

برای متخصصان امنیت، این به معنای توانایی ممیزی قوانین WAF با دقت جراحی است. به جای حدس زدن دلیل مسدود شدن یک درخواست، آن‌ها می‌توانند دقیقاً تشخیص دهند که محرک مسدودسازی، نسخه TLS بوده، ترتیب مجموعه رمزها یا یک تنظیم خاص در HTTP/2.

کاربران علاقه‌مند می‌توانند پیاده‌سازی کامل و قالب‌های config.yaml را در مخزن گیت‌هاب پروژه بیابند تا تست‌های خود را در محیط‌های مجاز آغاز کنند.

جزئیات پیکربندی و مکانیزم‌ها

برای دستیابی به شبیه‌سازی با دقت بالا، فایل config.yaml اجازه بازنویسی رفتارهای پیش‌فرض را می‌دهد. فیلد listen به صورت پیش‌فرض روی 127.0.0.1:8080 و mgmt_listen برای مدیریت API روی 127.0.0.1:8081 تنظیم شده است.

نگاشت اثرانگشت TLS

در حالت preset: "custom"، پروکسی فیلدهای پیکربندی را مستقیماً به مؤلفه‌های دست‌دادن TLS متصل می‌کند:

• نسخه‌ها: لیست versions (مثلاً ["1.3", "1.2"]) محدوده نسخه‌های اعلام شده را تعیین می‌کند.
• مجموعه رمزها: لیست cipher_suites ترتیب و انتخاب الگوریتم‌ها را کنترل می‌کند. برای پروفایل Chrome 131، این لیست شامل 0x1301 (TLS_AES_128_GCM_SHA256)، 0x1302 (TLS_AES_256_GCM_SHA384) و 0x1303 (TLS_CHACHA20_POLY1305_SHA256) و موارد دیگر است.
• افزونه‌ها: لیست extensions مؤلفه افزونه‌های JA3 را کنترل می‌کند. شناسه‌های کلیدی شامل 0 (server_name)، 10 (supported_groups)، 11 (ec_point_formats)، 16 (ALPN) و 43 (supported_versions) است.
• منحنی‌ها: فیلد curves (مانند X25519Kyber768، X25519، P256) تعیین می‌کند کدام سهم‌های کلید ارسال شوند.

جزئیات اثرانگشت HTTP/2

اثرانگشت‌های HTTP/2 از فریم SETTINGS و مقدار افزایش WINDOW_UPDATE استخراج می‌شوند. پروکسی اجازه می‌دهد تا پروفایل‌های مرورگر خاص را شبیه‌سازی کنید:

• Chrome: تنظیمات 1:65536, 2:0, 4:6291456, 6:262144 با WINDOW_UPDATE مقدار 15663105.
• Firefox: تنظیمات 1:65536, 4:131072, 5:16384 با WINDOW_UPDATE مقدار 12517377.
• Safari: تنظیمات 1:4096, 3:100, 4:2097152, 6:16384 با WINDOW_UPDATE مقدار 10485760.

کنترل‌های افزونه

افزونه کروم بر پایه Manifest V3 یک رابط کاربری برای این تنظیمات پیچیده فراهم می‌کند. علاوه بر دکمه فعال/غیرفعال کردن پروکسی، شامل موارد زیر است:

• منوی کشویی TLS Preset: تغییر سریع بین chrome، firefox، safari، edge، ios، random، golang یا custom.
• فیلدهای سفارشی: هنگام انتخاب "Custom"، رابط کاربری فیلدهایی برای مجموعه رمزها، منحنی‌ها، نسخه‌های TLS و افزونه‌ها را نمایش می‌دهد تا تنظیمات JA3/JA4 در زمان اجرا و بدون ویرایش YAML تغییر کنند.
• بازنویسی هدرها: ورودی مستقیم برای IP کلاینت و User-Agent که سپس به API مدیریتی ارسال (POST) می‌شوند.

معماری پروژه

کدبیس پروژه به گونه‌ای سازماندهی شده که منطق MITM از منطق اثرانگشت‌گیری جدا باشد:

• main.go: نقطه ورود برنامه.
• fp/dialer.go: پیاده‌سازی uTLS dialer برای پیش‌فرض‌های TLS.
• h2fp/conn.go: مدیریت فریم‌ساز HTTP/2 برای کنترل SETTINGS و شبه-هدرها.
• mitm/ca.go: مدیریت تولید و ارائه گواهینامه‌های CA و گواهینامه‌های برگ (Leaf).
• rewrite/headers.go: منطق بازنویسی User-Agent، ترتیب هدرها و جعل IP.
• mgmt/server.go: سرور HTTP API برای به‌روزرسانی تنظیمات در زمان اجرا.

جزئیات پیشرفته افزونه‌های TLS

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

• ID 0: server_name (SNI)
• ID 5: status_request برای OCSP stapling
• ID 11: ec_point_formats (ثابت روی uncompressed/0)
• ID 16: ALPN (اعلام h2 و http/1.1)
• ID 18: signed_certificate_timestamp
• ID 21: Padding به سبک BoringSSL
• ID 23: extended_master_secret
• ID 27: compress_certificate
• ID 28: record_size_limit (ثابت روی 0x4001)
• ID 35: session_ticket
• ID 45: psk_key_exchange_modes (PSK با DHE)
• ID 51: key_share (استفاده از لیست منحنی‌ها برای X25519 و P256)
• ID 17513: application_settings (ALPS) برای h2
• ID 65281: renegotiation_info

مثال‌های API زمان اجرا

API مدیریتی اجازه به‌روزرسانی‌های جراحی را بدون نیاز به ری‌استارت می‌دهد. برای مثال، برای تغییر به اثرانگشت فایرفاکس و جعل یک IP خاص، می‌توان یک درخواست POST به http://127.0.0.1:8081/api/config با بدنه JSON زیر ارسال کرد:
{"tls_preset":"firefox","client_ip":"203.0.113.1","user_agent":""}

برای پیاده‌سازی یک اثرانگشت JA3/JA4 کاملاً سفارشی در زمان اجرا، شیء custom_hello از طریق JSON ارسال می‌شود. یک نمونه بدنه شامل cipher_suites به صورت آرایه‌ای از اعداد صحیح (مثلاً [2570, 4865, 4866, 4867, 49195, 49199, 49196, 49200, 52393, 52392, 49171, 49172, 156, 157, 47, 53])، curves به صورت ["X25519", "P256", "P384"] و extensions به صورت توالی خاصی از شناسه‌ها خواهد بود.

دستورات نصب و ساخت

برای اطمینان از محیط صحیح، کاربران لینوکس باید از نصب Go توزیع‌شده در سیستم اجتناب کنند. مسیر پیشنهادی عبارت است از:
۱. دانلود باینری رسمی: curl -OL https://go.dev/dl/go1.22.5.linux-amd64.tar.gz (یا linux-arm64 برای Raspberry Pi/AWS Graviton).
۲. استخراج در /usr/local: sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz.
۳. به‌روزرسانی PATH: export PATH=$PATH:/usr/local/go/bin.
۴. ساخت پروکسی: git clone https://github.com/ytkoka/impersonate-proxy.git && cd impersonate-proxy && make build.

پیاده‌سازی اعتماد به CA

از آنجایی که پروکسی در اولین اجرا گواهینامه CA تولید می‌کند (مثلاً در تاریخ 2026/04/22 12:00:00 generated CA certificate → ca.crt)، اعتماد باید دستی برقرار شود. در دبیان یا اوبونتو، این کار با کپی گواهینامه به /usr/local/share/ca-certificates/impersonate-proxy.crt و اجرای sudo update-ca-certificates انجام می‌شود. در RHEL، Fedora یا Amazon Linux، گواهینامه در /etc/pki/ca-trust/source/anchors/impersonate-proxy.crt قرار گرفته و سپس sudo update-ca-trust اجرا می‌شود.

برای کاربرانی که نمی‌توانند ذخیره اعتماد سیستم را تغییر دهند، پروکسی امکان ارسال صریح CA را فراهم می‌کند. در curl از فلگ --cacert ca.crt و در Node.js از متغیر محیطی NODE_EXTRA_CA_CERTS برای اشاره به فایل محلی ca.crt استفاده می‌شود.

گام بعدی شما

• اگر از ابزارهای اتوماسیون مثل Playwright استفاده می‌کنید، این پروکسی را در مسیر http://127.0.0.1:8080 قرار دهید تا اثر WAFها را بسنجید.
• برای تأیید صحت اثرانگشت‌های تولید شده، حتماً از سرویس tls.peet.ws استفاده کنید تا خروجی JA3 و JA4 را با مرورگر واقعی مقایسه کنید.
• در صورت استفاده در لینوکس، برای جلوگیری از خطاهای SSL، گواهینامه ca.crt را در سطح سیستم یا اپلیکیشن Trust کنید.

اما این تنها بخشی از نبرد لایه‌های شبکه است؛ برای درک اینکه چگونه پروتکل‌های جدیدتر مثل HTTP/3 این بازی را تغییر می‌دهند، تحلیل ما درباره استانداردهای QUIC را بخوانید.