Форум

[QUOTE] написал:
[QUOTE] написал:
у меня на проекте, назовем его так, 15 человек в четырех городах, которые заходят в админку с компа, с телефона, с планшета, а далее, из офиса, из кафе, просто с улицы, с аэропорта и т.д. Как мне ограничить доступ по IP? это просто невероятная задача[/QUOTE]
Делов минут на 10, поднять прокси с авторизацией, адрес прокси (если прокси не на том же сервере что и сайт) прописать в конфиг nginx в разрешенные и вуаля [QUOTE] написал:
есть еще внешние сервисы, типа телеги и всяких маркетплейсов.[/QUOTE]
Если ip не статика, то выяснить какие файлы проекта отвечают за коммуникацию с внешними сервисами и завернуть трафик на прокси, ну или на свой страх и риск на крайняк дать им доступ с любых ip [QUOTE] написал:
Закрыться как черепаха в панцире можно[/QUOTE]
Нужно, превинтивно закрыть доступ к файлам с еще не выявленными ошибками это лучшее что можно придумать, ИМХО конечно![/QUOTE]
Так вот, выражаясь фигурально, Вы предлагаете мне создать еще одну форму авторизации. Мы начинаем городить огород вокруг огорода - это только для юзверов. А дальше вообще лес, который отменяет вообще надобность всех танцев с IP адресами - палюбому надо давать доступ внешним сервисам. Надевая панцирь черепахи (и то не факт, что не найдется других дыр, тем более отложенных бекдоров после взломов) наращивая структуру разрешенных IP, скорее всего, мы положим доступы к системе для какой-то части, не говоря уже о том, что каждый IP внешнего сервиса надо отловить и размещать руками. Не сработает, слишком трудоемкий и ресурсозатратный, а тем более опасный вариант - можно случайно остаться с голым Битрикс, в котором перестанет работать даже генерация печатных документов ))

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

И вот тут, кстати, интересен такой вопрос - а как быть с интернет-магазинами? Те же компоненты Аспро лежат именно в системной папке...

[QUOTE] написал:
[QUOTE] написал:
за исключением локального сервера и локального использования[/QUOTE]
В этом как раз таки и есть мораль - отсечь от внешней сети, то куда обычному пользователю нет необходимости лазить, вот разве обычному пользователю в отличии от хакера необходим доступ к примеру в каталоги  /bitrix/tools/...,  /bitrix/wizards/... и прочим? Нет, от слова совсем, так для чего эти каталоги словно кишки вспоротой свиньи торчат наружу? Для полноценного функционирования Битрикса доступ к данным каталогам можно смело ограничивать по ip

[QUOTE] написал:
не работает это на практике, нет возможности позакрывать всё[/QUOTE]
Если нет возможности закрыть 100%, то можно закрыть 99,99 %, и защитить на эти самые 99,99% свой сайт, выше привел кусок конфига nginx который отсекает все попытки хакеров получить доступ к файлам каталога /bitrix/, я почти каждый день смjтрю логи nginx и как это приятно видеть когда хакер лезет в каталог /bitrix/admin/... или /bitrix/tools/... и т.д. и получат ответ 444... не относитесь скептически, а возьмите и попробуйте, фича реально работает, проверно! [QUOTE] написал:
как Вы думаете, почему тема массовой регистрации ботов в админке до сих пор толком не представлена хоть одним нормальным решением[/QUOTE]
По мне причина в шаблонном мышлении, задача решатся закрытием в конфиге сервера возможности сканировать папки сайта и изменением адреса страницы регистрации на рандомную, которой априори нет в скрипте у ботов[/QUOTE]
Юрий, при всем моем уважении -  у меня на проекте, назовем его так, 15 человек в четырех городах, которые заходят в админку с компа, с телефона, с планшета, а далее, из офиса, из кафе, просто с улицы, с аэропорта и т.д. Как мне ограничить доступ по IP? это просто невероятная задача. К тому же, есть еще покупатели - для них интранет реализован... это я говорю только про людей, а есть еще внешние сервисы, типа телеги и всяких маркетплейсов. Закрыться как черепаха в панцире можно, когда для этого есть возможность - в подавляющем большинстве случаев, это нереально

