حفره‌هاي لينوكس سه برابر بيش‌تر از نقايص ويندوز است

بر اساس تحقيقات صورت گرفته توسط دولت آمريكا، كه از سه برابر بيشتر بودن حفره‌هاي امنيتي سيستم‌هاي عامل لينوكس و يونيكس در مقايسه با سيستم عامل ويندوز، سه برابر بيش‌تر هستند كه اين خبر، مورد انتقاد جامعه نرم‌افزارهاي open-source قرار گرفته است. موسسه آمادگي در برابر شرايط اضطراري آمريكا (US-CERT) وابسته به دولت اين كشور، در گزارش جديدي اعلام كرده است كه از ميان تعداد كلي پنج هزار و صد و نود و هشت حفره امنيتي شناسايي شده در سال 2005، دو هزار و سيصد و بيست و هشت حفره امنيتي به كامپيوتر‌هاي مبتني بر لينوكس يا يونيكس، دو هزار و پنجاه و هشت مورد مربوط به كامپيوتر‌هاي چند سيستم عاملي و تنها هشتصد و دوازده مورد مربوط به سيستم عامل ويندوز بوده است. با اين وجود، برخي از كارشناسان كامپيوتري عقيده دارند كه آمار ارايه شده توسط اين موسسه كه در ظاهر از سه برابر آسيب‌پذيرتر بودن لينوكس خبر مي‌دهد، صحت نداشته و كاربران را گمراه مي‌كند. در گزارش موسسه US-CERT، تنها حفره‌هاي امنيتي نسخه‌هاي XP، نود و هشت و NT از سيستم عامل ويندوز شمارش شده و اين درحالي است كه براي ذكر تعداد حفره‌هاي امنيتي لينوكس، تعداد نقص‌هاي اعلام شده، از بررسي صد نسخه‌ي مختلف اين سيستم عامل كه توسط شركت‌هاي مختلف عرضه مي‌شود، به دست آمده است. به گفته منتقدان گزارش اخير، در اين گزارش نقص‌هاي امنيتي مرورگر فايرفاكس نيز به حساب نقايص لينوكس گذاشته شده، درحالي كه مرورگر فايرفاكس در ويندوز نيز مورد استفاده قرار مي‌گيرد و به علاوه، ميزان خطرناك بودن اين ايرادهاي امنيتي مورد توجه قرار نگرفته و تنها به شمارش آن‌ها اكتفا شده است و از سوي ديگر به ميزان حملات اينترنتي صورت گرفته با استفاده از هر كدام از اين حفره‌هاي امنيتي نيز اشاره‌اي نشده است. متخصصان مسايل امنيتي كامپيوتري عقيده دارند با وجود آن كه در ظاهر و با يك شمارش ساده تعداد نقايص امنيتي لينوكس سه برابر بيش‌تر از ويندوز به نظر مي‌رسد، اما نمي‌توان گفت كه كاربران ويندوز در مقايسه با كابران لينوكس از امنيت بيش‌تري برخوردارند. منبع: NewsFactor.com

IIS يا Apache، يك انتخاب

 

 
اينم يه مقاله مفيد

چكيده : 
از زمان ارايه سيستم‌عامل شبكه‌اي ويندوز 0.4NT، وب سرورIIS يكي از اجزاي سيستم‌عامل‌هاي سرور مايكروسافت بوده كه نصب يا عدم نصب آن از طرف كاربر به صورت دلخواه و به راحتي در هر زماني قابل انجام بوده است. به عنوان مثال ويندوز 0.4 NT همراه 4IIS ، ويندوز 2000 همراه 5 IIS و ويندوز XP به همراه 1.5 IIS به بازار ارايه شدند. تا قبل از ويندوز 2003، كليه ويرايش‌ها و نسخه‌هاي مختلف IIS بسيار مشابه هم بودند و مي‌شد آن‌ها را جزء يك خانواده به حساب آورد، اما پس از آن و با به ميان آمدن ويندوز 2003، كه نسخه ششم IIS را به همراه خود داشت، قضيه كاملاً متفاوت شد. در اين نسخه كه مي‌توان آن را يك بازنويسي كامل از وب سرور قديمي دانست، بسياري از مدل‌هاي اجراي كد، تسهيلات مربوط به مديريت و سرعت و كارايي آن، دچار تغييرات و بهبودهاي قابل ملاحظه‌اي شده‌است. از طرف ديگرآپاچي با سابقه‌اي بيشتر كه براساس كدينگ http كار مي‌كرد، همواره به عنوان سمبل وب سرورهاي دنياي يونيكس مطرح بود. نسخه1.3 x آپاچي كه تا سال 2002 مورد استفاده قرار مي‌گرفت، با استفاده از ترفندهاي تكنيكي خاصي برروي ساير سيستم‌عامل‌ها و حتي ويندوز هم قابل نصب و اجرا بود. اما با پيدايش آپاچي نسخه 2، همين معادلات هم دچار تحولي بزرگ گرديد. اين نسخه كه داراي محيطي كاملاً تغيير يافته بوده و توابع درون آن با ظرافت هر چه تمام‌تر استقلال خود را از سيستم‌عامل تثبيت كرده بودند، توانست بر روي كليه سيستم‌عامل‌هاي ويندوز، يونيكس، لينوكس، مكOSX و حتي سيستم‌عامل‌هاي ديگري چونVMS و Be OS نصب و اجرا شود.

