12.07.2005

Война на передовой в условиях шаред хостинга на базе WHM/Cpanel/RHE

В данной статье рассмотрены методы борьбы на "передовой"; противодействие атакующему через веб-скрипты (apache/mod_php) на базе распространенной панели для shared hosting WHM/Cpanel (cpanel.net) с ОС Linux RHE. (Учитывая особенности работы данной панели, применяемые меры не идут в разрез с работой WHM/Cpanel), которые дают Вам зацепку, через которую можно выстроить достаточно плотную защиту обход которой будет не всегда соразмерен полученному результату.

whice (RST/GHC)

Особые благодарности:

foster,edisan,Mik,blf,1dt.w0lf

"Война на передовой в условиях шаред хостинга на базе WHM/Cpanel/RHE"

Вступление

Сегодня в условиях развития информационных технологий на рынке е-комерции особое внимание уделяеться таким видам е-бизнеса как "shared hosting". Этот сегмент рынка продолжает стремительно рости и из-за своей распространенности и прибыльности попадает в поле зрения злоумышленников различного уровня.

Обеспечение безопасности "shared hosting" имеет свои особенности. Я постараюсь обрисовать особенности защиты при проникновении через apache/mod_php.

Известно, что для построения эффективной системы защиты в первую очередь следует определить каким образом может действовать атакующий; какого вида угрозы могут иметь место и исходя из этого сделать выводы о целесообразности самой защиты.

И так, рассмотрим стандартные методы проникновения в систему.

Приблизительный план атакующего:

  1. поиск на сервере доменов, содержащих php скрипт с уязвимостью;
  2. использование скрипта для выполнения локальных команд (с уровнем nobody);
  3. заливка, запуск backdoor;
  4. вход через backdoor;
  5. повышение привилегий.

Противодействие пунктам 1 и 5 не рассматриваются, так как предполагается, что дырявый скрипт уже найден, а также, что предполагаемые статьей мероприятия нацелены на действия, предотвращающие 5-ый пункт.

Учитывая, что среднестатистический сервер на базе WHM (исходя из default установки которую мало кто меняет) использует php как модуль apache (safe_mode = Off ), запускаемые через уязвимый скрипт команды имеют уровень привилегий apache (пользователь nobody).

Пример списка процессов:

[root@redhat root]# ps -eo %p%u%a --forest
......
23091	root		/usr/local/apache/bin/httpd -DSSL
23092	nobody		\_ /usr/local/apache/bin/httpd -DSSL
23093	nobody			\_ uname -a 
......

После определения возможности запускать програмы, атакующий попытаеться залить backdoor's, exploit's, bot's .... etc с целью получить полноценный shell, повысить уровень привелегий.

Исходя из вышеопределенного - выводим следующий план противодействия:

  1.  Установка noexec nosuid на директории свалок

  2. - ограничение директорий свалок (/tmp,/var/tmp) от запуска backdoor, bot и другой закачанной нечисти;
  3. Контроль выполняемых процессов

  4. - ограничение количества команд, выполняемых от пользователя nobody;
  5. Настройка firewall.
  6. Настройка cPanel(WHM)+apache+php.ini.

Данные меры вполне способны нарушить план атакующего, и отпугнуть многих scriptkidies.

Перейдем к непосредственному расмотрению пунктов нашего плана.

1. Установка noexec nosuid на директории свалок (/tmp, /var/tmp).

К сожалению, в предустановленном варианте /tmp раздел не всегда идет отдельным разделом, что открывает атакующему дополнительные возможности. Мы прикроем это следующим образом:

- директории-свалки сделаем отдельными файлами и будем присоединять их через mount -o loop,noexec,nosuid;

- будем проверять все директории-свалки и что-то делать с файлами с опастными правами (x, s). Этот пункт противодействия важен, так-как noexec ограничение на раздел возможно обойти;

Разобьем первый пункт на подпункты:

1.1 Определение директорий для контроля

1.2 Создание файл-разделов.

