پایه و اساس این حمله بر دو موضوع استوار بود؛ نخست آن که در آن زمان، سرورهای DNS برای هر Query که تولید می‌کردند در فیلد Query ID (QID) (یا Transaction ID که از آن برای ره‌گیری queryها و responseهای آن‌ها استفاده می‌شود) مقداری عددی قرار می‌دادند که به‌ازای هر پیام جدید، به این مقدار یک واحد اضافه می‌شد. به بیان دیگر، شماره QIDها یک رشته از اعداد متوالی بودند، پس با به‌دست آوردن یک QID ،QID پیام بعدی به‌راحتی حدس زده می‌شد.
مورد دوم آن‌که DNS از UDP استفاده می‌کرد. به‌همین دلیل، زمان ارسال یک Query روی یک پورت UDP، منتظر دریافت پاسخ مربوط به آن، از روی همان پورت می‌ماند و به‌محض دریافت نخستین پاسخ درست، پاسخ پذیرفته می‌شد و سایر پیام‌ها رد می‌شدند.
مهاجم ابتدا برای به‌دست آوردن QID و شماره پورت، یک Host (تصور کنید یک وب‌سایت جعلی) در DNS server متعلق به خود ایجاد و سپس به‌سمت Recursive Resolver، کوئری را برای دسترسی به این Host ارسال می‌کرد. چون در آن زمان سرورهای DNS، شماره پورتی تصادفی و خالی را در اختیار می‌گرفتند و برای تمام پیام‌های بعدی که قرار بر ارسال آن‌ها بود از همین شماره پورت به‌عنوان شماره پورت مبدا در هِدر پیام UDP استفاده می‌کردند، و از سوی دیگر چون شماره QIDها به‌شکل متوالی افزایش پیدا می‌کردند، مهاجم تنها با شنود ترافیک DNS جاری شده به‌سمت سرور خود می‌توانست به‌راحتی به این دو مورد دست پیدا کند.
مرحله‌ی بعد، سمی کردن رکورد مربوط به Host مورد حمله در DNS سرور Recursive Resolver بود. ابتدا مهاجم با ارسال Query، از Recursive Resolver آدرس IP مربوط به Host مورد نظر را پرس‌وجو می‌کرد. Recursive Resolver نیز برای پیدا کردن آدرس آن Host (البته اگر آن را در Cache خود ذخیره نداشت) به سراغ Root Server می‌رفت. همزمان با این که Recursive Resolver پیام Query را برای یافتن آدرس IP دامنه‌ی مورد نظر برای Root Server ارسال می‌کرد، مهاجم نیز شروع به ارسال پی‌درپی responseهایی با آدرس IP جعلی و QIDهایی در بازه‌ی QID به‌دست آورده، می‌کرد.
نخستین QID که با QID مربوط به Query ارسال شده مطابقت پیدا می‌کرد، Recursive Server همان را به‌عنوان پاسخ درست می‌پذیرفت و در Cache خود ذخیره می‌کرد و حتا اگر پس از آن سرور اصلی مربوط به آن Host نیز، پاسخ درست را ارسال می‌کرد، آن پاسخ دیگر پذیرفته نمی‌شد.
تصویر زیر بیان‌گر اتفاقاتی است که گفته شد.
مورد دوم آن‌که DNS از UDP استفاده می‌کرد. به‌همین دلیل، زمان ارسال یک Query روی یک پورت UDP، منتظر دریافت پاسخ مربوط به آن، از روی همان پورت می‌ماند و به‌محض دریافت نخستین پاسخ درست، پاسخ پذیرفته می‌شد و سایر پیام‌ها رد می‌شدند.
مهاجم ابتدا برای به‌دست آوردن QID و شماره پورت، یک Host (تصور کنید یک وب‌سایت جعلی) در DNS server متعلق به خود ایجاد و سپس به‌سمت Recursive Resolver، کوئری را برای دسترسی به این Host ارسال می‌کرد. چون در آن زمان سرورهای DNS، شماره پورتی تصادفی و خالی را در اختیار می‌گرفتند و برای تمام پیام‌های بعدی که قرار بر ارسال آن‌ها بود از همین شماره پورت به‌عنوان شماره پورت مبدا در هِدر پیام UDP استفاده می‌کردند، و از سوی دیگر چون شماره QIDها به‌شکل متوالی افزایش پیدا می‌کردند، مهاجم تنها با شنود ترافیک DNS جاری شده به‌سمت سرور خود می‌توانست به‌راحتی به این دو مورد دست پیدا کند.
مرحله‌ی بعد، سمی کردن رکورد مربوط به Host مورد حمله در DNS سرور Recursive Resolver بود. ابتدا مهاجم با ارسال Query، از Recursive Resolver آدرس IP مربوط به Host مورد نظر را پرس‌وجو می‌کرد. Recursive Resolver نیز برای پیدا کردن آدرس آن Host (البته اگر آن را در Cache خود ذخیره نداشت) به سراغ Root Server می‌رفت. همزمان با این که Recursive Resolver پیام Query را برای یافتن آدرس IP دامنه‌ی مورد نظر برای Root Server ارسال می‌کرد، مهاجم نیز شروع به ارسال پی‌درپی responseهایی با آدرس IP جعلی و QIDهایی در بازه‌ی QID به‌دست آورده، می‌کرد.
نخستین QID که با QID مربوط به Query ارسال شده مطابقت پیدا می‌کرد، Recursive Server همان را به‌عنوان پاسخ درست می‌پذیرفت و در Cache خود ذخیره می‌کرد و حتا اگر پس از آن سرور اصلی مربوط به آن Host نیز، پاسخ درست را ارسال می‌کرد، آن پاسخ دیگر پذیرفته نمی‌شد.
تصویر زیر بیان‌گر اتفاقاتی است که گفته شد.
شاید این حمله به گفتار ساده باشد اما در حقیقت دارای پیچیدگی‌های بسیاری است:
نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.
این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.
راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.
باگ Kaminsky
در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.
همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.
در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به این ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.
پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، همچنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.
تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.
نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.
این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.
راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.
باگ Kaminsky
در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.
همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.
در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به این ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.
پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، همچنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.
تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.
رییس کمیته پدافند غیرعامل وزارت فاوا:
مانور تست پایداری شبکه ملی اطلاعات برگزار شد
رییس کمیته پدافند غیرعامل وزارت ارتباطات از برگزاری مانور تست پایداری شبکه ملی اطلاعات همزمان با هفته پدافند غیرعامل در شرکت زیرساخت و لایه‌های مختلف خبر داد، اقدامی که به گفته او درصد آمادگی و قابل پیش‌بینی شدن حملات احتمالی را افزایش می‌دهد.
صادق بیک پور با اعلام اینکه اولویت اصلی پدافند غیرعامل در حوزه ارتباطات زیرساخت، توسعه زیرساخت‌ها با رویکرد ملی است، افزود: با توجه به وجود حملات احتمالی در بستر شبکه، این ضرورت احساس می‌شود که تست‌های پایداری شبکه برگزار شود...
#security @unixmens
مانور تست پایداری شبکه ملی اطلاعات برگزار شد
رییس کمیته پدافند غیرعامل وزارت ارتباطات از برگزاری مانور تست پایداری شبکه ملی اطلاعات همزمان با هفته پدافند غیرعامل در شرکت زیرساخت و لایه‌های مختلف خبر داد، اقدامی که به گفته او درصد آمادگی و قابل پیش‌بینی شدن حملات احتمالی را افزایش می‌دهد.
صادق بیک پور با اعلام اینکه اولویت اصلی پدافند غیرعامل در حوزه ارتباطات زیرساخت، توسعه زیرساخت‌ها با رویکرد ملی است، افزود: با توجه به وجود حملات احتمالی در بستر شبکه، این ضرورت احساس می‌شود که تست‌های پایداری شبکه برگزار شود...
#security @unixmens
📊کدام کشورها تا سال 2030، بیشترین تولید ناخالص داخلی را بدلیل تاثیر فناوری 5G در صنعت ساخت خود خواهند داشت؟
🇨🇳چین و 🇺🇸ایالات متحده آمریکا مجموعاً با سهم تقریبی 41 درصد ، بیشترین تولید ناخالص داخلی را خواهند داشت.
🔗منبع: نظرسنجی انجام شده توسط شرکت مشاوره و تحقیقاتی STL Partners از نمایندگان صنایع تولیدی و تلکام 104 کشور در سرتاسر جهان در سال 2019
🇨🇳چین و 🇺🇸ایالات متحده آمریکا مجموعاً با سهم تقریبی 41 درصد ، بیشترین تولید ناخالص داخلی را خواهند داشت.
🔗منبع: نظرسنجی انجام شده توسط شرکت مشاوره و تحقیقاتی STL Partners از نمایندگان صنایع تولیدی و تلکام 104 کشور در سرتاسر جهان در سال 2019
Forwarded from yashar esmaildokht 🐧
جلسه ۴۵۴ - با موضوع چرا پارتیشنینگ در mysql |mariadb - هم بصورت وبینار (آنلاین ) و فیزیکی . https://bit.ly/2CqJkLF
حال با کلودفلر ssl رایگان داشته باشید . Cloudflare, Google Chrome, and Firefox add HTTP/3 support.
zdnet.com/google-amp/article/cloudflare-google-chrome-and-firefox-add-http3-support
zdnet.com/google-amp/article/cloudflare-google-chrome-and-firefox-add-http3-support
yashar esmaildokht 🐧
جلسه ۴۵۴ - با موضوع چرا پارتیشنینگ در mysql |mariadb - هم بصورت وبینار (آنلاین ) و فیزیکی . https://bit.ly/2CqJkLF
امروزه هر کسی با سیستم مدیریت پایگاه داده (dbms) و مفاهیم پایگاه داده درگیر است . از سیستم اتوماسیون اداری گرفته تا وبلاگ و سیستم مهم و حیاتی در بیمارستان و ...
پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است چه راهکارهایی برای افزایش pt را دارا می باشیم . در اینجا بصورت کلی به بررسی این ساختار از محضر پارتیشنینگ خواهیم پرداخت .
نکته : این وبینار و جلسه برای عموم افراد مناسب میباشد . حتی اگر با مفاهیم پایگاه داده بصورت کامل آشنا نباشید .
حال پارتیشن بندی در پایگاه داده به چه معناست ؟
پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است چه راهکارهایی برای افزایش pt را دارا می باشیم . در اینجا بصورت کلی به بررسی این ساختار از محضر پارتیشنینگ خواهیم پرداخت .
نکته : این وبینار و جلسه برای عموم افراد مناسب میباشد . حتی اگر با مفاهیم پایگاه داده بصورت کامل آشنا نباشید .
حال پارتیشن بندی در پایگاه داده به چه معناست ؟
Academy and Foundation unixmens | Your skills, Your future
امروزه هر کسی با سیستم مدیریت پایگاه داده (dbms) و مفاهیم پایگاه داده درگیر است . از سیستم اتوماسیون اداری گرفته تا وبلاگ و سیستم مهم و حیاتی در بیمارستان و ... پس عملکرد و سرعت پایگاه داده بسیار حائز اهمیت است . (performance tuning ) .حال سوال این است…
نحوه مانت کردن به ceph
https://www.howtoforge.com/tutorial/how-to-mount-cephfs-on-centos-7/
#ceph #storage #sds @unixmens
https://www.howtoforge.com/tutorial/how-to-mount-cephfs-on-centos-7/
#ceph #storage #sds @unixmens
HowtoForge
How to Mount CephFS on CentOS 7
I will show you how to mount Ceph as a File System on CentOS 7 in this third part of the Ceph tutorial series. Ceph is an open source storage platform...
✅ #برترین_پیش_بینی_های_گارتنر از برترین فناوری های IT و چالش های پیش رو از سال 2020 به بعد در مهمترین گردهمایی_جهانی_سالانه_گارتنر در ماه اکتبر امسال در اورلاندو آمریکا با حضور بیش از بیست هزار مدیر ارشد IT – بخش اول
1️⃣افزایش 💥سه برابری💥 معلولان شاغل در حوزه های مختلف کاری به دلیل پیشرفت هوش مصنوعی(AI)، واقعیت افزوده (AR) ، واقعیت مجازی (VR) و سایر فناوری های های نوظهور و کاهش موانع فعالیت های کاری تا سال 2023
👇👇👇
👌در نتیجه این رویکرد، سازمانهایی که افراد دارای معلولیت را استخدام می کنند نه تنها حسن نیت خود را در جامعه گسترش می دهند ، بلکه نرخ افزایش 89 درصدی حفظ نیروی کار ، 72 درصدی بهره وری کارمندان و 29 درصدی افزایش سودآوری را تجربه خواهند کرد.
1️⃣افزایش 💥سه برابری💥 معلولان شاغل در حوزه های مختلف کاری به دلیل پیشرفت هوش مصنوعی(AI)، واقعیت افزوده (AR) ، واقعیت مجازی (VR) و سایر فناوری های های نوظهور و کاهش موانع فعالیت های کاری تا سال 2023
👇👇👇
👌در نتیجه این رویکرد، سازمانهایی که افراد دارای معلولیت را استخدام می کنند نه تنها حسن نیت خود را در جامعه گسترش می دهند ، بلکه نرخ افزایش 89 درصدی حفظ نیروی کار ، 72 درصدی بهره وری کارمندان و 29 درصدی افزایش سودآوری را تجربه خواهند کرد.
#برترین_پیش_بینی_های_گارتنر-بخش سوم
🔵تا سال 2023 ، 30 درصد سازمانهای IT ، سیاست های BYOD (استفاده از دیوایس های شخصی در محیط کار) خود را به منظور تقویت نیروی انسانی و افزایش بهره وری و ایمنی محیط کاری گسترش می دهند.
☑️این افزایش به دلیل پیشرفت در تکنولوژی گجت های پوشیدنی wearable (مانند ساعت های هوشمند، دستبندهای سلامتی و غیره) در اکثر صنایع از جمله صنایع خودرو ، نفت و گاز ، خرده فروشی و پزشکی مشهود خواهد بود.
🔵تا سال 2023 ، 30 درصد سازمانهای IT ، سیاست های BYOD (استفاده از دیوایس های شخصی در محیط کار) خود را به منظور تقویت نیروی انسانی و افزایش بهره وری و ایمنی محیط کاری گسترش می دهند.
☑️این افزایش به دلیل پیشرفت در تکنولوژی گجت های پوشیدنی wearable (مانند ساعت های هوشمند، دستبندهای سلامتی و غیره) در اکثر صنایع از جمله صنایع خودرو ، نفت و گاز ، خرده فروشی و پزشکی مشهود خواهد بود.
📸 درصد نفوذ اینترنت در مناطق مختلف جهان
🔹 ۴.۳۸۸ میلیارد نفرد در جهان از اینترنت استفاده می‌کنند (۵۷ درصد).
🔹آمریکای شمالی و اروپا با ۹۵ درصد بیشترین نفوذ اینترنت در جهان را دارند. در مقابل آفریقای مرکزی با ۱۲ درصد، کمترین نفوذ اینترنت را در بین مناطق جهان دارا میباشد.
🔹ضریب نفوذ اینترنت کشورمان با ۹۰ درصد، بالاتر از میانگین جهانی است. ➖➖➖➖➖
🌐 @unixmens
🔹 ۴.۳۸۸ میلیارد نفرد در جهان از اینترنت استفاده می‌کنند (۵۷ درصد).
🔹آمریکای شمالی و اروپا با ۹۵ درصد بیشترین نفوذ اینترنت در جهان را دارند. در مقابل آفریقای مرکزی با ۱۲ درصد، کمترین نفوذ اینترنت را در بین مناطق جهان دارا میباشد.
🔹ضریب نفوذ اینترنت کشورمان با ۹۰ درصد، بالاتر از میانگین جهانی است. ➖➖➖➖➖
🌐 @unixmens