Browsed by
Štítek: logmanager

Critical Windows Vulnerability

Critical Windows Vulnerability

Microsoft zveřejnil novou kritickou zranitelnost, označenou CVE: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26809

Co to přesně znamená? Zde je vysvětlení od společnosti Microsoft:

Chyba zabezpečení při vzdáleném spuštění kódu za využití vzdálené volání procedury

Aby mohl útočník tuto chybu zabezpečení zneužít, musel by hostiteli RPC odeslat speciálně vytvořené volání RPC. To by mohlo mít za následek vzdálené spuštění kódu na straně serveru se stejnými oprávněními jako služba RPC.

Jaké operační systémy Windows jsou zranitelné?

  • Windows Server 2008 a výš
  • Windows 7 a výš

Co s tím můžete dělat a jak vám může pomoci LOGmanager?

  1. Nainstalujte poslední bezpečnostní záplaty. Díky aktuálnímu operačnímu systému nebudete vůči této hrozbě zranitelní.
  2. Ujistěte se, že máte zakázanou komunikaci pro port 445 na firewallu, směrem z internetu do vnitřní sítě. K využití této zranitelnosti potřebuje útočník pouze otevřený port 445, bez jakéhokoliv speciálního oprávnění.
  3. Zkontrolujte pomocí LOGmanageru komunikaci z internetu na portu 445 směrem do vnitřní sítě. Pro to pochopitelně potřebujete provádět sběr logů z firewallů. Pro ukázku tady máme logy z next-gen firewallů Fortinet FortiGate:

Jak vidíte, za posledních 7 dní jsme zaznamenali 734 pokusů o připojení k portu 445. Protože jsem použil filtr msg.src_ip:192.168.* OR msg.src_ip:172.16.* OR 10.* nastavený na NOT. Jsem si jistý, že všechna tato spojení pocházela mimo mou síť – jinými slovy, pokud je zdrojová IP v rozsahu privátních adres (RFC 1918), LOGmanager ji na panelu nezobrazí. Nyní se podíváme, zda bylo na firewallu akceptováno nějaké připojení.

Vypadá to, že ne – všech 734 připojení bylo odmítnuto. To je dobře – to znamená, že nikdo nebyl schopen otevřít zvenčí port 445.

Můžeme také zkontrolovat, ze kterých zemí tato připojení pocházejí.

Vypadá to, že se jedná většinou o Bulharsko/Rusko. To samozřejmě neznamená, že útočník skutečně sedí v jedné z těchto zemí – obvykle využívají VPN/Jumphosty/TOR, aby skryli svůj původ.

V tomto případě to vypadá, že je naše síť v bezpečí. Ale v moment, kdy byste po použití výše uvedených filtrů viděli jakýkoli provoz se statusem „akceptováno“ , důrazně doporučuji provést úplnou investigaci a hledat indikátory kompromitace (IoC) – například trvalé připojení z vaší sítě směrem do internetu s nastavenými intervaly (kanály C&C). Existuje možnost, že zranitelnost proběhla ještě před jejím objevením…

Existuje také možnost využít tuto zranitelnost a spustit útok zevnitř sítě – v takovém případě ho bude mnohem obtížnější odhalit pouhým pohledem na provoz, protože bude smíchaný s legitimními připojeními. Co však můžete udělat, je obrátit NOT filter tak, aby zobrazoval spojení přicházející POUZE zevnitř vaší sítě, a pak zkontrolovat, zda cílové servery vůbec mají mít spuštěnou službu SMB na portu 445 – někdy prostě zapomeneme některé služby zakázat.

S obráceným filtrem nyní vidím 6773 připojení k portu 445.

Nyní mohu prozkoumat, jaké servery uvedené v grafu Destination IP mají mít spuštěnou službu SMB, a zakázat ji tam, kde není potřeba.

To je vše, přátelé! Chcete-li se dozvědět více o tom, jak využít Dashboardy LOGmanageru k provádění analýz/investigace, podívejte se na naše uživatelské fórum a kanál Youtube, kde sdílíme spoustu obsahu.

LOGmanager – Forum

LOGmanager – YouTube

Microsoft just issued a new CVE: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26809

What does this mean exactly? Here is an explanation from Microsoft:

Remote Procedure Call Runtime Remote Code Execution Vulnerability

To exploit this vulnerability, an attacker would need to send a specially crafted RPC call to an RPC host. This could result in remote code execution on the server side with the same permissions as the RPC service.

Which Windows Systems are vulnerable?

  • Windows Server 2008 and above
  • Windows 7 and above

So what can you do about it and how LOGmanager can help?

  1. Apply newest Microsoft patch to your systems. This will ensure you are not vulnerable to this exploit.
  2. Make sure port 445 is closed on firewall for traffic coming from outside. To run this exploit attacked does not need any access permissions – just an open port 445.
  3. Check connections from outside to port 445 on LOGmanager. Of course you need logs from your FW to do this. We have Fortigate logs so for example:

 