1.3 Проверка работы noexec,nosuid.

1.4 Обход ограничения noexec

1.5 Скрипт для дополнительной защиты.

1.1 Определение директорий для контроля

Определяем, для каких директорий будут создаваться файл-разделы. Обычно это /tmp, /var/tmp .

Для поиска директорий имеющих права запись/выполнение/чтение для всех + sticky bit (1**7) . можно использовать следующую команду:

[root@redhat root]# find / -perm -1007 -type d -print

Тоже но без sticky bit:

[root@redhat root]# find / -perm -007 -type d -print

Пример вывода:

/tmp
/tmp/.font-unix
/var/tmp
/var/spool/samba 

Так как обычно на Shared hosting не поддерживается работа samba (которая входит в установку по умолчанию), рекомендуется удалить пакет samba*. Вывести все пакеты, имеющие отношение к samba, может следующая команда:

[root@redhat root]# rpm -qa|grep samba

Пример вывода:

samba-3.0.9-1.3E.2
samba-common-3.0.9-1.3E.2
samba-client-3.0.9-1.3E.2
redhat-config-samba-1.0.16-2
samba-swat-3.0.9-1.3E.2

Удаляем пакеты:

[root@redhat root]# rpm -e samba samba-common samba-client redhat-config-samba samba-swat

Если не желаете удалять пакеты, тогда уберите права с директории /var/spool/samba:

[root@redhat root]# chmod 0000 /var/spool/samba

Если Вы таки используете samba, тогда с этой директорией поступайте так же, как дальше по статье работаем с /tmp.

1.2 Создание файл-разделов.

Мы определили директории, для которых необходимо создать раздел-файлы. Это /tmp, /var/tmp.

Создаем директорию, где будут лежать файлы-разделы:

mkdir /filesystems

Создаем файл-разделы:

[root@redhat root]# dd if=/dev/zero of=/filesystems/tmp_fs seek=100 count=1 bs=1M
[root@redhat root]# dd if=/dev/zero of=/filesystems/var_tmp_fs seek=100 count=1 bs=1M

Я решил выделить под /tmp и /var/tmp по 100 M. Вы можете выделить больше - по Вашим потребностям.

Следующим шагом создаем в файлах ФС:

[root@redhat root]# mkfs.ext3 /filesystems/tmp_fs
[root@redhat root]# mkfs.ext3 /filesystems/var_tmp_fs

Добавляем в /etc/fstab строки автоматического присоединения файл-разделов при старте сервера:

/filesystems/tmp_fs /tmp ext3 defaults, noexec, nosuid, loop 1 1
/filesystems/var_tmp_fs /var/tmp ext3 defaults, noexec, nosuid, loop 1 1       

Присоединяем и проверяем присоединились ли новые файл-разделы (не забыв удалить данные из папок /tmp /var/tmp или, если там есть нужные данные, - временно перенести в другое место, а потом положить в новые файл-разделы):

[root@redhat root]# mount /tmp
[root@redhat root]# mount /var/tmp
[root@redhat root]# df 

Пример вывода:

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1              2.0G  988M  926M  52% /
/filesystems/tmp_fs    98M  4.1M   89M   5% /tmp
/filesystems/var_tmp_fs
                      98M  4.1M   89M   5% /var/tmp

1.3 Проверка работы noexec,nosuid.

Пробуем запустить suid файл из под nobody. Вот код С программы:

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main (int argc, const char * argv[],char * envp[])
        {
           uid_t uid;
           uid = getuid();
           printf("My id is %d\n",uid);
           if(0 != setuid(0)) printf("\nError suid to root\n");
           uid = getuid();
           printf("After suid My id is %d\n",uid);
        }         

Собираем:

[root@redhat root]# gcc suid.c -o suid

Ставим SUID на suid:

[root@redhat root]# chmod 4775 suid

Копируем для проверки в /:

[root@redhat root]# cp suid /

проверяем:

[root@redhat root]# sudo -u nobody /suid
My id is 99
After suid My id is 0  

