Category: Наблюдение и управление

Домашен дейтацентър или лаборатория|HomeLab, Home Data center

Много devops, програмисти, системни и мрежови администратори изграждат свои домашни лаборатории, мини дейтацентрове, включително доста амбициозни и сериозно направени системи…

В тази статия разглеждам някои от съществените лимити, с които следва да се съобразяваме в амбициите и инвестициите си.

Тъй като е удобно и дори изглежда изгодно да натоварим домашната си лаборатория със сериозни задачи (например проекти за клиенти) – изхождайки от опита си за проектиране и изграждане на сериозна домашна лаборатория (от клас мини дейта център :), споделям лош опит, в желанието си да спестя на читателя настъпването на някоя и друга мотика по пътя. 😉

1. Не правете голяма инвестиция – в крайна сметка домашната лаборатория е за тестове и PoC (Proof of Concept), използването и за други цели рано или късно води до задънена улица и по някое време ще се наложи да отпишете инвестираното и направите нещата както трябва.
Все пак, по-долу (т. 7.) описвам добра (макар не изключителна) идея, която може да осмисли сериозното използване на домашната инфраструктура.

Така че – инвестирайте разумно и пестеливо, за да не загубите много (пари, време, нерви, недоволни клиенти и пропуснати възможности).

2. Причината да отпишете инвестицията е, че домашният дейтацентър не скалира добре – нито в посока повече оборудване, но винаги ще е зле в посока отказоустойчивост и надеждност на работата.

Винаги! Винаги!!

Дали съм достатъчно категоричен?

Винаги!!!

3. Имайте предвид, че много рядко електрическите инсталации в стандартните жилища са оразмерени добре, за да поддържат
7 x 24 x 365 дори малки товари от 1-2KW. Това не винаги се забелязва и никога не е проблем в началото, но е добре да се провери след няколко месеца работа дали предпазителите и изходните шини не греят. Следващите индикатори са черни конвективни следи над таблото, миризма на изгоряло и вой на пожарни сирени.

4. Проблемите с шума са добре известни и всеки чувал стартиращ или натоварен сървър има ясна звукова представа за тях. :). Ще добавя само, че шумът от вентилаторите на средномощен сървър, в някои сгради се чува и през нощта, включително И от съседите.
Разбира се, те не са чак такъв проблем, но помислете за отношенията си с партньора… 🙂  

5. Охлаждането – няма лесен и смислен начин да направите добро охлаждане, ако ще имате повече сървъри. Студеният въздух трябва да се движи отдолу нагоре и фронт/гръб спрямо сървърите (ако са за рак монтаж). Това, което можете да направите е да държите достатъчно ниска температурата в помещението, за да осигурите генерално температурния режим на оборудването, но тази схема консумира повече енергия и поради това е ценово неефективна.

Е, ако имате достатъчно средства може да заложите на рак със собствена климатизация, но това е инвестиция, която не си струва предвид описаното в т. 2.

6. Възможните компромиси –

– Ако просто имате нужда от домашен лаб – използвайте втора ръка мобилни работни станции – те дават доста мощност и са относително тихи (стига да не спите в едно и също помещение с тях). Предимствата им – не ви трябва UPS или KVM имате си вградени монитор, мишка и клавиатура.

– За ML (Machine Learning) – сглобете си машина с големи бавни вентилатори, не повече от един, но възможно най-мощен ускорител, например NVidia GeForce RTX 2080Ti. Пак ще шуми, но ако е в съседно помещение се търпи. Или не се търпи – зависи…

7. Направете си (или използвайте “as a service”) мониторинг – като минимум – температура на околната среда и на системите – трябва да знаете температурното им състояние и да получавате известия при надвишаване на допустимите рамки.

Разбира се мониторинга е необходим и за други цели – например: параметри на експлоатация, надеждност, сигурност, контрол на SLA.

Хубавото в тази схема е, че когато прехвърлите проектите си, където им е мястото – тогава домашната инфраструктура може да се използва за независим (или втори) мониторинг.

