افزایش پیچیدگی‌های پویش شبکه

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

در این مقاله ما می‌خواهیم به شما سامانه‌ی پنهانی را نشان دهیم که به وسیله‌ی آن بررسی هزاران و شاید میلیون‌ها دستگاه ناآگاه سخت است. ما به شما نشان خواهیم داد که چگونه این سامانه به شکلی مؤثر هر یک از نشانی‌های آی پی دستگاه‌ها را برمی‌دارد و به یک پویش‌گر می‌سپارد که آن نیز در ادامه به پویش‌ درگاه‌ها و وضعیت امنیت قربانیان ناآگاه، از جهت آسیب‌پذیری می‌پردازد.

اولین پرچم قرمز زمانی می‌آید که ما متوجه جریانی ثابت از پویش‌‌های ناخواسته‌ی شبکه می‌شویم که در دستگاه‌های ما رخ می‌دهند.  آنچه از همه گیج‌کننده‌تر بود این واقعیت بود که دستگاه‌هایی که مورد هدف قرار گرفتند دارای آدرس‌های IPv۶ تصادفی بودند که نه در DNS و نه در هیچ رکورد عمومی دیگری منتشر نمی‌شدند.  آن‌ها برای همه‌ی اهداف و نیت‌ها در شبکه آزمایشگاه ما با امنیت کامل، مخفی بودند.

۳۰-InContent

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

چگونه آن‌ها آدرس آی‌پی‌های منتشرنشده را می‌دانستند؟ این آدرس‌ها ۱۲۸ بیت طول دارند که محدوده‌ی وسیعی از اعداد غیر قابل تصور را در بر می‌گیرند.  غیر قابل حدس زدن، تنها راه توصیف آدرس‌های تصادفی مورد استفاده در دستگاه‌ها بوده است.

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

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

پس‌زمینه

اگر شما یکی از میلیون‌ها کاربران سامانه‌های عامل‌ دبیان، اوبونتو و یا Raspbian باشید، و یا از کسانی باشید که دارای کارگزارهایی هستند که این سامانه‌های عامل‌ در آن‌ها اجرا می‌شوند و شما یک نشانی IPv۶ داشته باشید، پس به احتمال زیاد دستگاه شما نیز در حال حاضر پویش‌ شده است. دستگاه‌های ما در شبکه‌ی آزمایشگاهی که مورد هدف قرار گرفته بودند همگی در حال اجرای توزیع Raspbian از سامانه‌ی عامل دبیان لینوکس بودند.

دبیان یکی از توزیع‌ها از سامانه‌ی عامل لینوکس است. این سامانه‌ی عامل برای روی‌کرد حداقلی خود و موفقیت در پشتیبانی از معماری رایانه‌های بر پایه‌ی ARM مشهور است.  این سامانه‌ی عامل بر روی کارگزارهای ابری، مسیریاب‌ها و رایانه‌هایی که به اندازه‌ی کارت‌های اعتباری به تازگی محبوب شده‌اند و Raspberry Pi نام دارند، اجرا می‌شود (آن‌ها نیز Raspberry را اجرا می‌کنند). بسته‌هایی نیز به همراه NTP time daemon عرضه می‌شود که از قبل پیکربندی شده تا به نیاز مجموعه‌ی خاصی از ارائه‌دهندگان پاسخ دهد.

همان‌طوری که ما به تازگی دریافته‌ایم بخش‌های دیگر این مجموعه دارای گردآورنده‌هایی هستند که مجموعه‌ی RedHat NTP را شامل می‌شوند.

از جمع‌آوری تا پویش‌ چه مدت طول می‌کشد؟ 

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

چگونه آن‌ها قادر به دریافت نشانی‌های تصادفی IPv۶ ما هستند؟ 

آیا آن‌ها در DNS ثبت شده‌اند؟ خیر. آیا قابل حدس زدن هستند؟ خیر. نحوه‌ی عمل آن به این شکل است: رایانه‌ی ما یک درخواست عادی به پروتکل زمانی شبکه‌ی NTP برای تنظیم ساعت خود می‌فرستد. در کنار NTP، کارگزار نیز باید نوعی از برنامه یا اسکریپت که آی‌پی بسته‌های ورودی را می‌گیرد، اجرا کند.  اما ما باید پیش‌تر برویم و نیاز داریم تا شرح دهیم که چگونه به این نتیجه رسیده‌ایم.

