Merion Academy

🐸 Аквариум. В лобби казино стоял большой аквариум, а следил за ним умный термометр: температура, кормление, чистка воды - всё удалённо, через интернет. Устройство подключили в общую сеть, потому что «это же термометр, что с ним может случиться». Пароль по умолчанию, прошивка без обновлений, никакой сегментации. Через него зашли внутрь, дошли до базы с данными клиентов и вытащили около десяти гигабайт - аккуратно, через тот же аквариум, чтобы трафик выглядел безобидно. Случай...

🐸 Казино в Северной Америке. Серьёзная охрана, камеры, деньги, всё под контролем. Сеть тоже под контролем: файрволы, сегментация, безопасники в штате. И вот система мониторинга показывает странное: из внутренней сети наружу уходит около десяти гигабайт данных. Получатель - какое-то устройство в Финляндии. Начинают искать источник. Не рабочая станция. Не сервер. Не чей-то ноутбук 🐸 Вопрос: откуда утекали данные?...

Что сломалось? 🐸 Если ответил «DNS» - правильно. Но на собесе за этим сразу летит второй вопрос: а как ты это проверишь и где именно посмотришь? И тут выясняется, что вариантов много: • dig или nslookup - отвечает ли сервер имён вообще и что именно отдаёт • /etc/resolv.conf - а тот ли сервер мы спрашиваем • /etc/hosts - самая обидная причина, кто-то прописал руками полгода назад • кэш - имя уже отдавали, адрес поменялся, а старый ответ ещё живёт • TTL записи - через сколько мир увидит новый адрес после правки Дальше идёт третий вопрос, на котором...

? Пинг показывает всего одно: доходит пакет или нет. Он не скажет, где именно теряется трафик, кто занял порт и почему DNS отдаёт не тот адрес😳 Собрали шпаргалку по сетевым командам Linux: • ip и ss вместо устаревших ifconfig и netstat, • traceroute и mtr - чтобы увидеть, на каком узле всё умирает, • dig и nslookup - когда виноват DNS, а не сеть, • tcpdump - когда надо посмотреть на пакеты своими глазами. 💡 В статье простым языком: что вводить, что читать в выводе и в каком порядке проверять, чтобы не гадать...