Сегодня рассмотрим сразу два кейса – данные клиентов и партнеров двух совершенно разных компаний оказались в свободном доступе «благодаря» открытым серверам Elasticsearch с логами информационных систем (ИС) этих компаний.



В первом случае — это десятки тысяч (а может и сотни тысяч) билетов на различные культурные мероприятия (театры, клубы, речные прогулки и т.п.) продаваемые через систему «Радарио» (www.radario.ru).


Во втором случае — это данные о туристических поездках тысяч (возможно нескольких десятков тысяч) путешественников, купивших туры через турагентства, подключенные к системе «Слетать.ру» (www.sletat.ru).


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


Дисклеймер: вся информация ниже публикуется исключительно в образовательных целях. Автор не получал доступа к персональным данным третьих лиц и компаний. Информация взята либо из открытых источников, либо была предоставлена автору анонимными доброжелателями.


Случай первый. «Радарио»


Вечером 06.05.2019 наша система обнаружила в свободном доступе сервер Elasticsearch, принадлежащий сервису по продаже электронных билетов «Радарио».


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



Общий объем логов превышал 1 Тб.


По данным поисковика Shodan сервер находился в открытом доступе с 11.03.2019. Я оповестил сотрудников «Радарио» 06.05.2019 в 22:50 (МСК) и 07.05.2019 около 09:30 сервер стал недоступен.


В логах находился универсальный (единый) токен авторизации, предоставляющий доступ ко всем купленным билетам по специальным ссылкам, вида:


http://radario.ru/internal/tickets/XXXXXXXX/print?access_token=******JuYWw6MDIzOWRjOTM1NzJiNDZjMTlhZGFjZmRhZTQ3ZDgyYTk

http://radario.ru/internal/orders/YYYYYYY/print?access_token=******JuYWw6MDIzOWRjOTM1NzJiNDZjMTlhZGFjZmRhZTQ3ZDgyYTk

Проблема также заключалась в том, что для учета билетов использовалась сквозная нумерация заказов и простым перебором номера билета (XXXXXXXX) или заказа (YYYYYYY), можно было получить все билеты из системы.


Для проверки актуальности базы я даже честно купил себе самый дешевый билет:




и позже обнаружил его на общедоступном сервере в логах ИС:


http://radario.ru/internal/tickets/11819272/print?access_token==******JuYWw6MDIzOWRjOTM1NzJiNDZjMTlhZGFjZmRhZTQ3ZDgyYTk

Отдельно хочется подчеркнуть, что были доступны билеты как на уже прошедшие мероприятия, так и на те, которые еще только планируются. То есть, потенциальный злоумышленник мог воспользоваться чужим билетом для прохода на планируемое мероприятие.


В среднем в каждом индексе Elasticsearch, содержащем логи за один определенный день (начиная с 24.01.2019 и по 07.05.2019), находилось от 25 до 35 тыс. билетов.


Помимо самих билетов в индексе содержались логины (адреса электронной почты) и текстовые пароли для доступа в личные кабинеты партнеров «Радарио», продающих билеты на свои мероприятия через данный сервис:


Content: \"ReturnUrl=&UserEmail=***@yandex.ru&UserPassword=***\"

Всего было обнаружено более 500 пар логин/пароль. В личных кабинетах партнеров видна статистика продаж билетов:



Также в открытом доступе находились ФИО, телефоны и адреса электронной почты покупателей, решивших осуществить возврат, купленных ранее билетов:


"Content": "{\"name\":\"***\",\"surname\":\"*** \",\"middleName\":\"Евгеньевна \",\"passportType\":1,\"passportNumber\":\"\",\"passportIssueDate\":\"11-11-2011 11:11:11\",\"passportIssuedBy\":\"\",\"email\":\"***@mail.ru\",\"phone\":\"+799*******\",\"ticketNumbers\":[\"****24848\",\"****948732\"],\"refundReason\":4,\"comment\":\"\"}"

За один, случайно выбранный день, было обнаружено более 500 таких записей.


Я получил ответ на оповещение от технического директора «Радарио»:


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

А чуть позже компания сделала официальное заявление:


В электронной системе продажи билетов Radario была обнаружена и своевременно устранена уязвимость, которая могла привести к утечке данных клиентов сервиса, сообщил Агентству городских новостей «Москва» директор по маркетингу компании Кирилл Малышев.