8. Ако правилно изберете оркестрацията на виртуализация/контейнеризация – ще можете лесно да мигрирате приложенията си към ваши ресурси в частни или публични клауд платформи. Така ще си запазите възможноста да правите бързи и евтини тестове и PoC в домашната среда, същевременно ще можете лесно да мигрирате продакшън системите на правилните платформи.

9. Спестете си проблеми със сигурността и надеждността и разделете правилно инфраструктурата за тестове и PoC от домашния си интернет, не ги смесвайте от самото начало най-добре – т.е. организирайте си файъруол (може и виртуализиран, но с много мисъл), умен суич/и.

Повтарям – от самото начало разделете едното от другото, никакъв компромис, временно решение и прочие.

Експлоатация на сървъри. Част 1. Натоварване

  • Кое е оптималното натоварване на един сървър?
  • Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
  • Над какво натоварване считаме, че сървърът е претоварен?

В тази статия ще дам някои насоки и възможни отговори. IT инфраструктурата е комплекс от много взаимозависимости и няма еднозначен отговор. Освен това натоварването само по себе си не е проблем, проблем са страничните ефекти от него.

Винаги, когато планираме и експлоатираме IT инфраструктура (за целите на статията нека разглеждаме уеб сървър), следва да отчитаме TCO (Total Cost of Ownership) като параметър. Като пример за важността – в рамките на средностатистическия полезен живот на хардуера, управлението на електрическата консумация е съществена необходимост (грубо може да се приеме, че 10% от свързания оперативен разход подлежи на оптимизация).

Изключително важно е да си осигурим добра видимост към инфраструктурата, което предполага тотален (но разумен и не изкривяващ профила на натоварването) мониторинг върху работата на системите. Добрият мониторинг дава възможност за предвиждане и изследване потенциалните проблеми още преди да сме стигнали до етапа на продукция.

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

TCO зависи от хардуера и начина, по който го експлоатираме. Най-силна и видима е зависимостта от броя и типа сървърни захранвания. Това е така, защото ефективността на захранването е най-висока, ако натоварването му е над 60% и оптимална при ~80%.

Ако сървърът е слабо натоварен, с малко памет и дискове – консумацията му е ниска и ако използва две балансиращи натоварването захранвания – то всяко от тях ще работи извън оптималния си режим.

  • В този случай е необходимо ръчно конфигуриране за работа в режим hot/cold stand-by на едно от захранванията
  • Така другото ще се натовари повече и ще работи в оптималните граници
  • По-новите сървъри поддържат автоматизирано управление на консумацията, но е необходимо да са включени в съответния режим (обикновено не е по подразбиране)

От гледна точка разходи за електричество – колкото повече натоварите сървъра – толкова по-добре, стига системата да се държи предвидимо. Друга зависимост се проявява в случаите, когато сървърът работи върху bare metal или виртуализиран хардуер. Ако е виртуализиран, хайпървайзъра ще се погрижи голямо натоварване (70%+) на сървъра да не се отрази (в някакви граници) на латентността на другите виртуализирани услуги.

Някои конкретни съвети

Насочени са основно към системни администратори и devops. Всъщност препоръчително е CIO и IT мениджърите да са наясно с материята, доколкото TCO и качеството на услугите са тяхна отговорност.

  • Някои комбинации сървърен софтуер (например Apache/PHP) предизвикват и въобще са чувствителни към латентност. Не допускайте в продукция всичко да зависи от фронтенд перманентно натоварен над, да речем, 50%, защото:
    • Няма място за реакция на инцидентни (пикови натоварвания)
    • Влияе и усложнява откриването на други свързани или несвързани проблеми
    • В крайна сметка усложнява и оскъпява експлоатацията на цялостната система
  • Планирайте и от самото начало използвайте лоудбалансър(и) и поне два фронтенда
    • Може да бъдат виртуализирани напълно или да се използва хибридна схема за оптимално TCO
    • Когато натоварването нарастне, за да си струва – тогава може да преминете към bare metal хардуер
  • В общи линии най-изгодно е инфраструктурата да е виртуализирана (контейнеризирана в частност)
  • Контролирайте (по възможност) архитектурата на приложението и качествения код на разработчиците
  • По възможност (особено, ако разработвате бизнес критични системи) избягвайте да съчетавате множество функции в един сървър (например уеб, дейтабейс, файлов и прочие)
    • Ако това не е възможно – оставете достатъчно резерв например средно натоварване на сървърен процес под 20% (за да имате резерв за абсорбиране на пикови натоварвания)
    • Не лош вариант е да управлявате прецизно натоварването в рамките на един сървър с cgroups, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:

