سیستم های عامل در معرض تهدید
تقریبا” تمامی سیستم های یونیکس و لینوکس بهمراه یک نسخه از NFS و NIS ارائه می گردند. سرویس های فوق،  بصورت پیش فرض فعال می باشند .

نحوه تشخیص آسیب پذیری سیستم
بمنظور تشخیص آسیب پدیری سیستم در رابطه با سرویس های NIS و NFS موارد زیر پیشنهاد می گردد :

• بررسی و اطمینان از نصب آخرین Patch ارائه شده توسط تولید کننده . تمامی نسخه هائی که بهنگام نشده و یا آخرین Patch موجود بر روی آنان نصب نشده باشد در معرض تهدید و آسیب قرار خواهند داشت . در اکثر نسخه ها  با استفاده از دستور rpc.mountd -version  می توان از شماره نسخه NFS  نصب شده آگاهی یافت . بمنظور آگاهی از شماره نسخه NIS  می توان از دستور  ypserv -version   استفاده نمود ( دستور فوق شماره نسخه NFS را نیز نمایش خواهد داد ) .
• بمنظور تشخیص آسیب پذیری نرم افزار، می توان  از یک پویشگر نقاط آسیب پذیر بهنگام شده بصورت مستمر استفاده تا بررسی لازم در خصوص ضعف های جدید صورت پذیرد.

بمنظور برخورد با عدم پیکربندی مناسب NIS موارد زیر پیشنهاد می گردد :

• اطمینان از عدم نگهداری Root Password در یک NIS map
• سازگاری رمزهای عبور تعریف شده با سیاست های امنیتی موجود. در این راستا می توان از یک برنامه Cracker  بمنظور بررسی استحکام رمزهای عبور تعریف شده،استفاده نمود.

بمنظور برخورد با عدم پیکربندی مناسب NFS موارد زیر پیشنهاد می گردد :

• بررس لازم در خصوص بهنگام بودن میزبانان ، netgroups و مجوزها در فایل etc \ exports \ .
• اجرای دستور Showmount e بمنظور مشاهده عناصر export شده و بررسی سازگاری آنان با سیاست های امنیتی .

نحوه حفاظت در مقابل نقطه آسیب پذیر
موارد زیر در ارتباط با پیکربندی NIS ، پیشنهاد می گردد:

• مشخص نمودن صریح سرویس دهندگان NIS  بر روی سرویس گیرندگان ( پیشگیری لازم در خصوص  تظاهر سایر سیستم ها بعنوان یک سرویس دهنده NIS ) .
• در زمان ایجاد فایل های DBM ، ویژگی YP_SECURE  فعال گردد . بدین ترتیب ،سرویس دهنده صرفا” به درخواست های ارسالی توسط یک سرویس گیرنده و از طریق پورت های مجاز ، پاسخ خواهد بود . در این رابطه می توان از سوئئچ S بهمراه دستور makedbm استفاده نمود .
• درج میزبانان مورداعتماد و شبکه ها در var/yp/securenets / که توسط پردازه های  ypserv و  ypxfrd  استفاده می گردد.
• درج    ::: ۰:۰ : * :+   در password map بر روی سرویس گیرندگان NFS

موارد  زیر در ارتباط با پیکربندی NFS  پیشنهاد می گردد:

• استفاده از آدرس های عددی IP و یا FQDN) fully qualified domain names)  در مقابل اسامی مستعار (زمانیکه به سرویس گیرندگان در فایل etc / exports اجازه داده می شود) .

• بمنظوربررسی پیکربندی سیستم می توان از برنامه ای با نام NFSBug ، استفاده نمود.برنامه فوق امکانات متنوعی را بمنظور تست پیکربندی سیستم ارائه می نماید . برای دریافت برنامه NFSBug ، می توان از آدرس ftp://coast.cs.purdue.edu/pub/tools/unix/nfsbug استفاده نمود .