مقايسه
در مقام مقايسه IIS و آپاچي مي‌توان گفت كه هر كدام داراي مزايا و معايبي نسبت به يكديگر هستند. IIS فقط براي اجرا در ويندوز ساخته شده ‌است به‌خصوص نسخه ششم آن فقط در ويندوز 2003 قابل‌اجرا مي‌باشد. اگر چه بسياري از كارشناسان، اين مسئله را نوعي نقطه‌ضعف در ساختار IIS مي‌دانند، برخي ديگر هماهنگي بسيار دقيق ميان آن و ويندوز 2003 و سرويس‌هاي ديگر سيستم‌عامل را كه باعث آسان‌تر بودن مديريت IIS شده است، از نقاط برتري آن به حساب مي‌آورند. به‌خصوص در نسخه ششم جدا شدن ماژول مخصوص دريافت درخواست‌ها(Request) از ماژول ويژه پردازش آن‌ها، سهم به‌سزايي در افزايش كارايي آن داشته است. در اين روش ماژول  Listener كه در كرنل مستقر شده است (Http.sys)، درخواست‌هاي ارسالي از طرف كلاينت‌ها را دريافت‌‌‌كرده و آن‌ها را به ترتيب در داخل يك يا چند صف درخواست قرار مي‌دهد. سپس IIS به اين درخواست‌ها با اختصاص حداقل يك پروسه كاري (Worker Process) به هر درخواست، پاسخ مي‌دهد. اين ويژگي باعث مي‌شود حتي زماني كه IIS به شدت مشغول پاسخ‌دهي به درخواست‌هاي قبلي است، ماژول جداگانه‌اي كه در كرنل مستقر است، بتوانند درخواست‌هاي جديد را دريافت كرده و حداقل آن‌ها را در انتظار پاسخ قرار دهند. همچنين با اين وضعيت، سيستم‌عامل مي‌تواند كنترل بهتري را در اختصاص پروسه‌هاي لازم به IIS جهت پردازش درخواست‌ها انجام دهد. در آپاچي هم جريان تا حدودي مشابه همين روال است. در اين جا تعدادي ماژول با قابليت انجام چند پردازش در واحد زمان (Multi Processing module)  وظيفه دريافت و پاسخ به درخواست‌ها را برعهده دارند. اين ماژول‌ها كه با استفاده از تكنولوژي APR يا Apache Portable Runtime برروي بسياري از سيستم‌عامل‌هايي كه از كدهاي كامپايل شده زبان C  پشتيباني مي‌كنند، قابل اجرا هستند، با استفاده از امكانات و قابليت‌هايMultithreading  همان سيستم‌عامل ميزبان به سرعت و به صورت همزمان درخواست‌هاي رسيده از طرف كلاينت‌ها را دريافت و پردازش مي‌كنند.


امنيت

نحوه عملكرد وب سرور

