Сегодня рассмотрим сразу два кейса – данные клиентов и партнеров двух совершенно разных компаний оказались в свободном доступе «благодаря» открытым серверам 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¤cyAlias=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-канале «Утечки информации».
Vamp
Я считаю, что это всё же проблема elasticsearch, раз уж настройки по умолчанию позволяют подключиться к базе всему миру.
olku
Бесплатная версия elasticsearch не имеет никакой авторизации. Тот кто ее устанавливает, видит это, проверяя работоспособность на 9200 порту.
alexey-kirilenko
всё так, но по дефолту сервис открыт по 9200 порту только локально, что бы его открыть извне надо делать отдельные телодвижения.
Vamp
И правда. Снимаю свои обвинения с es.
D01
Скорей всего проблема в докере, если не указать маппинг порта на 127.0.0.1: порт: порт, а просто порт: порт, то порт открывается наружу, несмотря на блокировку фаерволом. (а в настройках ES и Mongo образов изначально разрешено подключаться с других хостов, т.к. межконтейнерное взаимодействие)
ashotog Автор
а можно поподробнее про это? реально хочется понять, почему такое происходит. Про докер слышал от одной «потерпевшей» компании, которой зарепортил находку. Они так и сказали «докер добавляет свои правила в iptables, которые перекрыли ручную настройку правил на уровне Elastic».
D01
Обычно во всех инструкциях по тому же docker-compose идет пример открытия порта для хоста (именно в такой формулировке)
ports:
— «3110:1000»
Т.е. мы можем обратиться с хоста на порт 3110 к сервису в контейнере.
Но вот почему-то не пишут, что так оно будет доступно не только на хосте, но и при всех обращениях к хосту извне и пофиг на правила ufw.
Для ограничения доступа только для хоста надо написать
ports:
— «127.0.0.1:3110:1000»
В какой-то степени это даже удобно. Но в руководствах это не описывают (ну или мне такие инструкции попадались))).
ashotog Автор
ага, спасибо. это многое теперь объясняет ;) становится понятно откуда такой шквал открытых эластиков
MinskV
Спасибо! Я опытным путем обнаружил что база (в докере) доступна снаружи по 3306, хотя ufw уверял меня в обратном. Понимая что вряд ли косяк ufw я терялся в догадках.
Naves
А можете показать весь вывод iptables -L
И что там ufw показывает
MinskV
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
Dushman
авторизация доступна в basic лицензии с версии 7.1.0 (Release date:
May 20, 2019) и 6.8
Naves
Я считаю, что это всё же проблема HTTP, раз уж настройки по умолчанию позволяют подключиться к нему всему миру.
Vamp
Вы сравнивание тёплое с мягким (протокол с его реализацией). Апач ведь в дефолтной инсталляции не позволяет шариться по всей файловой системе сервера, в отличии от эластика, который, между прочим, тоже можно считать реализацией http сервера.
Naves
>протокол с его реализацией
я просто не стал перечислять apache/nginx/lighthttpd/тысячи их
где это еластик «позволяет шариться по всей файловой системе сервера» даже если он открыт всему миру?
Revertis
ashotog Автор
да, неудачно выразился ;)
ukt
Я помню времена, когда уязвимые хосты искались в гугле специально составленным запросом(SQL — вариант).
В данном топике примерно тоже самое, только уже ищут по портам или ещё каким маякам и очень не исключен вариант, когда на этих ребят с расшаренным доступом к персональным данным достучались люди, не только с белыми шапками, но с черными.
Когда уже будет адекватная ответственность или способ влияния за такое безалаберное отношение(или, что хуже, специально запланированный слив) к персональным данным многих людей.
DarkHost
То есть им очень повезло, что никто DELETE не сделал.