Изпечатай

[djpatzo]

Здравейте, отново. Значи проблема е следния. Пуснал съм safe_mode on но като се качи shell на сървъра и може да се излиза спокойно от директорията.. Можете да обясните как мога да го направя да не може да се излиза от директорията. Използвам CentOS 5.4 . На UBUNTU като бях там си функционираше тази опция. Единственото, което прави в момента, е да ми забранява include дори и от подпапка. Гледах в php.net но не видях никъде require Или include да са от забранените функции..

[neter]

Останах с впечатлението, че ще правиш сървър за хостинг, а не за лични нужди. Ако е така, то да си оповаваш сигурността на safe_mode опцията на PHP е пълна безсмислица. Първо, ограничаваш някои потребители, на които им е нужно safe_mode да е off, за да работят сайтовете им (и не с цел чупене на системата). Второ, safe_mode може да се включва и изключва от .htaccess (тъй като изпълнението му е на ниво apache, а не на ниво php), а потребителите ще си имат позволение да ползват .htaccess. Трето, кой е казал, че системата може да се чупи само с PHP? Съвсем спокойно може да ползва Perl например за целта, ако нещо PHP-то го спъва.
Не се занимавай с безсмислия, а чети за chroot jail за apache, както ти препоръчах и в предната тема

[borovaka]

Според мен пък е по добре да ползваш виртуални машини а не chroot но си е въпрос на вкус

[gat3way]

Ако се ползва php_admin_value в apache конфигурацията, не могат да се override-ват с .htaccess. Това може да се направи и per-vhost.

Но иначе, open_basedir и safe_mode не са особено добра идея.

[neter]

Според мен пък е по добре да ползваш виртуални машини а не chroot но си е въпрос на вкус

Всяко нещо с целите си. Не може да се каже, че shared hosting системата и vps-ът са взаимозаменяеми според вкуса. Всяко си има своите предимства и недостатъци спрямо другото. VPS-ът изисква повече ресурси в сравнение с shared hosting-а, така че би било твърде излишно разхищение на ресурси, ако shared hosting-ът е достатъчен за това, което се цели. Освен това, управлението на акаунти, намиращи се във виртуалните машини на потребителите, от страна на съпорта на хостинг компанията (говорим за масови промени на услуги във виртуалните машини) е много по-трудоемък процес в сравнение с този при shared hosting-а. А ако е дадено позволение на потребителите да достъпват системата във виртуалната машина, ще е направо невъзможно, а за какво му е на човек vps, ако няма да има достъп до системата. Но пък shared hosting-ът не дава тази свобода на управление на услугите от страна на потребителите, която дава vps-ът, и управлението на наличните ресурси. Има още много разлики, но няма смисъл да ги описвам - това са услуги, които се използват за коренно различни цели. Ако ще даваш достъп на потребителите да си качват сайтове и файлове, решението е shared hosting. Ако ще даваш достъп на потребителите да си управляват собствен сървър с всички приложения в него, но нямаш достатъчно хардуер за dedicated сървъри - решението е vps.

[borovaka]

В случая не говорех за отделна виртуална машина за всеки потребител, а по-скоро за подкарване на apache и самия hosting под виртуална машина. По този начин ще се избегне възможността за достъп до сървъра вижда ми се по-добро решение от гледна точка на сигурността. Иначе съм напълно съгласен с мнението ти.

[djpatzo]

Добре, а как да направя да не може да се излиза от директорията в която са потребителите, т.е. ако домейна е site.com и се хоства в директория /home/vhosts/main да не може да се излиза от main. Сега е конкретно зададен въпроса.

http://www.faqs.org/docs/securing/chap29sec254.html от този линк мога ли да си помогна...

[neter]

Това ръководство е по-добро. Досега не съм попадал на слабо ръководство от този сайт, така че го имай в предвид за разни неща, за които искаш да прочетеш как се правят. Не забравяй да прочетеш и страници 2 и 3 от ръководството, линкове към които можеш да намериш отдолу на страницата.
Не забравяй и да сложиш следния ред в конфигурацията на ftp сървъра, за да ограничиш ftp потребителите до техните папки:

DefaultRoot ~

В случая не говорех за отделна виртуална машина за всеки потребител, а по-скоро за подкарване на apache и самия hosting под виртуална машина. По този начин ще се избегне възможността за достъп до сървъра вижда ми се по-добро решение от гледна точка на сигурността.

