آموزش بستن دستورات شل و جلوگیری از اجرای دستورات

[Habili]

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

ابتدا با یوزر روت به سرور متصل شده و با دستورات locate و یا whereis دنبال فایل php.ini میگردید به این صورت :

locate php.ini
or
whereis php.ini

خوب من کامندش رو زدم همونطور که میبینید فایل php.ini توی مسیر etc/php.ini/ میباشد.
من از کامند whereis استفاده کردم :

[root[@localhost ~]# whereis php.ini
php: /usr/bin/php /etc/php.ini /etc/php.d /usr/include/php /usr/share/man/man1/php.1.gz
[root[@localhost ~]# 

بعدش فایل php.ini رو با دستور vi باز میکنید و دنبال کلمه =Disable_functions میگردید . بعد از علامت "=" این فانکشن ها رو بنویسید :

symlink,shell_exec,exec,proc_close,proc_open,popen ,system,dl,passthru,escapeshellarg,escapeshellcmd

مثل شکل زیر :

بعدش هم فایل رو save و سرویس آپاچی رو ریستارت میکنید.

[Server-Sec]

سلام

باتشکر از مطلب مفید شما.

این فانکشن هایی که بسته شده خیلی کم و جزئی می باشد/.
Disable_funtions هایی که بنده در مدت فعالیتم جمع اوری کردم به شکل زیر می باشد :

"python_eval,curl_multi_exec,./,ln,passthru,system,exec,popen,shell_exec,proc_close,proc_open,proc_nice,proc_terminate,proc_get_status,posix_getpwuid,posix_uname,ftp_exec,posix_uname,posix_getpwuid,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,get_current_user,getmygid,listen,chgrp,apache_note,apache_setenv,apache_child_terminate,ini_restore,netscript,escapeshellarg,cmd,backtick,virtual,show_sourc,show_source,pclose,pcntl_exec,datasec,old_offset,ctrl_dir,ini_alter,leak,listen,chgrp,apache_setenv,define_syslog_variables,root,posix_kill,getmygid,apache_child_terminate,php_ini_scanned_files,ls,ps_aux,chown,getrusage,posixc,posame,chgrp,posix_setuid,posix_setsid,posix_setgid,apache_note,apache_setenv,x_getuid,e_ini_file,nfo,SQL,mysql_li,t_dbs,ini_get_all,ilegetcontents,popen,popens,pfsockopen,dos_conv,apache_get_modules,crack_check,crack_closedict,rar_open,bzopen,bzread,bzwrite,shellcode,posix_isatty,posix_getservbyname,escapeshellarg,hypot,pg_host,pos,posix_access,posix_times,posix_mknod,pclose,ps_fill,symlink,id,escapeshellcmd,php_uname"

البته اینم بگم بستن فانشکن از نظر من فقط گول زدم ادم هست !
زیرا تمامی این تنظیمات قابل بایپس می باشند چه راحت و چه سخت !

روش بعدی هم روشن کردن Safe_mod یا حالت امنیتی php می باشد.
برای این کار دنبال متن safe_mod بگردید و به شکل زیر تغییر دهید :

safe_mod = on

[Pr0grammer]

سلام
دوستان مطالب مفیدی رو ارایه کرده بودند فقط یه سری نکات به نظرم اومد بهش اضافه کنم.
1- یادتون باشه قابلیت php.ini سفارشی رو غیر فعال کنید تا کاربر امکان آپلود php.ini خودش و بایپس کانفیگ شما رو نداشته باشه.
2- امکان استفاده از perl رو محدود کنید چون اگه فعال باشه می تونه با استفاده از cgi بایپس انجام بده.
3- خیلی وقتا در چندین مسیر سرور فایل php.ini وجود داره که بسته به هندلری که داره استفاده می کنه ممکنه متفاوت باشه ، بهترین راه برای پیدا کردن فایل php.ini اصلی می تونید از این دستور استفاده کنید php -i | grep php.ini
4- کانفیگ صحیح وب سرور خیلی نقش مهمی در امنیت داره بخصوص در آپاچی ، سعی کنید از کمترین ماژول ها استفاده کنید
5- امکان استفاده از user dir برای اجرا فایل ها ببندید چون مشکل ساز هستش

موفق باشید

[Server-Sec]

سلام

عادت بدی که معمولا مدیران سرور و مخصوصا ایرانی ها دارند اینه که کار رو با ایجاد محدودیت پیش میبرند !
درصورتی که سروری کانفیگ میشه هیچ یک از موارد بسته نیست و باز هم به ان نمیتوان نفوذ کرد و امنیت ان از سرور محدود شده بیشتر است !
خواستم یاد اوری کنم تا دوستان به این سمت گرایش پیدا کنند نه ایجاد محدودیت ;)

[Pr0grammer]

بله اما محدودیت هم در خیلی از موارد لازمه
شما اول باید تعیین کنید امنیت رو در چی می بینید ؟؟ مثلا خیلی از دوستان همین که سرورشون DDOS نمیشه میگن دیگه ته امنیته
یا مثلا نمیشه symlink زد فکر نی کنند دیگه تمومه!
اما همیشه از یک سرور به یک منظور استفاده نمیشه ، به شخصه بار ها برام پیش اومده که از سرور های خیلی امن برای spam یا حتی به صورت زامبی استفاده کردم که این عمل نتیجه خیلی نا مناسبی داشته. استفاده از DDOS رو سرور باعث میشه لود بره بالا و اگه زمان زیادی لود بالا باشه خود دیتاسنتر ساسپند می کنه و حالا باز کردنش دردسر های خاص خودش رو داره یا خیلی وقتا شده بلاک آی پی رو اسپم اعلام کردند که برای یک سرور هاستینگ این عمل فاجعه محسوب میشه.
اگه یک مقدار دقیق تر به موضوع نگاه بشه متوجه میشیم نه تنها محدودیت بد نیست بلکه خیلی وقتا لازمه.
البته این نظر و تجربه من بود

[Server-Sec]

سلام

شما لطف میکنید بگید ایا با بستن این فانکشن ها دیداس رفع میشه ؟
محدودیت خوبه ولی تا جایی که بدون محدودیت میشه نیازی نیست !
برای مثال ایجاد محدودیت تعداد کانکشن برای هر ایپی مفید هست!

در هاستینگ (هاست اشتراکی) مهم ترین مورد مقابله با سیملینک هست !* شما اومدید با بستن پرل پایتون فانکشن php اینو درست کردید - یه نفر سیملینک رو کلا پتچ میکنه و پرل پایتون فانکشن ها همه باز هستند !

محدودیت بعضی وقتا لازمه ولی در این مورد از نظر بنده نیازی نیست بلکه مشکل ایجاد میکند (مشکل در اسکریپت ها و...)

بازم نظر شما محترم هست :)