• اسفاده از فایل etc\exports بمنظور اعمال محدودیت در رابطه با دستیابی به سیستم فایل NFS با افزودن  پارامترهای زیر :
  - ممانعت کاربران معمولی از mounting یک سیستم فایل NFS با افزودن یک پارامتر ایمن پس از آدرس IP و یا نام Domain مربوط به سرویس گیرنده NFS .
  مثلا” : ( home 10.20.1.25(secure /
  - export نمودن سیستم فایل NFS با مجوزهای مناسب .عملیات فوق را می توان با افزودن مجوزهای لازم ( ro برای فقط خواندنی و یا rw برای خواندن و نوشتن ) پس از آدرس IP مربوط به نام domain  سرویس گیرنده NFS  در فایل etc\export  انجام داد.
  مثلا” : ( home 10.20.1.25(ro /  .
  - در صورت امکان ، از پارامتر root_squash  بعد از آدرس IP و نام Domain مربوط به سرویس گیرنده NFS استفاده گردد . در صورتیکه پارامتر فوق فعال شده باشد ،  superuser ID root  بر روی سرویس گیرنده NFS با کاربر ID nobody  در سرویس دهنده NFS جایگزین می گردد. بدین ترتیب root user  بر روی سرویس گیرنده ، قادر به دستیابی و یا تغییر فایل ها  بر روی root نخواهند بود.
  مثلا” : ( home 10.20.1.25(root_squash / .

• بر روی سیستم عامل سولاریس ، مانیتورینگ پورت فعال گردد. عملیات فوق را می توان با افزودن  Line set nfssrv:nfs_portmon = 1  در فایل etc/system / ، انجام داد .

موارد زیر در  ارتباط با NFS و NIS  پیشنهاد می گردد :

• بازنگری و بررسی  سیاست های فایروال بمنظور اطمینان از بلاک شدن تمامی پورت های غیر ضروری(  مثلا” پورت ۱۱۱ ( portmap ) و پورت ۲۰۴۹ ( Rpc.nfsd ) ) .امکان دستیابی به سرویس دهندگان NFS و NIS ، می بایست صرفا” از طریق سرویس گیرندگان مجاز انجام شود.

• بررسی لازم در خصوص استفاده از NFS بر روی یک پروتکل ایمن نظیر SSH . در این رابطه می توان از آدرس  http://www.math.ualberta.ca/imaging/snfs/ استفاده نمود .

• نصب تمامی patch های ارائه شده توسط تولید کنندگان و یا ارتقاء  سرویس دهندگان NIS و  NFS به آخرین نسخه موجود. برای آگاهی از اطلاعات  مربوط به نصب و  پیکربندی یونیکس با لحاظ نمودن مسائل امنیتی مضاعف ، می توان از آدرس UNIX Security Checklist استفاده نمود.

• غیر فعال نمودن NFS و NIS مربوط به deamons بر روی سیستم هائی که مختص یک سرویس دهنده NFS و یا NIS طراحی و تائید نشده اند . بمنظور پیشگیری لازم در اینخصوص می توان سرویس های  NIS و یا NFS ( و یا هر دو آنان ) را  از روی سیستم حذف نمود.

دهمین نقطه آسیب پذیر : ( Open Secure Sockets Layer (SSL
کتابخانه OpenSSL ( بصورت Open source است ) ، نرم افزاری رایج  بمنظور افزدون امنیت رمزنگاری به برنامه ها ئی است که از طریق شبکه با یکدیگر ارتباط برقرار می نمایند .سرویس دهنده  آپاچی ، مهمترین وشناخته ترین برنامه استفاده کننده از  پکیج فوق می باشد ( بمنظور حمایـت از  hhtps ، ارتباط بر روی پورت ۴۴۳ ) . برنامه های متعدد دیگر با انجام برخی تغییرات ، استفاده از  OpenSSL بمنظور افزایش امنیـت اطلاعات مبادله شده در یک شبکه را در دستور کار خود قرار داده اند .
برنامه های متعددی بمنظور ارائه امنیت رمزنگاری در ارتباط با یک Connection از OpenSSL استفاده می نمایند . مهاجمان در اغلب موارد در مقابل هدف قرار دادن مستقیم OpenSSL ، برنامه هائی را برای حملات خود انتخاب می نمایند که از OpenSSL  استفاده می نمایند . یکی از اهداف مهاجمین در این رابطه ، سرویس دهنده آپاچی است که از OpenSSL استفاده می نماید . برنامه هائی دیگر نظیر: mail ، openldap,CUPS     که از OpenSSL استفاده می نمایند نیز در معرض تهاجم قرار خواهند داشت .
OpenSSL دارای نقاط آسیب پذیر متعددی بوده که می توان به چهار نمونه مهم آنان اشاره نمود :   مورد اول ، مورد دوم ، مورد سوم ، مورد چهارم . مهاجمان با  استفاده از نقاط آسیب پذیر فوق، قادر به اجرای کد دلخواه بعنوان کاربر کتابخانه OpenSSL می باشند.

سیستم های عامل در معرض تهدید
هر یک از سیستم های یونیکس و یا لینوکس که بر روی آنان نخسه OpenSSL 0.9.7 و یا  قبل از آن اجراء می گردد، در معرض این آسیب قرار خواهند داشت .

نحوه تشخیص آسیب پذیری سیستم
در صورتیکه نسخه version 0.9.7a و یا قبل از آن  نصب شده باشد ، سیستم در معرض تهدید و آسیب قرار خواهد داشت . در این رابطه می توان از دستور OpenSSL version ، بمنظور آگاهی از شماره نسخه نرم افزار نصب شده ، استفاده نمود.

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت در مقابل نقطه آسیب پذیر فوق ، موارد زیر پیشنهاد می گردد :

• ارتقاء به آخرین و جدیدترین نسخه OpenSSL . در صورتیکه OpenSSL بهمراه سیستم عامل نصب شده است ، از تولیدکننده سیستم عامل مربوطه می بایست آخرین نسخه مربوطه را  دریافت و آن را  بر روی سیستم  نصب نمود.
• در صورت امکان ، از ipfilter و سایر ابزارهای موجود در این زمینه  بمنظور اعمال محدودیت در رابطه با  سیستم هائی که می بایست به سرویس دهنده  OpenSSL متصل گردند ،استفاده شود .

مهمترین نقاط آسیب پذیر یونیکس و لینوکس ( بخش اول )

مهمترین نقاط آسیب پذیر یونیکس و لینوکس ( بخش دوم )

مهمترین نقاط آسیب پذیر یونیکس و لینوکس ( بخش سوم )

مهمترین نقاط آسیب پذیر یونیکس و لینوکس ( بخش چهارم )

سیستم های عامل در معرض تهدید
تقریبا”  بر روی تمامی سیستم های یونیکس و لینوکس  یک نسخه SNMP نصب و بهمراه آن عرضه می گردند. در اغلب موارد پروتکل فوق ، بصورت پیش فرض فعال می باشد. اکثر دستگاه ها و سیستم های عامل شبکه ای مبتنی بر SNMP دارای نقطه آسیب پذیر فوق بوده و در معرض تهدید قرار خواهند داشت .

نحوه تشخیص آسیب پذیری سیستم
بمنظور بررسی نصب SNMP  بر روی دستگاههای موجود و متصل شده در شبکه ، می توان از یک برنامه کمکی و یا روش دستی استفاده نمود. برنامه پویشگر SNScan ، نمونه ای در این زمینه بوده که می توان آن را از طریق آدرس  http://www.foundstone.com/knowledge/free_tools.html دریافت نمود. در مواردیکه امکان استفاده از ابزارهای  پویشگر وجود ندارد ، می توان بررسی لازم در خصوص نصب و اجراء SNMP  را بصورت دستی انجام داد. در این راستا می توان به مستندات سیستم عامل مربوطه مراجعه تا پس از آگاهی از نحوه پیاده سازی SNMP  ، عملیات لازم بمنظور تشخیص فعال بودن SNMP را انجام داد . در این رابطه می توان ، جستجوی لازم در لیست پردازه ها برای یافتن “snmp” در حال اجراء بر روی پورت های ۱۶۱ و ۱۶۲ را انجام داد .  وجود صرفا ” یک نمونه SNMP  ، دلیلی بر آسیب پذیری سیستم است . بمنظور آگاهی از جزیئات لازم در اینخصوص می توان از آدرس  CERT – 2002 – 03 استفاده نمود . در صورت تحقق یکی از شرایط زیر و نصب  SNMP ،  سیستم در معرض آسیب  و تهدید قرار خواهد داشت :

• وجود اسامی SNMP Community پیش فرض و یا خالی ( اسامی استفاده شده بعنوان رمزهای عبور )
• وجود اسامی SNMP Community  قابل حدس
• وجود رشته های مخفی SNMP Community

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت در مقابل نقطه آسیب پذیر فوق ،در دو زمینه می توان اقدامات حفاظتی را سازماندهی نمود .
حفاظت در مقابل  درخواست های آسیب رسان  و تهدید کننده :

• غیر فعال نمودن SNMP در صورت عدم ضرورت استفاده از آن
• استفاده از یک مدل امنیتی مبتنی بر کاربر SNMPv3 ،  بمنظور تائید پیام ها و رمزنگاری داده ها ( در صورت امکان )
• در صورت استفاده از SNMP نسخه یک و یا دو ، می بایست آخرین نسخه Patch ارائه شده توسط تولید کننده ، نصب گردد برای آگاهی از مشخصات تولیدکننگان، می توان به  بخش ضمیمه CERT Advisory CA-2002-03 ، مراجعه نمود .
• SNMP را در گلوگاه های ورودی شبکه فیلتر نمائید ( پورت ۱۶۱ مربوط به TCP/UDP و پورت ۱۶۲ مربوطه به TCP/UDP )  . عملیات فوق را در مواردیکه ضرورتی به مدیریت دستگاهها بصورت خارجی وجود ندارد ، می بایست انجام داد .
• از  کنترل دستیابی مبتنی بر میزبان بر روی سیستم های SNMP agent استفاده گردد . ویژگی فوق ممکن است توسط SNMP agent سیستم های عامل دارای محدودیت هائی باشد ، ولی می توان کنترل لازم در خصوص پذیرش درخواست ها توسط agent مربوطه را انجام داد. در اکثر سیستم های یونیکس ، می توان عملیات فوق را توسط  یک TCP-Wrapper و یا پیکربندی Xined انجام داد . استفاده از یک فایروال فیلترینگ بسته های اطلاعاتی مبتنی بر agent  بر روی یک میزبان  نیز می تواند در بلاک نمودن درخواست های ناخواسته SNMP موثر واقع شود .

حفاظت در مقابل رشته های قابل حدس

• غیر فعال نمودن SNMP در صورت عدم ضرورت استفاده از آن

• استفاده از یک مدل امنیتی مبتنی بر کاربر SNMPv3 ،  بمنظور تائید پیام ها و رمزنگاری داده ها ( در صورت امکان )
• در صورت استفاده از SNMP نسخه یک و یا دو ، می بایست از یک سیاست خاص بمنظور اسامی community ( استفاده شده بعنوان رمزهای عبور ) استفاده گردد. در این راستا لازم است اسامی بگونه ای انتخاب گردند که  غیر قابل حدس بوده و بصورت ادواری و در محدوده های خاص زمانی نیز تغییر داده شوند .
• با استفاده از امکانات موجود می بایست بررسی لازم در خصوص  استحکام اسامی در نظر گرفته شده برای رمزهای عبور راانجام داد.در این رابطه می توان از خودآموز و ابزار ارائه شده در آدرس  http://www.sans.org/resources/idfaq/snmp.php ، استفاده کرد.
• SNMP را در گلوگاه های ورودی شبکه فیلتر نمائید ( پورت ۱۶۱ مربوط به TCP/UDP و پورت ۱۶۲ مربوطه به TCP/UDP )  . عملیات فوق را در مواردیکه ضرورتی به مدیریت دستگاهها بصورت خارجی وجود ندارد ، می بایست انجام داد . پیکربندی فیلترینگ را صرفا” بمنظور ترافیک مجاز SNMP بین subnet های ممیزی شده ، انجام دهید.

هشتمین نقطه آسیب پذیر : Secure Shell (SSH
SSH ، یک سرویس عمومی برای ایمن سازی Login ، اجرای دستورات و ارسال فایل در یک شبکه است .اکثر سیستم های مبتنی بر یونیکس از بسته نرم افزاری OpenSSH ( نسخه فوق بصورت open-source  است ) و یا نسخه تجاری  SSH Communication Security ، استفاده می نمایند . با اینکه SSH دارای ایمنی مناسبتری نسبت به telnet,ftp و برنامه های R-Command  می باشد ، ولی همچنان  در هر دو نسخه اشاره شده ، ضعف های امنیتی متعددی وجود دارد . اکثر ضعف های موجود صرفا” اشکالات جزئی بوده و تعداد اندکی از آنان ، حائز اهمیت بوده و می بایست بلافاصله نسبت به برطرف نموودن آنان اقدام گردد . مهمترین تهدید مرتبط با ضعف های امنیتی SSH ، امکان دستیابی (سطح ریشه)  به ماشین آسیب پذیر توسط مهاجمان است . با توجه به  رشد چشمگیر استفاده از سرویس گیرندگان و سرویس دهندگان  SSH  در محیط های ویندوز،  اکثر اطلاعات ارائه شده در رابطه با نقطه آسیب پذیر فوق ، به نسخه های پیاده سازی شده  SSH در  ویندوز و nix *  ( یونیکس ، لینوکس  )  بر می گردد .عدم مدیریت مناسب SSH ، خصوصا” در ارتباط با پیکربندی و بکارگیری patch ها و بهنگام سازی لازم ، می تواند مسائل و مشکلات خاص خود را  بدنبال داشته باشد .
SSH2 ، ابزاری قدرتمند
تعداد زیادی از نقاط آسییب پذیر تشخیص داده شده   در پروتکل هائی نظیر POP3 ( جایگزین با SSH2 SFTP ) ، برنامه Telnet ، سرویس HTTP ,  و ابزارهای مبتنی بر rhost ( نظیر : روش های تائید ,rsh ,   rlogin ,rcp ) باعث ارسال اطلاعات بصورت clear text  و یا عدم پردازش مناسب session های سرویس گیرنده – سرویس دهنده می گردد. پروتکل SSH1 ، دارای  پتانسیل آسیب پذیری  بالائی خصوصا” در ارتباط با session  موقتی رمزنشده می باشد . بدین دلیل  مدیران سیستم و شبکه ، استفاده از پروتکل SSH2  را  گزینه ای شایسته در اینخصوص می دانند( در مواردیکه امکان آن وجود دارد) . لازم است به این نکته مهم  اشاره گردد که SSH1 و SSH2 با یکدیگر سازگار نبوده  و لازم است  نسخه SSH بر روی سرویس گیرنده و سرویس دهنده یکسان باشند (در این رابطه موارد استثنا ء نیز وجود دارد ) .
کاربران OpenSSH می بایست به این نکته توجه نمایند که کتابخانه های OpenSSH در مقابل پتانسیل های ایجاد شده توسط OpenSSH ، دارای نرم افزارهای آسیب پذیر مختص خود می باشند. بمنظور آگاهی از جزئیات مربوطه ، می توان از آدرس  CERT Advisory 2002-23 استفاده  نمود .در سال ۲۰۰۲ یک نسخه آلوده از OpenSSH  ( نسخه فوق دارای یک trojan-horse  بود ) در زمان کوتاهی گسترش و باعث آسیب های فراوانی گردید. بمنظور کسب اطلاعات بیشتر در این رابطه و اطمینان از عدم آسیب پذیری سیستم خود در مقابل نسخه آلوده فوق ، می توان از آدرس  http://www.openssh.org/txt/trojan.adv استفاده نمود .

سیستم های عامل در معرض تهدید
هر نسخه یونیکس و یا لینوکس که بر روی آن OpenSSH 3.3 و یا بعد از آن ( نسخه  ارائه شده در سال ۲۰۰۳ ،version 3.6.1)  و یا SSH Communication Security’s SSH 3.0.0  و یا بعد از آن ( نسخه ارائه شده در سال ۲۰۰۳ شماره version 3.5.2 ) نصب واجراء می گردد ،  در معرض این آسیب قرار خواهد داشت .

نحوه تشخیص آسیب پذیری سیستم
با استفاده از یک پویشگر مناسب ، می توان بررسی لازم در خصوص آسیب پذیری یک نسخه را انجام داد . در این رابطه می توان با اجرای دستور ” ssh   -V ” ، از شماره نسخه نصب شده بر روی سیستم آگاه گردید.  ScanSSH ، ابزاری مفید  بمنظور تشخیص  از راه دور سرویس دهندگان SSH  آسیب پذیر بدلیل عدم Patching ، می باشد. دستور خطی ScanSSH ، لیستی از آدرس های شبکه را برای سرویس دهندگان  پویش و گزارشی در ارتباط با شماره نسخه های آنان را ارائه می نماید . آخرین نسخهScanSSH  که در سال ۲۰۰۱ ارائه شده است را می توان از آدرس http://www.monkey.org/~provos/scanssh دریافت نمود .

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت در مقابل نقطه آسیب پذیر فوق ، موارد زیر پیشنهاد می گردد :

• نسخه  SSH و یا  OpenSSH را به آخرین نسخه موجود ارتقاء دهید . درصورتیکه SSH و یا OpenSSH بهمراه سیستم عامل ، نصب شده باشد ، می بایست  آخرین Patchمربوطه را از سایت ارائه دهنده سیستم عامل دریافت و آن را برروی سیستم نصب نمود. در صورت استفاده  از OpenSSL  ، از نصب آخرین نسخه آن مطمئن شوید .

• حتی المقدور سعی گردد، نسخه SSH1 به SSH2 ارتقاء یابد .در رابطه با توسعه SSH1  در آینده تصمیم خاصی وجود نداشته و توسعه SSH2 مورد نظر می باشد .

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

• پیکربندی مناسب  سرویس گیرندگان SSH  در زمان اتصال به سرویس دهنده ای که SSH را حمایت نمی نماید . در چنین مواردی سرویس گیرنده ممکن است به عقب برگشته و استفاده از rsh را در این رابطه مفید تشخیص دهد . بمنظور پیشگیری از مواردی اینچنین می بایست  به کلید FallBackToRsh  در فایل پیکربندی SSH ، مقدار NO را نسبت داد .

• از رمزنگاری blowfish در مقابل ۳DES استفاده گردد (روش ۳DES ، ممکن است بصورت پیش فرض در نسخه مربوطه در نظر گرفته شده باشد ). بدین ترتیب علاوه بر افزایش سرعت در عملیات ، رمزنگاری انجام شده نیز از استحکام مناسبی برخوردار خواهد بود.

در بخش پنجم  این مقاله به بررسی سایر نقاط آسیب پذیر یونیکس و لینوکس خواهیم پرداخت

سرویس هائی نظیر Telnet و FTP که شامل اطلاعات  مربوط به تائید هویت کاربران می باشند ، اطلاعات مورد نظر را بصورت متن  ارسال  که  بالاترین ریسک را بدنبال خواهد داشت . در چنین مواردی مهاجمان می توانند با استفاده مجدد از داده های حساس کاربران نظیر نام و رمز عبور، با خیال راحت ! به سیستم دستیابی نمایند .علاوه براین ، اجرای دستورات  بصورت clear text می تواند توسط مهاجمان استفاده تا با استفاده از آنان دستورات دلخواه خود را بدون الزامی برای تائید ، اجراء نمایند. سرویس های Clear text  ، می توانند زمینه تهدیدات مختلفی نظیر  :  تسهیل در انجام  حملات  ، دستیابی از راه دور ، اجرای دستورات بر روی یک سیستم مقصد ، شنود و تشخیص اطلاعات را بدنبال داشته باشد .

سیستم های عامل در معرض تهدید
تمامی  نمونه های یونیکس  ارائه شده ، از سرویس ها ی Clear text استفاده می نمایند. ( telnet و FTP دو نمونه متدواول در این زمینه می باشند ) . تمامی  نمونه نسخه های  ارائه شده یونیکس و  لینوکس ( تنها استنثاء در این  رابطه، مربوط به آخرین ویرایش  Free/OpenBSD  می باشد ) ، بصورت پیش فرض ، برخی از سرویس های فوق را نصب می نمایند .

نحوه تشخیص آسیب پذیری سیستم
موثرترین و مطمئن ترین روش بمنظور تشخیص نقطه آسیب پذیر فوق (سرویس های clear text )  ، بکارگیری  نرم افزاری مشابه با  ابزارهای استفاده شده (sniffer) توسط مهاجمان است. متداولترین برنامه موجود در این زمینه ،  tcpdump می باشد. برای دریافت برنامه “tcpdump ” می توان از آدرس  http://www.tcpdump.org ،  استفاده نمود . نحوه فعال نمودن برنامه فوق،بمنظور تشخیص هر گونه ارتباط clear text ،  بصورت زیر است :

# tcpdump -X -s 1600

دراین راستا می توان از برنامه های دیگر نظیر : “ngrep” نیز استفاده نمود. برنامه فوق،امکان جستجوی الگوئی خاص نظیر “sername ” و یا ” assword ” را در شبکه فراهم می نماید.  ( اولین حروف، بمنظور سازگاری با حروف بزرگ احتمالی ، در نظر گرفته نشده است ) . برای دریافت برنامه فوق ، می توان از آدرس    http://www.packetfactory.net/projects/ngrep استفاده نمود . نحوه فعال نمودن برنامه فوق ،  بصورت زیر است :

# ngrep assword

در این رابطه می توان از ابزارهای متنوع  دیگری بمنظور تشخیص داده های حساس کاربران ( نام و رمز عبور )  استفاده نمود . Dsniff ، متداولترین ابزار در این زمینه است . برنامه فوق ، بررسی لازم در خصوص تمامی زوج نام و رمزعبور بر روی پروتکل های Plain text حجیم، نظیر FTP ، Telnet و POP3 را انجام و پس از تشخیص، آنان را نمایش خواهد داد. برای بدست آوردن برنامه فوق می توان از آدرس  http://www.monkey.org/~dugsong/dsniff استفاده نمود . نحوه فعال نمودن برنامه فوق ،  بصورت زیر است :

# /usr/sbin/dsniff

نحوه حفاظت در مقابل نقطه آسیب پذیر
استفاده از رمزنگاری End-To-End و یا حداقل رمزنگاری Link-level می تواند در این زمینه مفید واقع گردد. برخی پروتکل ها از لحاظ رمزنگاری معادل یکدیگر می باشند( نظیر : POP3S و HTTPS ) . برای پروتکل هائی که دارای قابلیت ها  و امکانات  , ذاتی رمزنگاری نمی باشند ، می توان آنان را از طریق  SSH : Secure Shell ، و یا  SSL connection انجام داد( tunneling ) .
OpenSSH یک نمونه پیاده سازی شده متداول و انعطاف پذیر ازSSH  است.( قابل دسترس در آدرس  http://www.openssh.org ) . برنامه فوق، در اکثر نسخه های یونیکس اجراء و می توان از آن بمنظور ارتباطات از راه دور ( replaces telnet ,rlogin ,rsh ) و tunneling ( پروتکل هائی نظیر POP3,SMTP و X11 )   استفاده گردد .
دستور زیر نحوه tunnel نمودن POP3 را بر روی SSH connection  نشان می دهد. بر روی  سرویس دهنده POP3 ، می بایست سرویس دهنده SSH نیز اجراء گردد. در ابتدا آن را بر روی ماشین سرویس گیرنده اجراء می نمائیم :

# ssh -L 110:pop3.mail.server.com:110 username@pop3.mail.server.com

در ادامه ، برنامه سرویس گیرنده پست الکترونیکی را به localhost اشاره می دهیم ، پورت TCP 110  ( برخلاف روال معمول که بصورت : pop3.mail.server.com ، پورت ۱۱۰ است )  . بدین ترتیب ، تمامی ارتباطات بین ماشین و سرویس دهنده پست الکترونیکی بصورت رمز شده انجام خواهد شد ( tunneled over SSH  ) .
یکی دیگر از راه حل های متداول رمزنگاری مبتنی بر tunneling ، استفاده از stunnel است . روش فوق ، پروتکل SSL را پیاده سازی( با استفاده از OpenSSL Toolkit ) و می توان آن را  بمنظور tunel نمودن پروتکل های متفاوت plain text بخدمت گرفت . برای دریافت برنامه فوق ، می توان از آدرس  http://www.stunnel.org استفاده نمود.

ششمین نقطه آسیب پذیر : : Sendmail
Sendmail ، برنامه ای است که از آن بمنظور ارسال ، دریافت و فوروارد نمودن  نامه های الکترونیکی در اغلب سیستم های یونیکس و لینوکس استفاده می گردد. Sendmail ، یکی از متداولترین MTA : Mail Transfer Agent  در اینترنت بوده که بطور گسترده ای از آن بعنوان “آژانش توزیع نامه های الکترونیکی” بهمراه سرویس دهندگان پست الکترونیکی ، استفاده می گردد  . Sendmail ، یکی از اهداف اولیه مهاجمان  در سالیان اخیر بوده و تاکنون حملات متعددی را در ارتباط با آن شاهد بوده ایم. اکثر حملات انجام شده بدلیل قدیمی بودن  و یا عدم patch مناسب نسخه های نصب شده ، با موفقیت همراه بوده است .در این رابطه  می توان به چندین نمونه از حملات اخیر اشاره نمود :

- CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
- CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail
- CERT Advisory CA-2003-25 Buffer Overflow in Sendmail

خطرات و تهدیدات مرتبط با Sendmail را می توان به دو گروه عمده  تقسیم نمود :  از دست رفتن امتیازات که علت  آن buffer overflow  خواهد بود و پیکربندی نادرست سیستم که می تواند تبعات منفی را بدنبال داشته باشد ( مثلا” تبدیل یک سیستم به مرکزی آلوده برای توزیع نامه های الکترونیکی ) .عامل اصلی در بروز تهدیدات نوع اول ، عمدتا” به استفاده از نسخه های قدیمی و یا عدم  patching مناسب سیستم برمی گردد.علت اصلی تهدیدات نوع دوم ، به استفاده از فایل های پیکربندی پیش فرض و نادرست برمی گردد .

سیستم های عامل در معرض تهدید
تقریبا” تمامی نسخه های لینوکس و یونیکس بهمراه یک نسخه نصب شده از Sendmail عرضه می گردند. سرویس فوق،  بصورت پیش فرض فعال می باشد .

نحوه تشخیص آسیب پذیری سیستم
Sendmail ، در گذشته دارای نقاط آسیب پذیر فراوانی بوده که بتدریج  وبا ارائه نسخه های جدیدتر و patch های مربوطه ، میزان  آسیب پذیری آن کاهش یافته است .هر نسخه قدیمی و یا Patch نشده نرم فزار فوق در معرض آسیب قرار خواهد داشت . بمنطور مشخص نمودن شماره نسخه برنامه sendmail ، می توان از دستور زیر استفاده نمود :

echo \$Z | /usr/lib/sendmail -bt -d0

مسیر مشخص شده sendmail  در دستور فوق ، با توجه به پیکربندی سیستم ، می تواند متفاوت باشد. برای آگاهی از آخرین نسخه ارائه شده Sendmail می توان از آدرس  http://www.sendmail.org/current-release.html استفاده نمود .

نحوه حفاظت در مقابل نقطه آسیب پذیر
مراحل زیر بمنظور ایمن سازی و حفاظت Sendmail پیشنهاد می گردد :

• نسخه موجود را به آخرین نسخه ارتقاء و از آخرین patch های موجود ، استفاده گردد . برای دریافت source code می توان از آدرس http://www.sendmail.org استفاده نمود. در صورتیکه نسخه sendmail بهمراه سیستم عامل ارائه شده است  ( یک Package ) ، می توان برای دریافت patch مربوطه به سایت عرضه کنندگان سیستم عامل مراجعه نمود.

• برنامه sendmail عموما” بصورت پیش فرض در اکثر سیستم های یونیکس و لینوکس ( حتی آنانی که بعنوان سرویس دهنده mail  مورد نظر نبوده و فعالیت آنان در ارتباط با  mail نخواهد بود) نصب می گردد. برنامه Sendmail را در حالت daemon بر روی ماشین های فوق ، اجراء ننمائید ( غیر فعال نمودن سوئیچ  bd -  ) . امکان ارسال نامه الکترونیکی توسط سیستم های فوق ، همچنان وجود خواهد داشت . در این رابطه می بایست پیکربندی سیستم بگونه ای انجام شود که به یک mail relay در فایل پیکربندی sendmail ، اشاره گردد.فایل پیکربندی،  sendmail.cf نام داشته و معمولا” در آدرس  etc/mail/sendmail.cf  قرار دارد .

• در صورتیکه  لازم است sendmail در حالت daemon اجراء گردد، می بایست از صحت پیکربندی انجام شده اطمینان حاصل گردد. در این رابطه می توان از منابع اطلاعاتی زیر استفاده نمود :
  http://www.sendmail.org/tips/relaying.html
  http://www.sendmail.org/m4/anti_spam.html
  در نسخه  Sendmail 8.9.0 ، امکان open relay  بصورت پیش فرض غیرفعال می باشد.تعداد زیادی از عرضه کنندگان سیستم های عامل ، مجددا” آن رادر پیکربندی پیش فرض خود فعال می نمایند. در صورت استفاده از نسخه  Sendmail  ارائه شده بهمراه سیستم عامل ، می بایست دقت لازم در اینخصوص را انجام داد ( عدم استفاده سرویس دهنده برای  realying  ).

• در زمان استفاده از نسخه جدید sendmail ( سوئیچ نمودن به یک نسخه دیگر ) ،  لازم است تدابیر لازم در خصوص تغییر فایل های پیکربندی ارائه شده توسط نسخه قدیمی ، اندیشیده گردد . برای آگاهی از جزئیات  بیشتر در ارتباط با پیکربندی Sendmail ، می توان از آدرس http://www.sendmail.org/m4/readme.html استفاده نمود.

• در مواردیکه برنامه  Sendmail  از منابع موجود بر روی اینترنت Download  می گردد ، می بایست  بمنظور اطمینان از مجاز بودن نسخه تکثیری  از  PGP signature  استفاده نمود. در این رابطه لازم است به این نکته دقت شود که بدون بررسی integrity مربوطه به source code  برنامه Sendmail ، نمی بایست از آن استفاده شود. در گذشته ، نسخه هائی از Trojan ها در Sendmail  مستقر تا در زمان مناسب حرکت مخرب خود را آغاز نمایند .   بمنظور دریافت اطلاعات تکمیلی در این رابطه می توان از آدرس   CERT Advisory CA-2002-28 استفاده نمود. کلیدهای استفاده شده بمنظور sign نمودن برنامه Sendmail دریافتی را می توان از آدرس http://www.sendmail.org/ftp/PGPKEYS بدست آورد . در صورت فقدان  PGP ، می بایست از MD5 Checksum بمنظور بررسی integrity  کد منبع Sendmail ، استفاده گردد.

برای کسب اطلاعات بیشتر می توان از منابع اطلاعاتی زیر استفاده نمود :

http://www.sendmail.org/secure-install.html
http://www.sendmail.org/m4/security_notes.html
http://www.sendmail.org/~gshapiro/security.pdf

در بخش چهارم این مقاله به بررسی سایر نقاط آسیب پذیر یونیکس و لینوکس خواهیم پرداخت .

• غیر فعال نمودن سرویس ( DoS )
• نمایش و بمخاطره انداختن  فایل ها و داده های حساس
• دستیابی به سرویس دهنده از راه دور
• بمخاطره افتادن سرویس دهنده ( دستکاری و خرابی سایت )

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

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

• در رابطه با Apache 1.3.x را  می توان از آدرس   http://www.apacheweek.com/features/security-13
• برای Apache 2.0.x می توان از آدرس  http://www.apacheweek.com/features/security-20

آدرس های اشاره شده ، دارای اطلاعات فنی لازم بمنظور نحوه تشخیص آسیب پذیری سیستم و پیشنهادات لازم در خصوص ارتقاء وضعیت امنیتی می باشند . استفاده از آدرس:   http://httpd.apache.org نیز در این زمینه مفید است .

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت یک سرویس دهنده وب آپاچی ، پیشنهادات زیر ارائه می گردد :

• اطمینان از نصب آخرین patch  ارائه شده
  - در این رابطه می توان از آدرس http://httpd.apache.org بمنظور آگاهی  از آخرین  وضعیت نسخه ها و Patch levels  استفاده نمود.
  - بمنظور دستیابی به Source code  اکثر نسخه های آپاچی، می توان از آدرس   http://httpd.apache.org/download.cgi استفاده نمود.
  - بمنظور آگاهی و دریافت آخرین Patch های ارائه شده می توان از آدرس  http://www.apache.org/dist/httpd/patches/ استفاده نمود.

• اطمینان از patching عناصر کلیدی سیستم عامل که آپاچی بعنوان مرجع از آنان استفاده می نماید .در این رابطه لازم است که صرفا” ماژول های ضروری بمنظور صحت عملکرد سرویس دهنده ، در آپاچی کمپایل گردند .لازم است به این نکته اشاره گردد که  کرم(  mod_ssl ( CA-2002-27 نمونه ای کامل در این زمینه بوده که از نقاط آسیب پذیر در( OpenSSL ( CA-2002-23 استفاده نموده است .

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

• Chroot ، پتانسیلی است  که باعث تعریف مجدد محدوده یک برنامه می گردد . در حقیقت chroot ، باعث تعریف مجدد دایرکتوری ROOT”  و یا “/”  برای یک برنامه و یا یک Login session می گردد .chroot می تواند بعنوان یک لایه تدافعی استفاده گردد . مثلا” در صورتیکه فردی به کامپیوتر شما دستیابی پیدا نماید ، قادر به مشاهده تمامی فایل های موجود بر روی سیستم نخواهد بود . علاوه بر محدودیت فوق ، محدودیت هائی در خصوص اجرای برخی از دستورات نیز بوجود می آید.در این رابطه یک دایرکتوری با نام chroot/ ، ایجاد و تمامی سرویس های مورد نطر با یک انظباط خاص در آن مستقر می گردند . مثلا” سرویس دهنده آپاچی در chroot/httpd / قرار می گیرد. با توجه به موارد فوق ، می بایست آپاچی را در یک  محیط chroot اجراء نمود . درصورتیکه آپاچی بصورت chrooted اجراء و فعالیت خود را  آغاز نماید ، امکان دستیابی آن به سایر بخش های موجود در  ساختار دایرکتوری سیستم عامل و  خارج از chroot وجود نخواهد داشت . بدین ترتیب یک لایه تدافعی مناسب در خصوص سوء استفاده های احتمالی ایجاد می گردد. بعنوان نمونه ، ممکن است یک shell فراخوانده شده  و با توجه به اینکه  bin/sky / در chroot قرار ندارد ، می تواند زمینه سوء استفاده احتمالی را فراهم نماید. لازم است به این نکته مهم نیز اشاره گردد که Chrooting آپاچی می تواند اثرات جا نبی نامطلوبی را در ارتباط با CGI,PHP ، بانک های اطلاعاتی و سایر ماژول ها و یا ارتباطاتی که محیط سرویس دهنده وب بمنظور سرویس دهی به آنان نیازمند دستیابی به توابع کتابخانه ای خارجی است را بدنبال داشته باشد .روش های متعددی بمنظور chrooting  وجود داشته و می بایست از مستندات نرم افزار مورد نظر ، بعنوان یک منبع اطلاعاتی مناسب در خصوص ارائه راهکارهای مربوطه ، استفاده گردد

• بمنظور مدیریت یک سرویس دهنده وب ، لازم است فیدبک های لازم در خصوص فعالیت و کارآئی سرویس دهنده و سایر مسائلی که ممکن است یک سرویس دهنده با آنان برخورد نماید را اخذ و در ادامه با آنالیز آنان تمهِیدات لازم در خصوص مسائل موجود را بکار گرفت . سرویس دهنده آپاچی ، قابلیت ها و پتانسیل های انعطاف پذیری را در خصوص logging ارائه می نماید . بنابراین لازم است عملیات logging با دقت نظر بالا بصورت موثر و موشکافانه انجام تا امکان ردیابی هر نوع فعالیت امنیتی غیر مجاز و یا رفتار غیر منطقی سرویس دهنده ، فراهم گردد .پیشنهاد می گردد که با یک نظم خاص از اطلاعات موجود در فایل های لاگ ، آرشیو تهیه شود . بدین ترتیب ، امکان مدیریت فایل های لاگ و بررسی آنان فراهم خواهد شد. بمنظور آشنائی با فرمت های متفاوت لاگ می تواند از منابع زیر استفاده نمود :
  - برای Apache 1.3.x از آدرس http://httpd.apache.org/docs/logs.html استفاده شود .
  - برای Apache 2.0.x  از آدرس http://httpd.apache.org/docs-2.0/logs.html استفاده شود .
  در موارد متفاوتی و با توجه به شرایط پیش آمده ممکن است محتوی فایل های لاگ بتنهائی کافی نباشد . وضعیت فوق در مواردیکه از  PHP ، CGI و یا سایر تکنولوژی های مبتنی بر اسکریپت استفاده می گردد ، تشدید و می توان بمنظور افزایش توان آنالیز یک تهاجم و سوءاستفاده از یک ضعف امنیتی ، اقدام به ثبت لاگ های مربوط به  GET و POST  نمود.لاگ نمودن عملیات مرتبط به GET و POST می تواند از طریق mod_Security صورت پذیرد. ModSecurity یک سیستم تشخیص مزاحمین ( Intruder detection ) یوده و پیشگیری های لازم در خصوص یک برنامه وب را ارائه می نماید . سیستم فوق بهمراه سرویس دهنده وب مستقر و یک پوشش امنیتی مناسب را در جهت پیشگیری از یک تهاجم در ارتباط با برنامه های وب فراهم می نماید . ModSecurity   ، از سرویس دهنده آپاچی حمایت می نماید .
  - http://www.modsecurity.org
  -  http://www.securityfocus.com/infocus/17064.152.44.126 152.44.126

• PHP، CGI،SSI و سایر اسکریپت ها . در این رابطه موارد زیر پیشنهاد می گردد :
  - PHP,CGI,SSI و سایر زبان های اسکریپت را غیر فعال نمائید ( مگر اینکه ضرورتی جدی در رابطه با آنان وجود داشته باشد ).
  - SSI یا Server Side Includes را  که می تواند زمینه مساعدی بمنظور سوء استفاده از  سرویس دهنده و الزام آن در جهت اجرای کد ناخواسته گردد را غیر فعال نمائید .
  - در صورتیکه ضروری است که  از PHP,CGI,SSI و یا سایر زبان های اسکریپت استفاده گردد ، می بایست  از SuEXEC استفاده شود. suEXEC ، امکان  اجرای اسکریپت ها تحت آپاچی  بهمراه یک User Id در مقابل یک Apache User Id را فراهم می نماید در حقیقت suEXEC این امکان را برای کاربران آپاچی فراهم می نماید  که قادر به اجرای برنامه های SSI و CGI تحت یک User Id متفاوت نسبت به User Id مربوط به فراخوانی سرویس دهنده وب باشند.بدین ترتیب تهدیدات امنیـتی کاهش و امکان نوشتن و اجرای برنامه های SSI و CGI اختصاصی نوشته شده توسط مهاجمان ، حذف خواهد شد . استفاده از  suEXEC ،می بایست توام با آگاهی و دانش لازم باشد چراکه در صورت استفاده نادرست و یا عدم پیکربندی مناسب و شناخت نسبت به مدیریت setupid Root ،  خود باعث بروز حفره های امنیتی دیگر خواهد شد.. در این رابطه و بمنظور آشنائی با نحوه عملکرد و استفاده از suEXEC می توان از آدرس های زیر استفاده نمود:
  – برای Apache 1.3.x از آدرس http://httpd.apache.org/docs/suexec.html استفاده شود .
  – برای Apache 2.0.x  از آدرس   http://httpd.apache.org/docs-2.0/suexec.html استفاده شود.
  - بررسی لازم در خصوص محتوی دایرکتوری cgi-bin و سایر دایرکتوری های شامل اسکریپت ها انجام و لازم است تمامی اسکریپت های پیش فرض نمونه ، حذف گردند.
  - ایمن سازی PHP . پرداختن به موضوع فوق با توجه به گستردگی مطالب از حوصله این مقاله خارج بوده و صرفا” به دو نمونه مهم در اینخصوص اشاره می گردد :
  - غیر فعال نمودن پارامترهائی که باعث ارائه اطلاعات در HTTP header می گردد .
  - حصول اطمینان از اجرای PHP در حالت safe
  برای دریافت اطلاعات تکمیلی دراین خصوص می توان از آدرس  http://www.securityfocus.com/printable/infocus/1706 استفاده نمود .
  -  استفاده از ماژولهای اضافه بمنظوربهبود وضعیت امنیتی. مثلا”ماژول mod_Security می تواند باعث حفاظت در مقابل Cross Site Scripting:  XSS  ،  شود . برای آشنائی و مشاهده اطلاعات تکمیلی در این خصوص می توان  از آدرس  http://www.modsecurity.org استفاده نمود.
  - ممیزی و بررسی اسکریپت ها برای نقاط آسیب پذیر شامل XSS & SQL Injection نیز حائز اهمیت است . در این رابطه می توان از ابزارهای متعددی استفاده نمود. نرم افزار Nikto ( قابل دسترس در آدرس   http://www.cirt.net/code/nikto.shtml )  یکی از مناسبترین ابزارهای پویش و بررسی CGI  است .

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

• Account  تعریف شده  دارای رمز عبور ضعیف و یا فاقد رمز عبور است .
• عدم حفاظت مناسب کاربران از رمزهای عبور ،صرفنظر از استحکام رمزهای عبور تعریف شده .
• سیستم عامل و یا سایر نرم افزارهای موجود ، امکان ایجاد account مدیریتی ضعیف  و فاقد رمز عبور را فراهم می نمایند .

• الگوریتم های Hashing رمز عبور( رمزنگاری مبتنی بر کلید عمومی بر پایه یک مقدار hash ، استوار بوده و بر اساس یک مقدار ورودی که دراختیار الگوریتم hashing گذاشته می گردد ، ایجاد می گردد. در حقیقت مقدار hash ، فرم خلاصه شده و رمز شده ای  از مقدار اولیه خود است  ) ، شناخته شده بوده و در اغلب موارد مقدار Hashe بدست آمده ، بگونه ای ذخیره می گردد که امکان مشاهده آن توسط سایرین وجود خواهد داشت. مناسبترین نوع حفاظت در این راستا ، تبعیت از یک سیاست رمز عبور قدرتمند بوده  که در آن دستورالعمل ها ی لازم برای تعریف یک رمز عبورمناسب مشخص و در ادامه با استفاده از ابزارهای موجود، بررسی لازم در خصوص  استحکام و بی نقص بودن رمز عبور صورت گیرد.

سیستم ها ی در معرض آسیب پذیر
هر سیستم عامل و یا برنامه ای که فرآیند تائید کاربران آن براساس یک User ID و رمز عبور باشد ، در معرض این تهدید خواهد بود.

نحوه تشخیص آسیب پذیری سیستم
در صورتیکه از account هائی استفاده می شود که بین کاربران متعدد و یا کارکنان موقت  یک سازمان به اشتراک  گذاشته شده و یا کاربران از رمزهای عبور بدرستی حفاظت ننمایند، پتانسیل نفوذ به شبکه توسط یک مهاجم فراهم می گردد.پیکربندی account های جدید کاربران با یک رمز عبور مشابه و یا رمز عبوری که بسادگی قابل حدس باشد نیز  فرصتی مناسب را در اختیار مهاجمان بمنظور دستیابی به منابع اطلاعاتی  موجود در یک سازمان قرار خواهد داد .
لازم است در خصوص ذخیره سازی رمز عبور hashes تصمیم گیری و مشخص شود که محل استقرار و ذخیره سازی آنان در etc/passwd /  و یا etc/shadow / می باشد.قابلیت خواندن فایل etc/passwd /، می بایست توسط تمامی کاربران شبکه وجود داشته تا زمینه و امکان تائید کاربران فراهم گردد. در صورتیکه فایل فوق ، شامل رمزعبور hashed نیز باشد ،  در ادامه و پس از دستیابی کاربران به سیستم ، امکان خواندن مقادیر hash فراهم و مهاجمان می توانند با استفاده از یک برنامه cracker ، تلاش خود را جهت شکستن و تشخیص رمز عبور آغاز و به سرانجام برسانند . فایل etc/shadow/  ، صرفا” برای root قابل خواندن بوده و مکانی مناسب بمنظور ذخیره نمودن مقادیر hashes است . در صورتیکه account های محلی ، توسط /etc/shadow حفاظت نشود ، ریسک رمزهای عبور افزایش خواهد یافت . اکثر سیستم های عامل جدید بصورت پیش فرض از  etc/shadow / بمنظور ذخیره سازی رمز عبور hashes استفاده می نمایند ( مگر اینکه شرایط فوق توسط نصب کننده تغییر یابد ). در این رابطه می توان از الگوریتم MD5 بمنظور hash نمودن رمزهای عبور نیز استفاده نمود. الگوریتم فوق،  بمراتب از الگوریتم قدیمی crypt ایمن تر است .
NIS)Network Information System) ، یک بانک اطلاعاتی توزیع شده بمنظور مدیریت یک شبکه است . در حقیقت  NIS ، استانداردی برای اشتراک فایل ها بین سیستم های کامپیوتری متعدد را فراهم و شامل مجموعه ای از سرویس هائی است که بمنزله یک بانک اطلاعاتی از سرویس ها عمل نموده و اطلاعات مربوط به مکان سرویس ( Mapping ) را در اختیار سایر سرویس های شبکه نظیر( Network File System (NFS) ، قرار می دهد. با توجه به ماهیت طراحی بعمل آمده  ، فایل های پیکربندی NIS ، شامل رمزهای عبور hash  بوده و این امر می تواند امکان خواندن آنان را برای تمامی کاربران فراهم و عملا” رمزهای عبور در معرض تهدید قرار گیرند .نسخه های جدید پیاده سازی شده  از NIS ، نظیر +NIS و یا LDAP عموما” دارای استحکام لازم در ارتباط با رمزهای عبور hashes می باشند( مگر اینکه شرایط فوق توسط نصب کننده تغییر یابد). تنظیم و پیکربندی نسخه های فوق ( نسخه های جدید ) ، مشکل تر بوده و همین امر می تواند استفاده از آنان را با تردید و مشکل مواجه نماید .
حتی اگر رمزهای عبور hashes توسط /etc/shadow و یا امکانات پیاده سازی شده ، محافظت گردند ، امکان حدس و تشخیص رمزهای عبور توسط سایر افراد وجود خواهد داشت . در این رابطه می توان به موارد متعدد دیگری نظیر : ضعف رمز عبور ، وجود account های غیر استفاده مربوط به کارکنانی که سازمان خود را ترک نموده اند ، اشاره نمود .سازمان ها معمولا” در رابطه با غیر فعال نمودن account مربوط به کاربران قدیمی کوتاهی نموده و لازم است در این رابطه از روش های خاصی استفاده گرد.
نصب های پیش فرض سیستم های عامل و یا شبکه توسط سازندگان و یا مدیران  سیستم و یا شبکه ، می تواند نصب مجموعه ای از سرویس های غیرضروری را  نیز بدنبال داشته باشد.  رویکرد فوق،با اینکه عملیات نصب سیستم عامل و سرویس ها ی مربوطه را تسهیل می نماید ولی  مجموعه ای از سرویس های غیر ضروری و account هائی که بصورت پیش فرض ضعیف ویا فاقد رمز عبور می باشند را بهمراه بر روی سیستم مستقر و پیکربندی می نماید.

نحوه حفاظت در مقابل نقطه آسیب پذیر
بهترین و مناسبترین دفاع در مقابل ضعف رمزهای عبور ، تبعیت از یک سیاست امنیتی مستحکم بوده که دستورالعمل های لازم  کهه موجب می شود رمزهای عبور مناسب و مستحکمی توسط کاربران تعریف و توسط مدیران سیستم بصورت مستمر پیوستگی و استحکام آنان بررسی می گردد با حمایت کامل سازمان . مراحل زیر توصیه های لازم برای ارائه یک سیاست امنیتی مناسب می باشد :

• اطمینان ازاستحکام و انسجام  رمز های عبور . با استفاده از سخت افزار مناسب و اختصاص زمان کافی ، می توان هر رمز عبوری را  crack نمود. در این راستا می  توان با استفاده ازروش های ساده و در عین حال موفقیت آمیز، عملیات تشخیص رمز عبور را انجام داد . اغلب برنامه های تشخیص دهنده رمزعبوراز روشی موسوم به “حملات مبتنی بر سبک دیکشنری ” ، استفاده می نمایند. با توجه به اینکه روش های رمز نگاری تا حدود زیادی شناخته شده می باشند  ، برنامه های  فوق ، قادر به مقایسه  شکل  رمز شده یک رمز عبور در مقابل شکل  های رمز شده کلمات دیکشنری می باشند( در زبان های متعدد و استفاده از اسامی مناسب بهمراه جایگشت های مختلف آنان  ) . بنابراین ، رمز عبوری  که ریشه آن در نهایت یک کلمه شناخته شده باشد ، دارای استعداد ذاتی در رابطه با این نوع از حملات خواهد بود . تعداد زیادی از سازمان ها ، آموزش های لازم در خصوص نحوه تعریف رمزهای عبور را به کارکنان خود داده و به آنان گفته شده است  که رمزهای عبور مشتمل بر ترکیبی از حروف الفبائی و کاراکترهای ویژه را برای خود تعریف نمایند.متاسفانه اکثر کاربران این موضوع را رعایت ننموده و  بمنظور تعریف یک رمز عبور با نام “password” ، صرفا” اقدام به تبدیل حروف به اعداد و یا حروف ویژه می نمایند ( pa$$w0rd) . چنین جایگشت هائی نیز قادر به  مقاومت در مقابل یک تهاجم مبتنی بر دیکشنری نبوده و  “pa$$w0rd” به روش مشابهی که “password” تشخیص داده می شود ، crack خواهد شد .
  یک رمز عبور خوب ، نمی بایست از ریشه یک  کلمه و یا نام شناخته شده ای  اقتباس شده باشد .در این راستا لازم است به کاربران آموزش لازم در خصوص انتخاب و ایجاد رمزهای عبور از موارد تصادفی نظیر  یک عبارت ، عنوان یک کتاب ،نام یک آواز و یا نام یک فیلم  داده شود. با انتخاب  یک رشته طولانی که بر اساس رویکردهای خاصی می تواند انتخاب گردد( گرفتن اولین حرف هر کلمه ، جایگزینی یک کاراکتر خاص برای یک کلمه ، حذف تمامی حروف صدادارو  سایر موارد ) ، کاربران قادر به ایجاد رمزهای عبور مشتمل بر ترکیبی از حروف الفبائی و حروف ویژه بوده که در صورت مواجه شدن  با حملات مبتنی بر دیکشنری ، تشخیص آنان بسختی انجام می شود. لازم است به این نکته نیز اشاره گردد که رمزعبور می بایست براحتی بخاطر سپرده شده و بازیابی ( یادآوری)آن مشکل نباشد ( هدف از ذخیره سازی ، بازیابی است اگر چیزی را ذخیره  نمائیم ولی در زمان مورد نظر قادر به بازیابی آن نباشیم ، سیستم ذخیره و بازیابی ما با اشکال مواجه شده است ! ). پس از تدوین دستورالعمل لازم بمنظور تولید رمزهای عبور مناسب و  آموزش کاربران بمنظور پایبندی به  اصول امنیتی تعریف شده ، می بایست از روتین ها ی جانبی متعددی بمنظور اطمینان از پیروی کاربران از دستوراالعمل های اعلام شده ، استفاده گردد. بهترین گزینه در این راستا ، بررسی صحت رمزهای عبور پس از اعمال تغییرات توسط کاربران است .
  پس از ارائه دستورالعمل ها ی لازم و مناسب برای ایجاد رمزهای عبور ، روتین های تکمیلی خاصی  می بایست ایجاد تا این اطمینان حاصل گردد که کاربران پایبند به دستورالعمل های ارائه شده بوده اند. بهترین روش در این زمینه ، بررسی صحت اعتبار رمزهای عبور پس  از اعمال تغییرات توسط کاربران است . اکثر نمونه های یونیکس و لینوکس می توانند از Npasswd بمنظور بررسی رمز عبور در مقابل سیاست امنیتی موجود استفاده نمایند. سیستم های PAM-Enabled  نیز می توانند از Cracklib ( کتابخانه لازم بمنظور هماهنگی با  Crack ) بمنظور بررسی رمزهای عبور ایجاد شده ، استفاده نمایند.اکثر سیستم های PAM-enabled را می توان بگونه ای پیکربندی نمود که رمزهای عبوری  را که با سیاست های مشخص شده مطابقت ندارد ، رد نمایند .
  درمواردیکه امکان استفاده از ابزارهائی نظیر Npasswd و یا کتابخانه های PAM-Enabled ، وجود ندارد، مدیران سیستم و شبکه می توانند از برنامه های کاربردی Cracking  در حالت stand-alone و بعنوان یک روتین کنشگرایانه مستمر، استفاده نمایند. LC4 )l0phtcrack version 4) و John the Ripper ، نمونه هائی از برنامه های فوق ، می باشند.  لازم است مجددا” به این موضوع اشاره گردد که بدون کسب مجوز لازم از مدیران ارشد سیستم در سازمان ، نمی بایست از برنامه های cracking استفاده گردد.پس از کسب مجوزهای  لازم ، می توان عملیات فبررسی رمزهای عبور  را بر روی یک ماشین حفاظت شده انجام داد. به کاربرانی که رمزهای عبور آنان crack می گردد، بصورت محرمانه وضعیت فوق گزارش و دستورالعمل های لازم در خصوص نحوه انتخاب یک رمز عبور مناسب نیز به آنان ارائه گردد .اخیرا” و در پاسخ به رمزهای عبور ضعیف ، استفاده از روش هائی دیگر بمنظور تائید کاربران،  نظیر بیومتریک (زیست سنجی )  ، نیز مورد توجه  واقع شده است .

• حفاظت رمزهای عبور مستحکم . در صورتیکه رمزهای عبور hashes در etc/passwd /  ذخیره می گردند ، سیستم را بهنگام نموده تا از  /etc/shadow استفاده گردد . در صورتیکه بر روی  سیتستم  NIS و یا LDAP اجراء که امکان حفاظت hashes وجود نداشته باشد ، هر کاربری قادر به خواندن رمزهای عبور hashes و تلاش بمنظور cracking  آنان ، خواهد بود.در این رابطه  می بایست بررسی لازم در خصوص استفاده از گزینه های ایمن تری از نسخه های NIS و LDAP را انجام داد. تا زمانیکه این نوع برنامه های غیر ایمن وجود داشته و با نمونه های ایمن جایگزین نشده اند، می بایست  مجوزهای مربوطه را ایمن و از ابزارهای کنشکرایانه بصورت مستمر استفاده گردد.در این رابطه پیشنهاد می گردد که در مقابل استفاده از الگوریتم قدیمی Crypt بمنظورhash نمودن رمزهای عبور از الگوریتم  MD5 استفاده گردد.
  حتی اگر رمزهای عبور ، مستحکم و قدرتمند باشند ، در صورت عدم حفاظت آنان توسط کاربران ، سیستم های موجود در یک سازمان در معرض تهدید قرار خواهند گرفت .  یک سیاست امنیتی مناسب ، می بایست شامل دستورالعمل های لازم بمنظور آموزش کاربران در رابطه با حفاظت رمزهای عبور می باشد.عدم ارائه رمز عبور به افراد دیگر، عدم نوشتن رمز عبور در محلی که امکان خواندن آن برای دیگران وجود داشته باشد و حفاظت اتوماتیک فایل  هائی که رمزهای عبور در آن ذخیره شده اند ، از جمله مواردی می باشند که می بایست به کاربران آموزش داده شود. اغلب کاربران در مواجهه با پیامی مشابه “Your password has expired”  که نشاندهنده اتمام عمر مفید یک رمز عبور است ، یک رمز عبور ضعیف را برای خود انتخاب می نمایند ، بنابراین لازم است در فرصت مناسب و قبل از برخورد با اینچنین پیام هائی ، به کاربران آموزش های لازم ارائه گردد.

• کنترل دائم و پیوسته accounts . هر account مدیریتی و یا مبتنی بر سرویس که از آن استفاده نمی گردد، می بایست غیر فعال و یا در صورت امکان از روی سیستم حذف گردد. هر account مدیریتی و یا مبتنی بر سرویس که از آن استفاده می گردد ، می بایست دارای رمزعبورجدید و مستحکمی باشد. پیکربندی account های جدید کاربران  با رمزهای عبور اولیه (تولیده شده بصورت تصادفی)  و ضرورت تغییر رمزهای عبور توسط کاربران و در اولین log in  نیز می تواند در این زمینه مفید واقع شود. ممیزی account ها بر روی سیستم را انجام  و لازم است در این رابطه یک لیستی اصلی ایجاد گردد .در این رابطه می بایست رمزهای عبور در ارتباط با سیستم هائی نظیر روترها ، چاپگرهای دیجیتالی متصل شده به اینترنت و سایر موارد دیگر نیز مورد بررسی قرار گرفته و روتین هائی خاص بمنظور افزودن account های تائید شده  به لیست و یا حذف  account هائی که ضرورتی به استفاده از آنان نمی باشد ، پیاده سازی و همواره خود را پایبند به آن بدانیم .اعتبار لیست را در فواصل زمانی خاصی بررسی تا از بهنگام بودن آن اطمینان حاصل گردد.از روتین های  خاصی بمنظورحذف account متعلق به کارکنان و یا پیمانکارانی که سازمان را ترک نموده اند ، استفاده گردد .

در بخش سوم این مقاله به بررسی سایر نقاط آسیب پذیر یونیکس و لینوکس خواهیم پرداخت .

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

• BIND Domain Name System

• Remote Procedure Calls (RPC)

• Apache Web Server

• General UNIX Authentication Accounts with No Passwords or Weak Passwords

• Clear Text Services

• Sendmail

• Simple Network Management Protocol (SNMP)

• Secure Shell (SSH)

• Misconfiguration of Enterprise Services NIS/NFS

• Open Secure Sockets Layer (SSL)

در بخش اول این مقاله ، به بررسی BIND Domain Name System  وRemote Procedure Calls   (موارد یک و دو)  ، خواهیم پرداخت .

اولین نقطه آسیب پذیر : BIND Domain Name System
نرم افزار BIND ) Berkeley Internet Name Domain) ، در مقیاس گسترده ای و بمنظور پیاده سازی DNS)Domain Name Service) ، استفاده می گردد. BIND ، سیستمی حیاتی است که از آن بمنظور تبدیل اسامی میزبان ( نظیر : www.srco.ir ) به آدرس IP ریجستر شده ،استفاده می گردد .با توجه به استفاده وسیع از BIND  و جایگاه حیاتی آن در یک شبکه کامپیوتری ، مهاجمان آن را بعنوان یک هدف مناسب بمنظور انجام حملات ، خصوصا”  از نوع DoS)Denila Of  Service) انتخاب و حملات متنوعی را در ارتباط با آن انجام داده اند. حملات فوق،از کارافتادن سرویس DNS و عدم دستیابی به اینترنت برای سرویس های مربوطه و میزبانان را می تواند بدنبال داشته باشد. با اینکه پیاده کنندگان BIND ، تلاشی مستمر را از گذشته تا کنون بمنظور برطرف نمودن نقاط آسیب پذیر انجام داده اند ، ولی هنوز تعداد زیادی از نقاط آسیب پذیر قدیمی ، بدرستی پیکربندی نشده و سرویس دهندگان آسیب پذیر در آن باقی مانده است .
عوامل متعددی در بروز اینگونه حملات نقش دارد: عدم آگاهی لازم مدیران سیستم در خصوص ارتقاء امنیتی سیستم هائی که بر روی آنان Bind deamon  بصورت غیر ضروری  اجراء می گردد و پیکربندی نامناسب فایل ها ، نمونه هائی از عوامل فوق بوده و  می تواند زمینه  یک تهاجم از نوع DoS  ، یک Buffer Overflow و یا  بروز اشکال در DNS Cache  را بدنبال داشته باشد.از جمله مواردیکه اخیرا” در رابطه با ضعف امنیتی  BIND کشف شده است مربوط به یک تهاجم از نوع DoS است . مقاله CERT Advisory CA-2002-15 جزئیات بیشتری را در این رابطه ارائه می نماید. از دیگر حملات اخیر ، تهاجمی  از نوع Buffer Overflow است . مقاله CERT Advisory CA-2002-19 جزئیات بیشتری را در این رابطه در اختیار قرار می دهد. درتهاجم فوق ، یک مهاجم از نسخه آسیب پذیر پیاده سازی  توابع Resolver مربوط به DNS  استفاده و با ارسال پاسخ های مخرب به DNS و اجرای کد دلخواه ، امکان  سوء استفاده از نقطه آسیب پذیر فوق را فراهم و حتی دربرخی موارد می تواند زمینه بروز یک تهاجم از نوع  DoS را باعث گردد .
تهدیدی دیگر که می تواند در این رابطه وجود داشته باشد ، حضور یک سرویس دهنده BIND آسیب پذیر در شبکه است . در چنین مواردی ، مهاجمان از وضعیت فوق استفاده و از آن بمنزله مکانی جهت استقرار داده های غیر معتبر خود و بدون آگاهی مدیرسیستم استفاده می نمایند. بدین ترتیب ، مهاجمان از سرویس دهنده بعنوان پلات فرمی بمنظور فعالیت های آتی مخرب خود بهره برداری خواهند کرد .

سیستم های عامل در معرض تهدید :
تقریبا” تمامی سیستم های عامل  یونیکس و لینوکس بهمراه یک نسخه از BIND  ارائه شده اند .در صورت پیکربندی میزبان بعنوان سرویس دهنده ، نسخه ای  از BIND بر روی آن نصب خواهد شد.

نحوه تشخیص آسیب پذیری سیستم
در صورت دارا بودن  نسخه خاصی از BIND  که بهمراه سیستم عامل ارائه و بر روی سیستم نصب شده است ، می بایست عملیات بهنگام سازی آن را با استفاده از آخرین Patch های ارائه شده توسط تولید کننده ( عرضه کننده ) انجام داد. در صورت استفاده از نسخه BIND مربوط به  ISC: Internet Software Consortium ، می بایست از نصب آخرین نسخه BIND ، اطمینان حاصل نمود . در صورتیکه BIND  نصب شده بر روی سیستم ، نسخه ای قدیمی بوده و یا بطور کامل  Patch نشده باشد ، احتمال آسیب پذیری سیستم وجود خواهد داشت . در اکثر سیستم ها ، دستور : “named – v ” ، اطلاعات لازم در خصوص نسخه BIND نصب شده بر روی سیستم را بصورت X.Y.Z نمایش خواهد داد . X ، نشاندهنده نسخه اصلی ، Y ،نشاندهنده جزئیات نسخه و Z نشاندهنده یک Patch Level است . پیشنهاد می گردد ، آخرین نسخه BIND  ارائه شده  توسط  ISC  را دریافت و آن را  بر روی سیستم نصب نمود. آخرین نسخه موجود Version 9.2.2 بوده و می توان آن را از سایت  ISC دریافت نمود.  یکی دیگر از رویکردهای کنشگرایانه مرتبط با نگهداری امنیت  BIND ،  عضویت در گروه های خبری نظیر Symantec برای آگاهی از آخرین هشدارهای امنیتی است . در این راستا می توان از یک برنامه پویشگر بهنگام شده  که قادر به بررسی دقیق سیستم های DNS بمنظور تشخیص نقاط  آسیب پذیراست ، نیز استفاده گردد .

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت در مقابل نقاط آسیب پذیر مرتبط با BIND موارد زیر پیشنهاد می گردد :

• غیر فعال نمودن BIND deamon ( به آن  named نیز اطلاق  می گردد ) بر روی سیستم هائی که بعنوان یک سرویس دهنده DNS در نظر گرفته نشده اند .  بمنظور پیشگیری ازاعمال برخی تغییرات خاص ( نظیر فعال نمودن مجدد آن ) ،  می توان  نرم افزار BIND  را از روی اینگونه سیستم ها حذف نمود.
• بمنظور بهنگام سازی سرویس دهنده DNS ، از تمامی Patch های ارائه شده توسط تولید کنندگان استفاده و در صورت امکان آن را به آخرین نسخه موجود ارتقاء دهید . برای دریافت اطلاعات تکمیلی در رابطه با نصب مطمئن تر BIND ، از مقالات ارائه شده درسایت CERT و بخش UNIX Security Checklist ، استفاده نمائید .
• بمنظور پیچیده تر نمودن حملات اتوماتیک و یا پویش سیستم مورد نظر ، Banner مربوط به ” Version String ” را از BIND حذف و نسخه واقعی BIND  را با یک شماره نسخه غیرواقعی در فایل named.conf ، جایگزین نمائید .
• امکان ارسال انتقالات Zone را صرفا” برای سرویس دهندگان ثانویه DNS در Domain فراهم نمائید (  secondary DNS servers) . امکان انتقالات Zone در ارتباط با  Domain های Parent و Child را غیر فعال و در مقابل از امکان Delegation ( واگذاری مسئولیت ) و فورواردینگ ( Forwarding ) استفاده نمائید .
• امکان Recursion و glue fetching را بمنظور حفاظت در مقابل عماکرد ناصحیح  DNS Cache ، غیر فعال نمائید .
• بمنظور حفاظت در رابطه با استفاده از “named” و  تحت تاثیر قرار دادن تمامی سیستم ، BIND را محدود نمائید . بنابراین BIND بعنوان یک کاربر non-privilage در دایرکتوری Chroot اجراء می گردد. برای نسخه شمازه نه BIND از آدرس  http://www.losurs.org/docs/howto/Chroot-BIND.html استفاده نمائید .

بمنظور حفاظت در مقابل حملات اخیر و مرتبط با  نقاط آسیب پذیر کشف شده BIND  می توان از منابع زیر استفاده نمود:

• برای نقطه آسیب پذیر DoS در رابطه با ISC BIND 9 از آدرس  http//www.cert.org/advisories/CA-2002-15.html استفاده گردد.
• چندین نقطه آسیب پذیر DoS در رابطه با ISC BIND 8  از آدرس  http://www.isc.org/products/BIND/bind-security.html استفاده گردد .

برای آگاهی و استفاده از پیشنهادات لازم بمنظور نصب ایمن تر BIND بر روی سیستم های سولاریس ، می توان از آدرس : Running the BIND9 DNS Server Securely و آرشیو مقالات ارائه شده در آدرس Afentis استفاده نمود.

دومین نقطه آسیب پذیر :  ( Remote Procedure Calls (RPC
با استفاده از RPC برنامه های موجود بر روی یک کامپیوتر قادر به  اجرای روتین هائی در کامپیوتر دوم از طریق  ارسال داده و بازیابی نتایج می باشند . با توجه به جایگاه عملیاتی RPC ، استفاده از آن  بسیار متداول بوده و درموارد متعددی از آن بمنظور ارائه سرویس های توزیع شده شبکه نظیر مدیریت از راه دور ، اشتراک فایل NFS و NIS  استفاده می گردد.وجود ضعف های امنیتی متعدد در RPC باعث  بهره برداری مهاجمان بمنظور انجام حملات مختلفی شده است .دراکثر موارد ، سرویس های RPC با مجوزهای بیش از حد معمول  ، اجراء می گردند . بدین ترتیب یک مهاجم غیر مجاز قادر به استفاده از سیستم های آسیب پذیر در جهت اهداف خود خواهد بود.اکثر حملات از نوع DoS در  سال ۱۹۹۹ و اوایل سال ۲۰۰۰ در ارتباط با سیستم هائی بود که دارای ضعف امنیـتی و نقظه آسیب پذیر RPC بودند. مثلا” حملات گشترده و موفقیت آمیز در رابطه با سیستم های نظامی امریکا ، بدلیل نقطه آسیب پذیر RPC کشف شده در صدها دستگاه کامپیوتر مربوط به وزارت دفاع امریکا بوده است . اخیرا” نیز  وجود یک ضعف امنیتی DCOM RPC  در ویندوز ،  باعث انتشار گسترده یک کرم  در سطح اینترنت گردید .

سیستم های عامل در معرض تهدید :
تمامی نسخه های یونیکس و لینوکس که بر روی آنان سرویس های RPC نصب شده است در معرض این آسیب می باشند .

نحوه تشخیص آسیب پذیری سیستم
با استفاده از یک پویشگر نقاط آسیب پذیر و یا دستور ” rpcinfo” ، می توان از اجراء یکی از سرویس های متداول RPC  بر روی سیستم آگاه گرید :

سرویس های RPC ، عموما” از طریق حملات buffer Overflow ، مورد سوء استفاده قرار می گیرند .علت این امر ، عدم انجام بررسی لازم و کافی در خصوص خطاها و یا اعتبار داده های ورودی توسط برنامه های RPC است . نقاط آسیب پذیر Buffer overflow ، این امکان را برای یک مهاجم فراهم می نماید که داده غیر قابل پیش بینی را ( اغلب بصورت کد مخرب ) به درون حافظه برنامه ، ارسال نماید . با توجه به ضعف موجود در رابطه با بررسی خطاء و  صحت داده ، داده ارسالی مکان هائی حساس و کلیدی که مورد استفاده پردازنده می باشند را بازنویسی می نماید.در یک تهاجم موفقیت آمیز Overflow ، کد مخرب ارسالی ،در ادامه توسط سیستم عامل اجراء می گردد . با توجه به اینکه تعداد زیادی از سرویس های RPC ، با مجوزهای بیش از حد معمول ،  اجراء می گردند ، استفاده موفقیت آمیز از نقاط آسیب پذیر فوق می تواند امکان دسـیابی غیر مجاز و از راه  دور را به سیستم فراهم می نماید.

نحوه حفاظت در مقابل نقطه آسیب پذیر
بمنظور حفاظت سیستم در مقابل حملات مبتنی بر RPC ، موارد زیر پیشنهاد می گردد :

• غیر فعال نمودن و یا حذف هر یک از سرویس های  RPC که ضرورتی به استفاده از آن  بر روی شبکه  نمی باشد .
• نصب آخرین Patch ارائه شده در رابطه با سرویس هائی که امکان حذف آنان وجود ندارد:
  - برای نرم افزار سولاریس از آدرس  ( http://sunsolve.sun.com )   استفاده گردد.
  - برای IBM AIX  از آدرس : http://www.ibm.com/support/us و  http://techsupport.services.ibm.com/server/fixes استفاده گردد.
  - برای نرم افزار SGI  از آدرس :  http://support.sgi.com استفاده گردد .
  - برای کامپک ( Digital Unix ) از آدرس    http://www.compaq.com/support
  - برای لینوکس  از آدرس :  http://www.redhat.com/apps/support/errata و http://www.debian.org./security استفاده گردد .
• عملیات جستجو بمنظور آگاهی و نصب آخرین Patch  مربوطه می بایست بصورت مستمر انجام شود.
• پورت ۱۱۱ ( TCP و UDP ) مربوط به RPC portmapper  و پورت ۱۳۵ ( TCP و UDP ) مربوط به  Windows RPC را در سطح روتر و یا فایروال بلاک نمائید .
• پورت های Loopback  ۳۲۷۷۰ ، ۳۲۷۸۹  مربوط بهTCP و UDP را بلاک نمائید .
• فعال نمودن یک پشته غیراجرائی  بر روی سیستم های عاملی که از ویژگی فوق ، حمایت می نمایند. استفاده از یک پشته غیراجرائی ، لایه ای حفاظتی در مقابل تمامی حملات Buffer overflows نبوده ولی می تواند عاملی موثر در جهت مقابله با برخی از حملات استاندارد گردد.
• در ارتباط با سیستم های فایل NFS صادراتی  ، مراحل زیر می بایست دنبال گردد :
  - استفاده از میزبان / IP   مبتنی بر لیست های صادراتی
  - پیکربندی سیستم های  فایل صادراتی بصورت فقط خواندنی
  - استفاده از “nfsbug” برای پویش نقاط آسیب پذیر

برای اخذ اطلاعات تکمیلی در رابطه با نقاط آسیب پذیر RPC ،  می توان از آدرس های زیر استفاده نمود :

• http://www.cert.org/advisories/CA-2000-17.html
• http://www.cert.org/advisories/CA-1999-05.html
• http://www.cert.org/advisories/CA-1997-26.html
• http://www.cert.org/advisories/CA-2002-26.html
• http://www.cert.org/advisories/CA-2002-20.html
• http://www.cert.org/advisories/CA-2001-27.html
• http://www.cert.org/advisories/CA-2002-25.html
• http://www.cert.org/advisories/CA-1999-08.html
• http://www.cert.org/advisories/CA-2002-11.html
• http://www.cert.org/advisories/CA-1999-16.html
• http://www.cert.org/advisories/CA-2001-11.html
• http://www.cert.org/advisories/CA-1998-12.html
• http://www.cert.org/advisories/CA-2001-05.html
• http://www.cert.org/advisories/CA-2002-10.html
• http://www.cert.org/advisories/CA-2003-10.html
• http://www.cert.org/advisories/CA-2003-16.html
• http://www.cert.org/advisories/CA-2003-19.html

در بخش دو م این مقاله به بررسی سایر نقاط آسیب پذیر یونیکیس و لینوکس خواهیم پرداخت .

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

• Smurf/smurfing : این نوع حملات مبتنی بر تابع Reply  پروتکل  Internet Control Message Protocol) ICMP)  ،بوده و بیشتر با نام  ping شناخته شده می باشند .( Ping ، ابزاری است که پس از فعال شدن از طریق خط دستور ، تابع Reply  پروتکل ICMP را فرامی خواند) .  در این نوع حملات ، مهاجم اقدام به ارسال بسته های اطلاعاتی Ping به آدرس های Broadcast شبکه نموده که در آنان آدرس مبداء هر یک از بسته های اطلاعاتی Ping شده با آدرس کامپیوتر قربانی ، جایگزین می گردد .بدین ترتیب یک ترافیک کاذب در شبکه ایجاد و امکان استفاده از منابع شبکه با اختلال مواجه می گردد.

• Fraggle : این نوع از حملات شباهت زیادی با حملات از نوع  Smurf داشته و تنها تفاوت موجود به استفاده از User Datagram Protocol ) UDP) در مقابل ICMP ، برمی گردد . در حملات فوق ، مهاجمان  اقدام به ارسال بسته های اطلاعاتی UDP به آدرس های Broadcast  ( مشابه تهاجم  Smurf  ) می نمایند . این نوع از بسته های اطلاعاتی UDP به مقصد پورت ۷ ( echo ) و یا پورت ۱۹ ( Chargen ) ، هدایت می گردند.

• Ping flood : در این نوع تهاجم ، با ارسال مستقیم درخواست های Ping به کامپیوتر فربانی ، سعی می گردد که  سرویس ها  بلاک  و یا فعالیت آنان کاهش یابد. در یک نوع خاص از تهاجم فوق که به ping of death ، معروف است ، اندازه بسته های اطلاعاتی به حدی زیاد می شود که سیستم ( کامپیوتر قربانی ) ، قادر به برخورد مناسب با اینچنین بسته های اطلاعاتی نخواهد بود .

• SYN flood : در این نوع تهاجم از مزایای three-way handshake  مربوط به TCP استفاده می گردد . سیستم مبداء اقدام به ارسال  مجموعه ای  گسترده از درخواست های synchronization ) SYN)  نموده بدون این که acknowledgment ) ACK) نهائی  آنان را ارسال نماید. بدین ترتیب half-open TCP sessions (ارتباطات نیمه فعال ) ، ایجاد می گردد . با توجه به این که پشته TCP ، قبل از reset نمودن پورت ، در انتظار باقی خواهد ماند ، تهاجم فوق ، سرریز بافر اتصال کامپیوتر مقصد را به دنبال داشته و عملا” امکان ایجاد ارتباط وی با سرویس گیرندگان معتبر ، غیر ممکن می گردد .

• Land : تهاجم فوق، تاکنون در نسخه های متفاوتی از سیستم های عامل ویندوز ، یونیکس ، مکینتاش و IOS سیسکو،مشاهده شده است . در این نوع حملات ، مهاجمان اقدام به ارسال یک بسته اطلاعاتی TCP/IP synchronization ) SYN) که دارای آدرس های مبداء و مقصد یکسان به همراه  پورت های مبداء و مقصد مشابه می باشد ، برای سیستم های هدف  می نمایند . بدین ترتیب سیستم قربانی، قادر به پاسخگوئی مناسب بسته اطلاعاتی نخواهد بود .