Виртуализация –

Контейнеризация –

Traccar

Кратко описание

Traccar е Java базиран GPS tracking сървър. Поддържа практически всички популярни протоколи и устройства и е изключително подходящ за организации, които искат да следят, визуализира и анализират движението на устройства и превозни средства.

Вградените му възможности за визуализация и анализ го правят приложим както за автоматизация дейността на център за експлоатация в организацията, но така също и за извършване на бизнес анализ в областта на проследяването на превозни средства (AVL – Automatic Vehicle Location).

Подходящ за:
  • Бизнес аналитична дейност в организацията
  • AVL
  • Споделяне на информация в организацията и външни потребители
  • Поддръжка на активни и атрактивни табла за визуализация
  • Изпращане на съобщения при достигане или промяна на ключови параметри 
Неподходящ за:
  • В размките на своята ниша, Traccar е подходящ за всички дейности
За повече информация:
Защо Traccar:
  • Предлага цялата си функционалност в безплатна версия
  • Документацията е на приемливо ниво
  • Интеграция с LDAP
Недостатъци:
  • Traccar е монолитно java приложение и предполага грамотно поддържана база данни и сървърен ресурс
Оценка на необходимите ресурси при внедряване:
  • Лесно и бързо внедряване
Степен на завършеност на решението:
  • Завършено
Съвети към IT мениджъра:
  • Струва си – Traccar е функционална AVL система

ELK Stack – Elastic Stack

Кратко описание

Elastic Stack (известен по-рано като ELK Stack) е решение за обработка на лог информация. Представлява лог сървър с вградени колектор, процесор, система за съхранение, обработка, анализ, визуализация и изпращане на алерти, базиран е на отворен и свободен код.

Основните му компоненти са:

  • Elastic Search – система за съхранение и индексиране на информацията
  • Logshtash – система за събиране и препроцесинг на log информация
  • Beats – система от агенти за събиране на информация и изпращане към централната система
  • Kibana – система за визуализация и обработка на информацията

Еластик стек е дефакто стандарт за събиране и управление на лог информация, особено в клауд инфраструктура. Позволява изграждане на системи за наблюдение и анализ бизнес клас. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Богата функционалност в основна безплатна версия
  • Наличие на комерсиални версия и поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Подходящ за:

  • Внедряване на надеждни системи за събиране и управление на логове
  • Средство да получите и централизирано обработите/съхраните цялата необходима информация за отстраняване на проблеми и увеличаване на ефективност
  • Единна система, която може да агрегира лог информация от локални, отдалечени и клауд базирани източници
  • Може да бъде използван както за наблюдение на системи и инфраструктура, така също на приложения и услуги
Неподходящ за:
  • В рамките на специализацията си като лог сървър, Elastic Stack е подходящ да изпълнява всевъзможни задачи
За повече информация:
Защо Elastic Stack:
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Поддържа всевъзможни лог формати
  • Множество плъгин модули, които разширяват съществуваща или добавят нова функционалност
  • Добре се вписва в корпоративна среда (LDAP) 
  • Добра интеграция и поддръжка от Elastic
  • Може да се използва като SIEM система, дори в безплатната версия, но все още липсват съществени интеграции, които има в специализираните за целта средства (като например AlienVault OSSIM)
  • В платената версия има ML (Machine Learning) възможности за специализиран лог анализ