[Pr0grammer]

نه من نگفتم disable function جلوی دیداس رو میگیره ، اما خب اگه سورس کد های مربوط به اسکریپت ها رو بررسی کنید اکثرا از توابعی نظیر fsockopen استفاده می کنند و این که من فقط مثال زدم.

در هاستینگ (هاست اشتراکی) مهم ترین مورد مقابله با سیملینک هست !

یعنی این مورد حل بشه دیگه هیچ دغدغه ای نداره ؟؟

برای مثال ایجاد محدودیت تعداد کانکشن برای هر ایپی مفید هست!

اگر یک حمله بات نت داشتید چی کار می کنید ؟؟ مثلا حمله با 2000 آی پی ، بازم محدودیت کانکشن مفیده ؟

شما اومدید با بستن پرل پایتون فانکشن php اینو درست کردید - یه نفر سیملینک رو کلا پتچ میکنه و پرل پایتون فانکشن ها همه باز هستند !

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

[Server-Sec]

نه من نگفتم disable function جلوی دیداس رو میگیره ، اما خب اگه سورس کد های مربوط به اسکریپت ها رو بررسی کنید اکثرا از توابعی نظیر fsockopen استفاده می کنند و این که من فقط مثال زدم.

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

اگر یک حمله بات نت داشتید چی کار می کنید ؟؟ مثلا حمله با 2000 آی پی ، بازم محدودیت کانکشن مفیده ؟

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

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

موارد امنیتی از سطح کرنل (Kernel Hardening) انجام میشود ! باتوجه به موارد امنیتی وغیره میتوان تضمین داد که امکان روت شدن به کرنل با لوکال روت وجود ندارد.


اگر شرکت های بزرگ خارجی را بررسی کنید مانند HostGator.com ، تمامی فانکشن ها باز و پرل+پایتون باز میباشد.
+ کرنل 3.x ، اگر لوکال روت وجود داشت و تونستید روت کنید ماروهم در جریان بزارید ;)

[Pr0grammer]

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

میشه مثال بزنید چطوری ؟؟

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

تجربه حمله با botnet رو داشتید ؟ اصلش همینه که از هر آی پی حد اکثر 10 کانکشن ایجاد میشه البته اگه تعداد آی پی ها زیاد باشه ممکنه به 2-3 تا هم برسه! بعد فایروال چطوری می تونه بن کنه ؟ همه کاربرا بن میشن که ؟ اگه همه آی پی ها رو ببندید مشکل ارسال ایمیل پیش میاد ، مشکل روبات های موتور جست و جو ، برنامه های سرور نمی تونن بروز رسانی کنند و هزار مشکل دیگه.

موارد امنیتی از سطح کرنل (Kernel Hardening) انجام میشود ! باتوجه به موارد امنیتی وغیره میتوان تضمین داد که امکان روت شدن به کرنل با لوکال روت وجود ندارد.


اگر شرکت های بزرگ خارجی را بررسی کنید مانند HostGator.com ، تمامی فانکشن ها باز و پرل+پایتون باز میباشد.
+ کرنل 3.x ، اگر لوکال روت وجود داشت و تونستید روت کنید ماروهم در جریان بزارید ;)

موارد امنیتی سطح کرنل شامل همین بستن پرل و CGI هم میشه برای جلوگیری از اجرای exploit ها.

همینHostGator.com که مثال می زنید اگه داخل فروم های زیر زمینی خارجی فعال باشید میبینید که سابقه هک زیاد داره اما چون معروفه این موارد رو مطرح نمی کنه تا سابقشو حفظ کنه. مثال ایرانی همین هاست دی ال خودمون که خیلیا تو امنیت قبولش دارند و سال پیش دیفیس شد و من میشناسم کسی رو که همین الان هم روش دسترسی داره!!

[Server-Sec]

سلام
شب بخیر ،

مورد ارسال دیداس با استفاده از بخش Network در کرنل اختصاصی که در پست های قبل اشاره شد رفع میشه.
البته در فایروال csf هم میتوان این مورد رو با استفاده از LF_SCRIPT_ALERT , PT_LIMIT , PT_KILL و... رفع نمود/.

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

وقتی دسترسی کاربر از کرنل محدود شده باشه از نظر بنده باز بودن پرل*+ پایتون +*CGI + (لوکال روت) و غیره هیچ خطر امنیتی ای ایجاد نمیکند !