• Teardrop : در این نوع حملات از یکی از خصلت های UDP در پشته TCP/IP برخی سیستم های عامل ( TCPپیاده سازی شده در یک سیستم عامل ) ، استفاده می گردد. در حملات  فوق ، مهاجمان اقدام به ارسال بسته های اطلاعاتی fragmented برای سیستم هدف با مقادیر افست فرد در دنباله ای از بسته های اطلاعاتی می نمایند . زمانی که سیستم عامل سعی در بازسازی بسته های اطلاعاتی اولیه  fragmented می نماید،  قطعات ارسال شده بر روی یکدیگر بازنویسی شده و اختلال سیستم را به دنبال خواهد داشت . با توجه به عدم برخورد مناسب با مشکل فوق در برخی از سیستم های عامل ، سیستم هدف ، Crash و یا راه اندازی مجدد می گردد .

• Bonk : این نوع از حملات بیشتر متوجه ماشین هائی است که از سیستم عامل ویندوز استفاده می نمایند . در حملات فوق ، مهاجمان اقدام به ارسال  بسته های اطلاعاتی UDP  مخدوش به مقصد  پورت ۵۳ DNS ، می نمایند  بدین ترتیب در عملکرد سیستم  اختلال ایجاد شده و سیستم  Crash می نماید .

