debugfs برای ext3 و ext4 به شما کمکی نخواهد کرد. برای بازیابی اطلاعات فایل های خود در لینوکس با فایل سیستم ext3 و ext4 یکی از بهترین ابزارها extundelete می باشد. این ابزار فعلا در مخازن استاندارد وجود ندارد ولی به راحتی در خانواده دبیان می توانید آن را نصب و راه اندازی کنید. بعد از اینکه سورس برنامه را دانلود کردید نیاز دارید آن را کامپایل و سپس با کمی حوصله و مطالعه از آن استفاده کنید. برای کامپایل به هدرهای e2fsprogs و e2fslibs نیاز دارید. همچنین اگر پیش از این برنامه ای را از سورس کامپایل نکردید می بایست پیشنیازهای gcc را هم نصب کنید. به ترتیب این مراحل را نیاز خواهید داشت:

$ su -
# apt-get install build-essential
# apt-get install checkinstall
# apt-get install fsprogs
# apt-get install fslibs e2fslibs-dev

root@mira:/opt# cd extundelete-0.1.8/
root@mira:/opt/extundelete-0.1.8# cd src/
root@mira:/opt/extundelete-0.1.8/src# make

بعد از اینکه extundelete نصب شد می توانید با استفاده از راهنمای Recognized options of extundelete 0.1.8 به عملیات پر خیر و برکت بازیابی بپردازید. در حالت پیش فرض فایل هایی را که بازیابی کرده است در پوشه ای به اسم RECOVERED_FILES بازیابی می کند. اگر فایل را قدیم تر پاک کرده باشید و نتواند نام اصلی را بازیابی کند از inodeکد استفاده می کند. سعی کنید اگر فایل مهمی را پاک کرده اید و می خواهید بازیابی انجام دهید در کمترین زمان ممکن و بدون فعالیت اضافه ای این کار را انجام دهید. بدیهی است این روش ها هیچ ضمانت اجرایی ندارد و هرآنچه انجام می دهید به مسولیت خود شماست.

Tunneling with Free BSD

When talking about tunneling, different definitions come to people’s minds. Basically, tunneling is transmitting data that is encapsulated into a pipe, over a public network (for example, the Internet). However, there are different methods to tunnel data over a public network for different approaches. For example, when security is a concern, tunnel protocols with cryptography are more favorable. But when performance has higher priority, protocols with lower packet overheads will be chosen. FreeBSD 7 has a built-in support for a number of important tunneling protocols, although there are also many third-party applications in FreeBSD packages that support more tunneling protocols.

شرکت سان میکروسیستمز با اعلام توسعه OpenSparc امکان فعالیت بیشتری برای علاقه مندان به معماری CPUها و
به خصوص آشنایی بیشتری با ساختار خانواده  SPARC را فراهم کرده است. با پیشرفت خوب این پروژه و اعلام آماده شدن Niagara II، اهداف این پروژه به واقعی تر شدن نزدیک می شود. برای یک مرور کلی مراجعه کنید به مطلب زیر:

Technical
look at Niagara II

The gross overview is eight in-order
cores on a die, each capable of running multiple threads, same as Niagara (N1).
Niagara 2 (N2) does quite a lot more, it executes two groups of four threads per
core instead of four, and pulls large chunks of the north bridge on board.

In terms of raw die size, it hasn’t changed all that much, Niagara was 378 mm^2
and Niagara 2 is 342 mm^2. Once you factor in that Niagara the elder was on a
90nm process and Niagara 2 is 65, you can see that the new chip would be about
twice as big on a similar process. It also runs at a similar speed, 1.2 and
1.4GHz are the launch fequencies.

چند مقایسه هم بین محصولات
Sun، IBM،
Dell و HP را در
اینجا
بخوانید. بر طبق پیشبینی ها محصولات خانواده Niagara II
با ۸هسته و مجموع ۲۰۴۸ thread قابل اجرا به زودی در
دسترس خواهند بود:
Sun
preps 2048-thread monster