As you can see we had 734 connection attempts to port 445 in last 7 days. Because I used filter msg.src_ip:192.168.* OR msg.src_ip:172.16.* OR 10.* set to NOT, I’m sure all those connections came from outside of my network – in other words, if source IP is in range of private addresses (RFC 1918) LOGmanager will not show it on dashboard.

Now lets see if any connection were accepted on the firewall.

Look like no – all 734 connections were denied. That’s good – meaning no one was able to access port 445 from outside.

We can also check from which countries those connections came.

Looks like mostly Bulgaria/Russia. This of course does not mean that attacker is actually sitting in one of those countries – usually they make use of VPNs/Jumphosts/TOR/Whatever to mask their origin.

Now, in this case, looks like our network is safe. But in case you’d see any traffic with status accept after applying above filters I strongly suggest to run full investigation and look for indicators of compromise (IoC) – for example persistent connection to outside from your network with set intervals (C&C channels). There is a possibility exploit was running in the wild before it was discovered…

There is also a possibility to run this attack from inside of your network – in that case it will be much harder to detect just by looking at traffic, since it will be mixed with legitimate connections. What you can do though is reverse NOT filter to show connections coming ONLY from inside of your network and then check if destination servers are even supposed to have SMB service running on port 445 – sometimes we simply forget to disable certain services 😉

With filter reversed I now see 6773 connections to port 445.

I can now investigate which servers listed in Destination IP graph should have SMB service running and disable it where it is not needed.

That’s it folks! If you wish to know more how to leverage LOGmanager dashboards to run analysis/investigation check our user forum and youtube channel where we share a lot of content.

LOGmanager – Forum

LOGmanager – YouTube

Nový LOGmanager Agent / The new LOGmanager Agent

Nový LOGmanager Agent / The new LOGmanager Agent

Nový LOGmanager agent je tu!

Dalo to zabrat, ale nový agent je na světě. A zákazníci, včetně partnerů, se nás ptají proč? Dovolili jsme si sepsat hlavní důvody, proč by vás nový LOGmanager Agent měl zajímat. A opět, za vším stojí radikální jednoduchost!

Blockly!

Celé řešení LOGmanager stojí na vizuálním programovacím jazyce Blockly, ten umožňuje napříč systémem velice jednoduchou konfiguraci. Tak proč nerozšířit o jeho benefity a funkcionalitu také konfiguraci agentů?

Díky Blockly můžete velice jednoduše a efektivně filtrovat logy přímo na koncovém/zdrojovém zařízení. Nemusíte posílat všechny logy na LOGmanager, přeci jen jich může být drtivá většina pro vaše potřeby nepodstatná, a tak je budete zahazovat přímo na zařízení, kde je nový LOGmanager Agent nainstalovaný.

Nebo naopak můžete využít Blockly k tomu, abyste přeposlali na LOGmanager jen konkrétní logy, které pro vás mají hodnotu.

Zajímá-li vás víc – navštivte naši dokumentaci – https://doc.logmanager.cz/manual/3.8.1/cs/web/beats/config.html

Výkon a spolehlivost.

Výkon, to je oč tu běží. Zákazníci se setkávali s limity našeho starého WES agenta, proto jsme se při vývoji zaměřili i na výkon. Současný LOGmanager Agent zvládne až neuvěřitelných 3000 logů za sekundu. Tato hodnota je, jak jsme si ověřili, pro všechny dostačující. Navíc nový Agent nesebere z operačního systému mnoho prostředků, v praxi se pohybuje u vytížení cca 50mgb RAM a 0,1% CPU.

Co se spolehlivosti týká, největším přínosem jsou komponenty, na kterých je nový LOGmanager Agent založený. Jinými slovy, „Proč vyvíjet něco, co už někdo vyvinul a funguje to?“ Řeč je tu o Elasticu. V současné době nový agent podporuje Elastic Winlogbeat a Filebeat. Ověřené a spolehlivé komponenty, které je možné do budoucna doplnit o další.

Vylepšený sběr logů nejen z textových souborů.

Jsme si vědomi potřeby sbírat logy i z textových souborů, proto jsme tuto část pro vás vylepšili a neustále na ni pracujeme. Přidali jsme možnost aplikování šablon na konkrétní textový soubor, ta přidá tag/značku, kterou můžete dále používat a díky které se můžete v událostech jednoduše orientovat. Díky aplikaci šablony bude LOGmanager schopen také logy správně parsovat/zpracovávat.

Další důležitou částí konfigurace agenta je schopnost filtrovat logy událostí z Microsoft Event View (Prohlížeč událostí). V současné době máte na výběr mezi všemi událostmi, nebo těmi systémovými. To samo o sobě fungovalo i ve verzi starého WES agenta, ovšem s novým agentem budeme tyto možnosti rozšiřovat a správci LOGmanager budou moci využít specifičtějšího filtrování.

https://doc.logmanager.cz/manual/3.8.1/cs/web/beats/orchestrators.html

Bezpečnost na prvním místě!

Iniciální komunikace mezi LOGmanager serverem a Agentem proběhne pomocí TLS 1.2, po navázání spojení pak vše běží po TLS 1.3. Navíc zde nadále můžete využít možnosti validování SSL certifikátu a posunout bezpečnost ještě o kousek dál.