«Нами действительно была обнаружена уязвимость в работе системы, связанная с регулярным обновлением, которая была устранена сразу же после обнаружения. В результате уязвимости при определенных условиях недружелюбные действия третьих лиц могли привести к утечке данных, однако каких-либо инцидентов зафиксировано не было. В данный момент все неисправности устранены», — сообщил К.Малышев.

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

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


Случай второй. «Слетать.ру»


Рано утром 15.05.2019 DeviceLock Data Breach Intelligence выявил общедоступный сервер Elasticsearch с логами некой ИС.



Позже было установлено, что сервер принадлежит сервису по подбору туров «Слетать.ру».


Из индекса cbto__0 можно было получить тысячи (11,7 тыс. включая дубли) адресов электронной почты, а также некоторую платежную информацию (стоимость туров) и данные тур поездок (когда, куда, данные авиабилетов всех вписанных в тур путешественников и т.п.) в количестве около 1,8 тыс. записей:


"full_message": "Получен запрос за создание платежного средства: {\"SuccessReturnUrl\":\"https://sletat.ru/tour/7-1939548394-65996246/buy/?ClaimId=b5e3bf98-2855-400d-a93a-17c54a970155\",\"ErrorReturnUrl\":\"https://sletat.ru/\",\"PaymentAgentId\":15,\"DocumentNumber\":96629429,\"DocumentDisplayNumber\":\"4451-17993\",\"Amount\":36307.0,\"PaymentToolType\":3,\"ExpiryDateUtc\":\"2020-04-03T00:33:55.217358+03:00\",\"LifecycleType\":2,\"CustomerEmail\":\"XXX@mail.ru\",\"Description\":\"\",\"SettingsId\":\"8759d0dd-da54-45dd-9661-4e852b0a1d89\",\"AdditionalInfo\":\"{\\\"TourOfficeAdditionalInfo\\\":{\\\"IsAdditionalPayment\\\":false},\\\"BarrelAdditionalInfo\\\":{\\\"Tickets\\\":[{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX VIKTORIIA\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false},{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX ANDREI\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false},{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX Andrei\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false}],\\\"Segments\\\":[{\\\"Flight\\\":\\\"5659\\\",\\\"AviaCompany\\\":null,\\\"AviaCompanyIataCode\\\":null,\\\"DepartureCity\\\":\\\"LED\\\",\\\"DepartureAirport\\\":\\\"LED\\\",\\\"DepartureAirportIataCode\\\":\\\"LED\\\",\\\"DepartureDate\\\":\\\"2019-04-11T02:45:00\\\",\\\"DepartureTime\\\":null,\\\"ArrivalCity\\\":\\\"SHJ\\\",\\\"ArrivalAirport\\\":\\\"SHJ\\\",\\\"ArrivalAirportIataCode\\\":\\\"SHJ\\\",\\\"ArrivalDate\\\":\\\"2019-04-11T09:40:00\\\",\\\"ArrivalTime\\\":null,\\\"FareCode\\\":null},{\\\"Flight\\\":\\\"5660\\\",\\\"AviaCompany\\\":null,\\\"AviaCompanyIataCode\\\":null,\\\"DepartureCity\\\":\\\"SHJ\\\",\\\"DepartureAirport\\\":\\\"SHJ\\\",\\\"DepartureAirportIataCode\\\":\\\"SHJ\\\",\\\"DepartureDate\\\":\\\"2019-04-14T10:45:00\\\",\\\"DepartureTime\\\":null,\\\"ArrivalCity\\\":\\\"LED\\\",\\\"ArrivalAirport\\\":\\\"LED\\\",\\\"ArrivalAirportIataCode\\\":\\\"LED\\\",\\\"ArrivalDate\\\":\\\"2019-04-14T15:50:00\\\",\\\"ArrivalTime\\\":null,\\\"FareCode\\\":null}]},\\\"Tickets\\\":[{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX VIKTORIIA\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false},{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX ANDREI\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false},{\\\"Passenger\\\":{\\\"FIO\\\":\\\"XXX Andrei\\\"},\\\"ReservationSystem\\\":null,\\\"TicketNumber\\\":null,\\\"IsRefundPossible\\\":false}],\\\"Segments\\\":[{\\\"Flight\\\":\\\"5659\\\",\\\"AviaCompany\\\":null,\\\"AviaCompanyIataCode\\\":null,\\\"DepartureCity\\\":\\\"LED\\\",\\\"DepartureAirport\\\":\\\"LED\\\",\\\"DepartureAirportIataCode\\\":\\\"LED\\\",\\\"DepartureDate\\\":\\\"2019-04-11T02:45:00\\\",\\\"DepartureTime\\\":null,\\\"ArrivalCity\\\":\\\"SHJ\\\",\\\"ArrivalAirport\\\":\\\"SHJ\\\",\\\"ArrivalAirportIataCode\\\":\\\"SHJ\\\",\\\"ArrivalDate\\\":\\\"2019-04-11T09:40:00\\\",\\\"ArrivalTime\\\":null,\\\"FareCode\\\":null},{\\\"Flight\\\":\\\"5660\\\",\\\"AviaCompany\\\":null,\\\"AviaCompanyIataCode\\\":null,\\\"DepartureCity\\\":\\\"SHJ\\\",\\\"DepartureAirport\\\":\\\"SHJ\\\",\\\"DepartureAirportIataCode\\\":\\\"SHJ\\\",\\\"DepartureDate\\\":\\\"2019-04-14T10:45:00\\\",\\\"DepartureTime\\\":null,\\\"ArrivalCity\\\":\\\"LED\\\",\\\"ArrivalAirport\\\":\\\"LED\\\",\\\"ArrivalAirportIataCode\\\":\\\"LED\\\",\\\"ArrivalDate\\\":\\\"2019-04-14T15:50:00\\\",\\\"ArrivalTime\\\":null,\\\"FareCode\\\":null}]}\",\"FinancialSystemId\":9,\"Key\":\"18fe21d1-8c9c-43f3-b11d-6bf884ba6ee0\"}"