Недостатъци:
  • Непълна поддръжка на организационни йерархии (multitenancy)
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Инсталация на ELK- при използване на базови настройки за малка до средна инфраструктура – лесна. 
  • Предлагат се готови контейнер базирани инсталации за всички популарни клауд и контейнер инфраструктури
  • Има вградена поддръжка на разпределена инфраструктура, както за приемане, така и за обработка и съхраняване на лог информация
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Напълно завършено решение, но в безплатната версия са необходими множество времеемки интеграции, за да е напълно функциoнален. 
Съвети към IT мениджъра:
  • Elastic Stack е особено подходящ да замени класически лог сървъри (rsyslog, syslog-ng) като централен агрегатор и процесор на лог информация
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Допълнително разработените агенти (beats) позволяват мониторинг на всевъзможни системи
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • ELK е изключително всеобхватен и универсален продукт – поради това е необходимо да се инвестира време, за да се използват ефективно пълните му възможности. 

 

Graylog

Кратко описание

Грейлог (Graylog) е лог сървър с вградени колектор, процесор, система за съхранение, обработка, анализ, визуализация и изпращане на алерти, базиран на отворен и свободен код. Позволява изграждане на системи за наблюдение и анализ бизнес клас. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Богата функционалност в основна безплатна версия
  • Наличие на комерсиални версия и поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Подходящ за:

  • Внедряване на надеждни системи за събиране и управление на логове
  • Средство да получите и централизирано обработите/съхраните цялата необходима информация за отстраняване на проблеми и увеличаване на ефективност
  • Единна система, която може да агрегира лог информация от локални, отдалечени и клауд базирани източници
  • Може да бъде използван както за наблюдение на системи и инфраструктура, така също на приложения и услуги
Неподходящ за:
  • В рамките на специализацията си като лог сървър, Грейлог е подходящ да изпълнява всевъзможни задачи
За повече информация:
Защо Грейлог:
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Поддържа всевъзможни лог формати
  • Множество плъгин модули, които разширяват съществуваща или добавят нова функционалност
  • Добре се вписва в корпоративна среда (LDAP) 
  • Поддръжка на организационни йерархии (multitenancy)
  • Поддръжка на потребители и групи
  • Допълнително REST API
Недостатъци:
  • В безплатната (за разлика от платената) версия липсва механизъм, за правене на корелации между регистрираните и обработени събития
    • Все пак, с помощта на допълнителни плъгин модули е възможно да се постигне приемливо корелиране
  • Дребно неудобство – не поддържа стандартни лог портове, например UDP514, тъй като Java машината не работи с привилегировани портове (разбира се има решение, например локално пренасочване на портове)
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Инсталация на Graylog – при използване на базови настройки за малка до средна инфраструктура – лесна
  • Има вградена поддръжка на разпределена инфраструктура, както за приемане, така и за обработка и съхраняване на лог информация
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Завършено решение, макар че по отношение на визуализация има какво да се желае
    • Има положителна тенденция в последните години за развитие на тази функционалност
    • Относително лесно е да се добави и използва външна технология за визуализация, например Grafana
Съвети към IT мениджъра:
  • Graylog е особено подходящ да замени класически лог сървъри (rsyslog, syslog-ng) като централен агрегатор и процесор на лог информация
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват ефективно

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни Graylog решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

Security Onion Hybrid Hunter

Кратко описание

Security Onion Hybrid Hunter е следващата версия на Security Onion и текущо е в алфа тест. Отделям внимание на този незавършен продукт, защото като замисъл тази версия трябва да отстрани основните недостатъци на SO и може би си струва да се изчака и евентуално използва SO HH за реализация на мащабни open source SIEM системи в големи организации. 

За повече информация:
Защо Security Onion Hybrid Hunter:
  • SO-HH вероятно ще реши проблемите на SO като добави интегрирани възможности за корелация, анализ и управление на действия
  • В допълнение – модерната, базирана на контейнери архитектура на HH, би могла да предопредели дълъг живот и улеснена поддръжка на системата
Недостатъци:
  • На този етап е рано да се прецени
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO HH представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 4-8 часа
  • Разширени конфигурации – рано е за оценка
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Ранна алфа версия
  • Множество проблеми