• Boink : این نوع از حملات مشابه تهاجمات  Bonk می باشند. با این تفاوت که در مقابل استفاده از  پورت ۵۳ ، چندین پورت ، هدف قرارمی گیرد .

متداولترین  پورت های استفاده شده در حملات DoS

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

حملات از نوع Back door
Back door ، برنامه ای است که امکان دستیابی به یک سیستم را بدون بررسی و کنترل امنیتی ، فراهم می نماید . برنامه نویسان معمولا” چنین پتانسیل هائی  را در برنامه ها پیش بینی تا امکان اشکال زدائی و ویرایش کدهای نوشته شده در زمان تست بکارگیری نرم افزار ، فراهم گردد. با توجه به این که تعداد زیادی از امکانات فوق ، مستند نمی گردند ، پس از اتمام مرحله تست به همان وضعیت باقی مانده و تهدیدات امنیتی متعددی را به دنبال خواهند داشت .
برخی از متداولترین نرم افزارها ئی که از آنان به عنوان back door استفاده می گردد ، عبارتند از :

• Back Orifice : برنامه فوق یک ابزار مدیریت از راه دور می باشد که به مدیران سیستم امکان کنترل یک کامپیوتر را از راه دور ( مثلا” از  طریق اینترنت ) ، خواهد داد. نرم افزار فوق ، ابزاری  خطرناک است که  توسط گروهی با نام Cult of the Dead Cow Communications ، ایجاد شده است . این نرم افزار دارای دو بخش مجزا می باشد : یک بخش سرویس گیرنده و یک بخش سرویس دهنده . بخش سرویس گیرنده بر روی یک ماشین اجراء و زمینه مانیتور نمودن و کنترل یک ماشین دیگر که بر روی آن بخش سرویس دهنده اجراء شده است را فراهم می نماید .