[QUOTE] написал:
Не удалось выполнить отгрузку, так как для товара не указан маркировочный код. Зайдите в форму редактирования отгрузки, промаркируйте товар и повторите попытку.

Как отключить эту ошибку?[/QUOTE]

Карточка товара - Торговый каталог

самый низ - "Системные параметры"/группы товаров

вот тут все поубирайте, это и есть "маркировка"... Если не используете маркировку товаров, вообще поудаляйте группы.

[QUOTE] написал:
[QUOTE] написал:
устранять возможность взлома следует на уровне сервера[/QUOTE]
Прочитал статьи от разных рода студий касающиеся лечений и предотвращения заражений, и нигде не увидел подобной рекомендации, все рекомендации шаблонные, сводятся к обновлению платформы, но рекомендаций закрыть доступ к системным файлам сайта от хакеров не высказывается ... что это, ограниченность мышления или стремление к наживе на лечении зараженных сайтов? И ладно если бы дело касалось лишь меркантильности "лекарей", так и официалы не дают внятных пояснений почему все потроха сайта непременно должны быть вывалены наружу и доступны хакерам? Как это состояние мышления назвать?!!![/QUOTE]
не пишут по трем причинам, что это одна и та же информация от Битрикса или Аспро + абсолютное незнание предмета + нереальность позакрывать системники корректно и без ущерба самому себе

как Вы думаете, почему тема массовой регистрации ботов в админке до сих пор толком не представлена хоть одним нормальным решением, хотя тем на этот счет от "теоретиков" две тонны? потому что пишутся они людьми, которые разбираются в теме как свинья в балете - "посмотрите и заблокируйте IP"... а это ниразу не работает на практике. Хотя, дел там на 5 минут на самом деле. Более-менее толковые решения, пожалуй, можно найти только здесь, хотя и тут мусора с переизбытком.

[QUOTE] написал:
[QUOTE] написал:
Вот куда эта тварь ломится[/QUOTE]
Ломятся потому что могут, если у движка и приложений все "кишки" смотрят в инет, то взлом через 0-day уязвимости лишь дело времени, и последующие лечения устраняют лишь обнаруженную дыру, но никак не возможность взлома, устранять возможность взлома следует на уровне сервера - во первых поставить фильтра от разного рода инъекций, а во вторых закрыть весь каталог /bitrix от доступа извне, оставив лишь доступ локальным ip, доверенным ip, в том числе сервисам мониторинга Битрикса, nginx с этим справляется на ура[/QUOTE]
не работает это на практике, нет возможности позакрывать всё, за исключением локального сервера и локального использования

Вот куда эта тварь ломится. Видимо, есть часть сайтов, которые вскрывают через нештатные модули. ESOL так уж точно нужно ликвидировать с сайтов.

тоже получил подарки на трех подопечных сайтах.

лечился так: обновился, нашел все левые php.ini и файлы формата f0058fjdu45.txt
дырка обнаружилась банально через проактивную защиту - поиск троянов в модуле от esol
полностью удалил модуль со всех трех сайтов

4-й день сегодня - полет пока нормальный

[QUOTE] написал:
Вероятно надо выбрать в настройках базовую валюту доллары и, если вы не меняли стандартный шаблон вывода товаров, у вас выведется цена в долларах[/QUOTE]

Доброго всем дня. Такая проблема:

Мобильное приложение - Складской учет - Приход/оприходование

Все данные заполняются без проблем. Но когда дело доходит до указания валюты - базовая валюта не выбирается. При попытке выбрать валюту принудительно - открывается  форма выбора, но абсолютно пустая. таким образом валюту в документе выбрать не получается и документ именно в мобильном приложении не формируется. Как быть, кто сталкивался?