K bezpečnosti se také váže schopnost agenta sbírat logy i mimo doménové počítače, to doposud s naším starým WES agentem nešlo. Pomocí Windows registrů můžete přinutit agenta odesílat logy na libovolný LOGmanager. Stačí přidat klíč dns_override_host se jménem/ip adresou vašeho LOGmanager serveru. Proč? Mnoho zákazníků má část kritické infrastrukturu mimo doménu a díky této volbě mají jistotu, že se do LOGmanageru dostanou logy ze všech podporovaných zařízení. To mohou být například zálohovací servery, průmyslové nebo nemocniční systémy.

https://doc.logmanager.cz/manual/3.8.1/cs/devices/logmanager-orchestrator.html#dns-srv-override-1

A tím to nekončí!

Centrální správa z GUI LOGmanager, možnost nasazovat agenty pomocí GPO, přidávání vlastních tagů/značek, automatická aktualizace agentů a mnoho dalšího.

Nový LOGmanager Agent je ve zkratce výkonnější, bezpečnější a flexibilnější.

Na vývoji pracujeme neustále, nasloucháme potřebám našich zákazníků a snažíme se doručit funkce, které vyžadují nebo potřebují.

 

PS: Autor článku je Lukáš Termer, nová posila v týmu LOGmanager.

The new LOGmanager Agent is here!

It was difficult but new Agent was born. Customers including partners are asking us why? So we decided to write down main reasons, why you should be interested in. And again, everyting is about radical simplicity.

Blockly!

The whole LOGmanager is built on visual programming language called Blockly. It allows very simple configuration in all aspects of it. So why not extend the agent configuration to its benefits and functionality?

With Blockly you can very simply and effectively filter logs directly on endpoint/server. You don’t have to send all logs to LOGmanager, in your environment you don’t need all of them sometimes. So you will drop/discard logs directly on the device where new LOGmanager Agent is installed.

Or you can use Blockly to reverse logic and select only the logs which you want to send to LOGmanager.

If you are interested visit our documentation – https://doc.logmanager.cz/manual/3.8.1/en/web/beats/config.html

Performance and reliability.

Performance, this is what we are talking about! Many times the customers met limits of our old WES agent, so we focused on performance during development. The current LOGmanager Agent handles up to incredible 3,000 logs per second! This value is very sufficient for everyone, as we have verified with the partners and customers. The new Agent also does not take a lot of resources from the operating system, in practice it has a load of about 50mgb RAM and 0,1% CPU.

In terms of reliability, the biggest benefit is the components on which the new LOGmanager Agent is based. In other words, „Why develop something that someone has already developed and it works?“ We are talking about Elastic. The new agent currently supports Elastic Winlogbeat and Filebeat. Proven and reliable components that can be extended in the future.

Improved log collection not only from text files.

We are aware of the need to collect logs from text files, so we have improved this section for you and are constantly working on it. We’ve added the ability to apply templates to a specific text file, which will add a tag that will allow you better orientation in the events. According to the template function, LOGmanager will also be able to parse / process logs correctly.

Another part of the agent configuration is the ability to filter event logs from the Microsoft Event View. You currently have a choice between All events or System events. It also worked in the version of the old WES agent, but with the new agent we will expand these possibilities and LOGmanager administrators will be able to use more specific filtering.

https://doc.logmanager.cz/manual/3.8.1/en/web/beats/orchestrators.html

Security first!

The initial communication between the LOGmanager server and the Agent uses TLS 1.2, after the connection is established, everything runs according to TLS 1.3. In addition, you can continue to use the option of SSL certificate validation and extend the security a little bit.

Security is also linked to the agent’s ability to collect logs outside of domain computers, which has not been possible with our old WES agent. You can use Windows Registry to force the Agent to send logs to any LOGmanager. Just add the dns_override_host key with the name / ip address of your LOGmanager server. Why? Many customers have part of the critical infrastructure outside the domain and according to this option they can be sure that logs from all supported devices will get into LOGmanager. For example it can be the backup servers, industrial or hospital systems.

 

https://doc.logmanager.cz/manual/3.8.1/en/devices/logmanager-orchestrator.html#dns-srv-override-1

It doesn’t end there!

Central management from GUI of LOGmanager, the ability to deploy agents using GPOs, adding custom tags, automatic agents updates and much more.

In short, the new LOGmanager Agent is more powerful, more secure and more flexible.

We are constantly working on development, listening to the needs of our customers and deliver the features they require or need.

 

PS: The author of the article is Lukáš Termer, a new support to the LOGmanager team.


Deprecated: Funkce Šablona neobsahuje souboru sidebar.php není podporována už od verze 3.0.0 a v aktuální verzi WordPressu není dostupné ani žádné náhradní řešení. Používejte soubor sidebar.php ve vaší šabloně. in /mnt/data/html/logmanager.cz/www/wp-includes/functions.php on line 5411
logo
© 2022 Sirwisa a. s. Všechna práva vyhrazena.