چقدر استفاده از این NTP معمول است؟ 

امروزه تقریباً هر رایانه‌ی زمان خود را با استاندارد اتمی تنظیم می‌کند.  در اکثر مواقع، یک رایانه از یک NTP استفاده کرده تا ساعت خود را آنچنان که در پیکربندی رایانه تعریف شده است، با کارگزار NTP عمومی هم‌زمان سازی کند.

 نشانی کارگزار NTP برای هر رایانه‌ معمولاً به وسیله‌ی سازنده از قبل پیکربندی شده است و یا در مورد Raspberry Pi، به ایمیج سفت‌افزاری Raspbian تنیده شده است.

 آیا از IPv۶ برای گرفتن زمان NTP در دبیان استفاده می‌شود؟ شما احتمالاً توسط Shodan پویش‌ شده‌اید.

 NTPاز یک مفهوم از مجموعه‌ها یا گروه‌های کارگزار استفاده می‌کند. Ntp.org به گردآوری مجموعه‌های عمومی می‌پردازد و آن را با اسامی نظیر .Debian.pool.ntp.org. در دسترس قرار می‌دهد.

 پویش‌ کردن درگاه یا پورت چیست؟ 

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

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

 آیا این پویش‌ به طور خاص ما را هدف قرار داده است؟ 

خب، البته نه دقیقاً. این پویش‌‌ها، سامانه‌های دبیان را هدف قرار می‌دهند و به طور خاص افراد را هدف قرار نمی‌دهند.

 میلیون‌ها دستگاه از کارگزارهای NTP دبیان استفاده می‌کنند. درصد فزاینده‌ای از این دستگاه‌ها دارای نشانی‌های IPv۶ هستند.

IPv۶ چیست؟ 

پروتکل اینترنتی نسخه‌ی ۶ یا IPv۶ ، آخرین نسخه از پروتکل شبکه است که اطلاعات شما را در سراسر شبکه‌ی خانه یا اداره و یا در کل اینترنت حمل می‌کند.  این یک ارتقاء بسیار مهم برای اینترنت است و موجب می‌شود که دستگاه‌های نامحدود متصل به شبکه بتوانند نسبت به دو دهه‌ی گذشته با سرعت بیشتری به هم‌دیگر متصل شوند.

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

 IPv۶ تعدادی از ویژگی‌های مهم حیاتی را ارائه می‌دهد.  یکی از آن‌ها تصادفی کردن آدرس‌دهی میزبان است که به نام آدرس موقت یا پسوندهای حریم خصوصی شناخته می‌شود.

آدرس‌دهی تصادفی؟ 

این موضوع به «پسوندهای حریم خصوصی» اشاره دارد که وسیله‌ای برای دستگاه‌ها جهت اختصاص دادن یک آدرس آی‌پی است که نیمی از آن پیشوند خانه/ شبکه و نیمی از بیت‌های تصادفی تشکیل شده است. این کار قرار است تا ابزارهایی را ارائه کند که به وسیله‌ی آن‌ها دستگاه‌ها به صورت پنهان، نشانی‌های خود را تقریباً غیر قابل حدس کنند، اما همچنان‌که ما می‌دانیم ایمنی با ابهام، ابداً ایمنی تلقی نمی‌شود. گردانندگان این شبکه‌های پویش‌ از این واقعیت سوءاستفاده می‌کنند که این آدرس‌های حریم خصوصی در هر زمان که دستگاه یک اتصال به خارج انجام می‌دهد (نظیر تنظیم ساعت خود در کارگزارهای NTP) در معرض افشاء قرار می‌گیرد.

اما آیا آدرس‌های موقتی واقعاً امن هستند؟ 

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

آیا Shodan کار ناپسندی انجام می‌دهد؟ 