Копируем в защищенные директории /tmp /var/tmp:

[root@redhat root]# cp suid /tmp/
[root@redhat root]# cp suid /var/tmp/

Проверяем:

[root@redhat root]# sudo -u nobody /tmp/suid 
sudo: unable to exec /tmp/suid: Permission denied
[root@redhat root]# sudo -u nobody /var/tmp/suid 
sudo: unable to exec /var/tmp/suid: Permission denied               

Сделаем аналогичную проверку для SheLL, Perl, PHP скриптов.

Пример скриптов:

test.php:
#!/usr/bin/php -q
<? echo "running\n"; ?>    


test.pl:
#!/usr/bin/perl
print "running\n"    


test.sh:
#!/bin/sh 
echo "running"    

Результатты проверок:

PHP:

	[root@redhat root]# chmod 755 test.php
	[root@redhat root]# ./test.php
	running
	[root@redhat root]# cp test.php /tmp 
	[root@redhat root]# /tmp/test.php
	-bash: /tmp/test.php: /usr/bin/php: bad interpreter: Permission denied


Perl:

	[root@redhat root]# chmod 755 test.pl
	[root@redhat root]# ./test.pl
	running
	[root@redhat root]# cp test.pl /tmp/
	[root@redhat root]# /tmp/test.pl
	-bash: /tmp/test.pl: /usr/bin/perl: bad interpreter: Permission denied


Shell:

	root@redhat root]# chmod 755 test.sh
	[root@redhat root]# ./test.sh
	running
	[root@redhat root]# cp test.sh /tmp/
	[root@redhat root]# /tmp/test.sh
	-bash: /tmp/test.sh: /bin/sh: bad interpreter: Permission denied

На первый взгляд все хорошо. Ничего из директорий-свалок запустить нельзя.

1.4 Обход ограничения noexec .

Обход noexec при запуске исполняемого файла:

	root@redhat root]# sudo -u nobody  /lib/ld-linux.so.2 /tmp/suid
	My id is 99
	error suid to root
	After suid My id is 99   

Как видите, ограничение noexec было обойдено, ограничение на nosuid обойти не удалось (мне не известны способы обхода nosuid на директорию...).

Данный способ обхода был действителен для всех доступных мне ОС Linux RHE (<=2.4.21-27.0.4.EL - последний kernel, доступный для обновление через up2date, в момент написания статьи). В случае использование 2.6.x kernel, собранного с исходников, данный способ уже недействителен.

root@redhat root]# sudo -u nobody  /lib/ld-linux.so.2 /tmp/suid
/tmp/suid: error while loading shared libraries: 
/tmp/suid: failed to map segment from shared object: Operation not permitted 

Вот пример обхода ограничения на запуск скриптов PHP/Perl/Shell:

PHP:

[root@redhat root]# /usr/bin/php -q /tmp/test.php
running

Perl:

[root@redhat root]# /usr/bin/perl /tmp/test.pl
running

Shell:

[root@redhat root]# /bin/sh /tmp/test.sh
running         

1.5 Скрипт для дополнительной защиты.

Как видим, одно ограничение noexec, nosuid не способно остановить вторжение, но является дополнительным сдерживающим средством. Расширим его скриптом, который будет проходить по директориям-свалкам и изменять/удалять неугодные нам файлы. Я лишь приведу пример написанный на shell. Вы можете реализовать данную методику любым удобным Вам способом.

Вот код:

#!/bin/sh
DIR4PROTECT="/root/dir4protect"
for dir in `cat $DIR4PROTECT`;do
FILE2DELETE=`find $dir -perm +1111 -print`
for file in `echo $FILE2DELETE`;do
        if [ -f $file ];then
                chmod 0000 $file
                chown root.root $file
        fi
done
done   

Проверяем его работу:

[root@redhat root]# ./tmpprotect.sh 
	[root@redhat root]# ls -la /tmp
	total 45
	drwxr-xr-x    3 root     root         1024 Apr 29 18:32 .
	drwxr-xr-x   20 root     root         4096 Apr 28 23:45 ..
	----------    1 root     root            0 Apr 29 18:32 1
	drwx------    2 root     root        12288 Apr 27 21:31 	lost+found
	----------    1 root     root        11841 Apr 29 00:36 s2
	----------    1 root     root           34 Apr 29 00:10 shell.sh
	----------    1 root     root        11841 Apr 29 00:00 suid
	----------    1 root     root           40 Apr 29 16:30 test.php
	----------    1 root     root           38 Apr 29 16:35 test.pl
	----------    1 root     root           26 Apr 29 16:40 test.sh
	[root@redhat root]# ls -la /var/tmp
	total 29
	drwxr-xr-x    3 root     root         1024 Apr 29 00:00 .
	drwxr-xr-x   19 root     root         4096 Mar  4 23:29 ..
	drwx------    2 root     root        12288 Apr 27 21:32 	lost+found
	----------    1 root     root        11841 Apr 29 00:00 suid                  

Проверяем возможно ли запустить скрипты:

	[root@redhat root]# sudo -u nobody /usr/bin/php -q /tmp/test.php
	[root@redhat root]# sudo -u nobody  /usr/bin/perl /tmp/test.pl
	Can't open perl script "/tmp/test.pl": Permission denied 
	[root@redhat root]# sudo -u nobody /bin/sh /tmp/test.sh
	/tmp/test.sh: /tmp/test.sh: Permission denied 

Написанный скрипт помогает блокировать файлы, которые могут быть backdoor, exploits, trojanhorse в директориях свалках. Его можно расширить автоматическим отправлением письма администратору, любыми другими пришедшими вам на ум идеями. Самый простой способ - это установить данный скрипт для автозапуска в crontab на запуск раз в минуту.

Пример содержимого файла крон службы:

	* * * * * /root/tmpprotect.sh

2. Контроль выполняемых процессов.

Следующий эшелон защиты – это контроль выполняемых процессов. Этот способ заключается в проверке списка процессов и снятии с выполнения неугодных.

Вот пример скрипта, который, основываясь на файле-списке разрешенных процессов, убивает остальные.

/root/nobody.sh

#!/bin/sh
USER="nobody"
RULEFILE="/root/nobody"
if [ -f "$RULEFILE" ]; then
         KPID=`ps -eo "%p%u%c"|grep $USER|grep -vi $$|grep -vif $RULEFILE |awk '{print$1}'`
         for j in `echo "$KPID"`; do
 		kill -9 $j >> /dev/null 2>&1
         done
fi

файл список разрешенных програм:

/root/nobody

httpd
suexec

*Для корректной работы WHM/Cpanel в /root/nobody необходимо внести список выполняемых файлов из директорий /scripts/ /usr/local/cpanel/bin/.

Проверим работу скрипта. Открыв второй шелл, запустим там команду "sudo -u nobody sleep 500", а в первом – на выполнение наш скрипт.

[root@redhat root]# sudo -u nobody sleep 500
Killed                
---
[root@redhat root]# chmod 750 nobody.sh
[root@redhat root]# ./nobody.sh

Процесс, не входящий в список разрешенных, был убит нашим скриптом.

Теперь попробуем другой скрипт:

httpd:

#!/bin/sh
while [ "1" ];do
sleep 1
done 

Сохраним его в директории /tmp, сделаем запускаемым и запустим:

[root@redhat tmp]# sudo -u nobody ./httpd
sudo: unable to exec ./httpd: Permission denied
[root@redhat tmp]# sudo -u nobody /bin/sh ./httpd
Killed           

Наш скрипт его убивает, и все потому, что он видится как процесс sh. Для примера того, что скрипт может быть не убиваем, скопируем его в / и запустим оттуда. ( в реальной жизни это будет директория какого-то пользователя, который открыл директорию на заливку (777) )