Отново виждам само излишно разхищение на ресурси. Не знам какво точно имаш в предвид, но аз се сещам за два сценария на картинката. При първия web сървърът се инсталира във виртуалната машина, и във виртуалната машина се разполагат файловете на потребителите. Да, атакуващият няма да има достъп до реалната система, която държи включена виртуалната машина, но такъв достъп не му и трябва. Ако успее да се сдобие с root права, пак ще може да изключи или направо да изтрие цялата система на хостинга. Ще кажеш, че при тази схема имаме предимството, че можем лесно да правим бекъп с виртуалния твърд диск, и така бързо да се възстановява системата след срив? Не е много по-голямо времето за възстановяване на системата, ако се пазят два отделни бекъпа - единият с данните на потребителите, а другият с изображение на системата в състояние, готово за работа (данните в което може и да не се променят в бъдеще, или поне за дълъг период от време, така че няма да се налага да се прави често), след което да се плесват тези бекъпи след срив. Т.е., картинката откъм сигурност при този сценарий е една и съща както с реална, така и с виртуална система, така че разходът и ограничението на ресурси за поддържане на виртуална машина са напълно излишни. При втория сценарий web сървърът се намира на реалната машина, а на виртуалната машина седят само данните на потребителите, и web сървърът си ги черпи от там. Този сценарий ми изглежда още по-лош, защото (освен досега изброените недостатъци) ще има допълнително забавяне в четенето на файловете, а в зависимост от това как се направи схемата за вземане на файловете от виртуалната машина, атакуващият пак може да получи достъп до реалната система. Но, дори и да не получи достъп до реалната система, основната работа на хостингът отново ще може да бъде спряна, тъй като ще се получи достъп до файловете на другите потребители. И отново получаваме излишен разход на ресурси без никакво подсилване на сигурността.

[djpatzo]

От това което ми даде не иска да ми се стартира Apache(httpd) на какво може да се дължи това.

Ето и грешка от ErrorLog

Код

GeSHi (Bash):
[Tue May 25 20:29:02 2010] [emerg] (2)No such file or directory: mod_fcgid: Can't create share memory for size %zu byte

[gat3way]

Има смисъл от изолация в отделни виртуални машини. Точно така - всеки клиент получава отделна виртуална машина с инсталиран apache/mod_php/etc вътре. Що се отнася до дисковото пространство - относително гъвкаво нещата могат да се решат с някой storage сървър, който подържа iscsi (FC историите са доста скъпи). Вече дали му трябва шел (root?) достъп или не, е въпрос на преценка.

Това гарантира няколко неща: първо никой клиент няма да може да надскочи лимита си от процесорно време, колкото и да иска. Това е проблем при разните shared хостинги, където заради някакъв тежък сайт страдат останалите и се почват едни драми и разправии. Второ: много лесно им се дава повече място при желание. Всичко това може да стане ако подаваш на виртуалните машини LVM LV-та, които лесно се разширяват. Отделно вътре във виртуалната машина, ако се ползват нормални файлови системи като ext3, лесно се разширяват онлайн благодарение на resize2fs. Малко по-трудно се отнема място, ама все пак клиентите се очаква да искат още, а не да си режат нуждите. Освен което, при shared хостингите, много трудно се слагат квоти. Хубаво, ще сложиш ftp квота - всеки може да си направи формичка за HTTP upload и ще я заобиколи. Трябва всеки да работи в отделна монтирана файлова система с твърди квоти и тва е доволна простотия.

Виртуализацията дава висока сигурност. Дори някой да root-не виртуалната машина, ще му трябват някакви магии, за да хакне и хост операционната система/хипервайзора.

Накрая, най-голямото предимство е че така може да се осигури много високо availability. Ако имаш втора физическа машина, която също ползва споделените блокови устройства, виртуалните машини могат да се направят като клъстърна услуга примерно в RHCS, ако единият сървър падне, да се палят на другата и т.н. При нужда от хардуерно обслужване, нормалните софтуери за виртуализация като KVM и xen, имат наклонности за live миграции - демек местиш ги от хост на хост без да ги гасиш и клиентите трудно ще усетят разлика.

Overhead-а от виртуализацията не е толкова висок, ако се ползват разни паравиртуализационни наклонности, примерно при KVM може да се ползва virtio/virtnet.

Това според мен е почти перфектният хостинг - гъвкаво като collocate-нат сървър, по-сигурно от collocate-нат сървър и горе-долу толкова бързо (в зависимост колко ресурси му дадеш).


