Взломали сервер

Т.е. фактически, хакеры нашли в сайте дыру, залили файло и =>нигде в логах это не отражено и не доказать напрямую что взлом был через дырку сайта.

Потому что наверняка ведь заливали туда, где обычно юзера цмски картинки льют.

А вот если у тебя внезапно mod_php5, директория с пользовательскими аплоадами находится в DocumentRoot где-то, и ты на нее не сделал ни RemoveHandler, ни какое-то правило насчет

<FilesMatch *.php>
Deny from all
</FilesMatch>

или чего-то подобного, внезапно стрелки переводятся и на админа тоже...

Но студенты оказались не слишком вумными и их быстренько нашли.

А как нашли?

Тогда его только вводили, поэтому вели еще бумажные ведомости и сверяли их с данными в электронном университете.
А дальше увидели, что есть различие и парней хотели выкинуть и даже дело завести, но смягчились и просто откатили их на курс назад.

CMS хоть какая, и модули какие стоят там?

хех ) как банально. А сейчас на бумаге не дублируется все, значит?

Если бы они всем студентам оценки поменяли, тогда бы шансов остаться незамеченными было больше :)

сейчас происходит мартышкин труд: препод выставляет в бумажные ведомости(2 экземпляра, если не ошибаюсь) галочку в графу с оценкой, пишет ее прописью, ставит свою подпись.
Затем это все несут в деканат к специальной тетечке, которая это дело парсит и заносит в электронный универ.
Так было года 2-3 назад. Сейчас, я надеюсь, сотрудники кафедры, принимающей экзамен сами могут проставлять данные, но бумаги все равно ведутся.
Парни слажали, да. Но им все равно повезло.

если файлы созданы от пользователя www-data, это значит что взломщик получил права веб-сервера => сломали именно веб сервер (в смысле апач, к примеру, а не сервер). Далее, если сервер обновлён и в дебиановской рассылке по безопасности нет информации о незакрытых уязвимостях, то, 99.99% что взломали сайт, а совсем не что-то иное. кстати, может быть соседский сайт сломали.. или Phpmyadmin или вордпресс.. короче тут возможны варианты в зависимости от ситуации с конфигурацией. но если б взломали чужой сайт, поди на чужом и поместили бы ссылки я думаю.. хотя варианты возможны..

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

как минимум небезопасная точка зрения. Скажем, проломав рутовый шелл легко выкладывать файлы от имени www-data, оставляя логи чистыми.

кстати, да.

Взлом сайта посредством взлома сервера

Звучит как: «Удаление зубов через сонную артерию! Быстро, просто, дёшево!».

Двумя словами описываю текст ниже: «организовать honeypot». Проводить логирование по сети на другую машину. Желательно сделать логирование максимально подробным. «Подчистить» сайт от платных ссылок и другой дряни. Искать уязвимости в скриптах: сначала по бюллетеням безопасности, затем вручную. Уязвимости не закрывать (для того, чтобы доказать, что в скриптах уязвимости). Проводить постоянный (не реже раза в день) мониторинг сайта и сервера.

спасибо. вроде то что надо!

да, тут есть слабое место, но остальные сайты там наши - и они все чистые. кстати, а какие варианты по разграничению доступа апача есть кроме jail? вроде раньше было что-то типа mod_itk и mod_perchild.. они еще живы?

тут есть такой момент - откуда админы сервера знают, где у клиента какие каталоги? Это ведь проблема программиста сайта. Клиент просто заливает по FTP сайт, а мы предоставляем услугу хостинга.

да, левые php-скрипты есть и в логах есть к ним обращения, но ничего необычного..

И в чём тогда смысл этого электронного университета, если всё всё равно на бумаге?

//Хотя сейчас у всех гораздо больше вопросов к «модульной системе».

вопрос, видимо, был адресован мне.
наверное, смысл в том, чтобы и родители и ученики могли контроллировать посещения и успехи в учебе.
но после того случая доступ «извне» закрыли, те ознакомиться с содержанием eu можно только из бауманских сетей.
модульная система коснется меня только на физре, и это, правда, будет очень глупо выглядеть. Может, я несколько зазнался, но студент 4 курса уже освоился в вузе и знает, как учиться.
Но придется терпеть.
Как они собираются расширить модульную систему на некоторые предметы нашей кафедры я слабо себе представляю, тк преподаватели банально пошлют все лесом, благо авторитет позволяет.