[root@redhat /]# sudo -u nobody ./httpd
./httpd: line 4:  4101 Killed                  sleep 1
./httpd: line 4:  4111 Killed                  sleep 1  

Позапускав наш скрипт nobody.sh видим, что главный скрипт не умирает, а вот потомки снимаються с выполнения. Это из-за того, что главный скрипт подпадает под разрешенные процессы.

Приведенный вариант не панацея и является всего лишь толчком для Вашей фантазии. Вы его можете модернизировать, переделать или сделать как Вам удобнее. Главное – я показал принцип и точку, в которой можно противодействовать вторжению.

3. Настройка Firewall.

Учитывая нюансы WHM/Cpanel, перечислим порты, которые должны быть открыты на вход:

TCP 21,22,25,53,80,110,443,2082,2083,2086,2087,2089,2095,2096
UDP 53
ICMP 0,30,8

на выход:

TCP 25,53,2089
( 2089 необходим для работы WHM для авторизации)
UDP 53
ICMP 0,30,8

Напишем скрипт, который будет загружать в iptables правила для файрволинга при старте системы. Ограничивая исходящие соединения, мы тем самым уменьшаем количество возможных backconnect.

/etc/firewall.sh:

#/bin/sh
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 21 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 25 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 110 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 443 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2082 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2083 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2086 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2087 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2089 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2095 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 0/0 -d 10.10.10.10 --dport 2096 -j ACCEPT
/sbin/iptables -A INPUT -p udp -s 0/0 -d 10.10.10.10 --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -s 0/0 -d 10.10.10.10 --icmp-type 0 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -s 0/0 -d 10.10.10.10 --icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -s 0/0 -d 10.10.10.10 --icmp-type 30 -j ACCEPT
/sbin/iptables -A INPUT -p all -s 0/0 -d 10.10.10.10 -j DROP

/sbin/iptables -A OUTPUT -p tcp -d 0/0 -s 10.10.10.10 --dport 25 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 0/0 -s 10.10.10.10 --dport 53 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 0/0 -s 10.10.10.10 --dport 2089 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -d 0/0 -s 10.10.10.10 --dport 53 -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -d 0/0 -s 10.10.10.10 --icmp-type 0 -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -d 0/0 -s 10.10.10.10 --icmp-type 8 -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -d 0/0 -s 10.10.10.10 --icmp-type 30 -j ACCEPT
/sbin/iptables -A OUTPUT -p all -d 0/0 -s 10.10.10.10 -j DROP

В данном скрипте 10.10.10.10 - это IP адрес Вашего сервера. Если сервер имеет более одного IP то необходимо добавить эти-же строки но с другим IP .

Сделаем скрипт запускаемым:

chmod 755 /etc/firewall.sh

Добавим в /etc/rc.local строку:

/etc/firewall.sh

Осталось вручную загрузить правила:

/etc/firewall.sh

Будте осторожны - Вы можете закрыть доступ на сервер для самого себя.

Данный скрипт лиш пример-идея, которую Вы можете изменить согласно Вашим требованиям. Главное требование - это открыть лишь то, что необходимо для функционирования сервера, а остальное - закрыть.

4. Настройка cPanel(WHM)+apache+php.ini

Есть две задачи, которые в данном случае приходится решать, идя на компромис между ними:

- максимум возможностей для пользователя,

- максимум безопасности на уровне пользователя.

Увеличивая возможности для пользователя, а, соответственно, и привлекательность хостинга, нам прийдется забыть о safe mode для PHP. Однако, чтоб немного оградить тех же пользователей от взлома их страниц, а свой хостинг от проникновения скрипт-кидди, нам необходимо ограничить опасные функции, которые обычно используются для начального взлома системы.

Действовать будем, отталкиваясь от популярных уязвимостей.

Во-первых, это внедрение PHP кода в сценарии и выполнение произвольных команд. В php.ini прописываем следующее:

- запретим открытие/включение удаленных файлов:

allow_url_fopen = Off
enable_dl     = Off

- запретим выполнение команд:

