کتاب های مربوط به packetfence
https://www.dropbox.com/sh/aid06b56mrxjxzm/AACICYQ-l9tEtOmQ5W68Axtca?dl=0
#security #network @unixmens

#packetfense #security @unixmens

PacketFence - Using Statement of Health (SoH) protocol

مقدمه ای بر تست نفوذ و تست نفوذ وب
فرمانده ارشد امنیت اطلاعات (CISO)و مدیر ارشد امنیت (CTO)زمان و هزینه‌های هنگفتی را بر روی اپلیکیشن ها و امنیت کلی فناوری صرف می کنند . این
موضوع شاید فواید زیادی هم برای آنها نداشته باشد و در نهایت با امنیت پایین
روبرو شوند. گرچه طی سال های اخیر امنیت اطلاعات به یک اصل مهم و با
اولویت بالا برای سازمان ها تبدیل شده ولی نفوذهای امنیتی به قدرت خود باقی
است . حملات ایجاد شده بر روی اهداف سازمانی یکی از بزرگترین خرده فروشان در ایالات متحده امریکا موجب شده تا اطلاعات بیش از چهل میلیون کارت اعتباری و جزئیات آن افشا شود که در نتیجه منجر به استعفای CISOو CTOشرکت شده .
حمله بر روی شبکه شرکت پلی استیشن سونی حاصل حملات تزریق اسکیوال
بوده (یکی از رایج ترین حملات اپلیکیشن های وب) که در نتیجه آن شبکه مربوط
بیش از 24روز از سرویس دهی خارج شد! این حمله موجب لو رفتن اطلاعات شخصی بیش از 77میلیون حساب کاربری مشتریان شد. در ادامه آن جزئیات شخصی و رکوردهای مالی در بازارهای سیاه به صورت زیرزمینی به فروش رفته و برای فعالیت های مخرب مورد استفاده قرار گرفت .
حملات زیاد دیگری نیز رخ داده که در اخبار گزارش نشده است
هرچند که شاید اپلیکیشن ها ی وب تنها دلیل رخداد این حملات نبوده اند ولی همیشه به عنوان یک نقش یاری دهنده در کمک به هکرها برای سرقت اطلاعات و ارسال بدافزار بوده است .
تنها وب سرور یا وبسایت مسئول این حملات نبوده اند
. آسیب پذیری های موجود در مرورگر کاربران نیز نقش مهمی داشته است.
یک مثال خوب حمله آرورا(Aurora) بود که در سازمان های بزرگ زیادی مثل گوگل
, ادوبی , یاهو و ... انجام شد. مهاجمین یک آسیب پذیری ساعت صفر Heap Spray
را در مرورگر اینترنت اکسپلورر بکارگیری کردند تا به سیستم های سازمان و دیوایس
های کاربران نهایی دسترسی پیدا کنند . در این مورد خاص آسیب پذیری مرورگر
وب یک فاکتور کلیدی به شمار می رفت.
دلیل دیگر آسیب پذیر بودن اپلیکیشن های وب به حملات این است که پالیسی های امنیت فناوری اطلاعات به صورت واکنشی عمل می کنند در صورتیکه باید به صورت فعال عمل کنند . هرچند که امنیت در حال حرکت به سمت نقطه ایده آل خود می باشد ولی هنوز فاصله زیادی با حالت ایده آل مورد نظر دارد. یک کارمند ناراضی یا یک هکر قبل از اجرای حملات یا سرقت اطلاعات , پالیسی های واکنشی شما را مطالعه نمی کند! پس ایجاد مستندات واقعا خیلی موثر و یاری دهنده نیست
.سیستم های تشخیص و جلوگیری از نفوذ و فایروال ها با حملات جدید نمی توانند مقابله کنند! استفاده از دیوایس های شخصی کارکنان درون سازمان BYOD بسیار افز
ایش یافته و همین موضوع منجر به افزایش سطح حملات شده و موجب بروز مشکلات زیادی برای تیم امنیتی شده است .