• NetBus : این برنامه نیز نظیر Back Orifice ، امکان دستیابی و کنترل از راه دور یک ماشین از طریق اینترنت را فراهم می نماید.. برنامه فوق تحت سیستم عامل ویندوز ( نسخه های متفاوت از NT تا ۹۵ و ۹۸ ) ، اجراء و از دو بخش جداگانه تشکیل شده است :  بخش  سرویس دهنده ( بخشی که بر روی کامپیوتر قربانی مستقر خواهد شد ) و  بخش سرویس گیرنده ( برنامه ای که مسولیت یافتن و کنترل سرویس دهنده را برعهده دارد ) . برنامه فوق ، به حریم خصوصی کاربران در زمان اتصال به اینترنت ، تجاوز و تهدیدات امنیتی متعددی را به دنبال خواهد داشت .

• Sub7) SubSeven) ،  این برنامه برنامه نیز تحت ویندوز اجراء شده  و دارای عملکردی مشابه Back Orifice و NetBus می باشد . پس از فعال شدن برنامه فوق بر روی سیستم هدف و اتصال به اینترنت ،هر شخصی که دارای نرم افزار سرویس گیرنده باشد ، قادر به دستیابی نامحدود به سیستم خواهد بود .

نرم افزارهای Back Orifice ، NetBus,  Sub7 دارای دو بخش ضروری سرویس دهنده و سرویس گیرنده، می باشند . سرویس دهنده بر روی ماشین آلوده مستقر شده و از بخش سرویس گیرنده به منظور کنترل از راه دور سرویس دهنده ، استفاده می گردد.به نرم افزارهای فوق ، ” سرویس دهندگان غیرقانونی “  گفته می شود .
برخی از نرم افزارها از اعتبار بالائی برخوردار بوده ولی ممکن است توسط کاربرانی که اهداف مخربی دارند ، مورد استفاده قرار گیرند :

