Linuxoid.pro

Сообщество разработчиков программного обеспечения и IT-специалистов

Как найти геолокацию хакеров SSH в режиме реального времени

Наступил подъем машин. Пока вы читаете эту статью, совершаются тысячи, если не сотни тысяч кибератак. Некоторые из них более сложны, чем другие: от  трояновпопыток фишинга, заражения вредоносными программами  до атак ботнетов (также известных как  DDoS ), кибератаки происходят буквально повсюду.

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

I — Что такое SSH?

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

SSH  (что означает  Secure Shell ) — это  безопасный протокол связи . Это позволяет компьютеру общаться друг с другом, используя безопасный туннель, который никто не может понять. SSH является развитием протокола Telnet, который также обеспечивает уровень связи, но небезопасен.

SSH очень широко используется для доступа к удаленным удаленным машинам и выполнения на них некоторых административных задач.

Примечание: если бы мы подключились к нашим машинам с помощью Telnet, весь мир мог бы увидеть наш пароль, и это было бы так же просто, как открыть Wireshark и захватить пакеты Telnet. Попрощайтесь со своими виртуальными машинами.

Как это устроено?

Что ж … как и HTTPS, SSH построен на общих криптографических методах:  симметричное шифрование или асимметричное шифрование  по большей части. Эти два метода в некотором роде проверяют идентичность двух хостов. Если я являюсь клиентом, я обращаюсь к серверу, к которому я пытался обратиться в первую очередь, или это умный ребенок, который хочет получить мои учетные данные в Facebook?

На втором этапе вас попросят предоставить учетные данные SSH для аутентификации. Если эти два шага (криптографические проверки + аутентификация) действительны,  вы вошли в систему.

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

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

Сегодня мы положим этому конец.

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

II — Захват журналов атак SSH

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

В этой статье я использую   машину Ubuntu 18.04, использующую  rsyslog  для отслеживания журналов. Для тех, кто не очень знаком с системами Linux, rsyslog — это инструмент, используемый в дистрибутивах Linux для записи, стандартизации, преобразования и хранения журналов в агрегированном инструменте (например, Logstash!).

Записи SSH относятся к разделу auth в rsyslog, который агрегирован в var / log / auth.log.

Так как же это выглядит? Вот скриншот из моих собственных журналов Ubuntu, показывающий попытки перебора SSH. Выполнение простого менее /var/log/auth.log | grep ssh покажет вам атаки методом перебора, которые также могут произойти на вашем компьютере.


Попытки SSH грубой силы на моей машине

См. Неверный пароль для недопустимых пользовательских ubntlines? Это кто-то пытается получить доступ к моей машине с недопустимыми учетными данными. И делают это много, минимум десятки попыток в день. Рядом с ним указан их IP-адрес, а также порт, выделенный SSH для попытки подключения.

Теперь, когда у нас есть способ фиксировать попытки SSH,  давайте создадим систему, которая может отслеживать их в реальном времени и отображать их на карте мира в реальном времени .

III — Архитектура и дизайн

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

Давайте объясним каждую часть нашего приложения.

Во-первых, нам нужно  отслеживать  журналы rsyslog и  фильтровать  журналы, относящиеся к SSH. Прямо перед тем, как TCP пересылает наше сообщение, нам нужно нормализовать наше сообщение до общего формата (шаблон нормализатора… кто угодно?), Для этого я выбрал JSON.

Затем наше сообщение обрабатывается  TCP-сервером, который  прослушивает входящие журналы. Для удобства я решил использовать  для этого  Node , но вы можете использовать любую технологию, которую сочтете подходящей для этого. Сообщение анализируется, и IP-адрес отправляется в службу геолокации IP (  в данном случае IPStack ), которая, помимо прочего, предоставит нам широту и долготу.

Затем эта запись обрабатывается в  InfluxDB и отображается в  Grafana  для мониторинга в реальном времени. Все очень просто, не правда ли?

a — Фильтрация сообщений rsyslog

