سه قدم اساسی در بهبود امنیت اوراکل

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

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

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

همانطور که میدانیم , سیستم اوراکل از چند بخش مجزای عملیاتی تشکیل شده که Listener و ساختار مدیرت و کنترل بانک های اطلاعاتی دو مورد اصلی آن میباشند . در سیستم عامل لینوکس هر بخش تحت پروسه جداگانه ایی اجرا و کنترل میگردد اما در ویندور ، تقریبآ تمام بخش های اصلی اوراکل تحت پروسه هایی مشترک اجرا میگردند . سرویس Listener اوراکل که بطور پیشفرض بر روی پورت TCP/1521 سرویس دهی مکند ، در واقع یکی از مدخل های اصلی ورود به بانک اطلاعاتی و دسترسی به آن از طریق شبکه میباشد . همانند سایر سیستم های RDBMS اوراکل نیز از روش های مختلفی برای کنترل دسترسی به این سرویس را در اختیار میگذارد که رایج ترین آن همان کلمات عبور میباشند . همچنین از طریق سرویس Listener اطلاعات و قابلیت های کنترلی دیگری نیز در دسترس میباشد . بطور مثال شما قادر خواهید بود که از طریق ارسال درخواست ها و دستورات مشخص ، اطلاعات دقیق مربوط به سیستم عامل و نسخه آن , نسخه بانک اطلاعاتی , نام Instance های موجود و بسیاری موارد دیگر را دریافت کنید . علاوه بر این شما میتوانید به سادگی خود سرویس Listener را کنترل نمایید و بطور مثال آنرا غیرفعال نمایید .

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

نکته اینجاست که بطور پیشفرض شما قادر به انجام همه موارد فوق بدون در اختیار داشتن هرگونه نام کاربری یا دسترسی مجاز به سیستم خواهید بود . در نگاه اول شاید دانستن اطلاعات فوق مهم بنظر نرسد و تنها نکته حساس از دید مدیر بانک اطلاعاتی , غیرفعال شدن سرویس Listener باشد . اما جالب اینجاست که همین موارد بسیار ابتدایی و عدم کننرل دسترسی صحیح به آنها در صورت وجود , امکان نفوذ به بیش از 90% بانک های اطلاعاتی را فراهم میکنند ! پس موضوع جدیست .

حال چگونه میتوان این خطر را کاهش داد و از وقوع حملات از این طریق جلوگیری کرد ؟

قدم اول : مشخص کردن پسورد برای دسترسی به سرویس Listener

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

روش ست کردن رمز عبور برای Listener بصورت زیر میباشد که توسط ابزار LSNRCTL انجام میشود :

این عمل بهتر است همیشه توسط ابزار LSNRCTL انجام شود اگرچه امکان تغییر فابل listener.ora بصورت دستی نیز وجود دارد . اما مزیت استفاده از LSNRCTL ، دخیره شدن کلمه عبور شما در فایل بصورت کد شده است.

قدم دوم : محدود کردن دسترسی های Administration سرویس Listener

همانطور که گفته شد ، در صورت امکان دسترسی به سرویس Listener علاوه بر روش های استخراج اطلاعات , امکان کنترل خود سرویس نیز وجود دارد. ممکن است شما به هر دلیلی نیاز به یک Listener فاقد پسورد داشته باشید ( این یک مورد نادر و خاص است , پس در صورتی که مطمئن نیستید به آن احتیاج دارید , حتمآ قدم آول را دنبال کنید ! ) , اما شما باز هم قادر به محدود کردن دسترسی به امکانات سرویس خواهید بود . این کار توسط فعال کردن _محدودیت دسترسی Administration _ انجام میشود .

برای انجام آن کافیست به فایل listener.ora مربوطه مراجعه کرده و پارامتر را مانند مثال زیر تغییر دهیم یا در صورت عدم وجود آنرادرج کنیم :

ADMIN_RESTRICTION_{listener name} = ON

پس از اینکار کلیه پارامترها و دستورات SET مربوط به Listener غیرفعال خواهند شد و چه بصورت محلی و یا تحت شبکه امکان استفاده از آنها وجود ندارد. بلکه هر تغییری میباسیت مستفیمآ در فابل listener.ora مربوطه اعمال گردد. پس از این تغیررات , برای اعمال آنها نیاز به راه اندازی مجدد سرویس Listener میباشد. میتوان از دستور RELOAD ( و یا STOP و START ) ابزار LSNRCTL برای این منظور استفاده کرد.

در نسخه 10g ، امکان جدیدی بنام LOCAL_OS_AUTHENTICATION اظافه شده که بطور پیشفرض فعال میباشد . این امکان اگرچه دسترسی به امکانات administration را از طریق شبکه محدود کرده , اما این دسترسی ها از طریق محلی هنوز وجود دارند و امکان استفاده از پارامترهای SET میسر است.

قدم سوم : فعال کردن قابلیت Logging سروریس Listener

این کار به شما امکان بازرسی ومشاهده دسترسی ها و ارتباطات با سرویس Listener را میدهد که بطور مثال برای تشخیص و پیگیری حملاتی که از طریق Listener صورت میپذیرد و در بالا به آن اشاره شد بسیار مهم میباشد. در ادامه نحوه فعال کردن log سرویس Listener عنوان شده :

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