به نظر می‌رسد که پویش‌ انجام‌شده توسط شیوه‌ی پویش‌ API از سوی Shodan انجام می‌شود. آی‌پی انجام‌دهنده‌ی پویش‌‌ها توسط نام‌های میزبانی شودان ثبت شده است. در زیر چند نمونه قرار داده شده است:

(این‌ها چند نمونه از پویش‌گرهایی هستند که از دیوار آتش ما رد شده‌اند)

۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۹۷۰:a۰۰۱ = thor.scan۶.shodan.io.

۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰fe:d۰۰۱ = gateway.scan۶.shodan.io.

۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰۹۲:۲۰۰۱ = bone.scan۶.shodan.io.

۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰fd:۷۰۰۱ = burger.scan۶.shodan.io.

۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰۸۹:c۰۰۱ = rock.scan۶.shodan.io.

۲۶۰۷:ff۱۰:۰۰c۵:۰۵۰۹:bcde:۰۰d۰:fde۸:e۲۸d = ? Carinet ISP.

این یکی عجیب و غریب است و تنها دو بار دیده شده است.

نشانی‌ها دقیقاً چگونه برداشت می‌شوند؟ 

بنابراین به وضوح مشاهده می‌کنیم که انجام یک هم‌گام‌سازی زمان NTP می‌تواند یک پویش‌ را در بر داشته باشد، اما گردآوری‌کنندگان چگونه می‌توانند اطلاعات آی‌پی ما را دریافت کند؟ آیا آن‌ها را از نگاشته‌های پرونده‌ی NTP برمی‌دارند و یا شاید از نگاشته‌های دیوار آتش؟ به هر حال برای کوتاه‌تر شدن فهرست امکان‌های ممکن، ما تلاش کردیم تا درگاه NTP را به طور مستقیم با استفاده از netcat در برابر گردآورنده‌ی مشهور بررسی کنیم. اما نتیجه؟  پویش‌ صورت گرفت! بنابراین به نظر می‌رسد که حتی یک درخواست NTP واقعی نیاز نیست و ارسال یک بسته‌ی خالی ساده به درگاه ntp گردآورنده نیز برای بررسی‌شدن کافی است. این موضوع احتمال خواندن از یک نگاشته‌ی دیوار آتش، اسکریپت و یا هر ابزار سطح پایین دیگر از سوی گردآوری‌کنندگان آی‌پی را نشان می‌دهد و علاوه بر این نشان می‌دهد که خود برنامه‌ی ntp در کارگزارهای زمان شاید به هیچ روی سفارشی نشده باشد.

ما سعی کردیم یک بسته‌ی خالی را به درگاه ۳۲۱ روی یک کارگزار تحت تأثیر قرار گرفته (۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰d) ارسال کنیم و کاملاً موجب پویش‌ گردید. بنابراین به نظر می‌رسد که گردآوری‌ها کاملاً مستقل از سرویس ntp که روی کارگزارها قرار دارند هستند.

با داده‌های پویش‌‌شده چه می‌توانند بکنند؟ 

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

 پیشرفت جریان تجزیه و تحلیل 

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

آن‌ها از چه روشی برای گردآوری استفاده می‌کنند؟ 

بسیاری از آزمایش‌های ما بر استفاده از کارگزارهای ntp رایگان برای تنظیم زمان و آن‌گاه تجزیه و تحلیل پویش‌‌های انجام شده، متمرکز است.  ما کمی پیش رفتیم و تلاش کردیم تا دریابیم که آیا ترافیک NTP واقعی روی درگاه‌ها نیاز است یا خیر. همان‌طور که معلوم شد، نیازی به آن نیست.  تنها به راحتی با ارسال یک بسته‌ی خالی به پورت ۱۲۳ کافی بود تا پویش‌ را به حرکت وادارد.  بنابراین می‌توان نتیجه گرفت که این احتمال وجود دارد که عملیات گردآوری آی‌پی، برخلاف برخی از نرم‌افزارهای سفارشی شده NTP، به دنبال اهداف خود در سطح بسته‌ها است.  اگر یک اسکریپت Scapy و یا یک اسکریپت نگاشته‌های دیوار آتش در حال اجرا باشد، احتمال جمع‌آوری نشانی‌های آی‌پی اتصال‌های ورودی و عبور دادن آن‌ها به سمت پویش‌گر درگاه‌ها که در جای دیگری قرار دارند، زیادتر خواهد بود.