پایداری بسیاری از کسب و کارها به سرویس دهی و امنیت مناسب مرکز داده مورد استفاده بستگی دارد. ساختار فیزیکی دیتا سنترها شامل تجهیزات حیاتی مختلف، از تولید کنندگان مختلفی است. تجهیزاتی مانند روترها، سوییچ ها، PDUها، UPSها، تابلوهای برق، رک ها، تجهیزات امنیت فیزیکی، واحدهای تهویه (CRAC)، ژنراتورها و دوربین های حفاظتی هر کدام از چندین تولید کننده و با استاندارد های مختلفی هستند، مدیریت این ساختار پیچیده، نیاز به سیستمی دارد که بتواند با تولید کننده های مختلف ارتباط برقرار کند و برعکس ساختار پیچیده، مدیریت و مانیتورینگ را آسان کند. ۱۰ مورد زیر برای انتخاب راه حل های مانیتورنیگ مراکز داده می تواند مورد استفاده قرار بگیرد:

۱- هزینه عدم استفاده از سیستم مانیتورینگ را محاسبه کنید.

سیستم های مانیتورینگ مراکز داده می توانند گران قیمت باشند، اما هزینه سربار وقفه در سرویس دهی (Downtime) ممکن است هزینه بیشتری برای کسب و کار شما ایجاد کند. با تهیه هزینه خسارت های احتمالی در حالت بروز مشکل (با در نظر گرفتن هزینه های پنهانی مانند سخت افزار و تغییر ساختار) و همینطور هزینه یک سیستم مانیتورینگ می توانید تصمیم گیری موفق تری داشته باشید. همچنین دقت کنید سیستم های مانیتورینگ و تاثیر آن در کاهش هزینه، از عوامل مهم محاسبه ROI شما خواهد بود.

۲- لیست تمامی تجهیزاتی که می بایست کنترل شوند، را تهیه کنید.

البته حتما چنین لیستی از قبل تهیه کرده اید! این لیست برای دسته بندی محصولات موجود و انتخاب سیستم موثر بسیار کاربردی خواهد بود. بخش های مختلف این لیست می تواند شامل نام، مدل، تولیدکننده، سال تولید، نسخه نرم افزار، پروتکل های مورد پشتیبانی، امکان استفاده از API، امکان به روز رسانی، … باشد.

۳- راه حلی را انتخاب کنید که، دارای رابط گزارش دهی/گیری گرافیکی باشد.

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

۴- به دنبال یک معماری قابل توسعه باشید.

گسترش ساختار مورد استفاده (چه در بعد فیزیکی و چه در بعد ارتباطی) نیاز رعایت توسعه پذیری در آینده سیستم را مورد توجه قرار می دهد. این معماری علاوه بر توسعه پذیری در ابعاد کمی، می بایست قابلیت توسعه برای تطبیق با نرم افزارهای موجود را داشته باشد. به عنوان مثال یکپارچه سازی با CRM و یا قابلیت اتصال اطلاعات برای Helpdesk.

5- راه حلی را انتخاب کنید که از تمامی تجهیزات شما، پشتیبانی کند.

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

۶- برای استفاده از راه حل نرم افزاری و یا سخت افزاری تصمیم گیری کنید.

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

۷- راه حل هوشمندی را انتخاب کنید که قابلیت پردازش اعلان خطر (Alarm Processing) را داشته باشد.

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

۸- به دنبال پشتیبانی از پروتکل های مختلف باشید.

به علت ساده بودن پیاده سازی سیستم های تک پروتکل، تعداد این سیستم ها تا حدودی زیاد است. بهتر است برای یکپارچگی سیستم، از چندین پروتکل پشتیبانی انجام شود. به عنوان مثال تجهیزات الکترونیکی شما احتمالا از SNMP استفاده می کنند و ژنراتورها از Modbus استفاده می کنند.

۹- سعی کنید تمامی نیازهای منحصربفرد خود را پوشش دهید.

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