هرچند این کارمندان سازمان هستند که می مانند و ما بایستی به عنوان تیم امنیتی خود را با آنها سازگار کنیم. اینترنت شاهد بروز وبسایت ها و اشخاصی (Script Kiddies)شده که هیچ دانشی از علم امنیت ندارند و تنها با ابزارهای ساده ای آشنایی دارند که بعضا آنها را خریداری کرده و شروع به انجام حملات می‌کنند .
توسعه تعداد بیشمار وبسایت ها و ارایه راهکارهای جدید وب همگی موجب ایجادمشکلات جدید امنیتی می شوند . چرا که هرچه تکنولوژی گسترده تر شو
د بایستی به تناسب آن امنیت نیز رشد کند ولی متاسفانه هرگز اینگونه نیست
.سرمایه گذاری های کم و حتی عدم سرمایه گذاری در بازبینی کد و پیدا کردن
باگ ها , عدم درک اهمیت رمزنگاری داده ها بر روی شبکه و ... همگی مشکلات
زیادی را بوجود آورده اند .
اگر به دو مورد از رایج ترین انواع حملات اپلیکیشن های وب دقت کنیم , می بینیم که تزریق اسکیوال (SQL Injection)و حملات اسکریپت نویسی بین سایتی (XSS)موجب شده که ورودی کاربران به درستی بکارگرفته نشود . به همین منظور شما بایستی اپلیکیشن های خود را با راهکارهای فعالانه تری تست کنید . در طی فاز تست , می توانید از ورودی های مختلفی که یک هکر ممکن است بکارگیری کند استفاده کنید. این ورودی ها از طریق فرم های ثبت نام یا ورود به سمت سرور ارسال می شوند .
.این رویکرد خیلی بهتری است تا اینکه صبر کنید و منتظر مانده تا یک نفر
اپلیکیشن شما را بکارگیری کند و به آن نفوذ کند و تازه به فکر ایمن سازی آن
باشید. سیستم های جلوگیری از نفوذ و فایر وال ها هرگز آنقدر هوشمند نیستند
که بتوانند این نوع حملات را مانع شوند . اصلا به این منظور طراحی نشده اند.
شما بایستی اپلیکیشن های خود را درست به نحوی تست کنید که هکر این کار
را انجام می‌دهد .

#security @unixmens

برای مشاوره امنیتی می توانید با @yashar_esmaildokht مکاتبه نمایید .

آموزش تکنولوژی VMware NSX در خصوص مجازی سازی شبکه
زبان : EN
تعداد صفحه :263
#vmware #nsx @unixmens

#jobs #security #hardering @unixmens

منظور از Cloud-init چیست؟
به زبانی ساده cloud-init مجموع ه‏ای از اسکریپت ‏های پایتون برای اجرای سفارشی ‏سازی‏ هایی روی ماشین ‏های مجازی است.
برخی از قابلیت‏ های cloud-init عبارتند از:

setting hostname
ساخت SSH private keys
افزودن کلیدهای SSH
افزودن ephemeral mount points
پیکربندی قسمت‏های شبکه ‏ای
رفتار cloud-init و تغییرات و تنظیماتی که اجرا خواهد کرد از طریق user-data قابل پیکربندی است. user-data یکی از انواع metadata در OpenStack است. به طور کلی چهار نوع metadata در OpenStack وجود دارد که عبارتند از:

Meta-Data, User-Data, Vendor-Data, and Network-Data

که Meta-data به صورت مقادیر key=value هستند که از طریق CLI یا داشبورد می‏توان روی ماشین مجازی تعریف کرد

و Meta-data را می‏توان در زمان بوت ماشین مجازی یا حتی پس از بوت، روی ماشین مجازی تعریف کرد.


اما user-data اسکریپت‏ هایی هستند که می‏توانند به صورت مستقیم تایپ شوند یا به صورت فایلی باشند که هنگام راه‏ اندازی ماشین مجازی توسط cloud-ini استفاده خواهد شد. این اسکریپت ‏ها می‏توانند به زبان‏ هایی مانند پایتون یا shell باشند یا از فرمتی که شبیه به فایل‏های yaml و مختص cloud-config است، استفاده کنند.

در واقع user-data از داخل ماشین مجازی با دستور #curl ۱۶۹,۲۵۴.۱۶۹.۲۵۴/openstack/latest/user_data قابل دسترسی است. می‏توان اسکریپت ‏ها را طوری نوشت که خروجی آن در مسیری در داخل ماشین ‏مجازی نیز ذخیره شود. به صورت پیش‏فرض این اسکریپت ‏ها فقط در اولین بوت ماشین مجازی اجرا می‏شوند، البته راهکارهایی برای اجرای مجدد اسکریپت‏ ها در زمان‏های مختلف از چرخه حیات (lifecycle) ماشین مجازی نیز وجود دارند.

برخی از کاربردهای cloud-init:

تعریف کاربران و گروه‏ها
افزودن یک ریپازیتوری yum
پیکربندی فایل resolv.conf یک ماشین مجازی
نصب و اجرای chef
افزودن ریپازیتوری‏های apt
اجرای دستوراتی در بوت ماشین مجازی
نصب پکیج‏های موردنظر
اجرای upgrade با apt یا yum




