soka

Хватит тупить, вам же сказали что $apikey это не параметр GET запроса, а логин для HTTP Basic Authentification. В паскале может вы и прокурены, а с протоколами веб аутентификации вы явно не знакомы и слушать что вам говорят не хотите. https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side GET: /uri HTTP/1.1 Host: domain.ru Authorization: Basic base64_string где base64_string - пользователь:пароль в base64 API это интерфейс, а каким образом с ним взаимодействуют - методом GET, POST, HEAD, REQUEST URI не имеет никакого отношения. А в остальном все правильно.

Вы что-то перепутали. В загрузчике файлов уязвимости нету и никогда небыло. Нашумевшая в свое время уязвимость была в десериализации кукисов посредством функцией unserialize, что позволяло под видом лога записать выполняемый файл с произвольным кодом. И то, наделала она столько шума потому, что иксперт нашедший ее хотел славы и слил в паблик вместе с эксплоитом. Пока выпустили патч, пока очнулись пользователи, скрипткиддисы бесчинствовали взломов не один десяток форумов. А учитывая что пользователи спали очень долго, потом и вовсе стали на автомате это делать. Но уязвимости была закрыта чуть больше чем три года назад. В том же году были выпущены еще несколько патчей, которые закрывали подобные уязвимости, но для которых небыло эксплоитов и конечно небыло зафиксировано ни одного взлома. Если до сих пор через нее взламывают, то о чем еще тут можно говорить, портрет этих пользователей очевиден. Из-за этой функции кстати пострадал не только ипб, но также джумла и ряд других популярных кмс. Отсюда мораль такова, что чем бы вы не пользовались, не важно ксенфоро с его хваленной "безопасностью" или ипб, нужно ставить вовремя патчи безопасности и знать, что не нужно устанавливать все подряд, особенно когда дело касается платных скриптов валяющихся в открыто в интернете, как минимум безопасность вам никто не гарантирует. А все эти страшные взломы выполняемые якобы крутыми хакерами на любом форуме, на практике не что иное как скрипткидди, которые порой даже не понимают принцип действия используемого ими эксплоита и пытаются его выполнять везде где только можно. Поставьте патч или создайте любое не типичную ситуацию и они просто обосрутся. Коль вы решили ставить нуллы, поинтересуйтесь о актуальной версии скрипта и не пренебрегайте уведомлениями безопасности.

Через какой загрузчик? Если возможно укажите конкретную уязвимость или на основании чего вы пришли к выводу что взломали через нее? Надеюсь не стоить говорить, что после релиза вышли несколько несколько критических патчей закрывающие sql инъекции? Факт взлома никто не отрицает, уязвимости есть и с этим не возможно не согласится (я сам не однократно "использовал" их ради опыта и определения возможности их эксплуатации) но непропатченные старые версии не в счет, как показатель я их не рассматриваю. Покажите форуме который своевременно обновлялся и устанавливались патчи безопасности которого взломали. Вы утверждаете что взлом производился на 3.4.8, меня это и заинтересовало, так как после этой версии выпускались патчи только для xss, эксплуатация которых требует определенных знаний и навыков и уж тем более не в реалтайме. Получить админский доступ через них не так просто. Если действительно речь про "чистый" 3.4.8 очень интересно послушать про эту уязвимость. Пока же все взломы с которыми я сталкивался это банальная пренебрежение безопасности и установка уязвимых версий. Хотел почитать сообщения данного пользователя чтобы определить уровень его компетентность, как правило люди разбирающиеся в предмете пишут и довольно интересно их почитать, но к сожалению кроме одного поста "я то же за" больше ничего не увидел.

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

В 3.4.8? Вы уверены? И конечно же эта версия была установлена с нуля, а не обновлялась с 3.4.6-7 где админ устанавливал патчи безопасности через полгода их выхода. На ютубе столько видео про эксплуатации sql инъекции, что любой школьник посмотрев и скачав эксплоит на питоне может "взломать форум". Мы не однократно сталкиваемся со взломами, и все как на подбор по одному сценарию, тот же самый пайлоад одного и того же эксплоита (естественно из паблика). Во всех случаях взлома с которыми доводилась сталкиваться я не встречался с не шаблонным взломом, например в той же самой sql инъекции в случае отсутствия доступа к sql логам вместо error based использовался бы time bassed injection. Откуда новоиспеченному хацкеру знать про брут через инъекцию на основе задержке ответа сервера, а уже тем более написать под это дело эксплоит. У нас нас имеются разные версии начиная с 3.0.5 которые мы патчим своевременно, и вот что удивительно - пока никто их не взломал, хотя попытки периодически повторяются, естественно с заезженными уязвимостями. Может просто нужно вовремя устанавливать патчи? Да, в ипб есть уязвимости (они есть в любом масштабном продукте). Но проблема не столько в них, сколько в школьниках которые скачивают незапатченные нуллы старые, а потом жалуются что их взломали. Или в администраторов которые пренебрежительно относятся к безопасности форума и не обновляют продукт.

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