راه‌اندازی کارگزار آزمایشی 

ما چگونه کارگزار آزمایشی خود را برای استفاده از نشانی‌های منحصر‌به‌فرد IPv۶ هر بار که با گردآوری‌کننده آدرس برای تنظیم زمان ارتباط برقرار می‌کند، پیکربندی کردم؟  این بخش کمی فنی است و ما نمونه‌ی زیر را ارائه می‌کنیم، اما به طور کلی نرخ آدرس‌های تصادفی IPv۶ منقضی‌شده را افزایش دادیم و در نتیجه آن‌ها دوباره تولید و اختصاص داده می‌شدند.  این کار در سامانه‌های عامل‌ لینوکس و مک با انجام تنظیماتی در sysctl کاملاً آسان است. ما به شما توصیه نمی‌کنیم که این تنظیمات را بر روی رایانه‌ی رومیزی خود انجام دهید چرا که ممکن است با آی پی شما با انقضای زمان تغییر یافته و اتصال شما مختل شود.

sysctl.conf

# BH برای آزمایش SLAAC را غیرفعال کنید.

net.ipv۶.conf.all.autoconf=۰

net.ipv۶.conf.default.autoconf=۰

# BH پسوندهای حریم خصوصی، دوباره‌نویسی اعتبار زمانی پیش فرض یک‌روزه‌ی tempaddr با مقدار زمانی بسیار کوچکتر

# این کار کمک می‌کند که به کارگزار آدرس IPv۶ در میان سایرین محدود شویم.

net.ipv۶.conf.all.use_tempaddr=۲

net.ipv۶.conf.default.use_tempaddr=۲

net.ipv۶.conf.eth۰.use_tempaddr=۲

net.ipv۶.conf.all.temp_prefered_lft=۱۲۰۰

net.ipv۶.conf.all.temp_valid_lft=۲۴۰۰

net.ipv۶.conf.default.temp_prefered_lft=۱۲۰۰

net.ipv۶.conf.default.temp_valid_lft=۲۴۰۰

net.ipv۶.conf.eth۰.temp_prefered_lft=۱۲۰۰

net.ipv۶.conf.eth۰.temp_valid_lft=۲۴۰۰

 تنظیمات بالا منجر به این می‌شود که آدرس‌ها منقضی‌ شده و هر ۲۰ دقیقه یک بار تجدید شوند.  این کار درست بالای کم‌ترین مقادیر توصیه‌شده که می‌تواند موجب عمل‌کرد ضعیف پروتکل‌ها شود، قرار دارد.  این نرخ به خوبی موجب می‌شود که آزمایش‌ها هر سی دقیقه یک بار انجام شوند و هر آزمایش دارای IPv۶ منحصربه‌فرد باشد.

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

کدام‌یک از کارگزارهای NTP گردآوری می‌شوند؟ 

به طور پیش‌فرض سامانه‌ای که در حال اجرای دبیان است با پنج مجموعه از آدرس‌های کارگزارهای زمان از پیش پیکربندی شده است: ۰-۳.debian.pool.ntp.org این نام میزبان ۲.debian.poo..ntp.org است که در حال حاضر تعدادی از نشانی‌های IPv۶ را ارائه می‌کند:

$ host ۲.debian.pool.ntp.org

<snip>

۲.debian.pool.ntp.org دارای آدرس IPv۶ ۲۶۰۴: a۸۸۰: ۴۰۰: D۰ :: ۹: B۰۰۲ است

۲.debian.pool.ntp.org دارای آدرس IPv۶ ۲۶۰۴: a۸۸۰: ۴۰۰: D۰ :: ۹: b۰۰e است

۲.debian.pool.ntp.org دارای آدرس IPv۶ ۲۰۰۱: ۴۷۰: e۹۴۹: A :: ۱ است

۲.debian.pool.ntp.org دارای آدرس IPv۶ ۲۶۰۴: a۸۸۰: ۱: ۲۰ :: A۷: f۰۰۴ است