اسکریپت ‏های user-data به زبان پایتون در پایگاه‏ داده کد می‏شوند. می‏توان این اسکریپت ‎های کدشده را decode کرد. برای اطلاعات کامل درباره cloud-init می‏توان به سایت رسمی آن مراجعه کرد:

https://cloudinit.readthedocs.io/en/latest/index.html

و metadata با استفاده از neutron metadata agent یا config drive قابل دسترسی هستند. دسترسی از طریق config drive پیچیدگی ‏های دسترسی از طریق neutron metadata agent را ندارد. با استفاده از آپشن config-drive، metadata به صورت یک درایو مجازی نزدیک ماشین مجازی قرار می‏گیرد و قابل mount یا unmount است.
#cloud_init #linux #virtualization @unixmens

آیا می دانید open vswich چیست یا استفاده کرده اید ؟
public poll

اصلا نمی دانم چه چیزی هست – 14
👍👍👍👍👍👍👍 50%
@SoroushFarzamnik1367, @Seyed_hasan_ghasemi, @Dana_am, @eAmirGH, @Amr_2015, @AlirezaGhanbaripour, @srvctl, @amirmohammadKouyeshpour, @Khazaee_Fateme, @Mitiii007, @app_kernel, @arisch_45, @TheGreatLeo, @Alim1396

خیر – 10
👍👍👍👍👍 36%
@Saranipedram, @yousefj86, @Monsieur_ashkan, @Omidabc, @Changizi, @H0ssein05, @Montazeri_fatemeh, @Inject, @esba157, Mohammad

بلی – 4
👍👍 14%
@mshahmalaki, @t_MohammadReza, @JuniorAdmin, Mohammad reza

👥 28 people voted so far.

تهدیدات سایبری #security @unixmens

واژگان امنیتی #security @unixmens

کتاب open vswich : https://www.dropbox.com/s/pt1h5v7k9csyear/openvswitch.epub?dl=0 #network #linux #openvswich #vswich @unixmens

سوئیچ Open vSwitch یا به اختصار OVS یک سوئیچ مجازی چندلایه‌ای است که بسیاری از پروتکل‌ها و واسط‌های شبکه در آن پیاده‌سازی شده است. این سوئیچ که به طور نرم‌افزاری پیاده شده است، یک سوئیچ متن‌باز تحت حمایت Apache License 2.0 بوده و علاوه بر پشتیبانی از پروتکل‌هایی از جمله sFlow، NetFlow، SPAIN، RSPAIN، CLI، LACP و802.1agاز تمامی نسخه‌های پروتکل OpenFlow از 1.0 تا 1.5 نیز پشتیبانی می‌کند.

ویژگی‌های کلی سوئیچ OVS در زیر نشان داده شد است:

Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN, RSPAN, and GRE-tunneled mirrors
LACP (IEEE 802.1AX-2008)
Standard 802.1Q VLAN model with trunking
Multicast snooping
IETF Auto-Attach SPBM and rudimentary required LLDP support
BFD and 802.1ag link monitoring
STP (IEEE 802.1D-1998) and RSTP (IEEE 802.1D-2004)
Fine-grained QoS control
Support for HFSC qdisc
Per VM interface traffic policing
NIC bonding with source-MAC load balancing, active backup, and L4 hashing
OpenFlow protocol support (including many extensions for virtualization)
IPv6 support
Multiple tunneling protocols (GRE, VXLAN, STT, and Geneve, with IPsec support)
Remote configuration protocol with C and Python bindings
Kernel and user-space forwarding engine options
Multi-table forwarding pipeline with flow-caching engine
Forwarding layer abstraction to ease porting to new software and hardware platforms

لازم به ذکر است که در Mininet، از OVS به عنوان سوئیچ مجازی استفاده شده است.



منابع مفید:

https://en.wikipedia.org/wiki/Open_vSwitch

https://openvswitch.org/

شبکه نرم افزاری تعریف شده (Software Defined Networking یا SDN) یک معماری جدید در شبکه است. این معماری دارای ویژگی‌های زیر می‌باشد:

پویا
مدیریت‌پذیر
مقرون به صرفه
انطباق‌پذیر

در این معماری بخش کنترل از بخش داده جدا شده است. در یک معماری SDN/OpenFlow، دو مولفه اصلی وجود دارد:

تجهیزات روانه‌سازی (Forwarding Elements) یا سوئیچ‌های SDN
کنترلرهای SDN

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