Съвети към IT мениджъра:
  • Изчакайте. SO HH може да е добра основа за изграждане на SIEM решение за Вашата организация. 
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Security Onion

Кратко описание

Security Onion е SIEM (Security Information and Event Management) система с отворен код и представлява Linux дистрибуция за откриване на прониквания, наблюдение на сигурността на организацията и управление на логове. Основни функции:

  • Събиране на информация от мрежата в реално време (full realtime packet capture)
  • Мрежови и хост-базирани системи за откриване на проникване (NIDS и HIDS)
  • Мощни инструменти за анализ

Включва:

  • ELK Stack – Elasticsearch, Logstash, Kibana – събиране, съхранение, обработка и визуализация на информация
  • Snort – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Suricata – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Bro – използва се като система за откриване на проникване базирана на анализ (Analysis driven IDS  – Intrusion Detection System)
  • OSSEC – хост базиранa системи за откриване на проникване (HIDS)
  • Wazuh – използва се като система за откриване на проникване в сървъри (Host based IDS  – Intrusion Detection System)
  • Sguil – Система за анализ
  • Squert – Уеб интерфейс към Squil
  • И много други инструменти за сигурност

Security Onion представлява колекция от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Поддържа агенти, които могат отдалечено да събират и изпращат информация към разпределената система за обработка и визуализация. SO предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
  • Управление информационната сигурност на голяма организация – SO позволява изграждането на разпределена система от колектори, процесори на информация и сторидж системи
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси
За повече информация:
Защо Security Onion:
  • Зрял проект с дългогодишно развитие и широка база от разработчици на много от неговите компоненти
  • Предлага съществена функционалност в безплатна версия
  • За разлика от конкурентни продукти (например AlenVault OSSIM) има вграден и много добър механизъм за събиране, обработка и визуализация на логове (ELK stack)
  • Има комерсиална поддръжка
  • Безплатната версия има относително добра документация, както и някаква поддръжка от общността на потребителите
Недостатъци:
  • Макар положените усилия за сглобяване и интегриране на различните средства, дистрибуцията е доста насипна и еклектична комбинация от отделни продукти, които в повечето случаи се конфигурират и управляват през множество разположени във файловата система конфигурационни файлове без единен интерфейс
  • Макар да решава много задачи,  SO не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Липсват възможности за организиране на йейрархии и управление на действия при секюрити събития
  • Липсва единен механизъм за изпращане на алерти
  • Редки ъпдейти
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации са в зависимост от мащаба на организацията и може да са необходими много дни за постигане на удовлетворяващи резултати
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Насипно решение.
  • Някои компоненти работят добре и веднага, други изизкват много време за конфигурация. 
Съвети към IT мениджъра:
  • Security Onion е добра начална стъпка за осигуряване на информационна сигурност в голяма организация и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на SO в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате добри системни и мрежови администратори, R&D персонал и достатъчно време да поддържате насипно решение от различни компоненти с отворен код – по-скоро рано, отколкото късно – ще се наложи да търсите и мигрирате към комерсиално решение ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни SIEM решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

AlienVault OSSIM

Кратко описание

AlienVault OSSIM (Open Source Security Information Management) е SIEM (Security Information and Event Management) система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Понастоящем, AlienVault OSSIM е част от AT&T Cybersecurity. 

OSSIM не само събира различни средства с отворен код, но ги интегрира в общ интерфейс за управление, обмен на данни, възможност за корелиране на събития и управление на инциденти свързани със сигурността. Така OSSIM предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

AlienVault OSSIM има автоматизирани механизми за събиране на инвентарна (сканиране на мрежи, детекция на операционни системи, работещи услуги) и лог информация. Сканира за уязвимости, управлява събития, техния контекст и взаимна корелация. Генерира аларми, предписания и ескалира действия в рамките на SOC (Security Operations Center) на организацията. 

Чрез активиране на сървър и агенти в различните офиси/локации на организацията, може да се обхване цялостната и дейност в единна система. 