۱۰- پیش از تصمیم گیری به صورت آزمایشی از سیستم انتخابی استفاده کنید.

سیستم شما، بدون آزمایش ریسک بالایی برای کسب و کار شما خواهد داشت. اگر سیستم انتخابی نسخه آزمایشی ندارد، کمی در تصمیم گیری خود بیشتر تامل کنید.

یک distributed IDS به سازمان ها و اپراتورهای شبکه اجازه می دهد تا به صورت موثر و مستند منابع شبکه ای و سازمانی خود را تحت کنترل قرار دهند و در صورت نیاز به سرعت اطلاعات مورد نیاز را از سیستم بیرون بکشند. برای آشنایی بیشتر مقاله زیر را بخوانید:

An Introduction To Distributed Intrusion Detection Systems

Due to the greater view the agent allows the analyst to achieve, the dIDS offers the incident analyst many advantages over other single mode IDS systems. One of these advantages is the ability to detect attack patterns across an entire corporate network, with geographic locations separating segments by time zones or even continents. This could allow for the early detection of a well-planned and coordinated attack against the organization in question, which would allow the security people to ensure that targeted systems are secured and offending IPs are disallowed any access. Another proven advantage is to allow early detection of an Internet worm making its way through a corporate network. This information could then be used to identify and clean systems that have been infected by the worm, and prevent further spread of the worm into the network, therefore lowering any financial losses that would otherwise have been incurred.

تبادل اطلاعات بین IDS ها در سه گونه تقسیم بندی می شود. دسته اول محصولاتی که برای dIDS طراحی شده اند و با استفاده agentهای مختلف در نقاط مختلف شبکه اطلاعات را برای سرور کنترلی IDS ارسال می کنند. دسته دوم محصولاتی که شامل IDS هایی از یک دسته هستند و لاگ فایل های خود را در یک محل متمرکز ذخیره می کنند و مانند دسته اول ادامه کار می دهند. و بالاخره دسته سوم که شامل IDS ها و IPS های (به طور کلی آن ها را sensor خطاب می کنیم.) مختلف از مارک های متفاوتی هستند که به وسیله ابزار های مدیریت سیستم های امنیتی لاگ فایل ها را ذخیره و پردازش می کنند. استاندارد تبادل اطلاعات در سنسور ها، در قالب یک پیش نویس استاندارد IETF در حال شکل گیری است.

The Intrusion Detection Message Exchange Format (IDMEF) is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they deem suspicious. The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.

به دو علت پروژه های کمی در مورد dIDS هم اکنون وجود دارد. اولین مورد عدم درک نیاز به چنین سیستمی در بخش تجاری و صنعتی و دلیل دوم نو بودن چنین ترکیبی است. همانطور که پیشتر گفتم، IDMEF هنوز به حالت استاندارد در نیامده است. البته جایگزینی این سیستم به وسیله سیستم های یکپارچه مدیریت امنیت گران قیمت نیز دلیل دیگری در کم بودن پروژه ها است. تعدادی از این پروژه ها را در freshmeat ببینید. بدنیست نگاهی هم به پروژه رو به پیشرفت Prelude Hybrid IDS ( حداقل What is Prelude Hybrid IDS را بخوانید.) بندازید.

* این مطلب مقدمه ای است برای سری نوشته های امنیت در عمق که در Secure2S بیشتر در مورد آن ها خواهید خواند. لطفا نظرات و پیشنهادات خود را در میان بگذارید. مجموعه نوشته های امنیت در عمق، تلاش خواهد کرد تا به امنیت در شبکه های بزرگ و تجاری و همچنین نکات امنیتی که کمتر به آن ها پرداخته می شود بپردازد.

وب سایت WBG Liks که مدتی است دیگر وجود ندارد! برای بسیاری از قدیمی های دنیای زیرزمینی آشناست. مجموعه جملاتی که در بالای وب سایت نمایش داده می شد، برگزیده ای از زیباترین ها در حوزه کامپیوتر و بیشتر با طعم یونیکس بود.

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