آدرس در f۰۰۴ که آدرس یک دستگاه گردآورنده‌ی شناخته‌شده است خاتمه می‌پذیرد. تعداد بسیار بیشتری از آن‌ها وجود دارد.  در زیر ما چندین مورد دیگر را تأیید کرده‌ایم. ما اسکریپت دیگری را هنگام بحث از هر کدام از آدرس‌های مجموعه اجرا کردیم و درخواست زمان دیگری را دادیم تا ببینم که آیا آن‌ها پویش‌‌ها را تحریک می‌کنند؟

تنها چند آدرس معدود IPv۶ با مراجعه به DNS به این مجموعه برگردانده شدند، اما در کل همه‌ی آن‌ها برگردانده شدند.  به معنای واقعی کلمه، صدها بلکه هزاران آدرس آی‌پی وجود دارند که می‌توانند برگردانده شوند.  این ابزار مؤثری برای توزیع سرویس‌گیرندگان ntp در تعداد زیادی از کارگزارهای موجود است و در شبکه‌سازی کاملاً طبیعی است. با این حال تا حدودی دشوار است که فهرست کاملی از کارگزارهای IPv۶ NTP را به دست آوریم و بنابراین ما می‌توانیم هر کدام را نسبت به رفتار گردآوری آدرس‌ها بررسی کنیم.

 پروتکل NTP عجیب و غریب است. برای خواندن دقیق‌ترین زمان ممکن، از تعدادی از کارگزارهای مختلف بازدید می‌کند تا به تنظیم نهایی ساعت دسترسی پیدا کند. این کار بدان معناست که برای رسیدن به یک دوره‌ی هم‌گام‌سازی ممکن است بیش از ده کارگزار زمانی مختلف را بازدید کند.  این کار موجب خواهد شد که تا حدودی شناسایی کارگزار ntp که به گردآوری آدرس و راه‌اندازی پویش‌ مشغول است، مشکل شود. ما سعی کردیم تمام تلاش خود را برای رفع این چالش با استفاده از طول عمر کوتاه tempaddr و اسکریپت کارآگاهی مناسب خود که کارهای حجیم را راحت کرده است، انجام دهیم.

اسکریپت کارآگاه

ما یک اسکریپت در پایتون به نام detective.py نوشته‌ایم که به ما کمک می‌کند تا برخی از کارهای سنگین و تجزیه و تحلیل نگاشته‌ها را انجام دهیم. این اسکریپت به تجزیه و تحلیل نگاشته‌های دیوار آتش می‌پردازد تا عملیات پویش‌ را کشف کند.  سپس این اسکریپت ویژگی‌ها را از جست‌وجوی‌های اولیه جدا کرده و دومین پرس‌وجو را برای کشف بسته‌های خروجی که به احتمال زیاد دقیقاً موجبات این پویش‌‌ها را فراهم کرده بودند، آغاز می‌کند.

خروجی نرم‌افزار نمونه: 

 SCAN DETECTED: startTime=۲۰۱۶-۰۱-۱۳T۱۹:۳۳:۱۰.۰۰۰+۰۰:۰۰ numPortsScanned=۱۱۷ SRC=۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۹۷۰:a۰۰۱ DST=my:prefix:my:prefix:۷c۰d:e۶cb:۸۷۱۹:۷d۹۴ durationSeconds=۰.۰ startTimeEpoch=۱۴۵۲۷۱۳۵۹۰.۰

یک یا چند مورد از این بسته‌ها ممکن است باعث پویش‌ شده باشند …

 lag=۴۷.۰s @۲۰۱۶-۰۱-۱۳T۱۹:۳۲:۲۵.۰۰۰+۰۰:۰۰ epoch=۱۴۵۲۷۱۳۵۴۵  my:prefix:my:prefix:۷c۰d:e۶cb:۸۷۱۹:۷d۹۴:۴۲۵۳۹ -> ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۷:۱۲۳

 lag=۷.۰s @۲۰۱۶-۰۱-۱۳T۱۹:۳۳:۰۵.۰۰۰+۰۰:۰۰ epoch=۱۴۵۲۷۱۳۵۸۵  my:prefix:my:prefix:۷c۰d:e۶cb:۸۷۱۹:۷d۹۴:۵۹۰۸۱ -> ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۹:۱۲۳