Все идет к тому, что наша жизни на земле обречена и через 1,1 млрд лет она исчезнет в следствие увлечение светимости Солнца. И чем же она так хороша? https имеет смысл там где идет обмен конфиденциальными данными, на обычных сайтах "про котят" он нахрен никому не нужен и еще сто лет не будет нужен. Возможно, когда нибудь в будущем, через пару десяток лет, когда он станет протоколом по умолчанию...

Вы внимательно читали статью? Гугл приравнивает https к http и при выдаче будет отдавать предпочтение https дублям страниц доступные по разным протоколам, а не сайтам. "Вебмастеры" уже нафантазировали себе ниреальных ништяков в виде взлета в топе. Не о каком предпочтений сайтов там не говорится, а том что https будет по умолчанию если сайт доступен по двум протоколам.

Однозначно с далью вероятности 99,99% взлом был через WP. Конечно фору уже скопроментирован, для эффективного лечения надо менять все пароли - от администраторов форума, до бд и фтп и удалять шеллы.

Эти оба форума случайно не работают на одном аккаунте? Очень интересно посмотреть каким образом взломали 2.3 до такой степень.

Версией форума случайно не ошиблись? Там 3.x, да и у Вас в профиле указан 3.4x. Обычно каждой уязвимости характерен свой тип взлома. Такой тип явно не характерен для 2.3 - нет там таких явных уязвимостей. Есть разные xss которые на автомате эксплуатировать довольно сложно, что не характерно для того что вы описываете. Ручной взлом имеет свои особенные черты. Менее опасным, но не обеспечивающий защиту от повторного взлома.

Взломать 2.3 не так просто. Каким образом его взломали? В чем заключается взлом? Есть какие-то конкретные подтверждения что взломали именно его? Если ли на аккаунте другие сайты? Искать нехорошие файлы реально и в некоторых случаях даже предпочтительнее, но этим естественно должны заниматься компетентные люди. Искать вам все равно придется, в противном случае файлы придется удалять полностью вместе с вложениями, либо как минимум исключить исполняемые файлы из папки загрузки. Нулл может быть как скрипт без лицензионного ключа так и оригинальный дистрибутив в котором все функции сохранились. Правда найти последний не так просто, и в любом случае имеете шанс нарваться на бэкдор в скрипте которые так любят оставлять на варезниках. Лицензия прикрепляется к домену, так что вы можете использовать любой тип дистрибутива - проверяется наличие лицензии на использование ипб на то домене. Но это конечно некомильфо при лицензии использовать варезные дистрибутивы. Надо заботится о том что всегда был бэкап дистрибутива. Это прописная истина на ряду с обязательным бэкапом базы данных.

Указать в conf_global.php sql_utf8mb4 => true Такая ересь имеет место быть только когда данные в одной кодировки пытаются всунуть в таблицу другой. Например когда поле имеет кодировку cp1251, а туда вставляют двухбайтную кириллицу в utf-8, в итоге она обрезается наполовину потому что для нее рассчитано только 255 байт. На самом деле mysql выделяет столько место, сколько занимают символы в этой кодировке. varchar(255) будет содержать максимум 255 символов, а занимать место будет согласно кодировке этого поле.