یک زیرساخت SDN همانند شبکه‌های سنتی دارای مجموعه‌ای از تجهیزات شبکه (از جمله سوئیچ‌ها،‌ مسیریاب‌ها و جعبه‌های میانی (Middlebox Appliances))می‌باشد. تنها تفاوتی که در این بین وجود دارد، تبدیل تجهیزات فیزیکی سنتی به عناصر ساده روانه‌سازی می‌باشد که این عناصر فاقد بخش کنترلی و یا نرم‌افزاری جهت تصمیم‌گیری‌های خودکار می‌باشد. هوش شبکه از تجهیزات بخش داده به یک سیستم کنترلی به طور منطقی متمرکز انتقال یافته است. این سیستم کنترلی شامل سیستم عامل شبکه و برنامه‌های کاربردی آن می‌باشد. به منظور اطمینان از قابلیت همکاری و سازگاری بین انواع مختلف بخش کنترل و داده، می‌بایست این شبکه‌ها بر روی واسط‌های باز و استانداردی (از جمله OpenFlow) ایجاد شوند. در صورت وجود چنین واسطی، کنترلر قادر به برنامه‌ریزی تجهیزات روانه‌سازی ناهمگون به صورت پویا خواهد بود. این موضوع در شبکه‌های سنتی چالشی اساسی می‌باشد، که دلیل آن استفاده از تجهیزات شرکت‌های مختلف با واسط‌های غیر متن‌باز و بخش کنترلی توزیع‌شده می‌باشد.

یک دستگاه روانه‌سازی مبتنی بر پروتکل OpenFlow دارای خط لوله‌ای از جداول جریان (Flow Tables) است که هر مدخل (Entry) از این جداول شامل سه بخش می‌باشد:

یک قاعده انطباق (Matching Rule)؛
یک اقدام (Action) که برای بسته‌های انطباق‌یافته صورت می‌پذیرد؛
و شمارنده‌هایی که آمار بسته‌های انطباق‌یافته را نگهداری می‌کنند.

این مدل سطح بالا از OpenFlow در حال حاضر در ساخت و پیاده‌سازی بسیاری از دستگاه‌های بخش داده‌ی SDN بکارگرفته شده است.

در یک دستگاه OpenFlow، چگونگی رفتار با یک بسته توسط مجموعه‌ای از جداول جریان (Flow Tables) متوالی مشخص می‌شود. زمانی‌که یک بسته وارد می‌شود، یک فرآیند جستجو از اولین جدول آغاز می‌شود و تا زمانی‌که یک انطباق اتفاق نیفتد (Match) و یا به طور قطع قاعده‌ای برای آن بسته یافت نشود (Miss) این روند ادامه می‌یابد. همان طورکه در شکل ‏فوق نشان داده شده است، یک مدخل جریان می‌تواند به شکل‌های مختلفی تعریف شود. اگر هیچ قاعده‌ی پیش‌فرضی بر روی سوئیچ نصب نشده باشد آن‌گاه بسته دور ریخته خواهد شد. اگرچه به طور متداول، یک قاعده پیش‌فرض بر روی سوئیچ نصب خواهد شد که به سوئیچ دستور می‌دهد تمامی بسته‌های دریافتی را به سمت کنترلر ارسال نماید (و یا به خط لوله معمولی غیر OpenFlow موجود در سوئیچ ارسال کند؛ توضیح این که در سوئیچ‌های هیبرید با استفاده از خط لوله Normal، این قابلیت وجود دارد که به طور پیش‌فرض می‌توان بسته‌ها را بدون استفاده از پروتکل OpenFlow هدایت نمود). الویت‌های این قواعد بر اساس شماره جداول و ترتیب سطرهای جداول جریان می‌باشد؛ یعنی ابتدا قواعد موجود در جدول ۰ و سپس قواعد موجود در جدول ۱ و الی آخر. پس از روی دادن یک انطباق می‌بایست اقداماتی برای آن جریان صورت پذیرد. اقدام‌ها (Actions) شامل موارد زیر می‌باشند:

هدایت بسته به سمت پورت(های) خروجی تعیین شده
کپسوله (Encapsulate) و سپس هدایت کردن بسته به سمت کنترلر
دور ریختن بسته (Drop)
ارسال آن به سمت خط لوله عادی (Normal pipeline)
ارسال آن به جدول جریان بعدی و یا به جداول خاص (مانند جداول گروه (Group Tables) و یا جداول اندازه‌گیری (Metering Tables))

کنترلر SDN

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