Компоненти:

  • PRADS – използва се за идентифициране на хостове и услуги чрез пасивно наблюдение на мрежовия трафик
  • Suricata – използва се като система за откриване на проникване (IDS  – Intrusion Detection System)
  • Tcptrack – използва се за анализ на данни от TCP сесии, да предоставя полезна информация за корелиращите механизми
  • Munin – използва се за трафичен анализ и наблюдение на услуги
  • NFSen / NFDump – използва се за събиране и анализ на NetFlow 
  • FProbe – използва се за генериране на NetFlow от уловен трафик
  • Nagios – използва се за наблюдение на хостове и услуги
  • OpenVas – използва се за оценка на уязвимостта на наблюдавани хостове и услуги
  • В допълнение OSSIM включва разработени от AlienVault инструменти, като най-важният е генерален механизъм за корелация с логическа поддръжка на директиви и обработка на лог информация със специализирани процесори
Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси. 
  • Управление информационната сигурност на голяма организация – същественото ограничение е, че OSSIM обработва информацията само на един сървър
За повече информация:
Защо OSSIM:
  • Зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага доста от необходимата функционалност в безплатната версия
  • Има комерсиална версия с повече възможности и разширена поддръжка
  • Безплатната версия има много добра документация, както и достатъчно надеждна поддръжка от общността на потребителите
  • Много добра документация, включително обучаващи клипове и редовни уебинари по различни аспекти на информационната сигурност
Недостатъци:
  • OSSIM е opensource вариант на комерсиален и скъп продукт, има мек натиск за преминаване към платената версия
  • Макар да решава много задачи, OSSIM не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Съществуват дребни (но отнемащи време на администраторите на OSSIM) проблеми, които не се отстраняват с години. Все пак следва да се отчита, че големите проблеми се отстраняват достатъчно бързо
  • Редовните ъпдейти на OSSIM – няколко пъти седмично, отнемат доста време и понякога се налага отстраняване на проблеми предизвикани от самия ъпдейт
Оценка на необходимите ресурси при внедряване:
  • Тъй като OSSIM представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации, включително дефинирането на необходимите за спецификата на организацията корелационни правила, отнема време в зависимост от мащаба на организацията и може да отнеме дни
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Завършено в голяма степен решение, но в безплатната версия липсат необходими компоненти – например сървър за запазване и обработка на историческа лог информация
  • Необходимо е дефиниране нужните на организацията корелационни правила
Съвети към IT мениджъра:
  • Струва си – AlienVault OSSIM е добра начална стъпка за осигуряване на информационна сигурност и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на OSSIM в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате R&D персонал и достатъчно време да създавате корелатори на събития и отчети за конкретните си нужди на – по-скоро рано, отколкото късно – ще се наложи ИЛИ да преминете към комерсиалната версия ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни SIEM решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

LibreNMS

Кратко описание

LibreNMS (ЛибреНМС) е SNMP система за мрежов мониторинг 

Форк е на известният софтуер за мрежово наблюдение Observium.

Доколкото работи по SNMP, може да се използва за наблюдение на всякакъв тип SNMP устройства, включително:

  • Сървъри, сторидж системи, HVAC, UPS и други. 
Характеристики:
  • Auto discovery – доста добре се справя включително със сложни топологии на мрежата. Отчита, както рутинг информация, така също и състоянието на интерфейсите. 
  • Alerting
  • Multiple environment sensors support
  • Multiple protocols data collection (STP, OSPF, BGP etc)
  • VLAN, ARP and FDB table collection
  • Customizable Dashboards
  • Device Backup integration (Oxidized, RANCID)
  • Distributed Polling
  • Multiple Authentication Methods (MySQL, LDAP, Active Directory, HTTP)
  • NetFlow, sFlow, IPFIX (NfSen)
  • Service monitoring (Nagios Plugins)
  • Syslog (Integrated, Graylog)
  • Traffic Billing (Quota, 95th Percentile)
  • Two Factor Authentication
  • API
  • Auto Updating
Интеграции
Подходящ за:
  • Цялостни решения за мониторинг и управление на мрежи. 
  • Автоматично откриване и визуализация на мрежови топологии
  • Организация поддръжка на комплексни мрежи
  • Трафичен анализ
  • Трафична статистика и подготовка на сметки и билинг