SCAN DETECTED: startTime=۲۰۱۶-۰۱-۱۳T۲۰:۰۱:۱۹.۰۰۰+۰۰:۰۰ numPortsScanned=۱۱۰ SRC=۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰۸۹:c۰۰۱ DST=my:prefix:my:prefix:c۱۰a:acd۰:af۴۰:c۲۵۹ durationSeconds=۰.۰ startTimeEpoch=۱۴۵۲۷۱۵۲۷۹.۰

یک یا چند مورد از این بسته‌ها ممکن است باعث پویش‌ شده باشند …

 lag=۸.۰s @۲۰۱۶-۰۱-۱۳T۲۰:۰۱:۱۳.۰۰۰+۰۰:۰۰ epoch=۱۴۵۲۷۱۵۲۷۳  my:prefix:my:prefix:c۱۰a:acd۰:af۴۰:c۲۵۹:۵۸۴۱۷ -> ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰c:۱۲۳

SCAN DETECTED: startTime=۲۰۱۶-۰۱-۱۳T۱۹:۱۲:۰۲.۰۰۰+۰۰:۰۰ numPortsScanned=۱۱۴ SRC=۲۶۰۴:a۸۸۰:۰۸۰۰:۰۰۱۰:۰۰۰۰:۰۰۰۰:۰۰ba:۴۰۰۱ DST=my:prefix:my:prefix:۹۵b۴:۸۳a۹:۳۱a۷:۰۲e۶ durationSeconds=۰.۰ startTimeEpoch=۱۴۵۲۷۱۲۳۲۲.۰

یک یا چند مورد از این بسته‌ها ممکن است باعث پویش‌ شده باشند …

 lag=۶.۰s @۲۰۱۶-۰۱-۱۳T۱۹:۱۱:۵۸.۰۰۰+۰۰:۰۰ epoch=۱۴۵۲۷۱۲۳۱۸  my:prefix:my:prefix:۹۵b۴:۸۳a۹:۳۱a۷:۰۲e۶:۵۲۳۸۲ -> ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۵:۱۲۳

تأیید هر کدام از گردآورنده‌ها

بعد از استفاده از اسکریپت پایتونی که ما برای دریافت فهرست محتمل گردآورنده‌ها نوشته بودیم، می‌توانستم هر کدام را به صورت جداگانه با درخواست زمان از آن‌ها تأیید کنیم، این کار را با استفاده از ntpdate و بررسی پویش‌ی که بلافاصله پس از آن در اثر تحریک گردآورنده رخ می‌داد انجام دادیم.

علاوه بر این برخی از کدهای bash عمومی را نیز اجرا کردیم تا با دقت هر کدام از مظنونین را زیر نظر گرفته تا در هنگام بررسی با ntp ارتباطی را برقرار نکنند:

 ip۶tables -I OUTPUT -j DROP

 for I in ۰ ۱ ۲ ۳ ۴ ۵ ۶ ۷ ۸ ۹ A B C D E F ; do

 export IPADDR=۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰${I}

 echo Triggering $I

 ip۶tables -I OUTPUT -m state –state NEW ! -d $I -j DROP

 ip۶tables -L OUTPUT -v -n;

 ntpdate $I

 ip۶tables -D OUTPUT ۱

 sleep ۱۲۰۵ # Wait long enough for IPv۶ temp address to refresh

done

که کمک می‌کند تا دسته‌ای از گردآوردنده‌های مظنون را تأیید کنیم.  ما به فهرست زیر رسیدیم:

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۱ (DNS: robot.data.shodan.io)

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۲

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۳

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۴

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۵

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۶

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۷

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۸

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰۹

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰a

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰b

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰c

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰d

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰d

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰e

 ۲۶۰۴:a۸۸۰:۰۴۰۰:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۰۹:b۰۰f

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۱  (DNS: abend.data.shodan.io)

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۲

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۳

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۴

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۵

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۶

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۷

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۸

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰۹

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰a

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰b

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰c

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰d

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰e

 ۲۶۰۴:a۸۸۰:۰۰۰۱:۰۰۲۰:۰۰۰۰:۰۰۰۰:۰۰a۷:f۰۰f

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۱  (DNS: analog.data.shodan.io)

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۲

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۳

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۴

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۵

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۶

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۷

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۸

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰۹

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰a

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰b

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰c

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰d

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰e

 ۲a۰۳:b۰c۰:۰۰۰۳:۰۰d۰:۰۰۰۰:۰۰۰۰:۰۰۱۸:b۰۰f

 تجزیه و تحلیل