Разбира се, лошите страни ги има - излиза скъпо, освен което няма готови решения, с които да се менажира лесно, подобно на cpanel. Демек ще ти трябват администратори, които си разбират от работата. За щастие, клъстерния софтуер идва без пари, а неща като drbd силно намаляват разходите по разни скъпи SAN-ове и storage сървъри. При все това, излиза по-скъпо от традиционната схема със споделения хостинг, по-трудно се управлява и изисква хора, които разбират какво правят. Но печелиш доста сигурен хостинг, доста гъвкаво управляем и най-важното: много високо availability. Качеството на услугата е в пъти над това на разните сървърчета с инсталиран cpanel и администрирани малоумно.

[neter]

Точно това е основната отрицателна черта на VPS решенията - цената. Всичко друго изглежда много розово в сравнение с shared hosting-а, но след като проектът Венера постигне целите си. Иначе как да предложиш VPS за $1 например? А когато някой потребител има нужда просто от място, където да си плесне фирмения сайт или някакъв блог, който няма кой знае какви посещения, без да разбира от техническата част на въпроса, без нужда от собствен пощенски сървър, с миниатюрна вероятност някога да надхвърли мястото, което му е заделено по начало, с орязан бюджет, при който не може да си позволи лична администрация, но има нужда от реклама или някакво място в Мрежата, и т.н., shared hosting-ът е идеалното решение за тях. За да постигнеш максимално ниска цена, за да могат да си го позволят, орязваш всичко до максимум, автоматизираш всеки процес, за да имаш нужда от минимален съпорт екип, и се опиташ да оставиш (ако е възможно) само разходите за ток и наем на помещението (даже може и този разход да се махне, ако ти се намира помещение за целта). А стандартните потребители на shared hosting-а нямат нищо против това, тъй като получават това, от което имат нужда (нищо, че технически е много ограничено нещо), плащат сума, съответстваща на това, от което имат нужда, и са доволни. А това са преобладаващата част от сайтопритежателите в света - все повече стават хората, които искат да имат сайт, дори без да съзнават трябва ли им наистина, и ако може да е най-близко до безплатното.
Естествено, винаги се намира някой потребител, който иска нещо повече и се опитва да получи от почти безплатния хостинг нещо повече. Системите се задействат, акаунтът му се спира, и потребителят бива уведомен, че трябва да ползва хостинга съобразно целите му, или да премине на друга услуга (например VPS). И този потребител не трябва да се сърди, защото (образно казано) не може да иска с евтиния автомобил, за който плаща, да копае тунели. Всяко нещо има своя смисъл и всяко нещо с целите си.
По тази линия можем да кажем, че и в dedicated решенията има смисъл, да зарежем и VPS-а, да изтъкнем всички отрицателни черти на виртуализацията пред реалната машина... Но ще се наложи да вдигнем цената, заради повишената нужда от хардуер. При dedicated решенията съпортът може малко да се смали в сравнение с VPS-а, но се оказва, че хардуерът е по-скъп от човешката работна ръка. И накрая, търсейки най-мощното решение, даваме на нищо неразбиращ от администрация човек, който има нужда да си сложи фирмения сайт някъде, който дори може да не променя с години, цяла машина, и започва да разнася пици в квартала със самолет, за който плаща с пъти и пъти повече от това, което му докарва сайтът.

P.S.: Защо ли се разписах толкова по темата... Нещо ме е ударила музата. Хубаво обяснение даде gat3way за VPS-ите

[gat3way]

Бах, то заради това съществуват сайтове като zone-h, заради това ми се е случвало сума ти пъти да псувам когато не мога да отворя сайта на някой магазин или туристическа агенция там щото им го няма уебсървърa.

Но както и да е, ти си си напълно прав, те си си преценяват. В смисъл дори не могат да осмислят ползата от цялата работа и интернет присъствието им е нещо дето им е покрай другото и идеята е да минат възможно най-евтино за тия глезотии.

[djpatzo]

A относно мойто предното мнение, някой няма ли да ми даде конкретен отговор...

[neter]

[emerg] (2)No such file or directory: mod_fcgid: Can't create share memory for size %zu byte

Да не си пропуснал да създадеш папката /var/run в chroot средата (нямам в предвид системната папка /var/run), където модулът mod_fcgid се опитва да си задели памет? Ако е така, създай я (погледни ръководството). Или пробвай да добавиш този ред в конфигурацията на apache:

SharememPath /някаква/папка/fcgid_shm

като замени "/някаква/папка" с папка, за която си сигурен, че я има, и че всичко е наред с нея.

[djpatzo]

Папката я има... По туториалчето, което ми дадохте го правих. Само това е грешката. И не се стартира apache и най-интересното е, че не ми отваря виртуалните хостове. Четох и за тях от това което ми беше дадено, но нещо не схванах...