Неподходящ за:
  • Управление на цялостен мониторинг, включващ освен мрежи, базови (например web, database, load balancer), комплексни услуги и софтуерни компоненти 
За повече информация:
Защо LibreNMS:
  • Напълно open source решение без твърди или меки стимули за купуване на допълнителни компоненти и възможности. 
  • Поддържа щирок набор SNMP устройства
  • Много добър за проактивен мониторинг, наблюдение състояние на интерфейси, трафик, загуби на пакети, jitter
  • Може да се впише в корпоративна среда (LDAP/AD) 
  • При интеграция с Netflow и Smokeping може да се правят добри анализи на трафик и свързаности, за да се следи спазване на SLA и контролират оперативни разходи 
Недостатъци:
  • Съществените настройки се правят през съответни конфигурационни файлове, което затруднява поддръжката на продукта, особено ако е на много нива и компетентности 
  • Активираната по подразбиране опция за автоматично обновяване на LibreNMS, понякога води до проблеми, особено при големи промени в структурата на базата данни при преход между мейжър версии. В тази връзка е препоръчително автоматичните ъпдейти да се забранят, ако LibreNMS се използва в продукционна система
Оценка на необходимите ресурси при внедряване:
  • Инсталация при използване на базови настройки за малка до средна инфраструктура – относително лесна
  • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Относително добра документация
Степен на завършеност на решението:
  • LibreNMS прави перфектно това, за което е създаден – нито повече, нито по-малко. При комплексна инфраструктура и необходимост от наблюдение не само на устройства и мрежи, но на услуги и софтуерни компоненти – необходимо е да се добавят допълнителни решения – като например Zabbix, което може да увеличи натоварването на екипа и може да се обмисли дали да не се използва само Забикс като по-универсално решение 
Съвети към IT мениджъра:
  • Архитектурата на LibreNMS позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко мрежови устройства, до големи мрежи тип “сървис провайдър”
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват на входно ниво
  • При наблюдение на комплексни системи е необходимо добро планиране и провизиране на необходимите ресурси – процесорни ядра и памет.
    • Особено в случай, когато се наблюдават множество системи с голям брой наблюдавани параметри и се запазват данни за големи периоди от време – необходимо е да се осигури достатъчно дисково пространство, както и проследяване на консумацията му
    • Следва да се отчита, че (ако) събирането на netflow статистика генерира огромни логове

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни LibreNMS решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

Zabbix

Кратко описание

Забикс е система за мониторинг и управление на IT инфраструктури – 

  • Мрежи
  • Хардуер
    • Сървъри, Сторидж системи, HVAC системи, Захранващи системи (UPS) 
  • Софтуер – бази данни, уеб сървъри, месидж брокери…
  • Цялостни услуги – с възможност за описание на взаимозависимости между отделни компоненти и услуги, както и проследяване изпълнението на споразумения за ниво на обслужване (Service Level Agreement). 

Подробно за всички поддържани технологии и интеграции – Zabbix Integrations

Подходящ за:
  • Цялостни решения за мониторинг и управление. 
  • Наблюдение на IT инфраструктура и услуги. Поддръжка с йерархични нива. Дашборди. 
  • Контролиране спазване на SLA (Service Level Agreement) от доставчици на услуги и към клиенти
Неподходящ за:
  • Автоматично създаване на топологична схема (карта) на мрежови връзки. Ръчно е възможно да се визуализират всевъзможни йерархии, но ако топологичната схема е необходимост, препоръчваме добавяне на решение като LibreNMS
За повече информация:
Защо Zabbix:
  • Напълно open source решение без твърди или меки стимули за купуване на допълнителни компоненти и възможности. 
  • Поддържа практически всички съществуващи IT инфраструктурни компоненти
    • Подробно за всички поддържани технологии и интеграции – Zabbix Integrations
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Може да се впише в корпоративна среда (LDAP/AD) 
  • Поддръжка на организационни йерархии (multitenancy)
  • Поддръжка на потребители и групи
  • Допълнително REST API
  • Вградена архитектура за отказоустойчивост (клъстер от сървъри)