يكي از مزاياي، IIS ارتباط تنگاتنگ موجود بين آن و سيستم‌عامل است. اين عامل سبب مي‌شود تا IIS با توجه به اين‌كه سيستم‌عامل بسياري از موارد امنيتي را قبل از رسيدن درخواست به وب سرور مورد بررسي قرار مي‌دهد و هويت كاربران متصل را ارزيابي (Authentication) مي‌كند، با اطمينان بيشتري به كار خود  ادامه دهد. ضمن اين‌كه مدير سيستم هم به دليل اشتراك روشي كه در تأمين امنيت بين سيستم‌عامل و وب سرور وجود دارد، مجبور به دوباره كاري نمي‌شود. به عنوان مثال اگر شما در اكتيودايركتوري ويندوز 2003 دسترسي به يك يا چند فايل خاص را براي يك گروه از كاربران مجاز و براي گروهي ديگر غيرمجاز تعريف كرده باشيد، اين كاربران از هر روشي كه بخواهند به آن فايل‌ها دسترسي پيدا كنند (حتي از طريق وب سرور) بايد تابع قواعد تنظيم شده در اكتيودايركتوري باشند و اين قوانين در IIS نيز حكمفرما است.
در مورد آپاچي نسخه دوم، مسئله به اين سادگي و رواني نيست و قاعدتاً مديريت امنيت در مورد آن پيچيده‌تر و وقت‌گيرتر از IIS است. البته اكنون ماژول‌ها و آداپتورهاي جديدي در آپاچي تعبيه شده كه امكان ارتباط بين آن و اكتيودايركتوري ويندوز يا  Password يونيكس را به‌وجود مي‌آورد، اما باز هم مي‌توان گفت كه اصولاً با وجود اين ارتباط هم در آپاچي، سيستم‌عامل و وب سرور هر كدام ساز خود را مي‌زنند و آپاچي چندان از قواعد امنيتي تعريف شده در سيستم‌عامل تبعيت نمي‌كند. البته بسياري از طرفداران آپاچي اين مسئله را نوعي نقطه قوت آپاچي دانسته و با ذكر اين نكته كه اولاً هر درخواست از طرف خارج بايد از دو سد محكم سيستم‌عامل و وب سرور عبور كند و ثانياً حفره‌هاي امنيتي در سيستم‌عامل‌هاي يونيكس و آپاچي بسيار كمتر از ويندوز و IIS است، استفاده از آپاچي را از لحاظ امنيتي داراي ريسك كمتري نسبت به IIS مي‌دانند.
از لحاظ پروتكل‌هاي امنيتي، هر دو وب سرور كليه پروتكل‌ها از جمله SSL ،IPsec و مكانيسم‌هاي هويت‌سنجي Basic  Digest  LDAP را پشتيباني مي‌كنند.

كارايي
مقايسه كارايي آپاچي و IIS همواره از مشكل‌ترين بحث‌هاي تكنيكي دنياي وب سرورها بوده است؛ چرا كه اين نوع مقايسه مستلزم به‌وجود آوردن شرايط يكسان آزمايش به صورت منصفانه‌ براي دو طرف رقابت است كه دست يافتن به اين شرايط، كاري آسان و صددرصد قابل انجام نمي‌باشد. شايد به تصور خيلي‌ها مي‌توان زمان دريافت، پردازش و پاسخ هر دو وب سرور به يك صفحه CGI يا JSP (كه مورد پشتيباني هر است) را برروي يك سرور با مشخصات سخت‌افزاري يكسان به معرض آزمون گذاشت، اما اين هم به نمي‌تواند تنهايي پاسخگوي معماي كارايي  باشد. چرا كه اولاً شايد هر دو وب سرور ادعاي بهترين كارايي خود در تكنولوژي مشتركي مثل JSP را نداشته باشند. مثلاً شايد مايكروسافت ASP.NET را كه فعلا در آپاچي پشتيباني نمي‌شود، بهترين عرصه براي نمودار‌شدن كارايي IIS بداند. ثانياًٌ نبايد فراموش كرد كه آپاچي، يك وب سرور چند سكويي مي‌باشد و اين باعث مي‌شود تا صورت مسئله كمي پيچيده‌تر شود و كساني كه مي‌خواهند به داوري مسابقه كارايي اين دو وب سرور بنشينند را با سؤالي جديدتر روبرو كند و آن هم اين است كه IIS ويندوز را با آپاچي كدام سيستم‌عامل مقايسه كنيم ؟ آيا اصولاً آپاچي ادعايي بر ارايه بهترين كيفيت و كارايي خود برروي سيستم‌عامل مشترك ويندوز را دارد يا اين‌كه كماكان به سرعت خود برروي سيستم‌عامل‌هاي يونيكس و لينوكس مي‌بالد؟

نمودار ميزان رشد كاربرد
وب سرورهاي مختلف در ده سال اخير