К слову сказать, линки на оплаченные туры вполне рабочие:



В индексах с именем graylog_ в открытом виде находились логины и пароли турагентств, подключенных к системе «Слетать.ру» и продающих туры своим клиентам:


"full_message": "Tours by request 155213901 added to local cache with key 'user_cache_155213901' at 5/6/2019 4:49:07 PM, rows found 0, sortedPriceLength 215. QueryString: countryId=90&cityFromId=1265&s_nightsMin=6&s_nightsMax=14&stars=403%2c404&minHotelRating=1&currencyAlias=RUB&pageSize=300&pageNumber=1&s_showcase=true&includeOilTaxesAndVisa=0&login=zakaz%40XXX.ru&password=XXX, Referer: , UserAgent: , IP: 94.154.XX.XX."

По моим прикидкам засветилось несколько сотен пар логин/пароль.


Из личного кабинета турагентства на портале agent.sletat.ru можно было получить данные клиентов, включая номера паспортов, загранпаспортов, даты рождения, ФИО, телефоны и адреса электронной почты.



Я оповестил сервис «Слетать.ру» 15.05.2019 в 10:46 (МСК) и через несколько часов (до 16:00) сервер Elasticsearch исчез из свободного доступа. Позднее в ответ на публикацию в Коммерсанте, руководство сервиса сделало весьма странное заявление через СМИ:


Руководитель компании Андрей Вершинин пояснил, что «Слетать.ру» предоставляет ряду крупнейших туроператоров-партнеров доступ к истории запросов в поисковой системе. И предположил, что DeviceLock получила его: «Однако в указанной базе нет паспортных данных туристов, логинов и паролей турагентств, платежных данных и т. д.». Андрей Вершинин отметил, что никаких доказательств столь серьезных обвинений «Слетать.ру» до сих пор не получила. «Сейчас пытаемся связаться с компанией DeviceLock. Полагаем, что это заказуха. Кому-то не нравится наш стремительный рост», – добавил он. "

Как показано выше и логины, и пароли, и паспортные данные туристов находились в свободном доступе достаточно продолжительное время (как минимум с 29.03.2019, когда сервер компании впервые был зафиксирован в открытом доступе поисковиком Shodan). Разумеется, с нами никто не связывался. Надеюсь, что, хотя бы турагентства они оповестили об утечке и заставили их сменить пароли.


Новости про утечки информации и инсайдеров всегда можно найти на моем Telegram-канале «Утечки информации».