$result = $this->DB->query( 'SELECT `conf_key`,`conf_value` FROM '.$this->settings['sql_tbl_prefix'].'core_sys_conf_settings WHERE conf_key IN ( "wa_mon_pro_1_ip","wa_mon_pro_2_ip","wa_mon_pro_3_ip","wa_mon_pro_4_ip","wa_mon_pro_5_ip", "wa_mon_pro_6_ip","wa_mon_pro_7_ip","wa_mon_pro_8_ip","wa_mon_pro_9_ip","wa_mon_pro_10_ip", "wa_mon_pro_11_ip","wa_mon_pro_12_ip","wa_mon_pro_13_ip", "wa_mon_pro_1_port","wa_mon_pro_2_port","wa_mon_pro_3_port","wa_mon_pro_4_port","wa_mon_pro_5_port", "wa_mon_pro_6_port","wa_mon_pro_7_port","wa_mon_pro_8_port","wa_mon_pro_9_port","wa_mon_pro_10_port", "wa_mon_pro_11_port","wa_mon_pro_12_port","wa_mon_pro_13_port", "wa_mon_pro_1_on","wa_mon_pro_2_on","wa_mon_pro_3_on","wa_mon_pro_4_on","wa_mon_pro_5_on", "wa_mon_pro_6_on","wa_mon_pro_7_on","wa_mon_pro_8_on","wa_mon_pro_9_on","wa_mon_pro_10_on", "wa_mon_pro_11_on","wa_mon_pro_12_on","wa_mon_pro_13_on", "wa_mon_pro_1_game","wa_mon_pro_2_game","wa_mon_pro_3_game","wa_mon_pro_4_game","wa_mon_pro_5_game", "wa_mon_pro_6_game","wa_mon_pro_7_game","wa_mon_pro_8_game","wa_mon_pro_9_game","wa_mon_pro_10_game", "wa_mon_pro_11_game","wa_mon_pro_12_game","wa_mon_pro_13_game") ORDER BY conf_id'); $s = 0; while ($row = mysqli_fetch_array($result)){ $s++; $data[$s] = $row; } $server[1]['on'] = $data[1]['conf_value']; $server[1]['game'] = $data[2]['conf_value']; $server[1]['ip'] = $data[3]['conf_value']; $server[1]['port'] = $data[4]['conf_value']; $server[2]['on'] = $data[5]['conf_value']; $server[2]['game'] = $data[6]['conf_value']; $server[2]['ip'] = $data[7]['conf_value']; $server[2]['port'] = $data[8]['conf_value']; $server[3]['on'] = $data[9]['conf_value']; $server[3]['game'] = $data[10]['conf_value']; $server[3]['ip'] = $data[11]['conf_value']; $server[3]['port'] = $data[12]['conf_value']; $server[4]['on'] = $data[13]['conf_value']; $server[4]['game'] = $data[14]['conf_value']; $server[4]['ip'] = $data[15]['conf_value']; $server[4]['port'] = $data[16]['conf_value']; $server[5]['on'] = $data[17]['conf_value']; $server[5]['game'] = $data[18]['conf_value']; $server[5]['ip'] = $data[19]['conf_value']; $server[5]['port'] = $data[20]['conf_value']; $server[6]['on'] = $data[21]['conf_value']; $server[6]['game'] = $data[22]['conf_value']; $server[6]['ip'] = $data[23]['conf_value']; $server[6]['port'] = $data[24]['conf_value']; $server[7]['on'] = $data[25]['conf_value']; $server[7]['game'] = $data[26]['conf_value']; $server[7]['ip'] = $data[27]['conf_value']; $server[7]['port'] = $data[28]['conf_value']; $server[8]['on'] = $data[29]['conf_value']; $server[8]['game'] = $data[30]['conf_value']; $server[8]['ip'] = $data[31]['conf_value']; $server[8]['port'] = $data[32]['conf_value']; $server[9]['on'] = $data[33]['conf_value']; $server[9]['game'] = $data[34]['conf_value']; $server[9]['ip'] = $data[35]['conf_value']; $server[9]['port'] = $data[36]['conf_value']; $server[10]['on'] = $data[37]['conf_value']; $server[10]['game'] = $data[38]['conf_value']; $server[10]['ip'] = $data[39]['conf_value']; $server[10]['port'] = $data[40]['conf_value']; $server[11]['on'] = $data[41]['conf_value']; $server[11]['game'] = $data[42]['conf_value']; $server[11]['ip'] = $data[43]['conf_value']; $server[11]['port'] = $data[44]['conf_value']; $server[12]['on'] = $data[45]['conf_value']; $server[12]['game'] = $data[46]['conf_value']; $server[12]['ip'] = $data[47]['conf_value']; $server[12]['port'] = $data[48]['conf_value']; $server[13]['on'] = $data[49]['conf_value']; $server[13]['game'] = $data[50]['conf_value']; $server[13]['ip'] = $data[51]['conf_value']; $server[13]['port'] = $data[52]['conf_value']; for($s=1; $s<=13; $s++){ if($server[$s]['on'] == 1) $srv[$s] = array ("ip" => $server[$s]['ip'], "port" => $server[$s]['port'], "game" => $server[$s]['game']); else $srv[$s] = array ("ip" => 'none', "port" => 'none', "game" => 'none'); } Автор, часом не из индии?.. Он положительно не слышал про алгоритмизацию через циклы и про конструктор запросов форума, хорошо хотя бы через метод форума выполнят запросы к бд. Но чуть ниже уже пишет mysqli_fetch_array, вместо $this->DB->fetch. И зачем ему нужен запрос к бд когда все настройки уже загружены в массиве $this->settings? $server[12]['on'] = $data[45]['conf_value']; $server[12]['game'] = $data[46]['conf_value']; $server[12]['ip'] = $data[47]['conf_value']; $server[12]['port'] = $data[48]['conf_value']; Это же как надо было умудрится расположить элементы в массиве $data, чтобы "$data[45]['conf_value']" соответствовал "$server[12]['on']"?.. Уныло. Дальше смотреть не стал, но думаю то же самое там творится. Весь этот яркий пример индусо кода можно было сократить в несколько раз простым циклом с 1 по 13: $server = array(); $data = array(); for( $i=1; $i<=13; $i++ ) { $on = $this->settings[ 'wa_mon_pro_'.$i.'_on' ]; $data[ $i ]['on'] = $on; foreach( array( 'ip', 'port', 'game' ) as $v ) { $key = 'wa_mon_pro_'.$i.'_'.$v; $server[ $i ][ $v ] = ( $on ) ? $this->settings[ $key ] : 'none'; $data[ $i ][ $v ] = $this->settings[ $key ]; } } $server = json_encode( $server ); $result = file_get_contents( $this->settings['board_url'].'/webask/mon/engine/index.php?url='.urlencode( $this->settings['board_url'] ).'&info='.urlencode( $server ) ); file_put_contents( DOC_IPS_ROOT_PATH . 'webask/mon/cache.web-ask.ru', $result ); file_put_contents( DOC_IPS_ROOT_PATH . 'webask/mon/cache2.web-ask.ru', print_r( $data, 1 ) );