در IIS 6 وجود مدل‌هاي متعدد پردازشي كه ويژه كار در محيط‌هاي چند پردازنده‌اي در نظر گرفته شده‌اند، سرعت اجراي برنامه‌هاي ASP و يا ISAPI را تا حد بسيار مطلوبي بالا برده‌اند. همچنين درايور HTTP.sys در اين نسخه قادر است به صورت مستقيم به اطلاعات موجود در cache (چه هاردديسك و چه حافظه اصلي) دسترسي پيدا كند بدون آن‌كه نيازمند وجود واسطه‌اي مثل پروسه‌هاي كاري براي انجام اين كار باشد. IIS همچنين قادر است صفحاتي را كه توسط عناصر ديناميك وب به صورت RunTime  ساخته مي‌شوند را در cache ذخيره كند تا در صورتي كه كلاينت‌ بعدي هم بخواهد همين صفحه را توليد كند، به جاي ساختن دوباره آن، از محل cache اطلاعات را بدون پردازش خاصي به سمت كلاينت مذكور بفرستد.
در آپاچي نيز اوضاع به همين گونه است. ماژول‌هاي modperl وmodphp با استفاده از همان مكانيسم cache سرعت توليد صفحات ديناميك را همانند صفحات استاتيك به حداكثر خود مي‌رسانند. همچنين دقيقاً مشابه فيلترهاي ASP و ISAPI در IIS، در اين جا هم ماژول‌هاي Perl  و PHP  مستقيماً درخواست‌هاي كلاينت‌ها را مورد بررسي قرار داده و پاسخ لازم را ارسال مي‌كنند و بدين وسيله از ارجاع درخواست‌ها به محيط خارج آپاچي و كند شدن روند پاسخ جلوگيري مي‌كنند.

مديريت
در مورد مديريت وب سرور، اختلافاتي بين دو وب سرور مذكور وجود دارد. آپاچي در نسخه‌هاي اوليه خود، وب سروري كاملا TextBased به نظر مي‌‌رسيد كه صرفاً با دستكاري مستقيم در فايل‌هاي پيكربندي، تنظيم وب سرور و يا با استفاده از دستورات خط فرمان مديريت آن امكان‌پذير بود. اما اكنون بسياري از واسط كاربرهاي گرافيكي مثل Comanche قادرند يك محيط گرافيكي كاربرپسند و در واقع يك لايه بيروني براي كار با آپاچي فراهم كنند. در اين زمينه ليستي از واسط كاربرهاي گرافيكي تهيه شده در سايت آپاچي به نشاني http://gui.apache.org  موجود و قابل داونلود است. البته بسياري از كاربران وجود مديريت و تنظيمات Text Based را براي آپاچي يك مزيت عنوان مي‌كنند. به عقيده اين افراد، با اين نوع پيكربندي آپاچي مي‌توان به سادگي و صرفاً با كپي كردن چند فايل از كامپيوتري به كامپيوتر ديگر همه تنظيمات يك سرور آپاچي را به سرور ديگر منتقل و از صرف وقت براي تنظيم دستي آن خلا‌ص شد. اين مسئله براي وب سروري مثل IIS كه تنظيمات خود را در قالب فايل‌هاي باينري نگهداري مي‌كند، قابل انجام نيست. البته در IIS 6 تنظيمات وب سرور در قالب فايل‌هاي XML قابل دسترسي است. و بدين‌وسيله و با روش Import و Export مي‌توان تنظيمات يك وب‌‌سرور را به ديگري منتقل كرد. همچنين اينكه علاوه بر اين كار، IIS 6  امكان مديريت راه‌دور را از طريق دستورات خط فرمان و اجراي آن با پروتكل Telnet را مشابه آپاچي به كاربران خود داده است. در ضمن هر دو وب سرور، امكان مديريت از طريق وب را به كاربران داده‌اند. IIS از طريق Web Based Administration و آپاچي با استفاده از ابزاري به نام Webmin اين تسهيلات را مهيا كرده‌اند.