گردآورنده‌ها از محدوده‌های آی‌پی Digital Ocean IP استفاده می‌کنند.  Digital Ocean به طور پیش‌فرض droplets را (نام کارگزار و یا سرویس آن) با محدوده‌ی آدرس از ۱-F (شامل ۱۵ آدرس) فراهم می‌کند که کارگزار ممکن است یکی یا همه‌ی آن‌ها را اختصاص دهد.

 هر کدام از ۱۵ بلاک بالا ممکن است یک کارگزار جداگانه در یک منطقه از شبکه متفاوت باشد.

جست‌وجوها در مکان جغرافیایی آی‌پی نشان می‌دهند که کارگزار(های) robot در سان‌فرانسیسکو قرار دارد، کارگزار(های) abend در نیویورک و کارگزارهای analog در فرانکفورت آلمان قرار دارند.

اهداف این پویش‌‌ها چیست؟ 

تا این زمان هنوز مشخص نیست. شما می‌توانید یک کارگزار هانی‌پات راه‌اندازی کرده و یک پویش‌ به راه بیاندازید و ببینید بعد از این‌که یک یا چند خدمات آسیب‌پذیر را کشف کرد، چه اتفاقی می‌افتد.

 این احتمال وجود دارد که نتایج پویش‌ در یک پایگاه داده‌ی عظیم همچون Shodan در جهان IPv۴ ذخیره ‌شوند.

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

چگونه می‌توانیم بگوییم که مورد پویش‌ قرار گرفته‌ایم؟ 

این مطلب بستگی به مواردی دارد، آیا شما دیوار آتش دارید؟ اگر چنین است، امیدواریم که نگاشته‌های بسته‌ها را ثبت کند. معمولاً دو مکان وجود دارند که یک دیوار آتش می‌تواند در آن‌ها نصب شود تا از رایانه محافظت کند: در خود رایانه و یا در درگاه دستگاه مرتبط به آن.  Comcast و دیگر ارائه‌دهندگان اینترنت تنها به‌ طور سخت‌افزاری ورودی‌های IPv۶ مسدود می‌کنند، گواهی می‌کند تا از این نوع حملات محافظت کنند.  شاید شما مجبور باشید که آشکارا اتصالات ورودی در تنظیمات مسیریاب خود را اجازه دهید و یا این‌که از یک دستگاه بدون گواهی‌نامه استفاده کنید که چنین حفاظتی را به طور پیش‌فرض ارائه نمی‌دهد.

 منبع: asis

درباره نماد امنیت وب

“نماد امنیت وب” به عنوان یکی از شرکت های پیشتاز در زمینه امنیت نرم افزار و سرویس های تحت وب، با ارائه سرویس های امنیتی برای تمامی کسب و کار ها و دارای نمایندگی شرکت Acunetix (اکوانتیکس) بعنوان محبوب ترین اسکنر امنیتی black box در دنیا، ایمنی وب سایت شما را در مقابل حمله هکر ها تضمین می کند.

اسکن امنیتی وب سایت
(5000 تومان)

نوع وب سایت: وبلاگ، شرکتی، تجارت الکترونیک و کسب و کارحرفه ای
آسیب پذیری های OWASP (شامل بررسی 10 آسیب پذیری متداول)
اسکن نرم افزار/وب سایت توسط Acunetix نسخه 11
اسکن تمامی پورت ها با ابزار Nmap
اسکن وب سرور و پیکربندی آن توسط ابزار Nikto
اسکن تزریق توسط نرم افزار قدرتمند SQLmap