Сегодня на vc.ru опубликовали пост с простым расширением, которое тупо возвращает все регионы обратно, как это и было раньше. Решение Алаева отдыхает))
Бага выявлена: похоже вся беда в обновлённом glibc на сервере ) народ не обновляйтесь из sid репозиториев ) Я обновлял proftpd (закрывал багу касаемую mod copy)и не обратил внимания и попал )
pupseg: в принципе, если вас ничего не исполняется кроном от этих юзеров и для исполнения им не нужен шелл - то правильно сделали что закрыли. в первом приближении системным юзерам не нужен шелл, за исключением тех, от которых стартуют системные демоны.
по сути если что-то и исполняется то только от рута, так что для меня можно смело их рубить.
==============
В целях безопасности от долбёжек ботов убрал isp панельку на отдельный поддомен, а порт 1500 (встроенного ihttpd) переместил на локальный айпишник 127.0.0.1:
0) Создаём поддомен
к примеру cp.mydomen.ru, для создания достаточно в редакторе DNS добавить запись А на ваш ip:1.2.3.4 (через панель поддомен создавать не нужно)
1) в /usr/local/ispmgr/etc/nginx.domain у меня
server { listen 1.2.3.4:80; listen 1.2.3.4:443 ssl; server_name cp.mydomen.ru;
2) в /usr/local/ispmgr/etc/nginx.inc нужно закомментировать всё что есть или просто удалить
3) а в /etc/rc.local сменить внешний ip на локальный
/usr/local/ispmgr/sbin/ihttpd 127.0.0.1 1500
после всего вышепроделанного грохаем
killall ihttpd
и перазапускаем
/usr/local/ispmgr/sbin/ihttpd 127.0.0.1 1500
или рестартим систему
теперь панель стала доступной исключительно и только на поддомене + для которого подрублены access логи, так что проще будет искать )
Пробовал стандартными способами, через "Адрес панели" повесить её на отдельный поддомен, но что-то там всё глухо, не работает, так что при использовании способа делаем простое проксирование средствами nginx на ihttpd и забываем про эту вкладку навсегда.
P.S. постю это суда чтобы самому не забыть, и авось кому пригодится.
pupseg: ну а если не менять шелл и запрыгнуть в этого юзера su - www-data и дать там например ls -l , че нить покажет ?
Когда то проскакивала тут тема на форуме про какую-то критическую уязвимость в 4ой версии isp , дескать раскрывать ее не стали, потому что она дико какая то опасная, но вроде как ее закрыли.. лениво искать
Ничего не покажет права на папку /var/www 751, а владелец root :) зато командами в шеле может пользоваться всеми.
Через крон, в логах была бы приписка что это крон, а тут идёт GET запрос причём с IP адреса самого сервера, это значит, что запрос обрабатывается напрямую апачем. Поверх апача у меня nginx, порт апача во внешку закрыт.
Т.е. запрос может быть выполнен только через php скрипт имеющийся на сервере, к которому можно обратится, передать данный запрос и чтобы этот скрипт его отправил. Оба этих запроса идут с реферами моих сайтов на вордпрессе, а в вордпрессе это можно сделать только через XML-RPC, т.е. обратившись и передав сценарию xmlrpc.php
Вот и оно http://habrahabr.ru/post/215543/ (Pingback) так скорее всего и был отправлен запрос. В логах обоих сайтов кстати в 07:48 как раз идут обращения к xmlrpc.php (срубил нафиг его со всех сайтов)
Но хр*ен с ним с rpc не понятно как всё таки пасс уставился, видимо isp пропустил, а пропустить он мог только тогда когда его "положили", больше я не вижу путей.
Полагаю, таким образом они снижают нагрузку на свои сервисы.
Скорее ДНР, ЛНР не хотят туда добавлять вот и убрали.
Ага, дыру закрыли, недаром значит тревогу били.
Звучит именно так) но панель действительно лагает с новой версией сишной либы.
Бага выявлена: похоже вся беда в обновлённом glibc на сервере ) народ не обновляйтесь из sid репозиториев ) Я обновлял proftpd (закрывал багу касаемую mod copy)и не обратил внимания и попал )
В качестве примитивной защиты можно использовать скрипт DDoS-Deflate https://github.com/Amet13/ddos-deflate
От серьёзных ddos атак с множества серверов не спасёт конечно, но от школоты поможет.
в принципе, если вас ничего не исполняется кроном от этих юзеров и для исполнения им не нужен шелл - то правильно сделали что закрыли.
в первом приближении системным юзерам не нужен шелл, за исключением тех, от которых стартуют системные демоны.
по сути если что-то и исполняется то только от рута, так что для меня можно смело их рубить.
==============
В целях безопасности от долбёжек ботов убрал isp панельку на отдельный поддомен, а порт 1500 (встроенного ihttpd) переместил на локальный айпишник 127.0.0.1:
0) Создаём поддомен
к примеру cp.mydomen.ru, для создания достаточно в редакторе DNS добавить запись А на ваш ip:1.2.3.4 (через панель поддомен создавать не нужно)
1) в /usr/local/ispmgr/etc/nginx.domain у меня
listen 1.2.3.4:80;
listen 1.2.3.4:443 ssl;
server_name cp.mydomen.ru;
ssl_certificate /usr/local/ispmgr/etc/manager.crt;
ssl_certificate_key /usr/local/ispmgr/etc/manager.key;
if ( $scheme = "http" ) {
rewrite ^/(.*)$ https://$host/$1 permanent;
}
# Чтобы при обращении по IP вида http://1.2.3.4 панелька не открывалась
if ($host !~ ^(cp.mydomen.ru|cp.mydomen.ru)$ ) {
return 444;
}
error_log /var/log/nginx/cp.mydomen.ru.error.log;
access_log /var/log/nginx/cp.mydomen.ru.access.log;
set $mgr_proxy "https://127.0.0.1:1500";
location /manimg/ {
alias /usr/local/ispmgr/skins/;
access_log off;
expires 7d;
}
location / {
proxy_pass $mgr_proxy;
proxy_redirect $mgr_proxy /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
}
}
2) в /usr/local/ispmgr/etc/nginx.inc нужно закомментировать всё что есть или просто удалить
3) а в /etc/rc.local сменить внешний ip на локальный
/usr/local/ispmgr/sbin/ihttpd 127.0.0.1 1500
после всего вышепроделанного грохаем
и перазапускаем
или рестартим систему
теперь панель стала доступной исключительно и только на поддомене + для которого подрублены access логи, так что проще будет искать )
Пробовал стандартными способами, через "Адрес панели" повесить её на отдельный поддомен, но что-то там всё глухо, не работает, так что при использовании способа делаем простое проксирование средствами nginx на ihttpd и забываем про эту вкладку навсегда.
P.S. постю это суда чтобы самому не забыть, и авось кому пригодится.
В общем отрубил у всех юзеров без пасса шелл и вам советую
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
libuuid:x:100:101::/var/lib/libuuid:/usr/sbin/nologin
........................................................
и через /etc/ftpusers закрыл им доступ по ftp
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
nobody
www-data
proxy
backup
list
irc
gnats
libuuid
........................
будем следить далее за ситуацией )
ну а если не менять шелл и запрыгнуть в этого юзера su - www-data и дать там например ls -l , че нить покажет ?
Когда то проскакивала тут тема на форуме про какую-то критическую уязвимость в 4ой версии isp , дескать раскрывать ее не стали, потому что она дико какая то опасная, но вроде как ее закрыли.. лениво искать
Ничего не покажет права на папку /var/www 751, а владелец root :) зато командами в шеле может пользоваться всеми.
А вообще странная хренотень в Debian
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
у всех юзеров с пустым пассом * стоит шелл /bin/sh
Через крон, в логах была бы приписка что это крон, а тут идёт GET запрос причём с IP адреса самого сервера, это значит, что запрос обрабатывается напрямую апачем. Поверх апача у меня nginx, порт апача во внешку закрыт.
Т.е. запрос может быть выполнен только через php скрипт имеющийся на сервере, к которому можно обратится, передать данный запрос и чтобы этот скрипт его отправил. Оба этих запроса идут с реферами моих сайтов на вордпрессе, а в вордпрессе это можно сделать только через XML-RPC, т.е. обратившись и передав сценарию xmlrpc.php
Вот и оно http://habrahabr.ru/post/215543/ (Pingback) так скорее всего и был отправлен запрос. В логах обоих сайтов кстати в 07:48 как раз идут обращения к xmlrpc.php (срубил нафиг его со всех сайтов)
Но хр*ен с ним с rpc не понятно как всё таки пасс уставился, видимо isp пропустил, а пропустить он мог только тогда когда его "положили", больше я не вижу путей.