Комментарии (19)


  1. Vamp
    21.05.2019 09:05

    Я считаю, что это всё же проблема elasticsearch, раз уж настройки по умолчанию позволяют подключиться к базе всему миру.


    1. olku
      21.05.2019 09:47

      Бесплатная версия elasticsearch не имеет никакой авторизации. Тот кто ее устанавливает, видит это, проверяя работоспособность на 9200 порту.


      1. alexey-kirilenko
        21.05.2019 10:11

        всё так, но по дефолту сервис открыт по 9200 порту только локально, что бы его открыть извне надо делать отдельные телодвижения.


        1. Vamp
          21.05.2019 11:30

          И правда. Снимаю свои обвинения с es.


          1. D01
            22.05.2019 08:11

            Скорей всего проблема в докере, если не указать маппинг порта на 127.0.0.1: порт: порт, а просто порт: порт, то порт открывается наружу, несмотря на блокировку фаерволом. (а в настройках ES и Mongo образов изначально разрешено подключаться с других хостов, т.к. межконтейнерное взаимодействие)


            1. ashotog Автор
              22.05.2019 09:24

              а можно поподробнее про это? реально хочется понять, почему такое происходит. Про докер слышал от одной «потерпевшей» компании, которой зарепортил находку. Они так и сказали «докер добавляет свои правила в iptables, которые перекрыли ручную настройку правил на уровне Elastic».


              1. D01
                22.05.2019 09:33
                +1

                Обычно во всех инструкциях по тому же docker-compose идет пример открытия порта для хоста (именно в такой формулировке)
                ports:
                — «3110:1000»
                Т.е. мы можем обратиться с хоста на порт 3110 к сервису в контейнере.
                Но вот почему-то не пишут, что так оно будет доступно не только на хосте, но и при всех обращениях к хосту извне и пофиг на правила ufw.
                Для ограничения доступа только для хоста надо написать
                ports:
                — «127.0.0.1:3110:1000»

                В какой-то степени это даже удобно. Но в руководствах это не описывают (ну или мне такие инструкции попадались))).


                1. ashotog Автор
                  22.05.2019 10:03

                  ага, спасибо. это многое теперь объясняет ;) становится понятно откуда такой шквал открытых эластиков


                1. MinskV
                  23.05.2019 08:51

                  Спасибо! Я опытным путем обнаружил что база (в докере) доступна снаружи по 3306, хотя ufw уверял меня в обратном. Понимая что вряд ли косяк ufw я терялся в догадках.


                  1. Naves
                    23.05.2019 09:31

                    А можете показать весь вывод iptables -L
                    И что там ufw показывает


                    1. MinskV
                      24.05.2019 12:31

                      iptables -L
                      Chain INPUT (policy DROP)
                      target prot opt source destination
                      ufw-before-logging-input all — anywhere anywhere
                      ufw-before-input all — anywhere anywhere
                      ufw-after-input all — anywhere anywhere
                      ufw-after-logging-input all — anywhere anywhere
                      ufw-reject-input all — anywhere anywhere
                      ufw-track-input all — anywhere anywhere

                      Chain FORWARD (policy DROP)
                      target prot opt source destination
                      DOCKER-USER all — anywhere anywhere
                      DOCKER-ISOLATION-STAGE-1 all — anywhere anywhere
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      DOCKER all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      DOCKER all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      DOCKER all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere
                      ufw-before-logging-forward all — anywhere anywhere
                      ufw-before-forward all — anywhere anywhere
                      ufw-after-forward all — anywhere anywhere
                      ufw-after-logging-forward all — anywhere anywhere
                      ufw-reject-forward all — anywhere anywhere
                      ufw-track-forward all — anywhere anywhere

                      Chain OUTPUT (policy ACCEPT)
                      target prot opt source destination
                      ufw-before-logging-output all — anywhere anywhere
                      ufw-before-output all — anywhere anywhere
                      ufw-after-output all — anywhere anywhere
                      ufw-after-logging-output all — anywhere anywhere
                      ufw-reject-output all — anywhere anywhere
                      ufw-track-output all — anywhere anywhere

                      Chain DOCKER (3 references)
                      target prot opt source destination
                      ACCEPT tcp — anywhere 172.21.0.2 tcp dpt:mysql
                      ACCEPT tcp — anywhere 172.21.0.3 tcp dpt:http-alt
                      ACCEPT tcp — anywhere 172.17.0.3 tcp dpt:http

                      Chain DOCKER-ISOLATION-STAGE-1 (1 references)
                      target prot opt source destination
                      DOCKER-ISOLATION-STAGE-2 all — anywhere anywhere
                      DOCKER-ISOLATION-STAGE-2 all — anywhere anywhere
                      RETURN all — anywhere anywhere

                      Chain DOCKER-ISOLATION-STAGE-2 (2 references)
                      target prot opt source destination
                      DROP all — anywhere anywhere
                      DROP all — anywhere anywhere
                      RETURN all — anywhere anywhere

                      Chain DOCKER-USER (1 references)
                      target prot opt source destination
                      RETURN all — anywhere anywhere

                      Chain ufw-after-forward (1 references)
                      target prot opt source destination

                      Chain ufw-after-input (1 references)
                      target prot opt source destination
                      ufw-skip-to-policy-input udp — anywhere anywhere udp dpt:netbios-ns
                      ufw-skip-to-policy-input udp — anywhere anywhere udp dpt:netbios-dgm
                      ufw-skip-to-policy-input tcp — anywhere anywhere tcp dpt:netbios-ssn
                      ufw-skip-to-policy-input tcp — anywhere anywhere tcp dpt:microsoft-ds
                      ufw-skip-to-policy-input udp — anywhere anywhere udp dpt:bootps
                      ufw-skip-to-policy-input udp — anywhere anywhere udp dpt:bootpc
                      ufw-skip-to-policy-input all — anywhere anywhere ADDRTYPE match dst-type BROADCAST

                      Chain ufw-after-logging-forward (1 references)
                      target prot opt source destination

                      Chain ufw-after-logging-input (1 references)
                      target prot opt source destination
                      LOG all — anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

                      Chain ufw-after-logging-output (1 references)
                      target prot opt source destination

                      Chain ufw-after-output (1 references)
                      target prot opt source destination

                      Chain ufw-before-forward (1 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      ACCEPT icmp — anywhere anywhere icmp destination-unreachable
                      ACCEPT icmp — anywhere anywhere icmp source-quench
                      ACCEPT icmp — anywhere anywhere icmp time-exceeded
                      ACCEPT icmp — anywhere anywhere icmp parameter-problem
                      ACCEPT icmp — anywhere anywhere icmp echo-request
                      ufw-user-forward all — anywhere anywhere

                      Chain ufw-before-input (1 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      ufw-logging-deny all — anywhere anywhere ctstate INVALID
                      DROP all — anywhere anywhere ctstate INVALID
                      ACCEPT icmp — anywhere anywhere icmp destination-unreachable
                      ACCEPT icmp — anywhere anywhere icmp source-quench
                      ACCEPT icmp — anywhere anywhere icmp time-exceeded
                      ACCEPT icmp — anywhere anywhere icmp parameter-problem
                      ACCEPT icmp — anywhere anywhere icmp echo-request
                      ACCEPT udp — anywhere anywhere udp spt:bootps dpt:bootpc
                      ufw-not-local all — anywhere anywhere
                      ACCEPT udp — anywhere 224.0.0.251 udp dpt:mdns
                      ACCEPT udp — anywhere 239.255.255.250 udp dpt:1900
                      ufw-user-input all — anywhere anywhere

                      Chain ufw-before-logging-forward (1 references)
                      target prot opt source destination

                      Chain ufw-before-logging-input (1 references)
                      target prot opt source destination

                      Chain ufw-before-logging-output (1 references)
                      target prot opt source destination

                      Chain ufw-before-output (1 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere
                      ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
                      ufw-user-output all — anywhere anywhere

                      Chain ufw-logging-allow (0 references)
                      target prot opt source destination
                      LOG all — anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "

                      Chain ufw-logging-deny (2 references)
                      target prot opt source destination
                      RETURN all — anywhere anywhere ctstate INVALID limit: avg 3/min burst 10
                      LOG all — anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

                      Chain ufw-not-local (1 references)
                      target prot opt source destination
                      RETURN all — anywhere anywhere ADDRTYPE match dst-type LOCAL
                      RETURN all — anywhere anywhere ADDRTYPE match dst-type MULTICAST
                      RETURN all — anywhere anywhere ADDRTYPE match dst-type BROADCAST
                      ufw-logging-deny all — anywhere anywhere limit: avg 3/min burst 10
                      DROP all — anywhere anywhere

                      Chain ufw-reject-forward (1 references)
                      target prot opt source destination

                      Chain ufw-reject-input (1 references)
                      target prot opt source destination

                      Chain ufw-reject-output (1 references)
                      target prot opt source destination

                      Chain ufw-skip-to-policy-forward (0 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere

                      Chain ufw-skip-to-policy-input (7 references)
                      target prot opt source destination
                      DROP all — anywhere anywhere

                      Chain ufw-skip-to-policy-output (0 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere

                      Chain ufw-track-forward (1 references)
                      target prot opt source destination
                      ACCEPT tcp — anywhere anywhere ctstate NEW
                      ACCEPT udp — anywhere anywhere ctstate NEW

                      Chain ufw-track-input (1 references)
                      target prot opt source destination

                      Chain ufw-track-output (1 references)
                      target prot opt source destination
                      ACCEPT tcp — anywhere anywhere ctstate NEW
                      ACCEPT udp — anywhere anywhere ctstate NEW

                      Chain ufw-user-forward (1 references)
                      target prot opt source destination

                      Chain ufw-user-input (1 references)
                      target prot opt source destination
                      tcp — anywhere anywhere tcp dpt:ssh ctstate NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
                      ufw-user-limit tcp — anywhere anywhere tcp dpt:ssh ctstate NEW recent: UPDATE seconds: 30 hit_count: 6 name: DEFAULT side: source mask: 255.255.255.255
                      ufw-user-limit-accept tcp — anywhere anywhere tcp dpt:ssh
                      ACCEPT tcp — anywhere anywhere tcp dpt:2375
                      ACCEPT tcp — anywhere anywhere tcp dpt:2376

                      Chain ufw-user-limit (1 references)
                      target prot opt source destination
                      LOG all — anywhere anywhere limit: avg 3/min burst 5 LOG level warning prefix "[UFW LIMIT BLOCK] "
                      REJECT all — anywhere anywhere reject-with icmp-port-unreachable

                      Chain ufw-user-limit-accept (1 references)
                      target prot opt source destination
                      ACCEPT all — anywhere anywhere

                      Chain ufw-user-logging-forward (0 references)
                      target prot opt source destination

                      Chain ufw-user-logging-input (0 references)
                      target prot opt source destination

                      Chain ufw-user-logging-output (0 references)
                      target prot opt source destination

                      Chain ufw-user-output (1 references)
                      target prot opt source destination


      1. Dushman
        22.05.2019 09:21

        авторизация доступна в basic лицензии с версии 7.1.0 (Release date:
        May 20, 2019) и 6.8


    1. Naves
      21.05.2019 10:10

      Я считаю, что это всё же проблема HTTP, раз уж настройки по умолчанию позволяют подключиться к нему всему миру.


      1. Vamp
        21.05.2019 11:24

        Вы сравнивание тёплое с мягким (протокол с его реализацией). Апач ведь в дефолтной инсталляции не позволяет шариться по всей файловой системе сервера, в отличии от эластика, который, между прочим, тоже можно считать реализацией http сервера.


        1. Naves
          21.05.2019 12:44

          >протокол с его реализацией
          я просто не стал перечислять apache/nginx/lighthttpd/тысячи их
          где это еластик «позволяет шариться по всей файловой системе сервера» даже если он открыт всему миру?


  1. Revertis
    21.05.2019 10:03

    Я оповестил сервис «Слетать.ру» 15.05.2019 в 10:46 (МСК) и через несколько часов (до 16:00) он исчез их свободного доступа.
    Слетать.ру исчез? :)))


    1. ashotog Автор
      21.05.2019 19:02

      да, неудачно выразился ;)


  1. ukt
    21.05.2019 16:08

    Я помню времена, когда уязвимые хосты искались в гугле специально составленным запросом(SQL — вариант).

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

    Когда уже будет адекватная ответственность или способ влияния за такое безалаберное отношение(или, что хуже, специально запланированный слив) к персональным данным многих людей.


  1. DarkHost
    21.05.2019 19:02

    То есть им очень повезло, что никто DELETE не сделал.