Прежде чем что-либо делать, нам нужно иметь возможность фильтровать входящие журналы Ubuntu и выбирать тот, который нас интересует: журналы SSH и, точнее, журналы службы ssd. Для удобства я выбрал сообщения, начинающиеся с Failed, поскольку именно они содержат большую часть информации о происхождении атаки.

Интересующая нас линия

Для этого нужно зайти в /etc/rsyslog.d/50-default.conf, который содержит стандартный файл конфигурации для rsyslog. Если вы не знакомы с этим файлом, здесь вы настраиваете место хранения журналов в вашей системе Linux.

Вверху мы собираемся добавить красивый RainerScript, который фильтрует сообщения sshd. (Примечание: не забудьте команду остановки, иначе они также будут сохранены в ваших местах авторизации по умолчанию)

# Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files. Log by facility.
#
if $programname == 'sshd' then {
if $msg startswith ' Failed' then {
// Transform and forward data!
}
stop
}

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log

 

б — Нормализация наших данных

Теперь, когда наши сообщения sshd фильтруются и передаются в канал, нам нужен способ их нормализации. Мы будем использовать для этого шаблоны. Шаблоны — это встроенные инструменты для rsyslog, которые используются для преобразования входящего сообщения в определенный пользователем шаблон.

Для нашего проекта мы отфильтруем соответствующую информацию в сообщении журнала и построим из нее JSON.


Соответствующая информация, которую нам нужно извлечь

В папке /etc/rsyslog.d/ создадим файл с именем 01-basic-ip.conf, в котором будет размещен наш шаблон. Чтобы извлечь соответствующую информацию из журнала, я буду использовать регулярное выражение в файле строкового шаблона.

Регулярное выражение должно соответствовать сообщениям, начинающимся с Failed, и иметь три группы захвата: одну для имени пользователя, одну для IP и одну для порта. На языке регулярных выражений это выглядит так:

^ Failed.*user([a-zA-Z]*).*([0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*).* port ([0-9]*)

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

template(name="ip-json" type="string" string="{\"username\":\"%msg:R,ERE,1,DFLT:^ Failed.*user ([a-zA-Z]*).* ([0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*).* port ([0-9]*)--end%\",\"ip\":\"%msg:R,ERE,2,DFLT:^ Failed.*user ([a-zA-Z]*).* ([0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*).* port ([0-9]*)--end%\",\"port\":\"%msg:R,ERE,3,DFLT:^ Failed.*user ([a-zA-Z]*).* ([0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*.[0-9][0-9]*[0-9]*).* port ([0-9]*)--end%\"}")

c — Пересылка нашего сообщения

rsyslog предлагает широкую панель модулей вывода для пересылки ваших журналов. Один из них — это просто перенаправление TCP, называемое  omfwd . Это директива, которую мы собираемся использовать для пересылки нашего отформатированного сообщения. Вернемся к нашему файлу 50-default-conf.

if $programname == 'sshd' then { 
if $msg startswith ' Failed' then { 
action(type="omfwd" target="127.0.0.1" port="7070" protocol="tcp" template="ip-json") 
} 
stop 
}

В этом случае наш JSON будет перенаправлен на TCP-хост, который прослушивает порт localhost 7070 (адрес нашего Node-сервера!).

Отлично, у нас есть конвейер rsyslog.

d — Создание TCP-сервера

Теперь перейдем к нашему TCP-серверу. Сервер TCP является получателем наших сообщений JSON. Для удобства использования JSON я выбрал  Node  в качестве среды выполнения. Так в чем же роль нашего TCP-сервера? Прослушивание  входящих сообщений,  запрос  внешней службы для получения геолокации нашего нового друга, и  хранить  весь пакет InfluxDB. Я не буду больше держать в напряжении, вот код для нашего сервера.

var geohash = require("ngeohash");
const config = require("./config");
const axios = require("axios");
const Influx = require("influx");

// TCP handles
const net = require('net');
const port = 7070;
const host = '127.0.0.1';

const server = net.createServer();
server.listen(port, host, () => {
console.log('TCP Server is running on port ' + port + '.');
});

// InfluxDB Initialization.
const influx = new Influx.InfluxDB({
host: config.influxHost,
database: config.influxDatabase
});

let sockets = [];


server.on('connection', function(sock) {
console.log('CONNECTED: ' + sock.remoteAddress + ':' + sock.remotePort);
sockets.push(sock);

sock.on('data', function(data) {
//console.log(data);
let message = JSON.parse("" + data)
// API Initialization.
const instance = axios.create({
baseURL: "http://api.ipstack.com"
});
instance
.get(`/${message.ip}?access_key=${config.apikey}`)
.then(function(response) {
const apiResponse = response.data;
influx.writePoints(
[{
measurement: "geossh",
fields: {
value: 1
},
tags: {
geohash: geohash.encode(apiResponse.latitude, apiResponse.longitude),
username: message.username,
port: message.port,
ip: message.ip
}
}]
);
console.log("Intruder added")
})
.catch(function(error) {
console.log(error);
});
});

// Add a 'close' event handler to this instance of socket
sock.on('close', function(data) {
let index = sockets.findIndex(function(o) {
return o.remoteAddress === sock.remoteAddress && o.remotePort === sock.remotePort;
})
if (index !== -1) sockets.splice(index, 1);
console.log('CLOSED: ' + sock.remoteAddress + ' ' + sock.remotePort);
});
});

Одно примечание к этому коду: широта и долгота кодируются в так называемые  геохеши,  которые являются способом кодирования пары широты и долготы и используются плагином Grafana для рисования точки. В качестве последнего штриха давайте инкапсулируем этот код в сервис systemd и запустим его.

Мы закончили кодирование!

IV — Всемогущая визуализация

Если вы до сих пор читали, вот и хорошие новости:  самое интересное уже впереди . Теперь, когда мы храним наши живые данные в InfluxDB, давайте привяжем к ним Grafana и визуализируем его.

Напомним, что наше   измерение InfluxDB выглядит так:


Структура измерения InfluxDB

Чтобы отслеживать наши геохеши на карте в реальном времени, мы собираемся использовать плагин  WorldMap Panel  от Grafana Labs.

Каждое отдельное значение в нашем измерении будет кружком на карте. Конечно, круги становятся больше, если на нашей машине больше вхождений определенных IP-адресов. Не дожидаясь большего,  вот карта!


💖 Из Китая с любовью. 💖


Конфигурация Grafana для карты реального времени

Вот оно!

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

V — Fun Facts

За  6 дней мою машину атаковали  1660 раз . В среднем это около 270 атак в день. Вот все, что было предпринято в качестве входа в систему.

Особое упоминание о   попытке «мокрого сервера» . Я знаю, что это Digital  Ocean 🐠 , но все же … « Супермен» , хорошая попытка, но я не настолько страдаю манией величия, когда дело доходит до выбора моих учетных данных ..

Из этих 1660 атак около 750 были выполнены с одного IP-адреса, расположенного в Буффало, в районе Нью-Йорка. Второй по количеству спамеров SSH — из  Стокгольма, Швеция .

Что касается остальных атак, в основном они исходят из  Японии, Китая, Гонконга, Южной Кореи и даже Бразилии, Великобритании и даже Египта.

VI — Краткое заключение

Я получил массу удовольствия от разработки и реализации этого побочного проекта. Если серьезно, то это показывает, что никто не застрахован от этих атак, и я надеюсь, что он может немного повысить осведомленность об атаках методом перебора SSH. Когда время станет не таким уж скудным ресурсом, я напишу статью о том, как защитить вашу машину и полностью предотвратить эти атаки.

Будьте очень осторожны, когда дело касается SSH,  его обслуживание и администрирование являются ключевыми факторами в любой системе .

А пока развлекайтесь с этим небольшим экспериментом. И, как всегда, если вам нравятся мои работы, аплодируйте, комментируйте и делитесь этой статьей. Это всегда помогает.

Спасибо за уделенное время.