Пиши в ЛС. Могу тебе сделать за 2000 руб так как нужно править файлы.

/system/Content/Controller.php \IPS\Output::i()->title = $container ? ( $title . ' - ' . $container->_title ) : $title; . ' - ' . $container->_title есть названия раздела

Не надо сказки рассказывать. Апач хоть немного и прожорливее, но не на столько, чтобы жрал в 20 раз больше чем nginx. 50-100 мб потребуется только операционной системы с демонами для управления веб-сервером. И вы хотите сказать что тройка с "кучой плагинов" и примерно 10К хитов в день будет работать нормально на оставшиеся 28-50 Мб? Для таких характеристик нужно как миимум 2Гб оперативной памяти на openVZ. Не знаю что у вас за чудо хостинг, может какая-то особенная виртуализация, может вы неправильно учитываете память.

Третий параметр функции is_subclass_of появился в версии 5.3.9.

./conf_global.php, sql_soket Узнать расположение сокета SHOW VARIABLES LIKE 'socket';

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

У вас две ошибки - вы неправильно указали mysql сокет в настройках форума и вторая, вытекает из первой - полезли создавать сим линки на сервер вместо того чтобы исправить конфигурационный файл. Неужели вы думаете что ips пишут скрипты под какую-то стандартную структуру сервера? Если магомет не идет к горе, гора придет к магомеду ©

Что вы несете, где вы там на скриншоте увидели 128 RAM? Там ясно написано Объем RAM 512. Пусть и на опенвз но все же. 128 мб только ос потребуется со всякими там ssh, ftp прочими атрибутами сервера. Веб-сервер и остальные его компоненты зависит от предустановленной системы и они могут меняться ПУ, тарифа, ос и пр.

Это доб обновления или после? Каким образом форум работал до этого?

В conf_global.php sql_utf8mb4 установить false. Проверить состояния данных в бд.

Для проверки никнейма используется символьный класс, так что "правильные" выражения подобрать там не возможно, только правкой сорсов. В \admin\sources\classes\member\memberFunctions.php найти if( ipsRegistry::$settings['username_characters'] ) { выше добавить if( preg_match( '/^\d+$/', html_entity_decode( $name ) ) ) { return array( 'name' => $original, 'errors' => array( 'Запрещены логины состоящие только из одних цифр.' ) ); }