Недостатъци:
  • Няма автоматично изобразяване на мрежи и визуализиране на мрежовата топология
  • Изключително комплексен продукт, поради това изисква сериозна експертиза при експлоатация
  • Лоша поддръжка на LDAP и Active Directory
Оценка на необходимите ресурси при внедряване:
  • Инсталация при използване на базови настройки за малка до средна инфраструктура – относително лесна
  • Има вградена поддръжка на разпределена инфраструктура чрез локални прокси сървъри
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Zabbix е завършено тотално решение за наблюдение на IT инфраструктура
  • Все пак следва да се отчита, че интеграциите с комплексни решения и инфраструктурни компоненти може да предполага писане на код и/или интеграционни скриптове
Съвети към IT мениджъра:
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват на входно ниво
  • При наблюдение на комплексни системи е необходимо добро планиране и провизиране на необходимите ресурси – процесорни ядра и памет.
    • Особено в случай, когато се наблюдават множество системи с голям брой наблюдавани параметри и се запазват данни за големи периоди от време – необходимо е да се осигури достатъчно дисково пространство.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни Забикс решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

ZabDash и Grafana plugin за Zabbix

Кратко описание

Забикс предлага визуализация на състоянието на наблюдаваните мрежи и системи чрез табла за наблюдение (dashboard). Макар с течение на времето възможностите му да се развиват и подобряват, те все пак са относително ограничени.

Благодарение на разработеното API към Забикс могат да бъдат свързани външни системи за визуализация като ZabDash (добавка към Забикс) и плъгин за използване на популярното средство за визуализация – Grafana. 

Подходящ за:
  • Подобряване на възможностите за визуализация на Забикс при мониторинг на мрежи и системи.
  • Дефиниране на различни табла за наблюдение за различни групи потребители и цели
    • Администратори
    • Поддръжка от различни нива
    • Мениджмънт
Неподходящ за:
  • Самостоятелна работа
За повече информация:
Защо ZabDash и Grafana plugin:
  • Подобряване на възможностите за визуализация
  • По-добра представителност на извършваното наблюдение
  • Поддръжка на специализирани табла за наблюдение, които отговарят на специфични изисквания за дизайн и цветова схема
Недостатъци:
  • Все пак това са само визуализации и не заменят добрата конфигурация и смислените неща за наблюдаване
  • Развитието при ЗабДаш е по-бавно
Оценка на необходимите ресурси при внедряване:
  • И двете добавки се инсталират бързо и безпроблемно
Степен на завършеност на решението:
  • Завършени решения
  • И двете добавки разполагат с предефинирани табла и възможности.
    • Графана е в по-насипно състояние, но благодарение на своята архитектура дава повече възможности, но и повече работа. 
    • ЗабДаш e написан на PHP и добавянето на нови възможности е свързано с модификации на кода. Вградените му визуализации са много и покриват основни сценарии на използване
Съвети към IT мениджъра:
  • Струва си да разширите възможностите на Zabbix базираната система за наблюдение и управление с тези добавки

SLA Калкулатор

DevOps Roadmap 2020

Кратко описание

Това, според Kamran Ahmed, е DevOps технологичният стек за началото на 2020г. 

 

Съвети към IT мениджъра:
  • Без претенции за всеобхватност и валидност за целия devops спектър, схемата дефинира примерен модел, който може да се следва от технологичните организации за изграждане и поддържане на модерна IT инфраструктура
  • Схемата е особено подходяща за фукционална визуализация на devops и sysadmin процесите в организацията и идентифицирането на необходимите ресурси и технологично ноу-хау
  • Препоръчително е CIO и IT мениджърите да имат предвид или да разработят подобна схема, която да подпомага процеса на търсене на нови и обучение служителите на организацията
  • Не че е невъзможно, но не е препоръчително да реализирате целия технологичен стек без по-тясна специализация и разпределение на роли в екипа