قابليت اطمينان 
IIS 6 با جدا كردن حافظه و محل اجراي برنامه‌هاي وب از يكديگر، باعث شده است در صورت بروز يك مشكل در هر يك از برنامه‌هاي در حال اجرا، اين مشكل به ساير برنامه‌ها و پردازش‌هاي در حال اجرا سرايت نكند. در آپاچي نسخه دوم اين عمل تا حدودي قابل انجام است. بدين‌معني كه اصولاً آپاچي با مكانيسم‌هاي تشخيص و ترميم خطا، از سرايت مشكل به قسمت‌ها و پردازش‌هاي ديگر جلوگيري مي‌كند، اما به طور كلي نمي‌تواند همانند IIS عمل جداسازي برنامه‌ها از يكديگر را انجام دهد و در برخي موارد، بروز يك مشكل در يكي از پردازش‌ها، مدير وب را ناچار به راه‌اندازي مجدد (Restart) وب سرور مي‌كند.
نكته دوم در اين مقايسه هم به نفع IIS تمام مي‌شود. بدين صورت كه در نسخه ششم آن امكان پيكربندي مجدد سيستم حتي در زمان اجراي پردازش‌ها و بدون‌نياز به راه‌اندازي مجدد وب‌سرور امكان‌پذير است. اين امكان كه به آن Live Configuration گفته مي‌شود، سبب مي‌شود مدير سيستم بتواند بدون آن‌كه وب سرور و در نتيجه بسياري از پردازش‌هاي در حال اجرا و درخواست‌هاي در حال پاسخگيري را متوقف كند، تنظيمات IIS را تغيير دهد و وب‌ سرور را Refresh كند. در صورتي كه در آپاچي نسخه دوم، اين عمل بدون بوت كردن مجدد وب سرور ميسر نيست.

Apache 2.1 Alpha
در نسخه 1/2 آپاچي كه نسخه ابتدايي آلفاي آن اكنون قابل دريافت و نصب است، وعده‌هاي بسياري براي افزايش كارايي يا پوشاندن نقاط ضعف نسخه‌هاي قبلي داده شده‌است. بسياري از ماژول‌هاي مربوط به chaching Authn/Authz مورد بازبيني قرار گرفته و  نسبت به نسخه‌هاي سابقشان از كارايي بهتري برخوردارند. پروتكل http  در اين نسخه قادر است فايل‌ها يا درخواست‌هاي با بيش از دو گيگابايت را دريافت و پردازش كند. مكانيسم smart Filtering در آپاچي 1/2 از يك شيوه جديد فيلترگذاري پويا برخوردار است كه باعث مي‌شود تا هر فيلتر براساس نوع درخواست يا پاسخي كه قرار است كنترل شود، فعال يا غيرفعال عمل كند. همچنين در اين نسخه ماژول جديدي براي ثبت كردن خطاهايي كه در ارتباط با كلاينت‌ها رخ مي‌دهد، تعبيه شده است. مديريت حافظه stack براي پردازش‌هاي در حال اجرا تغييريافته و اكنون آپاچي قادر است براساس سكويي كه برروي آن در حال اجرا است، ميزان اين حافظه را افزايش دهد. از لحاظ امنيتي به غير از تغييرات ايجاد شده در ماژول‌هاي مربوط به هويت‌سنجي كه بيشتر باعث افزايش سرعت فرآيندهاي مربوط به آن‌ها شده است، ماژول modssl نيز اكنون با پشتيباني از RFC7182، قادر‌است به جاي برقراري ارتباط به روش متني (chear text)، از روش كدگذاري TLS براي اين كار استفاده كند.

نويسنده : مهيار داعي‌الحق

نخستين سرويس پادكست ايراني توسط "پارسي بلاگ" راه اندازي شد

 

  

سرويس پارسي بلاگ اقدام به ارائه خدماتي نموده كه به سادگي كاربران را قادر به انتشار پادکست شخصي مي سازد.

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

پادكست، شيوه‌اي براي انتشار منظم صوت روي اينترنت است و ترکيبي از فناوري MP3 و مکانيزم RSS در اختيار کاربر قرار مي‌دهد. به همين دليل برخي کارشناسان پادکست را وبلاگ صوتي ناميده‌اند.

اين پديده مانند وبلاگ، ماهيت رسانه اي دارد و با توجه به سهولت دسترسي عموم افراد براي ايجاد پادكست و يا استفاده از آن، مي تواند تحولي چشمگير در عرصه رسانه ايجادكند.

اين شيوه از انتشار گفتار بخصوص در کشورهايي که اينترنت پرسرعت (ADSL) به آساني در دسترس کاربران است، بيشتر طرفدار دارد.

ابزارهائي كه تاكنون براي ايجاد پادكست وجود داشته، به علت پيچيدگي كار و نياز به آشنائي با مسائل فني مربوطه، مورد استقبال عموم قرار نگرفته و اين امر كم وبيش باعث ركود آن شده است.