disable_functions = ini_alter, curl_exec, exec, system, passthru, shell_exec, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, leak, listen, chgrp, chmod, set_time_limit, apache_note, apache_setenv, closelog, debugger_off, debugger_on, define_syslog_variables, openlog, syslog,ftp_exec,phpinfo,dl ;

запретим вывод php скриптами ошибок:

display_errors = Off

- выключим передачу информации о php в заголовках HTTP ответов:

expose_php = Off

Если пользователи не настаивают, то рекомендуем отключить и функции posix, с помощью которых возможен обход некоторых ограничений на выполнение команд.

Уязвимости типа SQL injection ограничим включением параметра

magic_quotes_gpc = on

В некоторых случаях можно было бы установить mod_security. Полезный модуль, который ограничивает внедрение SQL, java script и др. кода.

Полезно было бы сбить с толку горе-хакеров, изменив заголовок веб-сервера, отправляемый по умолчанию. Для apache это делается следующим образом. В файле src/include/httpd.h редактируем строки типа:

#define SERVER_BASEPRODUCT “Apache”
#define SERVER_BASEVERSION “1.3.27”

После этого компилируем веб-сервер и устанавливаем его. Впрочем, если вы установили mod_security, это все можно сделать с его помощью, не переустанавливая веб сервер.

И, наконец, зайдем в закладку "Tweak Security" в cPanel/WHM и активируем:

Php open_basedir Tweak
Compilers Tweak

Первый установит в httpd.conf на все VirtualHost open_basedir на домашнюю папку пользователя.

Второй разрешит доступ к GCC только для указанных в списке пользователей.

Эпилог

В данной статье рассмотрены методы борьбы на "передовой"; противодействие атакующему через веб-скрипты (apache/mod_php) на базе распространенной панели для shared hosting WHM/Cpanel (cpanel.net) с ОС Linux RHE. (Учитывая особенности работы данной панели, применяемые меры не идут в разрез с работой WHM/Cpanel), которые дают Вам зацепку, через которую можно выстроить достаточно плотную защиту обход которой будет не всегда соразмерен полученному результату.

P.S. Для всех используемых команд для более детального понимания прошу обращаться к man страницам.

"Лаборатория Касперского" - международная компания-разработчик программного обеспечения для защиты от вирусов, хакеров и спама. Продукты компании предназначены для широкого круга клиентов - от домашних пользователей до крупных корпораций. В активе "Лаборатории Касперского" 16-летний опыт непрерывного противостояния вирусным угрозам, позволивший компании накопить уникальные знания и навыки и стать признанным экспертом в области создания систем антивирусной зашиты.

Компания SoftKey – это уникальный сервис для покупателей, разработчиков, дилеров и аффилиат–партнеров. Кроме того, это один из лучших Интернет-магазинов ПО в России, Украине, Казахстане, который предлагает покупателям широкий ассортимент, множество способов оплаты, оперативную (часто мгновенную) обработку заказа, отслеживание процесса выполнения заказа в персональном разделе, различные скидки от магазина и производителей ПО.

Академия Информационных Систем (АИС) создана в 1996 году и за время работы обучила свыше 7000 специалистов различного профиля. АИС предлагает своим партнерам десятки образовательных программ, курсов, тренингов и выездных семинаров. Сегодня АИС представлена направлениями: «Информационные технологии», «Дистанционное обучение в области ИТ», «Информационная безопасность, «Управление проектами», «Бизнес-образование», «Семинары и тренинги», «Экологические промышленные системы», «Конференции», «Консалтинг» и «Конкурентная разведка на основе Интернет».

или введите имя

CAPTCHA
28-01-2016 14:11:15
Да все гораздо проще на самом деле! у меня такая проблема была в cPanel, я искала долго по всему инету ее решение и только сейчас нашла еще полезную статейку https://shneider-host.ru/blog/cpanel-oshibka-permission-denied-pri-udalenii-faylov.html, думаю, в ней более наглядно все указано))
0 |