• Virtual Network Computing)VNC) : نرم افزار فوق توسط آزمایشگاه AT&T و با هدف کنترل از راه دور یک سیستم ، ارائه شده است . با استفاده از برنامه فوق ، امکان مشاهده محیط Desktop از هر مکانی نظیر اینترنت ، فراهم می گردد . یکی از ویژگی های جالب این نرم افزار ، حمایت گسترده از معماری های متفاوت است .

• PCAnywhere : نرم افزار فوق توسط شرکت Symantec ، با هدف کنترل از راه دور یک سیستم با لحاظ نمودن فن آوری رمزنگاری و تائید اعتبار ، ارائه شده است . با توجه به سهولت استفاده از نرم افزار فوق ، شرکت ها و موسسات فراوانی در حال حاضر از آن و به منظور دستیابی به یک سیستم از راه دور استفاده می نمایند .

• Terminal Services : نرم افزار فوق توسط شرکت مایکروسافت و به همراه سیستم عامل ویندوز و به منظور کنترل از راه دور یک سیستم ، ارائه شده است .

همانند سایر نرم افزارهای کاربردی ، نرم افزارهای فوق را می توان هم در جهت اهداف مثبت و هم در جهت اهداف مخرب بکارگرفت.
بهترین روش به منظور پیشگیری از حملات  Back doors ، آموزش کاربران و مانیتورینگ عملکرد هر یک از نرم افزارهای موجود می باشد. به کاربران می بایست آموزش داده شود که صرفا” از منابع و سایت های مطمئن اقدام به دریافت و نصب نرم افزار بر روی سیستم خود نمایند . نصب و استفاده از برنامه های آنتی ویروس می تواند کمک قابل توجهی در بلاک نمودن عملکرد اینچنین نرم افزارهائی ( نظیر : Back Orifice, NetBus, and Sub7 ) را به دنبال داشته باشد . برنامه های آنتی ویروس می بایست به صورت مستمر بهنگام شده تا امکان شناسائی نرم افزارهای جدید ، فراهم گرد

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

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

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

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

• Logon Server : این نوع سرویس دهندگان مسئولیت شناسائی و تائید کاربران در زمان ورود به شبکه را برعهده دارند . سرویس دهندگان فوق می توانند عملیات خود را به عنوان بخشی در کنار سایر سرویس دهندگان نیز انجام دهند .

• Network Services Server : این نوع از سرویس دهندگان مسئولیت میزبان نمودن سرویس های مورد نیاز شبکه را  برعهده دارند . این سرویس ها عبارتند از :
  - Dynamic Host Configuration Protocol )  DHCP)
  - Domain Name System ) DNS)
  - Windows Internet Name Service)  WINS)
  - Simple Network Management Protocol )  SNMP)

• Application Server : این نوع از سرویس دهندگان مسئولیت میزبان نمودن برنامه ها ی کاربردی نظیر بسته نرم افزاری Accounting و سایر نرم افزارهای مورد نیاز در سازمان را برعهده دارند .

• File Server : از این نوع سرویس دهندگان به منظور دستیابی به فایل ها و دایرکتوری ها ی کاربران ، استفاده می گردد .

• Print Server : از این نوع سرویس دهندگان به منظور دستیابی به چاپگرهای اشتراک گذاشته شده در شبکه ، استفاده می شود .

• Web Server : این نوع سرویس دهندگان مسئولیت میزبان نمودن برنامه های وب و وب سایت های داخلی و یا خارجی را برعهده دارند .

• FTP Server : این نوع سرویس دهندگان مسئولیت ذخیره سازی فایل ها برای انجام عملیات Downloading و Uploading را برعهده دارند. سرویس دهندگان فوق می توانند به صورت داخلی و یا خارجی استفاده گردند .

• Email Server : این نوع سرویس دهندگان مسئولیت ارائه سرویس پست الکترونیکی را برعهده داشته و می توان از آنان به منظور میزبان نمودن فولدرهای عمومی و برنامه های Gropuware ، نیز استفاده نمود.

• News/Usenet (NNTP) Server : این نوع سرویس دهندگان به عنوان یک سرویس دهنده newsgroup  بوده  و کاربران می توانند اقدام به ارسال و دریافت پیام هائی بر روی آنان  نمایند .

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

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

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

• به چه نوع پروتکل و یا پروتکل هائی برای ارتباط سرویس گیرندگان ( Desktop ) با سرویس دهندگان ، نیاز می باشد ؟

• به چه نوع پروتکل  و یا پروتکل هائی برای ارتباط سرویس دهنده با  سرویس دهنده ، نیاز می باشد ؟

• به چه نوع پروتکل  و یا پروتکل هائی برای ارتباط سرویس گیرندگان ( Desktop ) از راه دور  با سرویس دهندگان ، نیاز می باشد ؟

• آیا پروتکل و یا پروتکل های انتخاب شده ما را ملزم به نصب سرویس های اضافه ای می نمایند ؟

• آیا پروتکل های انتخاب شده دارای مسائل امنیتی خاصی بوده که می بایست مورد توجه و بررسی قرار گیرد ؟

در تعداد زیادی از شبکه های کامپیوتری ،از چندین سیستم عامل نظیر ویندوز ، یونیکس و یا لینوکس ، استفاده می گردد . در چنین مواردی می توان از پروتکل TCP/IP به عنوان فصل مشترک بین آنان استفاده نمود. در ادامه می بایست در خصوص فرآیند اختصاص آدرس های IP تصیم گیری نمود ( به صورت ایستا و یا پویا و به کمک DHCP ) . در صورتی که تصمیم گرفته شود که فرآیند اختصاص آدرس های IP به صورت پویا و به کمک DHCP ، انجام شود، به یک سرویس اضافه و با نام DHCP نیاز خواهیم داشت . با این که استفاده از  DHCP  مدیریت شبکه را آسانتر می نماید ولی از لحاظ امنیتی دارای درجه پائین تری نسبت به اختصاص ایستای  آدرس های IP ، می باشد چراکه کاربران ناشناس و گمنام می توانند پس از اتصال به شبکه ،  بلافاصله از منبع صادرکننده آدرس های IP ، یک آدرس IP را دریافت و به عنوان یک سرویس گیرنده در شبکه ایفای وظیفه نمایند. این وضعیت در ارتباط با شبکه های بدون کابل غیرایمن نیز صدق می نماید. مثلا” یک فرد می تواند با استقرار در پارکینگ یک ساختمان و به کمک یک Laptop به شبکه شما با استفاده از یک اتصال بدون کابل ، متصل گردد.  پروتکل TCP/IP  ، برای “معادل سازی نام به آدرس ” از یک سرویس دهنده DNS نیز استفاده می نماید . در شبکه های ترکیبی شامل چندین سیستم عامل نظیر ویندوز و یونیکس  و با توجه به این که ویندوز NT 4.0 و یا ۲۰۰۰ شده است ، علاوه بر  DNS به سرویس  WINS  نیز نیاز می باشد . همزمان با انتخاب پروتکل ها و سرویس های مورد نیاز آنان ، می بایست بررسی لازم در خصوص چالش های امنیتی هر یک از آنان نیز بررسی  و اطلاعات مربوطه مستند گردند( مستندسازی ، ارج نهادن به زمان خود و دیگران است ) . راه حل انتخابی ، می بایست کاهش تهدیدات مرتبط با هر یک از سرویس ها و پروتکل ها را در یک شبکه به دنبال داشته باشد .

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

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

• یک زبان نشانه گذاری با تاکید بر یک گرامر تعریفی

• امکان استفاده از اسکریپت های خاص بمنظور انجام عملیات پیچیده

• امکان استفاده  بعنوان یک زبان برنامه نویسی کامل

اهداف طراحی XSL بشرح زیر است :

• XSL ، می بایست براحتی از طریق اینترنت قابل استفاده باشد.

• XSL ، می بایست همراه با گرامر XML  ارائه  شود

• XSL ، می بایست یک زبان تعریفی بمنظور انجام عملیات رایج در رابطه با  فرمت دهی باشد.

• XSL ، می بایست امکان استفاده از یک زبان اسکریپت را بمنظور افزایش توان عملیاتی فراهم نماید .

• XSL ، می بایست امکان تطبیق یک CSS  را به یک XSL stylesheet فراهم نماید .

• قابلیت استفاده آسان از XSL ، برای کاربرانی که دارای تجربه لازم در رابطه با زبان FOSI می باشند .

• تعداد ویژگی انتخابی در XSL ، می بایست حداقل مقدارممکن را دارا باشد .

• Stylesheet های نوشته شده بکمک XSL ، می بایست خوانائی مطلوبی را داشته باشند .

• طراحی XSL ، می بایست بسرعت انجام شود .

• ایجاد stylesheet بکمک XSL ، می بایست بسادگی انجام شود .

زبان ارائه شده  در اولین پیشنهاد ، دارای اغلب مفاهیم کلیدی XSLT است ، که در نهایت ارائه گردید . بمنظور طراحی گرامر زبان فوق از رویکرد مبتنی بر تمپلیت استفاده گردید . بدین ترتیب امکان برخورد با  گره ها ی موجود در سند مبداء و تطبیق آنها با یک الگوی تعریف شده ، فراهم می گردد . عدم وجود اثرات جانبی  و امکان تفسیر و برخورد با سندهای با حجم بالا ، از دیگر مواردی است که در زمان طراحی XSL به آنها توجه جدی گردید . برآیند  تمام تلاش های فوق، عرضه اولین نسخه پیشنهادی XSLT در سال ۱۹۹۸ بود . زبان پیشنهادی در سال   ۱۹۹۹ ،بصورت حرفه ای مطرح و مورد استفاده  قرار گرفت .
XSLT بعنوان یک زبان
XSLT ، دارای چه ویژگی منحصربفردی است که آن را بعنوان یک زبان برنامه نویسی از سایر زبان ها متمایز می نماید ؟ در این بخش به سه مورد اساسی اشاره خواهد گردید : استفاده از گرامر مبتنی بر XML  ، عدم وجود تاثیرات جانبی و  پردازش مبتنی بر  مجموعه ای از قوانین
استفاده از گرامر مبتنی بر XML
همانگونه که قبلا” اشاره گردید ، استفاده از گرامر SGML برای Stylesheet از سال ۱۹۹۴ مطرح شده بود . ایده استفاده از SGML در این زمینه ، دارای مشکلات خاص خود است . بمنظور عرضه stylesheet در XSLT ، از گرامر مبتنی بر XML استفاده می شود . رویکرد فوق دارای مزایای زیر است :

• از مزیت وجود یک پارسر XML در مرورگرها ، استفاده خواهد کرد .

• اغلب افراد از عدم وجود یک گرامر همگن و سازگار بین HTML  ، XML و CSS گلایه داشته و تمایلی به تکرار آن با یک گرامر جدید ندارند .

• اکثر زبان های مبتنی بر تمپلیت در حا ل حاضر، بعنوان یک outline از  سند خروجی  بوده که با دستورالعمل هائی نیز همراه می باشند  و از این نظر مفهوم فوق ، کاملا” شناخته شده است .

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

• حمایت از  یونیکد

• ضرورت استفاده از یک Stylesheet بعنوان ورودی و یا خروجی در زمان تبدیل ، بدفعات احساس خواهد شد( سیستم تبدیل ) . این ویژگی  که یک stylesheet  قادر به خواندن و نوشتن سایر Stylesheet ها  باشد ، یک مزیت تلقی می گردد .

اثرات جانبی
یکی از اهداف اولیه  در رابطه با طراحی XSLT ، عدم بروز اثرات جانبی در زمان استفاده از آن است . یک تابع و یا برنامه جانبی در صورتیکه باعث ایجاد تغییرات در محیط مربوط بخود شوند ، دارای اثرات جانبی خواهند بود. مثلا” تابعی که باعث تغییر مقدار یک متغیر سراسری مورد استفاده سایر توابع می گردد ، دارای اثرات جانبی بوده و می تواند در عملکرد سایر توابعی که از مقدار متغیر فوق استفاده می نمایند ، تاثیری منفی را بدنبال داشته باشد. بدیهی است توابعی که دارای اثرات جانبی می باشند، می بایست بدفعات مشخص و با یک نظم و اولویت خاص بخدمت گرفته شوند ( فراخوانی ). مثلا” در صورتیکه تابعی برای محاسبه محیط یک مثلث نوشته شده باشد که دارای اثرات جانبی نیست ، می توان با خیال آسوده تابع فوق را بدفعات استفاده و همواره انتظار عملکرد یکسانی را نیز از آن داشته باشیم ( محاسبه محیط مثلث با توجه به پارامترهای مربوطه ) . در صورتیکه تابع فوق دارای اثرات جانبی باشد ، (مثلا” تغییر اندازه  اضلاع مثلث)  استفاده از آن  بدفعات بسیار محدود ( یک مرتبه)  منطقی بوده و در صورت تکرار در استفاده از چنین تابعی ،  نباید انتظارعملکردی مثبت از آن را داشته باشیم . در صورتیکه زبانی دارای اثرات جانبی باشد، اولویت اجرای دستورالعمل ها در آن می بایست، بدرستی مشخص شود .در زبان هائی که دارای اثرات جانبی نمی باشند  ، امکان اجرای دستورالعمل ها  با هر اولویتی وجود خواهد داشت . این بدان  معنی است که می توان بخش هائی از یک Stylesheet  انتخابی را بصورت مستقل اجراء نمود . XSLT زبانی مناسب در این رابطه بوده و با توجه به انتظارات موجود در رابطه با اسناد ورودی ،  پتانسیل های لازم را بدون وجود اثرات جانبی ،  در اختیار استفاده کنندگان قرار می دهد .
زبان انتخابی ، می بایست برای استفاده در موارد batch و محاوره ای مناسب باشد . زمانیکه یک سند XML  با ظرفیت بالا ، از  سرویس دهنده ای اخذ می گردد ، مادامیکه آخرین بایت آن از سرویس دهنده دریافت نگردد، امکان  مشاهده هیچ چیزی وجود نخواهد داشت . در صورت اعمال  تغییرات اندک در یک سند XML ، انتظار داریم که اثر تغییرات انجام شده  در رابطه با نمایش سند را سریعا” مشاهده نمائیم . . در این رابطه لازم است به این نکته نیز اشاره گردد که  تعیین بخشی از سند خروجی که متاثر از تغییرات اندکی در یک بخش از سند ورودی است ، عملی ساده نخواهد بود . تمام پردازنده های XSLT ، نیازمند استقرار کامل سند XML در حافظه ، قبل از انجام هر گونه عملیاتی می باشند .  مورد فوق یکی از چالش های اصلی XSLT در مواجهه با سندهای XML با حجم بالا است .
XSLT مبتنی بر قوانین است
یک XSLT Stylesheet ، شامل مجموعه ای از قوانین مبتنی بر  تمپلیت است . هر یک از تمپلیت ها ، نحوه پردازش یک المان خاص را مشخص خواهند کرد . قوانین با یک نظم و اولویت خاص سازماندهی نشده و ضرورتی به رعایت اولویت و نظم در ورودی و یا خروجی نخواهند بود . زمانیکه XSLT  ، بعنوان یک زبان تعریفی در نظر گرفته می شود، می توان گفت که :  ” زمانیکه الگوهای خاصی در سند مبداء پیدا گردید ، چه نوع  اطلاعاتی و به چه صورت می بایست در خروجی ارائه شود.”
ساختار مبتنی بر قوانین ، بسیار مشابه CSS است . نحوه برخورد با الگوها  در CSS و XSLT کاملا” متفاوت است  . مثلا” در CSS عنوان می شود که  قانون تعریف شده در رابطه با کدام گره می بایست اعمال گردد ، در صورتیکه در XSLT مشخص می شود که در زمان یافتن یک الگوی  مشخص شده در سند مبداء ، چه عملیاتی می بایست انجام شود.

چه زمانی می بایست از XSLT استفاده کرد ؟

استفاده از XSLT در موارد زیر پیشنهاد می گردد :

