Горе от ума. Ленивые люди берут базовый тариф на лоукостере, там где почти нет диска, почти нет процессора, но есть безлимитная полоса в 100 Мбит/с и поднимают там OpenVPN. Остальное описано в книжках по сетям и NAT. В таком конфиге оно может даже быть вполне полезным. DDoS-ы не переживёт, а для добросовестного использования вполне хватит.
Там можно даже сайтики почти нормально хостить, выбросив на этот недохост на VDS провайдере nginx, а всё мясо развернув на узле дома....
Но нет, нужен телега-бот написанный на С++ который по curl-у с другого ресурса запрашивает IP и отдаёт его в телеге. Вся надежда на телегу, сайтик с определением IP и вот это вот всё....
Да, для других извращенцев, которым тоже простые решения как серпом по телу: как-то делал на bash раскривушку. Она получала IP из переменной окружения и регистрировала его на ns сервере. В том случае был BIND, но собрать такое на NSD нет проблем, даже проще. А дальше прописываем этот сервер 3-м уровнем (на второй нужна пара серверов), и конектимся по SSH. Всё нужное openssh положит в переменные окружения, останется только прописать команду на подключение по определённому ключу (в авторизованные ssh-ключ можно прописывать команды, стартующие при использовании этих ключей), откуда эта груда костылей получает имя (его прописываем в эту самую команду для ключа), регистрирует IP с которого проведено подключение и завершает сеанс. Конектится можно хоть раз в минуту, NSD переживёт.... Вот и халявный свой DynDNS с блек-джеком и всем, что развёртывающий вздумает на него навесить.... Можно даже узлы c NS и терминальный для соединений разнести по разным виртуалкам или контейнерам, если очень нужно.... У меня загнулось на этапе прототипа. Тесты прошло и было похерено, как рабочий концепт на случай атомной войны, поскольку решение с калиткой (точкой входа на дешёвой VDS) имеет больше перспектив и более управляемо и предсказуемо.
Упоминаемый Национальный Удостоверяющий Центр - это коммерческая шаражкина контора, созданная Гарантом на фоне роста рынка цифровых подписей и прочих ЭДО, о чём можно легко посмотреть по ИНН. Он такой же "национальный" как nic.ru, который должен быть основным регистратором для зоны RU (исходя из имени, и по началу даже был), но что-то пошло не так, рыночек порешал по-видимому... И эта контора уже не очень, даже как коммерческий регистратор. То что у нас бардак в наименованиях скажем спасибо либерализЬму и прочем свободам идиотизЬмов, когда за самым пафосным именем, скрывается самое ущербно ООО. Народ из министерства просто не заморачивался с названием. И прав по своему. При проблемах можно просто прибить АО....
Министерство - уполномоченное ведомство. Оно создало НУЦ - уполномоченный центр. В чем проблема? В том что НУЦ относится к министерству а не выделено в отдельную юр. морду.... Ну здесь на любителя, по мне, то что названо национальным, должно контролироваться государством полностью, иначе - это введение в заблуждение.
То что через ведомство попилили бабла, так не только в нём. У нас тут ГосОблако имени Ростелекома взлетает уже лет 10 на ежегодной основе. И ничего, пока не летит, в прошлом году снова поднимался вопрос об ГосОблаке.... Почему попиленный бюджет в прошлом должен стать препятствием к созданию НУЦ, не до конца понятно.
Вы можете входить из любого браузера на офф. порталы. Они просто должны доверять НУЦ. Пока доверяют из коробки двое. Остальные не хотят. Но есть сертификат, который им можно скормить. Если Браузер не принимает сертификат, то это проблема браузера а не УЦ его выпустившего...
И да по тому, что в сфере ГосИТ у нас не просто бардак, а пылающий звёздный бардачело даже не спорю. В такие непроходимые джунгли из поделий, недопродуктов и процего, без всякого намёка на стройную структуру, всё это довести прямо талант нужен. Наши люди талантливы... Но конкретно по НУЦ претензий нет, главное чтобы это был спец. комплекс а не роль Центра сертификации Microsoft на компе одного из админов в Министерстве.
Возможно это утверждение сделано на основе психологической травмы, нанесённой эксплуатацией этого чуда. Я верю, что знаючи эту тварь дотошно, её можно сделать адекватной (у людей то как-то выходит...). Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы... это само собой напрашивается на проблемы.... Вот что мешало эти долбаные объекты инициализировать json файлами???...
А так, при общей популярности темы сайтостроительства и общей уверенности, что выучив PHP можно почти сразу разбогатеть на непыльной работе (ну по крайней мере в горизонте прошлых лет), в отрасли полно людей склонных использовать инструменты криво, опасно и даже преступно... Вот только в сочетании с Bitrix это становится просто идеальным штормом...
Эта дрянь должна писать в себя, чтобы жить. Писать она может даже то, что потом она будет исполнять. И МАЛЕЙШЕЕ отверстие, позволяющее выполнить свой (атакующего) код в контексте сервера (а судя по тому, какая круговерть творится вокруг движка, пока он творит свою чёрную магию, этих отверстий там порядком), либо малейшая дрянь которую можно положить через механизмы движка на сервер а затем исполнить php-интерпретатором, даёт полный контроль над всем движком. И червяк начинает методично разбрасывать обфусцированные сниппеты по всем index.php и прочему бардаку, что обильно разбросан по всему движку, на всю, местами неадекватную, глубину вложенности. Я как администратор не могу с этим справится, в Bitrix нет такого каталога, где лежит код, и куда пользователь (лицо взаимодействующее с сайтом даже через админку) писать не должен, и каталога, где лежит переданное от клиента, и от которого должен держаться подальше php-fpm (ну по крайней мере не исполнять от туда скрипты). И это бесит! Я не в силах понять, что творится при создании контента. Простыни инициализируемых объектов мало чем сами отличаются от вредоносов. Ну нет там смысла для взгляда человеческого и нельзя в среднем объять мозгом простынь на 4-10 скролов с перечислением каких-то инициализируемых свойствах убер объекта...
Итого:
Битрикс делает невозможной пассивную защиту, поскольку нельзя реализовать классическую схему W^X (то куда можно записать не должно исполняться)
Он не позволяет легко понять, что на ресурсе происходит что-то не то. Оно штатно разбрасывает неожиданные php файлы в непостижимые места, многие из которых плохо выделяются на фоне вредоносов...
Эта штука умудряется заразиться кажется даже быстрее чем Windows XP с SP1 выставленная голой жопой в интернет. При этом если XP от интернета можно держать на расстоянии, то с Bitrix это не выйдет совсем...
И при всех своих заслугах оно стоит дичайших денег.....
Сталкивался с Bitrix несколько раз в качестве специалиста по "заставить это как-то работать" (aka эксплуатация на максималках). Все разы меня терзал странный вопрос: как это чудо света (а это без сомнения чудо света, ибо совершенно не постижимо как при наличии уже понимания, что нужно разделять в сущности представление, действия над ней её данные, всего накопленного опыта CMS можно было породить ЭТО) достигло своих высот.
Для меня как эксплуатации, данная CMS является головной болью. Ей нельзя запретить писать в собственные директории на сервере. То есть, без специальных извращений с несколькими экземплярами PHP под разными пользователями, один из которых под публичную часть, второй под админку, эта штука не способна защитить себя от различных червей. Мне приходилось иметь дело с дырявой Joomla. И манипуляция с правами пользователя PHP на файлы и директории давала достаточно защиты от червей. Да нужно обновляться но сидя в конторе в одно лицо, без умных (ну или просто) семпаев, задача "не ушатай" становится более приоритетной... Такой фокус с Bitrix не прокатит, там нужно иметь 4-й дан в эксплуатации PHP, чтобы защитить это чудо без постоянных обновлений. При чистой эксплуатации, когда все изменения в сайте производит разработка, либо заказчик, а я просто держу это на плаву, единственным решением задачи защиты стало обернуть всё в меркуриал репозитарий, выполнения с некоторой периодичностью status и если там что-то появилось отправку diff на почту, для дальнейшего выяснения, кто-куда-зачем.... Даже, когда разработки утверждала, что оно обновлено, раз в неделю diff давал 100500 файлов загаженных сложно вычленяемыми на фоне остального говнокода сниппетами заразы...
Работа сабжа со стилями вызывает трепет. Если не знать того единственного правильного способа (который мне лично не известен), оно порождает миллион css файлов, и весь этот миллион тянется пользователем при запросе страницы. И эти файлы однотипны и отличаются только штампов времени в конце. Понять откуда это всё без вдумчивого изучения решительно нельзя...
Поменять что-то на странице, если это не предусмотрено разработчиком модуля, вёрстки и прочего, даже при наличии доступа к коду, практически не реально. Понять куда там запрягают коней без специальных курсов решительно нельзя. В админке найти нужно тебе опцию - квест повышенной сложности. Если оно падает, то никто кроме поднимавшего не сможет вернуть всё взад (ну или разворачивание резервной копии с потерей всего, что сделано после её создания). Если человек, кто разворачивал, делал это методом тыка - ничто не поможет кроме бекапа....
Если кто-то сможет объяснить почему оно ТАК популярно, нижайше прошу просветить, иначе у меня создаётся впечатление о клиническом садомазохизме всей отрасли российского сайтоделательства. Нет, как коммерческий продукт, для создателей этой CMS - это просто шедевр: эксплуатация будет платить за лицензию, потому что ей нужны будут обновы. Там есть место облачным сервисам, поскольку НУЖНО регулярное резервное копирование и не помешает CDN, особенно если это чудо развёрнуто на shared-хостинге с драконовскими лимитами по диску. Но блин, что это кроме откатов даёт эксплуатации не ясно. Даже знакомый разработчик сайтов мне не смог внятно ответить о плюсах "продукта", но живописал великим и могучим своё к нему отношение....
Учиться работать с БД в рамках языка программирования с того, чтобы учиться работать с БД в целом, ИМХО плохая затея. Ибо человек такое создание, что склонно терять лес за деревьями, а реляционная логика, понятие множеств и действий над ними, на которых она строится и общая логика работы СУБД даст достаточно деревьев, чтобы за ними напрочь, месяцев на 6 минимум, полностью потерять GO из виду =))))) Эту часть квеста лучше проходить заранее....
А в рамках топика, о ALL, а никто не порекомендует обновляемый, адекватный, online справочник по синтаксису и стандартной библиотеке Go на русскомязыке.
Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
Считать максимум рабочих процессов от памяти - способ отстрелить себе пол организма под нагрузкой. Конкурирующие за вычислительный ресурс рабочие процессы будут друг-друга сильно тормозить. Такой фокус можно использовать только при том, что большая часть этих процессов будет спасть в ожидании данных с БД, и то до того момента как от DBA не прилетит не иллюзорная звездюлина, поскольку ему тоже вряд ли досталась SUN Niagara и количество исполнительных каналов процессоров у него на сервер БД также ограничено, а памяти и прочего процессы СУБД жрут не в пример больше чем php-fpm даже при достаточно кривом php коде...
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
То что браузеры исполняют их в песочнице не помешало эксплуатировать спектру с JS. Поэтому я и говорю, что времена, когда мы все были в домике и глаз хватало, чтобы быть в безопасности давно прошли.
Если скрипты и проникнут на ваш компьютер, то скорей через эти самые антивирусы, которые разрабатываются мелкими компаниями и безопасность которых никто толком не проверяет, в отличие от браузеров.
Я дико извиняюсь, но антивирусные компании очень даже немаленькие, а мантру о том что множество глаз БДИТЕЛЬНО следят мы проходили во времена heartbleed. Не помогло OpenSSL, за которым следили параноики, почему должно помочь браузерам.
А нода здесь как самый яркий пример того, как обычная человеческая лень программеров увеличивает поверхность атаки на порядок, а бардак в их модной инфраструктуре вполне может спровоцировать получение JS-зловреда с уважаемого сайта, и уберечься от этой дряни, хотя бы спустя некоторое время, сможет помочь только антивирусник.
И да, я читаю ежедневный отчёт от Kaspersky Cecurity Center по моей маленькой непримечательной сетке, и крайне счастлив, что вся эта дрянь из отчёта осталась за пределами сетки.
Все системы антивирусной защиты делятся на дырявое решето и имеющие функцию подмены сертификата. Как вы предлагаете проверять js-дрянь, идущую по SSL каналу. Кончилось то время когда на Web-е лежали файлики, и если не позволять им запускаться - то всё будет зашибись. Сейчас с помощью js Вас могут завязать в узел и сложить из Вас оригами почти не приходя в сознание с использованием только штатных API. А если к этому добавить не контролируемое вовсе мракобесие с node.js и просто разбросанными по интернету файлы с кусками фреймворков, в время от времени находят разное.
Вообще есть прекрасный способ сделать так, чтобы за пользователем не следили и он был в безопасности. Нужно по сайтикам лазить ка Столман. Где-то на хабре вроде была статья с его рецептом успеха. А в остальное время, приходится использовать проверку SSL-трафика, и внимательно следить за исключением трафика всяких банк-клиентов, которые это местами страсть как не любят.
Я правильно понимаю, что пересменка происходит на АТП, куда машина гонится с РЦ уже гружённая на следующий рейс? Если да, то не до конца понятно:
Почему пересменку нельзя сделать на РЦ, доставив туда новых водителей попутно другими машинами, либо просто установив точку рандеву на РЦ, перенаправив туда служебный вахты с водителями, которые должны начать рейс в ближайшее время.
Зачем гнать на АТП машину, когда большую часть проверок можно провести по окончании рейса, а на РЦ дежурный механик просто проведёт общий осмотр машины перед погрузкой и после неё на предмет базовых технических проблем. В конце концов машина должна уйти с АТП здоровой, и маловероятно, что по дороге у неё произойдёт что-то, что не сможет увидеть техник напару с водителем, закреплённым за машиной. Явно сейчас его там нет, но можно отправлять народ с АТП по графику на дежурство на РЦ на отдых за "особые заслуги". Тогда не нужно печатать документ до рейса, рейс начнёт уже сменщик и распечатает себе документы. Вся задумка с QR исключительно из-за того, что водители явно исполняют обязанности и экспедиторов и отвечают за груз, поэтому необходимо следить за погрузкой. Если снять с водителей такую ответственность через упаковку товара в контейнеры (на колёсиках) и оставить за водителями только ответственность доставить соответствующее количество контейнеров на соответствующие точки, а разборки по загруженной номенклатуре предоставить сборщикам и контролёрам на РЦ, принимающими специалистами на точках, обеспечив надёжные средства доказательства невмешательства водителя в груз, то водителям вообще должно быть без разницы: один доставил машину на РЦ и поставил на погрузку, тем самым завершив смену, второй просто принял гружёную машину вцелом, проверив что все места на месте, и пошёл распечатывать на неё документы, по которым после уже начинает свой рейс.
Просто мне кажется, что описанный в статье процесс слишком наворочен и разухабист. Очень похоже, что героически решили проблемы, возникшие из-за того, что "всегда так делали и вы задолбётесь пересогласовывать бизнес процессы целиком, но можно согласовать несколько костылей к ним, и обойтись малой кровью и не сдохнуть в совещаниях с топами сразу нескольких неповоротливых дивизионов, где каждый будет отстаивать незыблемость своих бизнес процессов, ибо если их колыхнуть, то сразу 100500 тысячмилионов долларов убытков ежеминутно" (с) Очень хочется верить что хоть у вас нету такой фигни....
Так и не понял, зачем такие сложности. Машина и водитель, вообще ИМХО разные сущности. Водитель вернул машину в РЦ (пересечение ворот), тем самым закрыл свой рейс, отметилось время. После этого машина обслуживается и попадает в планирование на рейсы в очереди. При необходимости, если в смене водителя осталось время, он её подаёт под загрузку. Загрузка происходит по планшетам, и склад формирует фактическую загрузку, и формируются документы в электронном виде. После загрузки уже тот водитель, который повезёт груз подходит к принтеру, которых может стоять батарея, сканирует QR из приложения на планшете/телефоне, ему отдаются накладные на все точки, которые уже по факту визируются и он едет. То есть машину рассматриваем отдельно, а водителя на неё планируем отдельно. А не вот этот человекомашинный комплекс с переходным состоянием "у первого водителя смены не хватит на следующий рейс, поэтому пусть он загрузит, а второй разгружать будет". Здесь есть вопросы с экспедицией, но если рассматривать сборку тележки (та хрень на колёсиках, которая в сетях и является местом груза) отдельно, то есть привязывать комплектовщика к этой тележке, накладывая на него ответственность за сборку и учёт собранного, и качественно опечатывать, на ценный груз используя прочные чехлы, на малоценку использовать продуманные механизмы опечатывания и фотоотчёты, может получится даже несколько гармоничней.
Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
а делать правильно
Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.
И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.
Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.
Горе от ума. Ленивые люди берут базовый тариф на лоукостере, там где почти нет диска, почти нет процессора, но есть безлимитная полоса в 100 Мбит/с и поднимают там OpenVPN. Остальное описано в книжках по сетям и NAT. В таком конфиге оно может даже быть вполне полезным. DDoS-ы не переживёт, а для добросовестного использования вполне хватит.
Там можно даже сайтики почти нормально хостить, выбросив на этот недохост на VDS провайдере nginx, а всё мясо развернув на узле дома....
Но нет, нужен телега-бот написанный на С++ который по curl-у с другого ресурса запрашивает IP и отдаёт его в телеге. Вся надежда на телегу, сайтик с определением IP и вот это вот всё....
Да, для других извращенцев, которым тоже простые решения как серпом по телу: как-то делал на bash раскривушку. Она получала IP из переменной окружения и регистрировала его на ns сервере. В том случае был BIND, но собрать такое на NSD нет проблем, даже проще. А дальше прописываем этот сервер 3-м уровнем (на второй нужна пара серверов), и конектимся по SSH. Всё нужное openssh положит в переменные окружения, останется только прописать команду на подключение по определённому ключу (в авторизованные ssh-ключ можно прописывать команды, стартующие при использовании этих ключей), откуда эта груда костылей получает имя (его прописываем в эту самую команду для ключа), регистрирует IP с которого проведено подключение и завершает сеанс. Конектится можно хоть раз в минуту, NSD переживёт.... Вот и халявный свой DynDNS с блек-джеком и всем, что развёртывающий вздумает на него навесить.... Можно даже узлы c NS и терминальный для соединений разнести по разным виртуалкам или контейнерам, если очень нужно.... У меня загнулось на этапе прототипа. Тесты прошло и было похерено, как рабочий концепт на случай атомной войны, поскольку решение с калиткой (точкой входа на дешёвой VDS) имеет больше перспектив и более управляемо и предсказуемо.
Что за поток создания?
Упоминаемый Национальный Удостоверяющий Центр - это коммерческая шаражкина контора, созданная Гарантом на фоне роста рынка цифровых подписей и прочих ЭДО, о чём можно легко посмотреть по ИНН. Он такой же "национальный" как nic.ru, который должен быть основным регистратором для зоны RU (исходя из имени, и по началу даже был), но что-то пошло не так, рыночек порешал по-видимому... И эта контора уже не очень, даже как коммерческий регистратор. То что у нас бардак в наименованиях скажем спасибо либерализЬму и прочем свободам идиотизЬмов, когда за самым пафосным именем, скрывается самое ущербно ООО. Народ из министерства просто не заморачивался с названием. И прав по своему. При проблемах можно просто прибить АО....
Министерство - уполномоченное ведомство. Оно создало НУЦ - уполномоченный центр. В чем проблема? В том что НУЦ относится к министерству а не выделено в отдельную юр. морду.... Ну здесь на любителя, по мне, то что названо национальным, должно контролироваться государством полностью, иначе - это введение в заблуждение.
То что через ведомство попилили бабла, так не только в нём. У нас тут ГосОблако имени Ростелекома взлетает уже лет 10 на ежегодной основе. И ничего, пока не летит, в прошлом году снова поднимался вопрос об ГосОблаке.... Почему попиленный бюджет в прошлом должен стать препятствием к созданию НУЦ, не до конца понятно.
Вы можете входить из любого браузера на офф. порталы. Они просто должны доверять НУЦ. Пока доверяют из коробки двое. Остальные не хотят. Но есть сертификат, который им можно скормить. Если Браузер не принимает сертификат, то это проблема браузера а не УЦ его выпустившего...
И да по тому, что в сфере ГосИТ у нас не просто бардак, а пылающий звёздный бардачело даже не спорю. В такие непроходимые джунгли из поделий, недопродуктов и процего, без всякого намёка на стройную структуру, всё это довести прямо талант нужен. Наши люди талантливы... Но конкретно по НУЦ претензий нет, главное чтобы это был спец. комплекс а не роль Центра сертификации Microsoft на компе одного из админов в Министерстве.
Возможно это утверждение сделано на основе психологической травмы, нанесённой эксплуатацией этого чуда. Я верю, что знаючи эту тварь дотошно, её можно сделать адекватной (у людей то как-то выходит...). Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы... это само собой напрашивается на проблемы.... Вот что мешало эти долбаные объекты инициализировать json файлами???...
А так, при общей популярности темы сайтостроительства и общей уверенности, что выучив PHP можно почти сразу разбогатеть на непыльной работе (ну по крайней мере в горизонте прошлых лет), в отрасли полно людей склонных использовать инструменты криво, опасно и даже преступно... Вот только в сочетании с Bitrix это становится просто идеальным штормом...
Эта дрянь должна писать в себя, чтобы жить. Писать она может даже то, что потом она будет исполнять. И МАЛЕЙШЕЕ отверстие, позволяющее выполнить свой (атакующего) код в контексте сервера (а судя по тому, какая круговерть творится вокруг движка, пока он творит свою чёрную магию, этих отверстий там порядком), либо малейшая дрянь которую можно положить через механизмы движка на сервер а затем исполнить php-интерпретатором, даёт полный контроль над всем движком. И червяк начинает методично разбрасывать обфусцированные сниппеты по всем index.php и прочему бардаку, что обильно разбросан по всему движку, на всю, местами неадекватную, глубину вложенности. Я как администратор не могу с этим справится, в Bitrix нет такого каталога, где лежит код, и куда пользователь (лицо взаимодействующее с сайтом даже через админку) писать не должен, и каталога, где лежит переданное от клиента, и от которого должен держаться подальше php-fpm (ну по крайней мере не исполнять от туда скрипты). И это бесит! Я не в силах понять, что творится при создании контента. Простыни инициализируемых объектов мало чем сами отличаются от вредоносов. Ну нет там смысла для взгляда человеческого и нельзя в среднем объять мозгом простынь на 4-10 скролов с перечислением каких-то инициализируемых свойствах убер объекта...
Итого:
Битрикс делает невозможной пассивную защиту, поскольку нельзя реализовать классическую схему W^X (то куда можно записать не должно исполняться)
Он не позволяет легко понять, что на ресурсе происходит что-то не то. Оно штатно разбрасывает неожиданные php файлы в непостижимые места, многие из которых плохо выделяются на фоне вредоносов...
Эта штука умудряется заразиться кажется даже быстрее чем Windows XP с SP1 выставленная голой жопой в интернет. При этом если XP от интернета можно держать на расстоянии, то с Bitrix это не выйдет совсем...
И при всех своих заслугах оно стоит дичайших денег.....
Решительно отказываюсь понимать происходящее.....
Какой ужас....
ППКС.
Сталкивался с Bitrix несколько раз в качестве специалиста по "заставить это как-то работать" (aka эксплуатация на максималках). Все разы меня терзал странный вопрос: как это чудо света (а это без сомнения чудо света, ибо совершенно не постижимо как при наличии уже понимания, что нужно разделять в сущности представление, действия над ней её данные, всего накопленного опыта CMS можно было породить ЭТО) достигло своих высот.
Для меня как эксплуатации, данная CMS является головной болью. Ей нельзя запретить писать в собственные директории на сервере. То есть, без специальных извращений с несколькими экземплярами PHP под разными пользователями, один из которых под публичную часть, второй под админку, эта штука не способна защитить себя от различных червей. Мне приходилось иметь дело с дырявой Joomla. И манипуляция с правами пользователя PHP на файлы и директории давала достаточно защиты от червей. Да нужно обновляться но сидя в конторе в одно лицо, без умных (ну или просто) семпаев, задача "не ушатай" становится более приоритетной... Такой фокус с Bitrix не прокатит, там нужно иметь 4-й дан в эксплуатации PHP, чтобы защитить это чудо без постоянных обновлений. При чистой эксплуатации, когда все изменения в сайте производит разработка, либо заказчик, а я просто держу это на плаву, единственным решением задачи защиты стало обернуть всё в меркуриал репозитарий, выполнения с некоторой периодичностью status и если там что-то появилось отправку diff на почту, для дальнейшего выяснения, кто-куда-зачем.... Даже, когда разработки утверждала, что оно обновлено, раз в неделю diff давал 100500 файлов загаженных сложно вычленяемыми на фоне остального говнокода сниппетами заразы...
Работа сабжа со стилями вызывает трепет. Если не знать того единственного правильного способа (который мне лично не известен), оно порождает миллион css файлов, и весь этот миллион тянется пользователем при запросе страницы. И эти файлы однотипны и отличаются только штампов времени в конце. Понять откуда это всё без вдумчивого изучения решительно нельзя...
Поменять что-то на странице, если это не предусмотрено разработчиком модуля, вёрстки и прочего, даже при наличии доступа к коду, практически не реально. Понять куда там запрягают коней без специальных курсов решительно нельзя. В админке найти нужно тебе опцию - квест повышенной сложности. Если оно падает, то никто кроме поднимавшего не сможет вернуть всё взад (ну или разворачивание резервной копии с потерей всего, что сделано после её создания). Если человек, кто разворачивал, делал это методом тыка - ничто не поможет кроме бекапа....
Если кто-то сможет объяснить почему оно ТАК популярно, нижайше прошу просветить, иначе у меня создаётся впечатление о клиническом садомазохизме всей отрасли российского сайтоделательства. Нет, как коммерческий продукт, для создателей этой CMS - это просто шедевр: эксплуатация будет платить за лицензию, потому что ей нужны будут обновы. Там есть место облачным сервисам, поскольку НУЖНО регулярное резервное копирование и не помешает CDN, особенно если это чудо развёрнуто на shared-хостинге с драконовскими лимитами по диску. Но блин, что это кроме откатов даёт эксплуатации не ясно. Даже знакомый разработчик сайтов мне не смог внятно ответить о плюсах "продукта", но живописал великим и могучим своё к нему отношение....
Учиться работать с БД в рамках языка программирования с того, чтобы учиться работать с БД в целом, ИМХО плохая затея. Ибо человек такое создание, что склонно терять лес за деревьями, а реляционная логика, понятие множеств и действий над ними, на которых она строится и общая логика работы СУБД даст достаточно деревьев, чтобы за ними напрочь, месяцев на 6 минимум, полностью потерять GO из виду =))))) Эту часть квеста лучше проходить заранее....
А в рамках топика, о ALL, а никто не порекомендует обновляемый, адекватный, online справочник по синтаксису и стандартной библиотеке Go на русском языке.
Попробуйте [bookstack](https://www.bookstackapp.com/). Этим приложением завершился мой поиск идеала. Что-то лучше найти уже не надеюсь
Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
Считать максимум рабочих процессов от памяти - способ отстрелить себе пол организма под нагрузкой. Конкурирующие за вычислительный ресурс рабочие процессы будут друг-друга сильно тормозить. Такой фокус можно использовать только при том, что большая часть этих процессов будет спасть в ожидании данных с БД, и то до того момента как от DBA не прилетит не иллюзорная звездюлина, поскольку ему тоже вряд ли досталась SUN Niagara и количество исполнительных каналов процессоров у него на сервер БД также ограничено, а памяти и прочего процессы СУБД жрут не в пример больше чем php-fpm даже при достаточно кривом php коде...
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
То что браузеры исполняют их в песочнице не помешало эксплуатировать спектру с JS. Поэтому я и говорю, что времена, когда мы все были в домике и глаз хватало, чтобы быть в безопасности давно прошли.
Я дико извиняюсь, но антивирусные компании очень даже немаленькие, а мантру о том что множество глаз БДИТЕЛЬНО следят мы проходили во времена heartbleed. Не помогло OpenSSL, за которым следили параноики, почему должно помочь браузерам.
А нода здесь как самый яркий пример того, как обычная человеческая лень программеров увеличивает поверхность атаки на порядок, а бардак в их модной инфраструктуре вполне может спровоцировать получение JS-зловреда с уважаемого сайта, и уберечься от этой дряни, хотя бы спустя некоторое время, сможет помочь только антивирусник.
И да, я читаю ежедневный отчёт от Kaspersky Cecurity Center по моей маленькой непримечательной сетке, и крайне счастлив, что вся эта дрянь из отчёта осталась за пределами сетки.
Все системы антивирусной защиты делятся на дырявое решето и имеющие функцию подмены сертификата. Как вы предлагаете проверять js-дрянь, идущую по SSL каналу. Кончилось то время когда на Web-е лежали файлики, и если не позволять им запускаться - то всё будет зашибись. Сейчас с помощью js Вас могут завязать в узел и сложить из Вас оригами почти не приходя в сознание с использованием только штатных API. А если к этому добавить не контролируемое вовсе мракобесие с node.js и просто разбросанными по интернету файлы с кусками фреймворков, в время от времени находят разное.
Вообще есть прекрасный способ сделать так, чтобы за пользователем не следили и он был в безопасности. Нужно по сайтикам лазить ка Столман. Где-то на хабре вроде была статья с его рецептом успеха. А в остальное время, приходится использовать проверку SSL-трафика, и внимательно следить за исключением трафика всяких банк-клиентов, которые это местами страсть как не любят.
Взрыв мозга, а не ОС. На фоне DOS-ов и первых форточек, так вообще звездолёт. Это мои первые впечатления....
Я правильно понимаю, что пересменка происходит на АТП, куда машина гонится с РЦ уже гружённая на следующий рейс? Если да, то не до конца понятно:
Почему пересменку нельзя сделать на РЦ, доставив туда новых водителей попутно другими машинами, либо просто установив точку рандеву на РЦ, перенаправив туда служебный вахты с водителями, которые должны начать рейс в ближайшее время.
Зачем гнать на АТП машину, когда большую часть проверок можно провести по окончании рейса, а на РЦ дежурный механик просто проведёт общий осмотр машины перед погрузкой и после неё на предмет базовых технических проблем. В конце концов машина должна уйти с АТП здоровой, и маловероятно, что по дороге у неё произойдёт что-то, что не сможет увидеть техник напару с водителем, закреплённым за машиной. Явно сейчас его там нет, но можно отправлять народ с АТП по графику на дежурство на РЦ на отдых за "особые заслуги". Тогда не нужно печатать документ до рейса, рейс начнёт уже сменщик и распечатает себе документы. Вся задумка с QR исключительно из-за того, что водители явно исполняют обязанности и экспедиторов и отвечают за груз, поэтому необходимо следить за погрузкой. Если снять с водителей такую ответственность через упаковку товара в контейнеры (на колёсиках) и оставить за водителями только ответственность доставить соответствующее количество контейнеров на соответствующие точки, а разборки по загруженной номенклатуре предоставить сборщикам и контролёрам на РЦ, принимающими специалистами на точках, обеспечив надёжные средства доказательства невмешательства водителя в груз, то водителям вообще должно быть без разницы: один доставил машину на РЦ и поставил на погрузку, тем самым завершив смену, второй просто принял гружёную машину вцелом, проверив что все места на месте, и пошёл распечатывать на неё документы, по которым после уже начинает свой рейс.
Просто мне кажется, что описанный в статье процесс слишком наворочен и разухабист. Очень похоже, что героически решили проблемы, возникшие из-за того, что "всегда так делали и вы задолбётесь пересогласовывать бизнес процессы целиком, но можно согласовать несколько костылей к ним, и обойтись малой кровью и не сдохнуть в совещаниях с топами сразу нескольких неповоротливых дивизионов, где каждый будет отстаивать незыблемость своих бизнес процессов, ибо если их колыхнуть, то сразу 100500 тысячмилионов долларов убытков ежеминутно" (с) Очень хочется верить что хоть у вас нету такой фигни....
Так и не понял, зачем такие сложности. Машина и водитель, вообще ИМХО разные сущности. Водитель вернул машину в РЦ (пересечение ворот), тем самым закрыл свой рейс, отметилось время. После этого машина обслуживается и попадает в планирование на рейсы в очереди. При необходимости, если в смене водителя осталось время, он её подаёт под загрузку. Загрузка происходит по планшетам, и склад формирует фактическую загрузку, и формируются документы в электронном виде. После загрузки уже тот водитель, который повезёт груз подходит к принтеру, которых может стоять батарея, сканирует QR из приложения на планшете/телефоне, ему отдаются накладные на все точки, которые уже по факту визируются и он едет. То есть машину рассматриваем отдельно, а водителя на неё планируем отдельно. А не вот этот человекомашинный комплекс с переходным состоянием "у первого водителя смены не хватит на следующий рейс, поэтому пусть он загрузит, а второй разгружать будет". Здесь есть вопросы с экспедицией, но если рассматривать сборку тележки (та хрень на колёсиках, которая в сетях и является местом груза) отдельно, то есть привязывать комплектовщика к этой тележке, накладывая на него ответственность за сборку и учёт собранного, и качественно опечатывать, на ценный груз используя прочные чехлы, на малоценку использовать продуманные механизмы опечатывания и фотоотчёты, может получится даже несколько гармоничней.
Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.
И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.
Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.