2. Еластичен стек: анализ на регистрационни файлове за сигурност. Logstash

В последния Статия срещнахме ELK стек, от какви софтуерни продукти се състои. И първата задача, пред която е изправен инженерът, когато работи със стека ELK, е изпращането на регистрационни файлове за съхранение в elasticsearch за последващ анализ. Това обаче са само на думи, elasticsearch съхранява регистрационни файлове под формата на документи с определени полета и стойности, което означава, че инженерът трябва да използва различни инструменти, за да анализира съобщението, което се изпраща от крайните системи. Това може да стане по няколко начина - напишете сами програма, която ще добавя документи към базата данни с помощта на API, или използвайте готови решения. В този курс ще разгледаме решението Logstash, който е част от стека ELK. Ще разгледаме как можем да изпращаме регистрационни файлове от крайни системи към Logstash и след това ще настроим конфигурационен файл за анализиране и пренасочване към базата данни Elasticsearch. За да направим това, вземаме регистрационни файлове от защитната стена на Check Point като входяща система.

Курсът не обхваща инсталирането на стека ELK, тъй като има огромен брой статии по тази тема; ще разгледаме конфигурационния компонент.

Нека съставим план за действие за конфигурацията на Logstash:

1. Проверка дали elasticsearch ще приеме регистрационни файлове (проверка на функционалността и отвореността на порта).
2. Обмисляме как можем да изпратим събития на Logstash, да изберем метод и да го приложим.
3. Ние конфигурираме Input в конфигурационния файл на Logstash.
4. Ние конфигурираме Output в конфигурационния файл на Logstash в режим на отстраняване на грешки, за да разберем как изглежда съобщението в журнала.
5. Настройка на филтъра.
6. Настройване на правилния изход в ElasticSearch.
7. Logstash стартира.
8. Проверка на дневниците в Кибана.

Нека разгледаме всяка точка по-подробно:

Проверка дали elasticsearch ще приема регистрационни файлове

За да направите това, можете да използвате командата curl, за да проверите достъпа до Elasticsearch от системата, на която е внедрен Logstash. Ако имате конфигурирано удостоверяване, тогава ние също прехвърляме потребителя/паролата чрез curl, като посочим порт 9200, ако не сте го променили. Ако получите отговор, подобен на този по-долу, значи всичко е наред.