• برنامه های تبدیل داده . زمانیکه قصد تبدیل یک مجموعه داده مبتنی بر XML را به فرمت دیگر XML داشته باشیم ، XSLT  گزینه ای مناسب خواهد بود . با استفاده از XSLT ، می توان عملیات متفاوتی نظیر انتخاب داده هائی خاص  از یک سند XML  ، ذخیره سازی داده های مورد نظر و موارد متنوع دیگری  را انجام داد . از XSLT  می توان بمنظور معتبر سازی داده ها نیز استفاده کرد . XSLT ، بعنوان یک زبان برنامه نویسی، گزینه ای مناسب برای انجام پردازش های لازم در خصوص ساختار اطلاعاتی است که از محتویات مربوط جدا شده اند . از XSLT می توان در رابطه با تبدیل یک سند XML به فرمت های مبتنی بر متن نیز استفاده کرد . ( مثلا” اطلاعات متنی که توسط ویرگول از هم جدا شده اند ) . یکی دیگر از ویژگی های جالب XSLT ، امکان استفاده از آن در رابطه با تبدیل یک سند غیره XML به یک سند XML و یا سایر فرمت های دلخواه دیگر است . در این مورد خاص، لازم است که یک نوع  پارسر بمنظور تشخیص فرمت داده های ورودی نوشته گردد . پس از نوشتن پارسر، عملیات تبدیل ، توسط یک زبان سطح بالا میسر می گردد .

• نشر اطلاعات . تفاوت بین تبدیل و نشر اطلاعات به مقصد داده ها بر می گردد . در مواردیکه تبدیل صورت می پذیرد، مقصد داده های تبدیل شده یک نرم افزار دیگر بوده در صورتیکه در زمان  نشر ، کاربران (انسان)  مقصد نهائی اطلاعات می باشند. تبدیل با نمایش و تبدیل بدون نمایش گزینه هائی  متفاوت بمنظور شناخت مفهوم نشر اطلاعات  است . در زمان  نشر اطلاعات، نیاز به ارائه  آنان بر روی کاغذ ( چاپ ) و یا وب خواهد بود . نشر اطلاعات بر روی کاغذ، مستلزم عملیات بمراتب پیچیده تری خواهد بود . در این حالت خاص ، کاربران دارای انتظار بالائی در رابطه با کیفیت می باشند. XSL FO ، امکانی بمنظور تعریف یک مدل مبتنی بر XML از یک فایل چاپی بمنظور نمایش با کیفیت بالا بر روی صفحات نمایشگر و یا کاعذ است . نشر اطلاعات بر روی وب دارای چالش های بمراتب کمتری نسبت به کاغذ است . در این مدل خاص، صرفا” می بایست داده ها به Html تبدیل و در ادامه مرورگرها  مسئولیت ارائه اطلاعات را با فرمت تعریف شده بر عهده خواهند گرفت . تبدیل یک سند XML به Html ، یکی از متداولترین کاربردهای XSLT در حال حاضر است . در این رابطه دو مرحله عملیات دنبال خواهد شد : در اولین مرحله، داده ها به یک مدل مبتنی بر XML که از لحاظ ساختاری شباهت زیادی را با سند Html مقصد دارد ، تبدیل و در دومین مرحله ، ساختار مشخص شده ، با تاکید بر امکانات Html نمایش داده خواهد شد .

XSLT و XPath
در زمان پیاده سازی XSLT ، برخی تعارضات بین گرامر عبارات استفاده شده در XSLT (بمنظور انتخاب بخش های خاصی از یک سند)  و زبان XPointer ( بمنظور ارتباط یک سند با سند دیگر) بروزکرد . بمنظور ممانعت از داشتن دو زبان متفاوت عبارات که با یکدیگر overlap دارند  ، کمیته های  XSLT و XPointer  کنسرسیوم وب ، تصمیم به ترکیب  توان آنها با یکدیگر و تعریف یک زبان جدید با نام XPath  نمودند .  نسخه شماره یک XPath ، همزمان با ارائه XSLT  نیز عرضه گردید ( شانزدهم نوامبر سال ۱۹۹۹ ) .
XPath ،  بعنوان یک زبان زیرمجموعه در یک XSLT stylesheet ایفای وظیفه می نماید . یک عبارت XPath ، ممکن است بمنظور انجام یک محاسبات عددی و یا عملیات بر روی رشته ها  و یا بررسی شرایط منطقی استفاده گردد . ،XPath در اغلب حالات بمنظور مشخص نمودن بخش های متفاوت یک سند ورودی که قصد انجام پردازش بر روی آن وجود دارد استفاده می گردد . مثلا” دستورالعمل زیر  قیمت میانگین را برای تمام کتاب های موجود در یک سند ورودی محاسبه می نماید .

در مثال فوق ، المان <xsl:value-of> یک دستورالعمل تعریف شده در XSLT است . دستورالعمل فوق ، باعث نوشتن  یک مقدار در سند خروجی می گردد . خصلت select ، یک عبارت مبتنی بر XPath است . عبارت فوق، مسئول محاسبه مقداری است که می بایست در خروجی نمایش داده شود . در این مثال خاص ، مجموع خصلت های price مربوط به تمام المان های <book> محاسبه و بر تعداد المان های موجود <book>  تقسیم تا معدل مربوطه محاسبه گردد .
تفکیک XPath و XSLT از یکدیگر منطقی بنظر می آید ولی در مواردی خاص تقسیم بندی و تمایز انجام شده باعث بروز مسائلی می گردد .در برخی حالات ، تشخیص اینکه کدام سند می بایست  خوانده شده تا پاسخ مناسب در رابطه با یک سوال خاص داده شود، مشکل خواهد بود . مثلا” یک عبارت XPath می تواند شامل یک مرجع  به  متغیری باشد ، ولی ایجاد  و مقدار دهی اولیه آن از وظایف XSLT است . جایگاه تعریف یک تابع در Xpath و XSLT  یکی دیگر از مسائل مربوط به تفکیک دو تکنولوژی فوق است . عبارات XPath قادر به فراخوانی توابع می باشند ( در این راستا مجموعه گسترده ای از توابع استادندارد تعریف شده است ) . برخی از آنان نظیر  string-lenght در عبارات XPath تعریف شده در صورتیکه  توابعی  دیگر که عملکرد  آنها  در ارتباط با تعاریف XSLT است (نظیر key ) ، در مشخصه XSLT تعریف می گردند . اغلب XSLT و XPath  در کنار یکدیگر استفاده می گردند . فراموش نکنیم که امکان استفاده از XPath  بصورت مستقل و بمنظور انجام عملیات متفاوتی نظیر تعریف ابرلینک های موجود در اسناد و …. نیز وجود دارد .

XSLT و XML
XSLT ،  ابزاری برای تبدیل اسناد XML است . در بخش اول این مقاله ، به ضرورت های  تبدیل اشاره گردید. در این بخش لازم  است به بررسی ارتباط دو تکنولوژی فوق با نگرشی عمیق تر ، پرداخته گردد .  مفاهیم   XML namespace و XML information set از جمله مواردی می باشند که زمینه تعامل ارتباطی بین XML و XSLT را فراهم می نمایند  . در ادامه هر یک از موارد فوق توضیح داده می شود :
XML namespace
در طراحی XSLT  بر نقش مهم و کلیدی XML namespace در استاندارد XML  توجه جدی شده است . بنابراین زمانیکه استاندارد XSLT به یک سند XML مراجعه می نماید ، عملا” مشخصات XML namespace  نیز مورد توجه قرار گرفته شده است  . مشخصات و استانداردهای مربوط به namespace را می توان  در آدرس  http://www.w3.org/TR/REC-xml-names مشاهده نمود .
Namespace  دارای نقشی حیاتی در XSLT است . تکنولوژی فوق ،امکان ترکیب تگ هائی از سند های XML مشابه با معانی متفاوت را فراهم می نماید . مثلا” ممکن است در یک سند XML ، المان <table> نشاندهنده یک بردار دو بعدی شامل  مقایر متفاوت داده بوده در صورتیکه در سند دیگر، المان <table> نشاندهنده بخشی از یک مبلمان باشد . Namespace توسط یک URI) Unique Resource Identifier) مشخص می گردد. بدین منظور از روش های متفاوتی استفاده می گردد. مثلا” در یک مدل،  از آدرس  مشابه یک URL معمولی استفاده می گردد:(http://www.yourcomany.com ) . در روش دیگر در برخی از اصطلاحات XML ( نظیر http://www.biztalk.org)  استفاده می گردد ، URN است . ( مثلا” urn:java:com:ic1.saxson ) . جزئیات مربوط به  URI  مهم  نبوده ولی همواره می بایست به این مسئله توجه گردد که نام در نظر گرفته شده  منحصر بفرد باشد . یکی از روش های مناسب تحقق وضعیت فوق،  استفاده از URL مربوط به سایت خود می باشد . لازم به توضیح است  که موضوع فوق بدین معنی نخواهد بود که  می بایست بر روی وب سایت ، آیتمی  بمنظور اشاره کردن به آن ، وجود داشته باشد . URI در حقیقت رشته ای است که بمنظور تمایز با  تعاریف انجام شده  توسط سایر افراد انتخاب می گردد .
با توجه به اینکه رشته های  URI اغلب طولانی و از کاراکترهای خاصی نظیر “/” استفاده می نمایند، از آنها  بصورت کامل همراه اسامی المان ها  و خصلت ها استفاده نمی گردد . بدین منظور اغلب از یک نام مستعار کوچک استفاده می شود . نام مستعار، بصورت  پیشوند در کنار اسامی المان ها و خصلت ها استفاده می شود . نام در نظرگرفته شده  برای پیشوند مهم نبوده و هر نامی را می توان انتخاب کرد . بدین ترتیب نام واقعی هر المان و یا خصلت ، از طریق URI مربوط به namespace و نام محلی آن ( آن بخش از نام که بعد از پیشوند قرار می گیرد )  مشخص خواهد شد . مثلا” می توان با استفاده از پیشوند xsl به namespace مربوط به http://www.w3.org/1999/XSLT/Transform اشاره  کرد . برای اسامی المان ها ، می توان یک URI پیش فرض را تعریف  و آن را به اسامی المان غیرپیشوندی مرتبط نمود . namespace پیش فرض URI  به اسامی خصلت های غیر پیشوندی نسبت داده نخواهد شد . تعریف یک پیشوند namespace  بصورت زیر است :

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

پردازش یک سند XML  توسط XSLT متاثر از واقعیت های موجود در  namespace  خواهد بود .

XML information set
XSLT بمنظور انجام پردازش های ضروری بر روی اطلاعات موجود در یک  سند XML ، طراحی  و با سند کاری نخواهد داشت . این بدان معنی است که ، یک برنامه نویس XSLT  قادر به دریافت یک  نمایش شبه درختی از یک سند مبداء بوده  که برخی از بخش های آن قابل مشاهد و برخی دیگر غیرقابل مشاهده خواهند بود. مثلا”می توان  اسامی و مقدار خصلت ها را مشاهده نمود  ولی امکان مشاهده اینکه یک خصلت در یک کوتیشن و یا دو کوتیشن استفاده شده ، وجود نخواهد داشت . همچنین امکان  مشاهده  نظم و اولویت خصلت ها و نحوه نگارش آنها وجود نخواهد داشت .تلاش های متعددی بمنظور تعریف اطلاعات مورد نیاز برای مشخص نمودن “خوش شکل ” بودن یک سند XML انجام شده است . در بیست و چهارم اکتبر ۲۰۰۱ ،کنسرسیوم وب محموعه اطلاعات مورد نیاز و تعریف شده در رابطه با یک سند XML را استاندارد و پیشنهاد داده است . مشخصات فوق را می توان از طریق آدرس http://www.w3.org/TR/xml-infoset مشاهده کرد .  این مشخصات  ، شامل  مجموعه ای از تعاریف مورد نیاز سایر تکنولوژی هائی است که نیازمند دستیابی به اطلاعات موجود در یک سند XML  می باشند . یک سند XML دارای مجموعه ای از اطلاعات ضروری بوده که “خوش شکل ” بودن آن را تضمین و سایر تکنولوژی های مربوطه با مراجعه به اطلاعات فوق قادر به برداشت مناسب از یک سند XML و انجام عملیات مربوط به خود خواهند بود . مجموعه اطلاعات یک سند XML شامل تعدادی از آیتم های اطلاعاتی است .  مجموعه اطلاعات مربوط به یک سند XML  ” خوش شکل “  ، حداقل دارای یک آیتم اطلاعاتی است . یک آیتم اطلاعاتی بخش خاصی از یک سند XML را تشریح و شامل مجموعه ای از خصلت های مربوط به خود است .

XSL و CSS
چرا دو زبان ( XSL و CSS )  مختص stylesheet وجود دارد؟ منظور از XSL  ، تکنولوژی XSLT بهمراه XSL Formating objects  است . مهمترین هدف  CSS ، تبین قوانین لازم بمنظور نمایش عناصر موجود در یک سند  Html می باشد . در این راستا امکان استفاده از CSS بهمراه سندهای XML نیز وجود دارد . با توجه به  ویژگی های خاص  نمایش  در رابطه با یک سند  XML ، بکارگیری تکنولوژی CSS  محدودیت های خاصی را بدنبال خواهد داشت  . در این زمینه می توان به موارد زیر اشاره کرد :

• CSS ، قادر به ثبت ( ذخیره ) المان های موجود در یک سند XML  نمی باشد .

• CSS ، قادر به افزودن متن و یا تصاویر نمی باشد .

• CSS ، قادر به تصمیم گیری در رابطه با اینکه چه المانی می بایست نمایش داده شده و یا اینکه چه المانی می بایست حذف گردد،نخواهد بود .

• CSS ، قادر به محاسبه مجموع و یا معدل دنباله ای از اعداد نمی باشد .

CSS ، صرفا” در زمانیکه ساختار سند مبداء شباهت زیادی به شکل نهائی نمایش دارد ، مفید و قابل استفاده است . صرفنظر از محدودیت های فوق ، استفاده از CSS  ساده بوده و منابع زیادی را بر روی ماشین بخود اختصاص نخواهد داد . ( مقرون بصرفه از بعد در اختیار گرفتن منابع ) . با توجه به عدم ذخیره سازی سند ، ضرورتی به ایجاد یک مدل شبه درختی برای نمایش و ارائه سند در حافظه نبوده و بلافاصله پس از دریافت اولین متون موجود ، فرآیند نمایش آنها آغاز می گردد .
در برخی حالات ، مناسب است که از XSLT و CSS در کنار یکدیگر استفاده نمود. مثلا” با استفاده از XSLT می توان یک مدل قابل قبول از سند مورد نظر را که قصد نمایش نهائی آن را داریم ، ( در مدل فوق متن ها بدرستی و با اولویت مناسب مستقر شده اند) ایجاد  و در ادامه  با استفاده از CSS ، عملیات لازم در رابطه با انتخاب نوع فونت ، اندازه فونت ، رنگ ها و … را انجام داد . در این راستا  امکان پردازش XSLT بر روی سرویس دهنده و پردازش CSS ، بر روی سرویس گیرنده وجود خواهد داشت . یکی  از مزایای رویکرد فوق ، کاهش حجم داده های ارسالی از طریق خط ارتباطی بوده و بدین ترتیب مدت زمان پاسخ به کاربران، بهبود پیدا خواهد کرد .
در بخش سوم این مقاله به نحوه شکل گیری و طراحی XSLT  اشاره  و جایگاه آن بعنوان یک زبان برنامه نویسی تبین خواهد شد

جرا سندهای XML نیازمند تبدیل می باشند ؟
XML ، روشی ساده و استاندارد بمنظور مبادله داده های ساختیافته بین برنامه های متفاوت کامپیوتر است . بخشی از موفقیت XML جهت نیل به خواسته فوق ، به نحوه نوشتن و خواندن این نوع فایل ها بر می گردد . با استفاده از یک ادیتور متنی می توان بسادگی و بسرعت اقدام به نوشتن یک سند XML ،خواندن و اعمال تغییرات در آنان نمود. فراموش نکنیم که مهمترین هدف XML ، ارتباط بین سیتستم های متفاوت نرم افزاری بوده و در این راستا  به دو نیاز  حیاتی  بخوبی جواب داده است :
تفکیک داده از نمایش ( ارائه ) . نیاز به تفکیک اطلاعات از جزئیات نمایش بر روی یک دستگاه خاص همواره مورد نظر طراحان و پیاده کنندگان بوده است . خواسته  فوق ، بموازات رشد دستگاههای مبتنی بر اینترنت به یک ضرورت حیاتی تبدیل شده است . سازمان ها و موسسات ارائه دهنده اطلاعات باارزش  ، تمایل به عرضه اطلاعات خود بر  روی مرورگرهای وب و سایر دستگاهها  نظیر تلویزیون  و یا تلفن های مبتنی بر WAP را دارند . بدین ترتیب دامنه استفاده از اطلاعات صرفا” به مرورگرهای وب محدوده نبوده و دستگاههای متفاوت مبتنی بر تکنولوژی اینترنت را  شامل می گردد .
ارسال داده بین برنامه ها . ارسال اطلاعات از  سازمانی  به سازمان دیگر بدون در گیر شدن در جزئیات ، همواره از آرزوهای بزرگ طراحان و پیاده کنندگان سیستم های نرم افزاری بوده است .

دو خواسته فوق هیچگونه تعارضی با یکدیگر ندارند ، مثلا” یک لیست قیمت کالا را می توان بر روی صفحه ، نمایش و در همان زمان از آن بعنوان ورودی در  سایر برنامه ها استفاده کرد . یکی دیگر از مزایای اساسی  XML ، یکپارچگی بین دنیای سندها و داده ها است . بدین ترتیب می توان از یک روش خاص بمنظور عرضه ساختار داده ها ( صرفنظر از اینکه اطلاعات توسط انسان و یا ماشین استفاده می گردد) ، بهره  گرفت  .  صرفنظر از اینکه داده های XML  سرانجام توسط انسان و یا یک برنامه نرم افزاری دیگر استفاده می گردند ، به این نکته مهم می بایست اشاره گردد  که بندرت داده ها به همان صورت که دریافت می گردند،  استفاده خواهند شد. در این راستا لازم است که داده ها در ابتدا به یک فرمت دیگر تبدیل گردند .  تبدیل XML   به Html  ، متداولترین کاربرد استفاده از XSLT است . پس از تبدیل داده ها  به فرمت Html ، امکان نمایش آنها در هر مرورگری فراهم خواهد شد  . بنابراین جایگاه “تبدیل ” در رابطه با ارائه و نمایش داده ها ، به تغییر فرمت سندهای XML به سایر فرمت های متداول نظیر Html  برمی گردد .XSLT در این رابطه بخوبی پاسخگو بوده و با استفاده از قوانین موجود قادر به تبدیل نوع یک سند به نوع دیگر با توجه به نیازهای مربوطه خواهد بود .

بمنظور ارسال اطلاعات بین برنامه های متفاوت، می بایست قادر به تبدیل داده ها از مدل استفاده شده توسط یک برنامه به مدل استفاده شده توسط برنامه دیگر باشیم . بمنظور تامین اطلاعات مورد نیاز یک برنامه ،از  فرمت های متفاوت استفاده می گردد . یک فایل حاوی داده های جداشده توسط ویرگول ، یک اسکریپت SQL  ، یک پیام HTTP و  یا مجموعه ای از توابع مربوط به یک اینترفیس خاص برنامه نویسی ، نمونه هائی در این زمینه می باشند . بموازات رشد تجارت الکترونیکی مبتنی بر XML ، نقش XSLT در تبدیل داده ها بین برنامه ها ی متفاوت  ، بسیار حائز اهمیت شده است .در این راستا استانداردهای متعددی وجود دارد . مثلا”  در صنعت روزنامه نگاری از یک فرمت خاص برای مبادله اطلاعات، نسبت  به صنعت تلویزیون استفاده می گردد .در برخی حالات دیگر ممکن است ، تمایل به استخراج   یک آدرس خاص  از یک لیست ثبت سفارش و الحاق آن به  لیست صورتحساب را داشته باشیم . بهرحال ، استخراج و ترکیب داده ها از یک مجموعه اسناد XML و ایجاد اطلاعات مورد نیاز برای سایر اسناد  XML  ، یک ضرورت بوده و XSLT در این راستا ابزاری مناسب  است .

XSLT چگونه یک سند XML را تبدیل می نماید ؟
برای تبدیل یک سند XML  و ایجاد خروجی مورد نظر، دو مرحله متفاوت را می بایست دنبال نمود  :

• اولین مرحله ، شامل یک تبدیل ساختاری است . در این حالت داده ها از ساختار استفاده شده در یک سند XML ،  به ساختاری دیگر  که تامین کننده خروجی مورد نیاز است ، تبدیل خواهند شد .

• دومین مرحله،  ایجاد فرمت مورد نیاز است . ساختار جدید  به فرمت مورد نظر نظیر Html و یا PDF تبدیل و در خروجی نمایش داده خواهد شد .

در رابطه با دومین مرحله ، در بخش قبل موارد لازم بیان  گردید  : ساختمان داده ئی که از اولین مرحله بدست می آید، می تواند بعنوان یک HTML ، یک فایل متن و یا یک سند XML دیگر در خروجی ارائه گردد . خروجی Html ، امکان نمایش مستقیم اطلاعات در یک مرورگر و یا تغذیه به یک برنامه پیشرفته واژه پرداز را دارا است  . خروجی مبتنی بر متن ، امکان فرمت دهی داده ها را با یک روش قابل قبول بمنظور استفاده توسط سایر برنامه ها فراهم می نماید . با تبدیل یک سند XML به نوع دیگر که خود نیز از نوع  XML  خواهد بود ، امکان استفاده مستقیم آن برای سایر برنامه هائی که قادر به دریافت داده های خود بصورت XML می باشند ، فراهم می گردد . مثلا” یک تبدیل کننده XSLT ، ممکن است میزان فروش ماهیانه را بعنوان یک سند XML اخذ و یک منحنی هیستوگرام را بصورت XML در خروجی ایجاد نماید .

در  مرحله اول ( تبدیل ) ، عملیات لازم در خصوص ایجاد خروجی با فرمت مناسب انجام خواهد شد . در مرحله فوق عملیاتی نظیر : انتخاب داده ، گردآوری  و گروه بندی داده ها ، مرتب سازی داده ها و  انجام عملیات محاسباتی ( نظیر تبدیل اینچ به سانتیمتر ) صورت می پذیرد. نحوه انجام عملیات فوق به چه صورت است ؟ قبل از عرضه XSLT ،   امکان پردازش سندهای XML ، صرفا” از طریق نوشتن یک برنامه خاص میسر بود . برنامه ها با استفاده از یک رابط برنامه نویسی (API) ، پارسر را فراخوانده تا امکان اخذ اطلاعات دررابطه با سند و یا انجام عملیات مورد نظر فراهم گردد . در این راستا از دو رابط برنامه نویسی استفاده می گردد : SAX)Simple API for XML )  و DOM)Document object Model) .

