"Красота"
Досталось кому-то в наследство
Досталось кому-то в наследство
Столкнуло тут с VipNet-ом.
И возник ряд вопросов.
Как получить доступ к WebUI в браузере из открытой сети ? Как прописать правила в консоле, чтоб пускало ?
Можно ли подсунуть ключевой файл от ПАК на рабочую станцию и наоборот ? Если нет, почему ?
В файле iplir.conf должен быть прописан мой адрес защищённой (VPN) сети ? Если должен и его нет, как его узнать и прописать ? И где его смотреть если его нет в этом файле ?
Можно ли использовать АРМ с установленным VipNet-ом как шлюз для других АРМ в защищённую сеть ?
Как заново произвести инициализацию ПАК без техподдержки ?
Можно подсунуть клиенту или ПАКу ключи от нескольких сетей, чтоб они работали одновременно в 2 сетях ?
Беглое гугление много чего даёт, но возникает ещё больше вопросов.
Утро 15 июля 2001 года для аналитиков компании eEye Digital Security Марка Мэифрета, Райана Перми и Райли Хассела выдалось непростым. Ребята как раз допивали очередную порцию газировки Code Red Mountain Dew, когда в лабораторию стали поступать предупреждения о массовом распространении нового компьютерного червя. Не мудрствуя лукаво, парни назвали вредонос в честь своего любимого напитка – “Code Red”. Так эта угроза получила свое имя, которое многим жертвам червя запомнилось надолго — буквально за несколько дней Code Red захватил Интернет.
Как выяснилось позже, распространение червя началось еще 13 июля 2001 года. Малварь использовала уязвимость веб-сервера Internet Informatiom Server, заключающуюся в классическом переполнении буфера. Несмотря на то, что за месяц до описываемых событий корпорация Microsoft выпустила заплатку для этой уязвимости, далеко не все администраторы вовремя установили обновление. Указанное обстоятельство и послужило основной причиной полномасштабной эпидемии.
Уязвимость скрывалась в библиотеке idq.dll, в которой был реализован функционал ISAPI — службы индексирования Windows 2000 Server. В частности, эта библиотека отвечала за обработку административных скриптов (с расширением .ida) и файлов запросов данных — Internet Data Queries (*.idq). В модуле, связанном с обработкой входящих URL-запросов, и обнаружилась ошибка переполнения буфера, вызвав которую, злоумышленник мог выполнить на сервере произвольный код.
Червь устанавливал соединение с HTTP-портом 80 на компьютере со случайно выбранным IP-адресом (в те времена очень немногие серверы использовали HTTPS) и отправлял туда GET- запрос следующего вида:
Если на целевой машине был запущен IIS, обрабатывающая запрос библиотека idq.dll воспринимала все, что идет после последней литеры “N”, как шелл-код, и благополучно запускала его. В те времена Windows не использовала механизм ASLR (Address Space Layout Randomisation), поэтому все загруженные в память библиотеки на всех машинах под управлением этой ОС использовали одно и то же адресное пространство. Ошибка в idq.dll направляла поток выполнения вредоносного кода в произвольное место памяти по выбору злоумышленника. Кроме того, Windows 2000 не поддерживала DEP (Data Execution Prevention), поэтому любой помещаемый в стек код мог выполняться вслепую, даже если стек предназначен для хранения данных, а не кода. Чем и воспользовались вирусописатели. Несмотря на то, что уязвимость присутствовала в компоненте службы индексирования, для ее использования совершенно не требовалось, чтобы сама служба была запущена на атакуемом хосте. Содержавшая ошибку библиотека автоматически загружалась в память при старте IIS, и соответствующее обращение к серверу в любом случае вызывало удаленное выполнение кода.
По большому счету, червю было плевать, запущен ли на атакуемом хосте IIS, и является ли он вообще веб-сервером. Запрос либо обрабатывался, либо нет. В логах многих серверов, работавших под управлением Apache, админы позже обнаруживали тот самый странный запрос с большим количеством символов “N”. Более того, само тело червя целиком содержалось в передаваемом запросе — малвари не нужно было заботиться о стабильности соединения, не требовалось скачивать или запускать какие-то исполняемые файлы, устанавливать связь с управляющим сервером или предпринимать какие-либо дополнительные действия. При выполнении кода из GET-запроса сервер заражался мгновенно и червь начинал действовать.
Запустившись на зараженном веб-сервере, Code Red в первую очередь дефейсил расположенный там сайт: на его главной странице появлялась надпись «HELLO! Welcome to www.worm.com! Hacked By Chinese!».
Следующие действия червя зависели от текущего числа. С 1 по 19 число каждого месяца вредонос занимался исключительно самораспространением: он опрашивал доступные в Интернете серверы, отправлял на них соответствующий запрос. Для этого на зараженном хосте создавалось 99 параллельных потоков, в каждом из них формировался список новых компьютеров-жертв, которым отправлялись HTTP-запросы.
С 20 по 27 число Code Red выполнял DDoS-атаки по списку намертво зашитых в нем IP-адресов, среди которых присутствовал адрес сайта Белого Дома. Именно поэтому исследователь Кеннет Д. Эйхман, первым обнаруживший способ борьбы с червем, в благодарность был приглашен на прием в спасенный им от атак вредоноса Белый Дом.
C 28 числа и до конца месяца малварь не делала вообще ничего — даже компьютерным червям нужны выходные.
Хотя массовое распространение червя было зафиксировано 15 июля 2001 года, своего пика оно достигло через 4 дня — 19 июля было заражено более 359 тыс. серверов. Позже, когда администраторы все-таки начали устанавливать на свои серверы рекомендованные Microsoft обновления безопасности, эпидемия понемногу пошла на убыль, хотя чуть позже появилась вторая версия Core Red, имевшая другую полезную нагрузку и использовавшая в GET-запросе символы “X” вместо “N”.
Из всей этой истории можно сделать два важных вывода. Первый — что своевременная установка патчей, которая была так важна 21 год назад, не потеряла своей актуальности и сейчас. Второй — то, что Code Red не шифровал файлы на дисках, не воровал пароли и не уничтожал данные, можно назвать чистым везением. Именно благодаря относительной «безобидности» червя эпидемия обошлась без серьезных последствий. А ведь они могли бы быть намного более печальными, если бы злоумышленники преследовали иные цели.
Оригинал
Подписывайтесь на наш блог, чтобы не пропустить новые интересные посты!
Пример, когда клиенты решили сами все подключить.
П. С. Работа клиентов на первом фото )
Имею PLC адаптер (на видео). Уже 2 дня на одном из них такая мигающая индикация. Может кто знает в чем может быть дело? ( резет нажимал, менял их местами - ничего не помогло)
За грязное видео простите - втруднодоступном местерозетка находится.
Всем привет, надеюсь кто нибудь сможет помочь разобраться, неделю бьюсь уже. Остаётся только в Спортлото писать.
Проблема в следующем, в этом году на объекте, заменил часть оборудования (видеорегистратор и камеры, все IP) и добавил точки доступа Unifi. После этого начались танцы-пляски, а именно на реге начался рандомный отвал камер (no link, кратковременный) или же мерцание окна камеры при просмотре субпотока ( как будто уведомление приходит, вспышка).
Рег, периодически пишет конфликт ip. Сканировал сеть, искал злодея. Не нашёл.
В итоге, при нахождении видеонаблюдения в одной подсети вместе с остальным сетевым оборудованием, идет или отвал камер или мерцание. Как только переносишь видеонаблюдение в другую подсеть, то все работает отлично. Тоже самое и наоборот, если WiFi оборудование в другую подсеть, то видео работает.
Список оборудования в сети:
Микротик hap ac2
Контролёр Cloud Key Gen2
Точки доступа Unifi 14шт.
Видеорегистратор Hiwatch 332/2b
IP камеры Hiwatch i200 - 32шт.
По ощущениям кто то еще раздает адреса в сети. Грешу на cloud key, больше некому козлить. В прошлом году примерно при том же конфиге, все работало отлично. А в этом, после добавления и замены оборудования такие дела происходят. Единственное, точно не помню, в пошлом году видеонаблюдение получало адреса по DHCP, а в этом, я присвоил видеонаблюдению статику.
Вариантов раскинуть на разные подсети нет. Кабель у всех общий. Vlan тоже не катит, оборудование не позволяет. Остается только найти причину и устранить.
Надеюсь на помощь. Спасибо
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Делается довольно просто. Рядом с заголовком поста или в шапку камента пишется IP машинки, откуда отправились данные. Так мы узнаем с какого белого IP бот или не бот. Далее к каждому IP можно прикрутить рейтинг. Будет забавно.
Скорее всего по закону о персональных данных так делать нельзя. Но есть geoIP и иностранных IP-адресов это, я полагаю, не касается. Поэтому можно публиковать IP не из России.
Также предлагаю админам запилить страничку с инфографиковой картой аналитики частоты обращений с IP разных стран. Чтобы было понятно, откуда больше всего комментируют.
Распарсить логи nginx несложно, господа. Интересно, какая глубина логирования у вас, админы?
Я верю, что все логи на ресурсе давно собираются каким-нибудь Elastic'ом, и все давно визуализировано. Просто прошу показать, откуда больше всего пользуются ресурсом.
Да, я знаю про VPN и Tor. ПОЭТОМУ также предлагаю собирать и показывать данные трэйса или количества хопов от пользователей. Тут понятно. Чем больше, тем дальше наш комментатор от сервера.
Конечно же, это супер небезопасно, да и не имеет смысла, ведь в скором времени умельцы напишут плагин, который будет в браузере подменять полученные через js данные на нужные, и даже снабдят их рандомайзером. Но видит Гаусс, у этих массовых комментаторов нет железных рандомайзеров, работающих на распаде частиц, и статистически можно будет определить какие задержки псевдослучайны.
И последнее предложение: собирать и показывать косвенные данные по времени загрузки страницы, чтобы понимать, через сколько слоёв Tor/VPN проходит конкретный комментарий.
Для чего?
Надоело, что в комментариях искусственные интеллекты обвиняют друг друга в проплаченных комментариях. И хочется понять, откуда действительно выходят в сеть владельцы определенных мнений.
Минусите.