[elastic@elasticsearch ~]$ curl -u <<user_name>> : <<password>> -sS -XGET "<<ip_address_elasticsearch>>:9200"
{
  "name" : "elastic-1",
  "cluster_name" : "project",
  "cluster_uuid" : "sQzjTTuCR8q4ZO6DrEis0A",
  "version" : {
    "number" : "7.4.1",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "fc0eeb6e2c25915d63d871d344e3d0b45ea0ea1e",
    "build_date" : "2019-10-22T17:16:35.176724Z",
    "build_snapshot" : false,
    "lucene_version" : "8.2.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
[elastic@elasticsearch ~]$

Ако отговорът не бъде получен, тогава може да има няколко вида грешки: процесът на elasticsearch не се изпълнява, посочен е грешен порт или портът е блокиран от защитна стена на сървъра, където е инсталиран elasticsearch.

Нека да разгледаме как можете да изпращате регистрационни файлове към Logstash от защитна стена на контролна точка

От сървъра за управление на Check Point можете да изпращате регистрационни файлове към Logstash чрез syslog с помощта на помощната програма log_exporter, можете да прочетете повече за нея тук Статия, тук ще оставим само командата, която създава потока:

cp_log_export добавете име check_point_syslog целеви сървър < > целеви порт 5555 протокол tcp формат общ режим на четене полуунифициран

< > - адрес на сървъра, на който работи Logstash, target-port 5555 - порт, към който ще изпращаме логове, изпращането на логове през tcp може да натовари сървъра, така че в някои случаи е по-правилно да използвате udp.

Настройка на INPUT в конфигурационния файл на Logstash

По подразбиране конфигурационният файл се намира в директорията /etc/logstash/conf.d/. Конфигурационният файл се състои от 3 значими части: INPUT, FILTER, OUTPUT. IN ВХОД ние посочваме откъде системата ще взема регистрационни файлове, в FILTER анализирайте дневника - настройте как да разделите съобщението на полета и стойности, в OUTPUT ние конфигурираме изходящия поток - където ще бъдат изпратени анализираните регистрационни файлове.

Първо, нека конфигурираме INPUT, разгледайте някои от типовете, които могат да бъдат - файл, tcp и exe.

TCP:

input {
tcp {
    port => 5555
    host => “10.10.1.205”
    type => "checkpoint"
    mode => "server"
}
}

режим => "сървър"
Показва, че Logstash приема връзки.

порт => 5555
хост => “10.10.1.205”
Приемаме връзки чрез IP адрес 10.10.1.205 (Logstash), порт 5555 - портът трябва да е разрешен от политиката на защитната стена.

тип => "контролна точка"
Маркираме документа, много удобно, ако имате няколко входящи връзки. Впоследствие за всяка връзка можете да напишете свой собствен филтър, като използвате логическата конструкция if.

File:

input {
  file {
    path => "/var/log/openvas_report/*"
    type => "openvas"
    start_position => "beginning"
    }
}

Описание на настройките:
път => "/var/log/openvas_report/*"
Посочваме директорията, в която трябва да се четат файловете.

тип => "openvas"
Тип събитие.

start_position => "начало"
При промяна на файл, той чете целия файл, ако зададете „край“, системата изчаква да се появят нови записи в края на файла.

Изпълнител:

input {
  exec {
    command => "ls -alh"
    interval => 30
  }
}

Използвайки този вход, се стартира (само!) команда на обвивката и нейният изход се превръща в съобщение в журнал.

команда => "ls -alh"
Командата, чийто изход ни интересува.

интервал => 30
Интервал на извикване на команда в секунди.

За да получаваме логове от защитната стена, регистрираме филтър tcp или UDP, в зависимост от това как регистрационните файлове се изпращат до Logstash.

Ние конфигурираме изхода в конфигурационния файл на Logstash в режим на отстраняване на грешки, за да разберем как изглежда съобщението в журнала

След като сме конфигурирали INPUT, трябва да разберем как ще изглежда съобщението в журнала и какви методи трябва да се използват за конфигуриране на филтъра за журнал (парсер).

За да направим това, ще използваме филтър, който извежда резултата на stdout, за да видим оригиналното съобщение; пълният конфигурационен файл в момента ще изглежда така:

input 
{
         tcp 
         {
                port => 5555
  	  	type => "checkpoint"
    		mode => "server"
                host => “10.10.1.205”
   	 }
}

output 
{
	if [type] == "checkpoint" 
       {
		stdout { codec=> json }
	}
}

Изпълнете командата, за да проверите:
sudo /usr/share/logstash/bin//logstash -f /etc/logstash/conf.d/checkpoint.conf
Виждаме резултата, снимката може да се кликне:

Ако го копирате, ще изглежда така:

action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,0x5,0xfe0a0a0a,0xc0000000}" origin="10.10.10.254" originsicname="CN=ts-spb-cpgw-01,O=cp-spb-mgmt-01.tssolution.local.kncafb" sequencenum="8" time="1576766483" version="5" context_num="1" dst="10.10.10.10" dst_machine_name="[email protected]" layer_name="TSS-Standard Security" layer_name="TSS-Standard Application" layer_uuid="dae7f01c-4c98-4c3a-a643-bfbb8fcf40f0" layer_uuid="dbee3718-cf2f-4de0-8681-529cb75be9a6" match_id="8" match_id="33554431" parent_rule="0" parent_rule="0" rule_action="Accept" rule_action="Accept" rule_name="Implicit Cleanup" rule_uid="6dc2396f-9644-4546-8f32-95d98a3344e6" product="VPN-1 & FireWall-1" proto="17" s_port="37317" service="53" service_id="domain-udp" src="10.10.1.180" ","type":"qqqqq","host":"10.10.10.250","@version":"1","port":50620}{"@timestamp":"2019-12-19T14:50:12.153Z","message":"time="1576766483" action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,

Разглеждайки тези съобщения, разбираме, че регистрационните файлове изглеждат така: поле = стойност или ключ = стойност, което означава, че е подходящ филтър, наречен kv. За да изберете правилния филтър за всеки конкретен случай е добре да се запознаете с тях в техническата документация или да попитате приятел.

Настройка на филтъра

На последния етап избрахме kv, конфигурацията на този филтър е представена по-долу:

filter {
if [type] == "checkpoint"{
	kv {
		value_split => "="
		allow_duplicate_values => false
	}
}
}

Избираме символа, с който ще разделим полето и стойността - “=”. Ако имаме идентични записи в дневника, запазваме само един екземпляр в базата данни, в противен случай ще получите масив от идентични стойности, тоест, ако имаме съобщението „foo = някои foo=some“, ние пишем само foo = някои.

Настройване на правилния изход в ElasticSearch

След като филтърът е конфигуриран, можете да качвате регистрационни файлове в базата данни еластично търсене:

output 
{
if [type] == "checkpoint"
{
 	elasticsearch 
        {
		hosts => ["10.10.1.200:9200"]
		index => "checkpoint-%{+YYYY.MM.dd}"
    		user => "tssolution"
    		password => "cool"
  	}
}
}

Ако документът е подписан с типа контролна точка, ние запазваме събитието в базата данни elasticsearch, която приема връзки на 10.10.1.200 на порт 9200 по подразбиране. Всеки документ се записва в конкретен индекс, в този случай записваме в индекс “checkpoint-” + текуща дата. Всеки индекс може да има конкретен набор от полета или се създава автоматично, когато се появи ново поле в съобщение; настройките на полето и техния тип могат да се видят в съпоставяния.

Ако имате конфигурирано удостоверяване (ще го разгледаме по-късно), идентификационните данни за писане в конкретен индекс трябва да бъдат посочени, в този пример това е „tssolution“ с парола „cool“. Можете да разграничите потребителските права да записват регистрационни файлове само към конкретен индекс и не повече.

Стартирайте Logstash.

Logstash конфигурационен файл:

input 
{
         tcp 
         {
                port => 5555
  	  	type => "checkpoint"
    		mode => "server"
                host => “10.10.1.205”
   	 }
}

filter {
        if [type] == "checkpoint"{
	kv {
		value_split => "="
		allow_duplicate_values => false
	}
        }
}

output 
{
if [type] == "checkpoint"
{
 	elasticsearch 
        {
		hosts => ["10.10.1.200:9200"]
		index => "checkpoint-%{+YYYY.MM.dd}"
    		user => "tssolution"
    		password => "cool"
  	}
}
}

Проверяваме коректността на конфигурационния файл:
/usr/share/logstash/bin//logstash -f checkpoint.conf


Стартирайте процеса на Logstash:
sudo systemctl стартиране на logstash

Проверяваме дали процесът е започнал:
sudo systemctl status logstash

Нека проверим дали гнездото работи:
netstat -nat | grep 5555

Проверка на дневниците в Кибана.

След като всичко работи, отидете на Kibana - Discover, уверете се, че всичко е конфигурирано правилно, картината може да се кликне!

Всички регистрационни файлове са на мястото си и можем да видим всички полета и техните стойности!

Заключение

Разгледахме как да напишем конфигурационен файл на Logstash и в резултат получихме анализатор на всички полета и стойности. Сега можем да работим с търсене и чертане на конкретни полета. След това в курса ще разгледаме визуализацията в Kibana и ще създадем просто табло за управление. Заслужава да се спомене, че конфигурационният файл на Logstash трябва постоянно да се актуализира в определени ситуации, например, когато искаме да заменим стойността на поле от число на дума. В следващите статии ще правим това постоянно.

Така че останете на линияTelegram, Facebook, VK, Блог за TS Solution), Yandex Zen.

Източник: www.habr.com