رابط برنامه نویسی SAX ، یک اینترفیس مبتنی بر رویداد بوده که پارسر در رابطه با هر یک از بخش های موجود در سند ، اطلاعات  لازم را در اختیار برنامه متقاضی  قرارخواهد داد. در صورتیکه از رابط برنامه نویسی DOM استفاده گردد، پارسر از طریق ایجاد یک ساختار شبه درختی در حافظه ، امکان ارتباط با آن را پیدا می نماید . در ادامه ، با نوشتن یک برنامه خاص ( مثلا” با استفاده از زبانهای برنامه نویسی نظیر VB ، جاوا ) امکان ارتباط با درخت بوجود می آمد . در مدل فوق ، برای پردازش هر نوع سند XML ، لازم است که یک برنامه خاص و اختصاصی نوشته شده تا با دنبال نمودن مراحل مورد نظر، عملیات لازم در  رابطه با یک سند XML صورت پذیرد.

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

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

مقایسه XSLT و SQL
در یک بانک اطلاعاتی رابطه ای ، داده ها شامل مجموعه ای از جداول می باشند . داده ها در فایل هائی تخت  با فرمت های مورد نظر ذخیره می گردند. قدرت یک بانک اطلاعاتی رابطه ای از ساختمان داده آن نبوده و به  زبانی  که قادر به پردازش داده ها است(SQL) ، وابسته است . در روشی مشابه، XML  ، صرفا” یک ساختمان داده مناسب از اطلاعات را تعریف و با استفاده از یک زبان سطح بالا می توان عملیات دلخواه  در رابطه با ساختمان داده  را انجام داد (XSLT) .
SQL و XSLT دو زبان کاملا” متفاوت نسبت بیکدیگر می باشند .در حالتی خاص ، می توان این ادعا را داشت که آنان دارای شباهت هائی در برخی موارد عملیاتی هستند. مثلا” بمنظور پردازش داده های موجود در یک بانک اطلاعاتی رابطه ای و یا یک سند XML  ، زبان پردازش می بایست مبتنی بر یک گرامر مشخص باشد . در SQL از عبارت SELECT و در XSLT از عبارات XPath استفاده می گردد .

زبان عبارات XPath ، یکی از بخش های اساسی XSLT  بوده که توسط کنسرسیوم وب استاندارد شده است . امکان استفاده از XPath مستقل از XSLT نیز وجود دارد . گرامر XPath ، امکان بازیابی گره های خاصی را از یک سند XML فراهم می نماید . بدین منظور ممکن است از طریق  مسیری در سند XML و یا از طریق فهرستی که  گره ها در آن قرار خواهند گرفت ، این امر تحقق یابد . با استفاده از XPath ، امکان دستیابی به گره هائی خاص فراهم و در ادامه با استفاده از XSLT امکان اخذ نتایج مورد نظر بوجود می آید . ( اجراء پرس وجوی لازم )

XSLT و SQL دارای شباهت های دیگری نیزمی باشند .  هر دو زبان ، دارای یک ویژگی مهم با نام closure می باشند. ویژگی فوق، بدین مفهوم است که خروجی ، دارای ساختمان داده مشابه ورودی است . مثلا” SQL خروجی خود را بصورت یک جدول و XSLT بصورت یک درخت ارائه خواهد داد . بدین ترتیب می توان خروجی یک عملیات را بعنوان ورودی در اختیار عملیات بعدی قرار داد. در SQL  این عملیات با استفاده از تعریف view و یا Subquery و در XSLT با ارسال داده از طریق مجموعه ای  stylesheet  انجام می گیرد .

در دنیای واقعی وچود  XSLT و SQL ضرورت داشته و  ارتباطات متعدددی بین آنها  وجود خواهد داشت  . داده ها  عموما” در بانک های اطلاعاتی رابطه ای ذخیره و با فرمت XML بین سیستم های متنوع ارسال خواهند  شد. مدل های داده در هر یک از سیستم های فوق با یکدیگر متفاوت بوده و XSLT  قادر به ایفای نقشی حساس در رابطه با تبدیل مدل های متفاوت داده است . تولیدکنندگان متفاوت بانک های اطلاعاتی در تلاش برای ارائه محصول خود بگونه ای هستند که امکان ارتباط XML و SQL را فراهم نماید . SQL Server 2000 امکان استفاده از پرس و جو های مبتنی بر XPath را حمایت می نماید.

پردازنده XSLT
مهمترین رسالت پردازنده XSLT ، بکارگیری یک XML stylesheet در رابطه با یک سند XML و ایجاد( تولید ) خروجی مناسب است . لازم به یادآوری  است که هر یک از موارد اشاره شده ، بمنزله یک برنامه XML بوده و بدیهی است که ساختار هر یک از آنها یک درخت باشد . عملکرد پردازنده XSLT  وابسته به وجود درخت های فوق است. پردازنده های متعددی در رابطه با  XSLT نظیر Saxon, xt, MSXML3  وجود دارد . پردازنده های فوق را می توان بصورت رایگان تهیه نمود .

پردازنده saxon ، قادر به تبدیل سند XML به سایر مدل های دیگر است ( یک سند Html) .  برای استفاده از برنامه فوق،می بایست برنامه Instan Saxon را از آدرس http://users.iclway.co.uk/mhkay/saxon/instant.html دریافت و بر روی سیستم  نصب کرد . برنامه فوق به زبان جاوا نوشته شده و می توان آن را مستقیما” از طریق خط دستور اجراء نمود ( ضرورتی به داشتن مرورگرهای وب و یا سرویس دهنده وب نخواهد بود ) . مرورگرها و سرویس دهندگان وب در این حالت با سند تبدیل یافته سروکار خواهند داشت .

xt ، یکی دیگر از پردازنده های XSLT است . برنامه فوق با زبان جاوا نوشته شده و امکان اجرای آن از طریق خط دستور وجود دارد . برای دریافت پردازنده فوق می توان به آدرس http://www.jclark.com/xml/xt.html مراجعه نمود. پردازنده فوق همانند saxon ، قادر به فعالیت با پارسر های مبتنی بر SAX می باشد .

امکان اجرای XSLT stylesheet بهمراه مرورگر IE نیز وجود دارد . بدین منظور می بایست  نسخه پنج مرورگر فوق و آخرین نسخه پردازنده MSXML مربوط به شرکت ماکروسافت ، بر روی سیستم نصب گردند. برای دریافت آخرین نسخه پردازنده فوق می توان به آدرس www.microsoft.com/xml مراجعه کرد .

مثال : در ادامه به بررسی مثالی خواهیم پرداخت که  نحوه استفاده از XSLT بمنظور تبدیل یک سند ساده XML را نشان خواهد داد . فرض کنید ، یک سند ساده XML مطابق زیر را داشته باشیم :

خروجی مورد نظر سند XML یک فایل Html بصورت زیر خواهد بود .

XSLT زیر بمنظور تبدیل سند XML و ایجاد خروجی Html استفاده می گردد .

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

استفاده از پردازنده saxon .بمنظور اجرای Stylesheet فوق با استفاده از پردازنده saxon ، عملیات زیر را می بایست انجام داد :

• دریافت برنامه پردازنده ( آدرس مربوطه در بخش قبل اشاره گردید )

• نصب برنامه saxon.exe در یک فولدر مناسب

• با استفاده از برنامه notepad دو فایل اشاره شده را در فایل هائی با نام hello.xml و hello.xsl ذخیره نمائید.

• خط دستور DOS را فعال نمائید .(start|programs|MSDOS prompt)

• دستور saxon   hello.xml   hello.xsl  را در خط دستور تایپ نمائید .

• خروجی html بر روی صفحه نمایش داده خواهد شد .

در صورتیکه قصد مشاهده خروجی را در مرورگر داشته باشید ، خروجی خط دستور را در یک فایل Html بصورت زیر ذخیره نمائید .

استفاده از پردازنده xt .  برای اجرای پردازنده xt ، از روشی مشابه saxon استفاده شده با این تفاوت که در عوض استفاده از برنامه  saxon از برنامه  xt استفاده می گردد .

استفاده از پردازنده MSXML . بمنظور اجرای stylesheet بهمراه مرورگر IE ، می بایست تغییرات اندکی در سند XML بمنظور مراجعه به stylesheet ایجاد گردد :

در ادامه می توان فایل hello.xml را در مرورگر IE ، فعال و مشاهده نمود . مرورگر فوق ، سند XML را خوانده و از وجود  یک stylesheet آگاه می گردد . در ادامه stylesheet مربوطه  فعال و بمنظور تبدیل سند XML و ایجاد خروجی Html ، آن را اجراء می نماید . در صورتیکه بر روی صفحه نمایشگر عبارت hello,world نمایش داده نشود و صرفا” سند XML مشاهده گردد، علت  عدم استفاده از آخرین نسخه MSXML بهمراه مرورگر بوده و می بایست آخرین نسخه را از آدرس اشاره شده دریافت و بر روی سیستم نصب نمود .

تشریح نحوه عملکرد XSLT  در رابطه با مثال فوق
اولین خط فایل stylesheet ، شامل دستور زیر است :

دستور فوق، اعلام می نماید که   یک XSLT stylesheet  ، خود بعنوان یک سند XML است . برای encoding کاراکترها ،می توان از استانداردهای متعدد موجود منجمله utf-8 استفاده کرد .
در ادامه با خط زیر مواجه می گردیم :

خط فوق، عنوان استاندارد XSLT است . یک المان شروع که نوع سند را بعنوان یک stylesheet معرفی می نماید . خصلت  xmlns:xsl تعریف یک namespace  بوده که مشخص می نماید پیشوند xsl در ادامه بمنظور مراجعه به  المان های تعریف شده ( استاندارد کنسرسیوم وب XSLT ) ، استفاده خواهد شد .
در ادامه با خط زیر مواجه می شویم :

المان <xsl:template> ، یک قانون تمپلیت را تعریف که بر اساس آن نحوه برخورد با بخش های خاص سند مبداء در هنگام پردازش، تبین می گردد . خصلت “/” مشخص می نماید که قانون فوق از ابتدای سند مبداء اعمال خواهد شد . در حقیقت، عبارت فوق یک عبارت مبتنی بر XPath بوده و المان ریشه سند XML را مشخص می نماید . یک سند XML دارای یک ساختار سلسله مراتبی بوده و همانند یونیکس که از “/” برای مشخص نمودن ریشه استفاده می نماید، XPath نیز از “/” برای مشخص نمودن المان ریشه در یک سند XML  استفاده می نماید . در مدل DOM به عنصر فوق  ” Document object” و در XPath به آن ریشه گفته می شود .
در ادامه با خطوط زیر مواجه می شویم :

بدنه تمپلیت،نحوه ایجاد خروجی را مشخص می نماید . اکثر بدنه تمپلیت در مثال فوق ، مجموعه ای از المان های Html  و متن مورد نظر را که  می بایست در فایل خروجی منعکس گردند  ، شامل می گردد . در دستورات فوق یک المان خاص با نام <xsl:valeu-of> وجود داشته  که یک دستورالعمل XSLT است( چون از namespace مربوطه با نام xsl استفاده می نماید ) . دستورالعمل فوق ، مقدار یک گره موجود در سند مبداء را در سند خروجی تکثیر می نماید . خصلت SELECT  مربوط به المان ، گره ای را که مقدار آن می بایست انتخاب شود  را مشخص می نماید . ( تمام المان های <greeting> که فرزند گره مربوطه می باشند ،انتخاب می گردند ) .
در ادامه با دستور زیر مواجه می گردیم :

برای یک تمپلیت ساده نظیر آنچه در مثال فوق وجود داشت ، می توان برخی از بخش ها را حذف نمود. با توجه به اینکه صرفا” از یک تمپلیت استفاده شده است المان <xsl:template> را می توان حذف نمود . در این حالت Stylesheet مربوطه بصورت زیر خواهد بود :