тут есть такой момент - откуда админы сервера знают, где у клиента какие каталоги? Это ведь проблема программиста сайта. Клиент просто заливает по FTP сайт, а мы предоставляем услугу хостинга.

А что, вашим клиентам доступно через .htaccess сделать RemoveHandler?

Есть такой вариант.
1) Сделать там предопределенную директорию для заливки пользовательских файлов, отключить в ней напрочь возможность выполнять скрипты

2) накатать рекомендации для нескольких популярных цмс, как сделать, чтобы закачиваемые пользователями (конечными, ну ты понял) файлы складывались туда

3) если кто инструкциям не следовал, тыкать носом до просветления.

Помню, давече один чувак жаловался, что на бюджетном хостинге вырубить Indexes нельзя вообще. Потому что для его DocumentRoot в недоступном для него конфиге апача выписали Options +Indexes и законопатили возможность изменить это значение через AllowOverride none. В его случае, конечно, админы тоже не виноваты, а это все он дурак, не понимает всех достоинств +Indexes.

Короче, вы оба неправы. Клиент профукал админку, а админ профукал секьюрити в важном месте.

нет, ну что скрипты это одно. но если ты видишь их _заливку_, то это доказательство того что они были залиты через уязвимость в cms.

Какие ещё аргументы?
Есть куча бесплатных cms стоящих на десятках сайтов.
Скачай какую нибудь и найди в дыру за день, бабла поднимешь.

Дыры могут быть вообще не в виде тупого SQL INJ который видно в логах, а из за багованной логики, или недостаточной фильтрации в конкретном месте (которое при этом все же не дает sql inj).
При этом в логах у тебя окажется только пара десятков POST запросов.

какие варианты по разграничению доступа апача есть кроме jail?

Это некий аналог chroot? Так тогда в каждом случае должен запускаться отдельный апач в изолированной среде?

А что, вашим клиентам доступно через .htaccess сделать RemoveHandler?

Ты столько всяких полезных вещей насоветовал, а самое главное скачать забыл.
Файл .htaccess должен быть в корне сайта, ровно один, без прав на перезапись скриптами.

И там кроме отключения скриптов должна быть одна важная типо такой:
<Directory /user_upload_data/*>
AllowOverride None
</Directory>
Апач не юзаю, поэтому лучше уточнить в манах.

Ибо очень многие товарищи запрещают лить php и даже запрещающие выполнение скриптов забывают о том, что надо запретить ещё и сам htaccess.
Влил свой htaccess, ну и фигач туда myshell.mp3

И да, не забываем о том, что у apache 1.x есть одна известная багофитча:
Если первое расширение файла ему не известно, но он будет ориентироваться на второе (и даже игнорить вырубание скриптов через htaccess).
Т.е «shell.php.wmv» будет исполнятся как php.
На это дело есть даже отдельный патч.

А что, вашим клиентам доступно через .htaccess сделать RemoveHandler?

гм.. ну <Files *.php> deny from all </Files>

доступно по-моему везде, если на то пошло.

Ну, это, конечно, да.

С другой стороны, это неудобно, когда файлы сыплются в черную дыру. Куда как лучше, если они отдаются обычным текстом.

Можно еще SetHandler default-handler прикрутить к файлам типа php, php5, phps и прочим таким типам.

Ибо очень многие товарищи запрещают лить php и даже запрещающие выполнение скриптов забывают о том, что надо запретить ещё и сам htaccess.
Влил свой htaccess, ну и фигач туда myshell.mp3

Можно через вышестоящий в самом главном apache.conf AllowOverride так кастрировать этот каталог, чтобы туда можно было только правила для mod_rewrite задавать. Это уж чтобы наверняка, а то .htaccess, который не может править скрипт, но может править пользователь, все же уязвим. Там можно указанный AllowOverride просто убрать, по указке из дурного ридми.