Анонсирован (http://www.apache.org/dist/httpd/Announcement2.2.html) выход релиза Apache 2.2.10. В новой версии устранена неопасная XSS (межсайтовый скриптинг) уязвимость (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2939) в модуле mod_proxy_ftp, внесено 18 изменений (http://www.apache.org/dist/httpd/CHANGES_2.2.10), затрагивающих такие модули как
mod_proxy_http, mod_ssl, mod_authn_alias, mod_charset_lite, mod_dav_fs, mod_cgid, mod_headers, mod_rewrite.
Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС, при старте apache будет выполнен переход в изолированное окружение, корневая директория которого задана через директиву ChrootDir. Новшество совместимо с MPM модулями prefork и worker.
В mod_proxy_balancer добавлен метод балансировки 'bybusyness', учитывающий загруженность бэкенда. В mod_rewrite появились 2 новые опции, управляющие отправкой Cookie: secure (cookie отправляется только по https) и HttpOnly (для активации возможности некоторых браузеров по блокированию передачи cookie в JavaScript код).URL: http://www.apache.org/dist/httpd/Announcement2.2.html
Новость: http://www.opennet.me/opennews/art.shtml?num=18426
>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС,
>при старте apache будет выполнен переход в изолированное окружение, корневая
>директория которого задана через директиву ChrootDir. Новшество совместимо с
>MPM модулями prefork и worker.хм .. и чем это отличаетца от chroot /bla/bla bla
>хм .. и чем это отличаетца от chroot /bla/bla blaТем, что демон чрутится после старта и, соответственно, не надо копировать нужные библиотеки и проч в /bla/bla
>хм .. и чем это отличаетца от chroot /bla/bla blaКоличеством файлов которое надо закопировать в чрутовый каталог.Если чрут сделает сама программа - в каталог не надо будет копировать ворох потребных программе для старта библиотек...
>>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС,
>>при старте apache будет выполнен переход в изолированное окружение, корневая
>>директория которого задана через директиву ChrootDir. Новшество совместимо с
>>MPM модулями prefork и worker.
>
>хм .. и чем это отличаетца от chroot /bla/bla blaУ меня другой вопрос: чем это отличается от mod_chroot ?
Ведь сто лет как существует и используется mod_chroot.
>>>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС,
>>>при старте apache будет выполнен переход в изолированное окружение, корневая
>>>директория которого задана через директиву ChrootDir. Новшество совместимо с
>>>MPM модулями prefork и worker.
>>
>>хм .. и чем это отличаетца от chroot /bla/bla bla
>
>У меня другой вопрос: чем это отличается от mod_chroot ?
>Ведь сто лет как существует и используется mod_chroot.Могу ошибаться, но, похоже, это и есть интеграция mod_chroot — вместе с решением проблем, связанных с оным.
Ждем ебилдов.
>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС, при старте apache будет выполнен переход в изолированное окружение, корневая директория которого задана через директиву ChrootDir. Новшество совместимо с MPM модулями prefork и worker.Не прошло и 10 лет…
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src...
да в век OpenVZ и XEN chroot очень важная фича...>>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС, при старте apache будет выполнен переход в изолированное окружение, корневая директория которого задана через директиву ChrootDir. Новшество совместимо с MPM модулями prefork и worker.
>
>Не прошло и 10 лет…
>
>http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src...
>да в век OpenVZ и XEN chroot очень важная фича...Вообще chroot очень полезная фича. Например, SFTP с чрутом в хомяк пользователя - очень удобно. Опять же, так как сторонние эффекты минимальны, то бывает очень удобно использовать chroot при обновлении системы и тому подобных действиях.
К тому же, в отличие от Xen/OpenVZ/etc, chroot прост и надёжен. Примерно как Unix shell против Konqueror. :) Одно другого не отменяет.
... А 6 лет назад Xen был ещё той экзотикой:).
>>>Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОС, при старте apache будет выполнен переход в изолированное окружение, корневая директория которого задана через директиву ChrootDir. Новшество совместимо с MPM модулями prefork и worker.
>>
>>Не прошло и 10 лет…
>>
>>http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src...
>да в век OpenVZ и XEN chroot очень важная фича...Апач в век OpenVZ и XEN - выглядит слегка overbloated зачастую =).Например на VDS юзать оный достаточно дорого (RAM дофига надо).
> Отдельно стоит отметить, появление поддержки chroot для Unix-совместимых ОСАпач этого до сих пор не умел?!
Ему это не нужно. Это нужно параноидальным сисадминам.
>Ему это не нужно. Это нужно параноидальным сисадминам.Простите, когда ваш апач последний раз ломали (через mod_php, например)?
никогда, тра-ла-ла :)
>никогда, тра-ла-ла :)Вот кого не ломали, те и не парятся. Ну а кто раз наступил на грабли, второй раз уже обычно не хочет. :) ИМХО, это уже не паранойя.
chroot - это настолько маленькое и кривенькое спасение, что им можно пренебречь. значительно важнее поставить _правильные_ права на процессы апач, а не www или apache или nobody как у большинства
>chroot - это настолько маленькое и кривенькое спасение, что им можно пренебречь.
>значительно важнее поставить _правильные_ права на процессы апач, а не www
>или apache или nobody как у большинства1. chroot как средство обеспечения безопасности — это не спасение, а лишь средство уменьшения последствий успешной атаки.
2. Права на процессы не ставят. Их ставят на исполняемые файлы.
3. www/apache/nobody — это не права.
4. www/apache/nobody — это прогресс по сравнению с root.
5. И что же вы называете «правильными правами»?
> 1. chroot как средство обеспечения безопасности — это не спасение, а лишь средство уменьшения последствий успешной атаки.да. и в то же время обрезание всяких приятных возможностей типа вызова программ ОС
кому-то оно, может, и не нужно... я ничего не имею против. но на большинстве моих апачей мне chroot бы только мешал.
а на серверах, где у меня действительно www для всех я предпочитаю второе (см ниже)> 2. Права на процессы не ставят. Их ставят на исполняемые файлы.
вы сами не осознаете глубину своего морального падения :)
>> 1. chroot как средство обеспечения безопасности — это не спасение, а лишь средство уменьшения последствий успешной атаки.
>
>да. и в то же время обрезание всяких приятных возможностей типа вызова
>программ ОС
>кому-то оно, может, и не нужно... я ничего не имею против. но
>на большинстве моих апачей мне chroot бы только мешал.Вполне вас понимаю, кое-где мне тоже приходится его отключать. Просто возможности, приятные для вас, будут точно также приятны для взломщиков. Особенно вызов программ ОС. :)
>а на серверах, где у меня действительно www для всех я предпочитаю
>второе (см ниже)
>
>> 2. Права на процессы не ставят. Их ставят на исполняемые файлы.
>
>вы сами не осознаете глубину своего морального падения :)Если вы про всякие SELinux'ы и прочие systrace, то не волнуйтесь, я в курсе. И ещё про многое другое тоже в курсе. Зато вы, видимо, забыли, что все эти средства осложняют конфигурирование, сопровождение - и взлом сервера, но отнюдь не гарантированно спасают от последнего.
И расскажите-ка, всё-таки, широкой общественности, что такое, по-вашему, «_правильные_ права на процессы апач, а не www или apache или nobody как у большинства». suexec?
>Если вы про всякие SELinux'ы и прочие systrace, то не волнуйтесь, я
>в курсе. И ещё про многое другое тоже в курсе. Зато
>вы, видимо, забыли, что все эти средства осложняют конфигурирование, сопровождение -
>и взлом сервера, но отнюдь не гарантированно спасают от последнего.очевидно да. боже упаси от SELinux
>...что такое, по-вашему, «_правильные_ права на процессы
mod_ruid
потому что если в www-директории пользователя лежит файл с чужими правами, смысла защищаться уже нет
>>Если вы про всякие SELinux'ы и прочие systrace, то не волнуйтесь, я
>>в курсе. И ещё про многое другое тоже в курсе. Зато
>>вы, видимо, забыли, что все эти средства осложняют конфигурирование, сопровождение -
>>и взлом сервера, но отнюдь не гарантированно спасают от последнего.
>
>очевидно да. боже упаси от SELinux
>
>>...что такое, по-вашему, «_правильные_ права на процессы
>
>mod_ruidУгу, Костыль v2.0 :) При MaxRequestsPerChild равном единице проще сразу пользоваться CGI…
>потому что если в www-директории пользователя лежит файл с чужими правами, смысла
>защищаться уже нетНикто не спорит:). Правда, suexec придумали задолго до появления Apache 2.0… Кстати, помните, сколько было в том костыле ошибок, при, казалось бы, простой постановке задачи?
>Угу, Костыль v2.0 :)это замечательный костыль
>Никто не спорит:). Правда, suexec придумали задолго до появления Apache 2.0… Кстати,
>помните, сколько было в том костыле ошибок, при, казалось бы, простой
>постановке задачи?вы, видимо, не пробовали.
>>Угу, Костыль v2.0 :)
>
>это замечательный костыльОхотно верю.
>>Никто не спорит:). Правда, suexec придумали задолго до появления Apache 2.0… Кстати,
>>помните, сколько было в том костыле ошибок, при, казалось бы, простой
>>постановке задачи?
>
>вы, видимо, не пробовали.Пока что нет — пока что все сервера, где ставил Apache 2, были сугубо однозадачные, и поэтому не нуждались в suexec и ему подобных. Собсно, я бы и Apache 2 не ставил, но разработчикам надо mod_perl2… :)
>Пока что нет — пока что все сервера, где ставил Apache 2,по моему скромному ИМХО эта вещь заслуживает быть награждена как лучший модуль для Apache. :)
>были сугубо однозадачные, и поэтому не нуждались в suexec и ему
>подобных. Собсно, я бы и Apache 2 не ставил, но разработчикам
>надо mod_perl2… :)а теперь представьте, что perl,что php, что любой cgi работает именно под тем пользовтелем, под которым он был создан и ничего для этого делать не надо.
автор маааленького модуля трахнул всех создателей suexec'ов вместе взятых
работает, правда, только под Линукс. но в этом ничего плохого нет
>>Ему это не нужно. Это нужно параноидальным сисадминам.
>
>Простите, когда ваш апач последний раз ломали (через mod_php, например)?Полный бред, а чем chroot спасет вас от взлома mod_php?
>>>Ему это не нужно. Это нужно параноидальным сисадминам.
>>
>>Простите, когда ваш апач последний раз ломали (через mod_php, например)?
>
>Полный бред, а чем chroot спасет вас от взлома mod_php?А он и не должен спасать. Равно как и виртуализация. Он нужен чтобы минимизировать ущерб _после_ успешно проведённой атаки на сервер. Секурности собственно программе он не добавляет ни на грамм.
>>Ему это не нужно. Это нужно параноидальным сисадминам.
>
>Простите, когда ваш апач последний раз ломали (через mod_php, например)?Никогда.
При грамотной настройке, отключении всего ненужного и постоянного отслеживания уязвимостей и обновлении вероятность сломать апач по причине ошибки в самом апаче очень мала. Ломают чаще всего через дурно написанные скрипты.
>>>Ему это не нужно. Это нужно параноидальным сисадминам.
>>
>>Простите, когда ваш апач последний раз ломали (через mod_php, например)?
>
>Никогда.
>При грамотной настройке, отключении всего ненужного и постоянного отслеживания уязвимостей и обновлении
>вероятность сломать апач по причине ошибки в самом апаче очень мала.
>Ломают чаще всего через дурно написанные скрипты.Видите ли, то, что не нужно вам, вполне может быть нужно разработчикам, или ещё кому-то. Так что приходится балансировать. Ну а мудрость «знать где упасть — можно и соломку подстелить» ещё никто не отменял. :)
К слову, меня тоже пока что не ломали через Апач. Но это не значит, что не стоит пренебрегать дополнительными мерами защиты.