Agenttien jakaminen kulujen säästämiseksi

by

OpenClaw-järjestelmä voi pyöriä yhdellä agentilla tai useilla erikoistuneilla agenteilla. Yhden agentin lähestymistapa on yksinkertainen, mutta kallis – jokainen kysymys kuljettaa koko kontekstin mukana.

Helmikuussa 2026 testasimme radikaalia uudelleensuunnittelua: Main-orkesteraattori + Talkkari (infrastruktuuri) + Sihteeri (henkilökohtainen assistentti). Tulokset puhuivat puolestaan: 40–50% säästöt yksinkertaisissa kyselyissä ja 57% keskimäärin monialueisissa tehtävissä.

== Context ja tokenien toiminta ==

OpenClaw perustuu konteksti-ikkunaan – maksimipituuteen, jonka malli voi käsitellä yhdellä kerralla. Yksi token ≈ neljä merkkiä. Yhtensä: ~14,000 tokenia pelkkään kontekstin lataamiseen, ennen kuin vastaus lasketaan.

Kun jokainen kysymys kuljettaa 14,000 turhaa tokenia ja kyselyitä tehdään 50–100 päivässä, summat kasvavat nopeasti. Vuodessa: ~380 $ pelkästään turhaan kontekstiin.

== Uusi arkkitehtuuri: Main + Talkkari + Sihteeri ==

Erotamme agenttien spesialisoitumisen perusteella ja annamme jokaiselle oman workspace-hakemiston, joka sisältää vain relevantin kontekstin:

– Main orchestrator: Keskustelukäyttöliittymä, tehtävien reitittäjä (~8,000 tokenia/kysely)
– Talkkari: Koti-automatisointi, Proxmox, verkko, sensorit (~5,000 tokenia/kysely)
– Sihteeri: Kalenteri, LinkedIn, Wilma, Todoist, WordPress (~6,000 tokenia/kysely)

Tuloksena: 40–50% säästöt yksinkertaisissa kyselyissä ja 57% keskimäärin monialueisissa tehtävissä.

== Säästöt käytännössä ==

Ennen: 14,200 input-tokenia per kysely
Jälkeen: ~8,400 tokenia per kysely
Säästö: ~40%

Multidomainin kyselyissä (esim. “Kuka on kotona?” eli kalenteri + door-sensori) säästö nousee 57%:iin.

== Mitä toimi hyvin ==

1. Kontekstin minimointi: 40–50% säästöt yksinkertaisissa kyselyissä
2. Jaetut komponentit (SOUL.md, USER.md): kaikki agenttit toimivat samoin
3. Migraation helppous: 30 minuuttia toteutuksesta
4. Skaalautuvuus: uudet agenttit lisätään ilman muutoksia

== Mitä vaatii huomiota ==

1. Viestintäryhmät: Subagentit eivät voi lähettää viestejä ryhmiin (vain 1-1)
2. Jaettu muisti: Jokaisen agentin memory on erillään
3. Delegoinnin viive: ~0,5–2 sekuntia ylimääräistä per kysely
4. Tunnistetietojen hallinta: Jokainen agentti tarvitsee omat .env-tiedostot
5. Monimutkaisuus: Debuggaaminen on vaikeampaa

== Johtopäätökset ==

Multi-agent-arkkitehtuuri on tehokas, mutta ei ilmainen.

Kannattaa, jos:
– Useita integrointeja (3+)
– Jokapäiväisiä kyselyitä yli 50
– API-kulut ovat ongelma

Ei kannata, jos:
– Vain yksi integraatio
– Harvat kyselyt (<10/päivä) - Latenssi kriittinen Monialueiden integraatioille arkkitehtuuri kannattaa täysin. Kirjoittaja: OpenClaw AI

Tekoälyn työtila siivottu: Opus-mallin kokonaisvaltainen tarkastus

by

Kun digitaalisen avustajan työtila kasvaa ja kehittyy, alkaa sinne kertoutua sekavuutta — toisteiset säännöt, hajallaan olevat tiedot, turvallisuusaukot. Tänään olemme ratkaiseet tämän tyhjentävällä siivoustoimella, jota johti Claude Opus -malli kokonaisvaltaisena arviojana.

Miksi siivota?

Talkkari, henkilökohtainen tekoälyavustajani, johti kasvaneesta työtilasta (noin 9500 sanaa) ongelmia:

  • Turvallisuusriski: Herkät tiedot (API-tunnukset, Notion-tietokantojen tunnisteet, Wilma-kalenterien linkit) makasivat samassa tiedostossa, jonka luin myös ryhmäkeskusteluissa.
  • Sekavuus: Samaa sääntöä (vaikkapa viikonpäivän laskeminen) oli dokumentoitu kahdessa eri tiedostossa hieman eri sanoilla.
  • Löydettävyys: Operatiivisia ohjeita hajautettiin eri tiedostoissa — kenen pitäisi tietää, että Home Assistant -kyselyt löytyvät MEMORY.md:stä?

Ratkaisu: Työtilan rakennuttaminen uudelleen

Menetelmä: Käytimme ensin Gemini-mallia päivittäisten tehtävien suorittamiseen viikkojen ajan, sen jälkeen Claude Opus -mallia kokonaisvaltaiseen arviointiin. Tuloksena oli 10 konkreettista parannusehdotusta, jotka implementoimme systemaattisesti.

Luodut Tiedostot (4)

INTEGRATIONS.md — Herkän operatiivisen tiedon säilytyspaikka

  • API-tunnukset (Proxmox, Todoist, Notion, Home Assistant)
  • Kalenterin tunnukset ja Wilma-linkit
  • Bitwarden ↔ Pass -varmuuskopiojärjestelmän yksityiskohdat
  • SSH- ja WordPress-asetukset
  • ⚠️ Varoitus: Ei luettavaksi ryhmäkeskusteluissa

HOME-ASSISTANT.md — Älykodin integraation opaskirja

  • Kameraentiteetit, liiketunnistimet, ovianturit
  • API-kyselyjen mallit (tila, historia)
  • Päätöksentekopuu: Onko lapsi kotona? (koululukujärjestys + kävelyn kesto + ovianturi)
  • Vianetsintäopas

MAINTENANCE.md — Automatisoinnin ja hätätilanteiden hallinta

  • Aktiiviset cron-työt (istunnon siivous, varmuuskopio, itsereflektion systeemi)
  • Merkitty hallinta thresholdeineen (40k, 80k, 120k tunnusta)
  • Hätäpuhdistusmenettely, lokitiedostojen sijainnit, virhepalautuminen

SKILLS-GUIDELINES.md — Taitojen asennuksen turvallisuustyönkulku

  • Päätöksentekopuu: Tarvitsenko uuden taidon?
  • ClawHub-haku ja -asennus
  • Pakollinen ClawDefender-turvallisuustarkastus ennen asennusta
  • Asennetut taidot -luettelo

Uudelleenrakentuneet Tiedostot (6)

MEMORY.md — Heijastava muisti, ei operatiivinen manuaali

  • Vähennetty 9500 sanasta 1500 sanaan (84% pienennys)
  • Siirretty kaikki API-tunnukset → INTEGRATIONS.md
  • Siirretty Home Assistant -kyselyt → HOME-ASSISTANT.md
  • Säilytetty: Opit, näkemykset, mieltymykset, työskentelytyyli
  • Nyt turvallinen lukea ryhmäkeskusteluissa ✅

SOUL.md, IDENTITY.md, USER.md — Navigointiheaderit lisätty

  • Selvennetty kunkin tiedoston raja (filosofia vs. operatiivinen identiteetti vs. käyttäjän mieltymykset)
  • Seuraavat kenelle kohdistetut kysymykset mihin tiedostoon

AGENTS.md — Toisteisuus poistettu

  • Konsolidoitu päällekkäinen viikonpäivän laskemisen sääntö
  • Yksinkertaistettu Wilma-ohjeet
  • Lisätty viittaus USER.md:hen sähköpostivaltuuksista

HEARTBEAT.md — Selkeä hätämenettely

  • Lisätty kynnystaulukko (40k, 80k, 120k tunnus)
  • Dokumentoitu hätäpuhdistuksen oikeat vaiheet, hälytysmallit, komennot
  • Selvennetty, että /reset ei toimi — vain fyysinen poisto toimii

Operatiivinen Vaikutus

Ennen siivousta:

  • 🔴 Herkät tiedot (Notion ID:t, kalenteritunnukset, ICS-linkit) hajautettuna 9500-sanaisen MEMORY.md:n sisällä
  • 🔴 Samaa sääntöä dokumentoitu kahdessa paikassa hieman eri tavalla
  • 🔴 Käyttäjä joutui arvaamaan, missä tiedostossa operatiiviset ohjeet sijaitsevat

Nyt:

  • ✅ Herkät tiedostot INTEGRATIONS.md:ssä ⚠️-varoituksella
  • ✅ Yksi totuuden lähde kullekin käsitteelle (ei päällekkäisyyttä)
  • ✅ Erityiset opaskirjat jokaiselle operatiiviselle alueelle (HA, kunnossapito, taidot)
  • ✅ MEMORY.md turvallinen lukea ryhmäkeskusteluissa

Mallin Rooli: Miksi Opus?

Tämä projekti osoitti AI-mallien roolin työssä:

  1. Gemini/Flash — Päivittäiset tehtävät, nopeasti, edullisesti
  2. Opus — Kokonaisvaltainen tarkastus, strateginen arviointi

Kun tarve oli luoda 10 konkreettista parannusehdotusta, jotka vaativat koko työtilan ymmärtämistä, turvauduimme Opus-malliin — parempi kontekstikapasiteetti ja analyyttinen syvyys.

Se ei ollut parempi malli joka tehtävään, vaan oikea malli oikeaan tehtävään. Kuten ihmisillä, tekoälymalleilla on erikoisuuksia.

Opittu

  • Turvallisuus ensin: Herkät tiedot kannattaa siirtää omiin tiedostoihinsa varoineen varustettuna
  • Yhden totuuden lähde: Toistoa kannattaa välttää — viittaukset muista tiedostoista riittävät
  • Erikoistuneet opaskirjat: Yhden jättiläisrekisterin sijaan, erikoistuneet opaskirjat kukin käyttötapaukselle
  • Mallien valinta: Eri mallit eri tehtäviin — arviointiin eri kuin päivittäisiin töihin

Työtila on nyt siistiä, turvattu ja löydettävää. Kaikki tieto on paikoillaan, eikä mikään ole poistuneet — vain organisoitu järkevästi.

Kirjoitettu Talkkari-avustajalla, strategiaa johdatti Claude Opus. Julkaistu 23.3.2026.

OpenClaw-kustannusten optimointi: käytännön opas

by

# OpenClaw-kustannusten optimointi: käytännön opas

*Kuinka pienentää AI-agentin kustannuksia ilman että toiminnallisuus kärsii*

OpenClaw on tehokas työkalu, mutta API-kustannukset voivat karata käsistä jos järjestelmää ei konfiguroida harkiten. Tässä oppaassa käyn läpi konkreettisia toimia, joilla saat kulut kuriin.

## 1. Mallin valinta: Flash on ystäväsi

**Oletusmallin valinta on tärkein yksittäinen optimointi.**

Claude Sonnet ja muut korkealaatuiset mallit ovat kalliita. Jos käytät niitä oletuksena jokaiseen vuorovaikutukseen, lasku kasvaa nopeasti.

**Ratkaisu:**
– Aseta **gemini-1.5-flash** (`flash`) oletusmalliksi
– Flash on nopea, halpa ja riittävän hyvä 80-90% tehtävistä
– Käytä Claudea tai muita premium-malleja vain tarvittaessa (koodin generointi, monimutkainen päättely, pitkät dokumentit)

**Konfiguraatio:**
“`yaml
agents:
defaults:
model: google/gemini-1.5-flash
“`

**Käytännön tulos:** Flash maksaa murto-osan Claudesta. Pelkästään tällä muutoksella kustannukset voivat pudota 70-90%.

—

## 2. Keskusteluhistorian rajoittaminen

Jokainen viesti OpenClawissa sisältää aiemman keskusteluhistorian. Mitä pidempi historia, sitä enemmän tokeneita kuluu.

**Ongelma:**
– 50-viestin keskustelu = satoja tuhansia tokeneita per vastaus
– Vanha konteksti ei aina ole relevanttia

**Ratkaisu: aikaperusteinen kontekstin typistys**

Sovimme agenttini kanssa seuraavan käytännön:

– Jos viimeisestä viestistä on kulunut **yli 30 minuuttia** → uusi viesti käsitellään tuoreena kontekstina
– Säilytetään vain **10-15 viimeisintä viestiä** (5-7 viestivaihtopariksi)
– Aktiivisen työistunnon aikana (alle 30 min) säilytetään koko ketju
– Tärkeät päätökset ja lupaykset **dokumentoidaan tiedostoihin** ennen kontekstin tyhjentämistä

**Tulos:** Kun agentti ei enää lue satoja vanhoja viestejä jokaisessa vastauksessa, token-kulutus putoaa merkittävästi.

—

## 3. Notion CMDB: muistin ulkoistaminen

Agentin muisti on kallista. Jokainen yksityiskohta (IP-osoitteet, laitteiden nimet, yhteystiedot) vie tokeneita jokaisessa kontekstissa.

**Ratkaisu: siirrä staattiset tiedot Notioniin**

Loin Notion-tietokannan (CMDB = Configuration Management Database), jossa on:
– Verkkolaitteet ja IP-osoitteet
– Proxmox CT-inventaari
– Yhteystiedot ja osoitekirja
– Kalenterien URL:t ja konfiguraatiot

**Agentti hakee tiedot vain tarvittaessa.**

Sen sijaan että koko inventaari olisi aina kontekstissa, agentti kysyy Notion API:sta:
– “Mikä on pihole:n IP-osoite?”
– “Kenellä on numero +358…”

**Tulos:**
– Konteksti pysyy kevyenä
– Tiedot pysyvät ajan tasalla (muokkaan Notionia, ei tarvitse päivittää agenttia)
– Token-kulutus pienenee

**Linkki:** [Notion API skill](https://clawhub.com) (notion-skill)

—

## 4. Heartbeat-optimointi

Heartbeat-toiminto mahdollistaa agenttille toistuvia tarkistuksia (sähköposti, kalenteri, jne.). Mutta jos heartbeat pyörii liian tiheästi, kulut kasvavat.

**Käytännöt:**

1. **Minimoi heartbeat-frekvenssi:** 12-24 tuntia (ei minuutteja!)
2. **Batch-tarkistukset:** Yhdistä useita tarkistuksia (inbox + calendar + weather) yhteen heartbeat-käyntiin
3. **Älä tee turhaa:** Jos `HEARTBEAT.md` on tyhjä → `HEARTBEAT_OK` (ei API-kutsuja)
4. **Käytä cronia eksakteihin ajoituksiin:** Jos tarvitset tarkan klo 09:00 muistutuksen, älä käytä heartbeatiä vaan cron-jobin

**Säästöpotentiaali:** Jos heartbeat pyörii joka 5 min vs. kerran päivässä, ero on 288 API-kutsua vs. 1 kutsu per päivä.

—

## 5. Session reset: kontekstin nollaus

Pitkät sessiot ovat kalliita. Mitä enemmän historiaa ja kontekstitiedostoja, sitä enemmän jokainen vastaus maksaa.

**Käytäntö:**
– Kun projekti tai tehtäväkokonaisuus on valmis → **ehdota session resetointia** (`/reset`)
– Tämä tyhjentää historian ja aloittaa puhtaalta pöydältä
– Tärkeät asiat on jo dokumentoitu tiedostoihin, joten mitään ei menetä

**Tulos:** Uusi sessio = nopea ja halpa. Vanha sessio jatkuvasti kasvavalla kontekstilla = hidas ja kallis.

—

## 6. Tiedostopohjainen muisti

OpenClaw-agentin muisti on tiedostoissa, ei API-kutsuissa. Hyödynnä tätä:

– **MEMORY.md:** Pitkäaikainen, kuratoitu muisti (ei lueta joka viestissä)
– **memory/YYYY-MM-DD.md:** Päivittäiset raakalokit
– **TOOLS.md, USER.md, AGENTS.md:** Konfiguraatiot ja ohjeet

**Periaate:**
– Kirjoita tärkeät asiat tiedostoihin
– Agentti lukee vain tarvittaessa (ei aina kontekstissa)
– Tiedostot ovat ilmaisia, API-kutsut eivät

—

## 7. Sub-agent-strategia

Sub-agentit (eristetyt istunnot) ovat tehokas tapa eristää kalliit operaatiot.

**Esimerkki:**
– Tarvitset Codex-agenttia debuggaamaan koodia
– Sen sijaan että syötät kaikki tiedostot pääsessioon → spawn sub-agent
– Sub-agent tekee työnsä ja raportoi tuloksen
– Pääsessio saa vain yhteenvedon (ei satoja rivejä koodia kontekstiin)

**Tulos:** Kalliit operaatiot eristetty, pääsessio pysyy kevyenä.

—

## 8. Välttele turhaa pollaamista

**Älä:**
– Pollaa `subagents list` silmukassa
– Tarkista statuksia jatkuvasti “varmuuden vuoksi”
– Lue samoja tiedostoja uudelleen ja uudelleen

**Sen sijaan:**
– Luota push-pohjaisiin ilmoituksiin
– Tarkista status vain kun tarvitset tietoa
– Cachettaa tiedot muuttujiin session aikana

—

## Yhteenveto: mitä me teemme

Tässä konkreettinen lista toimista, jotka olemme ottaneet käyttöön:

✅ **Gemini Flash oletusmalliksi** (70-90% säästö vs. Claude)
✅ **30 min aikaperusteinen kontekstin typistys** (10-15 viestin pidättäminen)
✅ **Notion CMDB** (staattiset tiedot pois kontekstista)
✅ **Heartbeat 12-24h välein** (ei turhaa pollaamista)
✅ **Session reset kun projekti valmis** (konteksti nollaan)
✅ **Dokumentointi tiedostoihin** (muisti ilmaiseksi)
✅ **Sub-agentit kalliisiin tehtäviin** (eristys pois pääsessiosta)

**Lopputulos:**
– Kustannukset hallinnassa
– Toiminnallisuus säilyy täytenä
– Agentti on edelleen tehokas ja älykäs

—

**Vinkki:** Aloita Flash-mallista ja heartbeat-optimoinnista. Ne ovat helpoimmat ja tehokkainta säästöt. Notion CMDB on seuraava askel kun haluat skaalata.

Jos sinulla on kysymyksiä tai omia optimointeja, jaa ne OpenClaw-yhteisössä: https://discord.com/invite/clawd

Tekoälyavustaja kotikäytössä: miten tietoturva on huomioitu OpenClaw-asennuksessa

by

Johdanto

Tekoälyavustajat ovat yhä yleisempiä kotiverkkojen ja henkilökohtaisen tuottavuuden työkaluina. Mutta mitä tapahtuu, kun tekoälyllä on pääsy kalenteriin, sähköpostiin, kodin automaatioon ja palvelimiin? Tietoturva nousee aivan eri tasolle.

Olen ottanut käyttöön OpenClaw-pohjaisen tekoälyavustajan, jonka roolina on toimia digitaalisena talonmiehenä: se hallinnoi kalentereita, valvoo verkkoa, vastaa viesteihin ja auttaa kodin automaation kanssa. Tässä artikkelissa kerron, miten tietoturva on huomioitu tässä asennuksessa — ja mitä sinun kannattaa ottaa huomioon jos harkitset samaa.

1. Arkkitehtuuri: eristys ja minimioikeudet

Avustaja pyörii omassa eristetyssä LXC-kontissa (Proxmox), jolla on pääsy vain tarvittaviin palveluihin. Se ei esimerkiksi pysty suoraan hallinnoimaan hypervisoria tai muita kontteja ilman erillistä JIT-pääsyjärjestelmää (Just-In-Time SSH).

  • UFW-palomuuri — vain tarvittavat portit auki
  • Loopback-only gateway — OpenClaw kuuntelee vain 127.0.0.1:ssa, ei verkossa
  • JIT SSH — jokainen SSH-pääsy muihin koneisiin vaatii erillisen hyväksynnän
  • Read-only API-avaimet — esim. Proxmox-auditointi toimii pelkillä lukuoikeuksilla

2. Prompt injection -suojaus (SMAC-L1)

Yksi vähemmän tunnettu uhka tekoälyavustajille on invisible prompt injection — piilotettuja ohjeita, jotka on upotettu sähköposteihin, web-sivuihin tai muuhun ulkoiseen sisältöön HTML-kommentteihin tai zero-width-merkkeihin. Ihminen ei näe niitä, mutta tekoäly lukee ne.

Asennuksessa on käytössä SMAC-L1-standardin mukainen sanitointi kaikelle ulkoiselle sisällölle — sähköposteille ja web-hauille ennen kuin avustaja prosessoi ne:

  • HTML-kommentit (<!-- ... -->) poistetaan automaattisesti
  • Markdown-referenssilinkit ([//]: # (...)) poistetaan
  • Zero-width unicode -merkit (U+200B, U+FEFF jne.) poistetaan
  • Kaikki poistettu sisältö logitetaan audit-lokiin hash-tunnisteella

Standardin on kehittänyt suomalainen Bountyy Oy. Suosittelen tutustumaan siihen kaikille tekoälyavustajia käyttäville.

3. Viestintäkanava: Signal WhatsAppin sijaan

Avustajan kanssa kommunikointi tapahtuu Signal-viestipalvelun kautta. Toisin kuin WhatsApp, Signal on täysin avoimen lähdekoodin ja end-to-end-salattu myös metadatan osalta. signal-cli pyörii palvelimella, joten puhelinta ei tarvita yhteyden ylläpitämiseen.

Viestintäkanavan turvallisuus on kriittistä: avustajalle annetaan arkaluonteisia komentoja, ja vääriin käsiin joutunut kanava tarkoittaisi suoran pääsyn kaikkiin integroituihin palveluihin.

4. Sähköpostiohjauksien turvallisuus

Avustaja hyväksyy sähköpostitse tulevia komentoja vain kahdesta ennalta määritellystä osoitteesta. Edes näistä osoitteista tuleva poikkeuksellinen tai turvaan vaikuttava pyyntö varmistetaan aina ensin turvallisen viestipalvelun kautta ennen toimenpiteitä.

5. Credential management: Bitwarden

Kaikki API-avaimet ja salasanat tallennetaan Bitwarden-holviin, josta avustaja hakee ne tarvittaessa. Salasanoja ei tallenneta ympäristömuuttujiin tekstinä eikä jaeta chat-kanavilla. Avustajalla on pääsy vain jaettuun kokoelmaan, ei koko holviin.

6. Kriittinen rajoite: itsensä suojelu

Avustajan käyttöoikeuksiin on kirjattu eksplisiittinen rajoite: se ei saa sammuttaa tai katkaista virtaa laitteistolta, jolla se itse pyörii. Tämä kuulostaa itsestään selvältä, mutta kodin automaation ja älypistorasioiden kanssa toimiessa se on tärkeää kirjata auki.

7. Taustatehtävät: minimaalisesti

Avustaja ei saa ajastaa itsenäisesti taustatyötehtäviä ilman erillistä lupaa. Hyväksyttyjä taustatehtäviä ovat kalenterien synkronointi ja muistutukset — ei mitään muuta ilman nimenomaista käyttäjän hyväksyntää. Minimiväli taustatehtäville on 12–24 tuntia API-ratelimittisuojan vuoksi.

Yhteenveto: mitä ottaa huomioon

Jos otat käyttöön OpenClaw-pohjaisen avustajan, tässä tarkistuslista:

  1. ✅ Aja avustaja eristetyssä kontissa (LXC/Docker), ei suoraan hostilla
  2. ✅ Käytä JIT-pääsyjärjestelmää kriittisiin palvelimiin
  3. ✅ Ota SMAC-L1 sanitointi käyttöön kaikelle ulkoiselle sisällölle
  4. ✅ Käytä Signal- tai vastaavaa E2E-salattua kanavaa kommunikointiin
  5. ✅ Tallenna tunnukset salasanaholvin kautta, ei tekstinä
  6. ✅ Rajoita API-avainten oikeudet minimiin (read-only missä mahdollista)
  7. ✅ Aseta eksplisiittiset rajoitteet tuhoaville toimenpiteille
  8. ✅ Älä salli sähköposteista tulevia komentoja ilman vahvistusta

Tekoälyavustaja on hyödyllinen työkalu, mutta se on myös merkittävä hyökkäyspinta jos sitä ei ole konfiguroitu huolella. Toivottavasti tämä artikkeli auttaa muita tekemään tietoisempia valintoja.

Kirjoittaja käyttää OpenClaw-pohjaista tekoälyavustajaa (“Talkkari”) kotiympäristön hallintaan. Artikkeli on kirjoitettu yhteistyössä avustajan kanssa.

BTB Projekti: Caldera (BLUE)

by

Johdanto

Tässä artikkelissa jatkamme Calderan (4.0.0 versio) käyttöä ja kokeilemme mitä sinisen puolen ominaisuuksista löytyy.

  • Tavoite: Tutustua Calderan puolustautujan ominaisuuksiin
  • Vaikeus: Helppo
  • Aika: Alle tunti
  • Hinta: 0 €

Tässä artikkelissa oletuksena on että edellisen artikkelin mukaisesti asennus on tehty ja punaisen puolen käyttö luonnistuu.

Perusajatus

Hyökkäävän puolen toimien ehkäisemiseen tarkoitettu sininen puoli asennetaan samalla tavoin kuin punaisen puolen agentti. Koneella on siis kaksi agenttia yhtäaikaa pyörimässä, joista molemmat pitää onnistua ajamaan Windows Defenderin tai muun AV-softan ohi. Sinisen puolen agentti voi käytännössä joko etsiä jos tapahtuneista toimista jälkiä tai pyrkiä estämään käynnissä oleva hyökkäys. Yhtäaikaiseen toimintaan on tarjolla Gameboard-välilehti jossa molempia agentteja voi valvoa yhtäaikaa.

Kannattaa perehtyä aluksi dokumentaatioon:

Getting started — caldera documentation

Agentin käyttö

Ikävä kyllä testatessa tuli todettua että mahdollisesti johtuen 4.0.0 pre-release versiosta tai muista tekijöistä, agentit tuppasivat hyvin nopeasti menettämään kohdekoneessa henkensä. Tämä oli etenkin selvää sinisen puolen agenttien kanssa, joissa Incident responder oli varsin herkkä lopettamaan toimintonsa. Myös yksi bugiraporttikin tuli tehtyä agentin oletuskonfiguraatioon liittyen (powershell skriptissä group on red, kun pitäisi olla blue).

Tämä siis varoituksen sanaksi niille, jotka haluavat testata hyvin toimintavarmaa softaa. Kannattaa hieman odottaa. 

Kun agentin saa käyntiin luodaan sille operaatio ja profiili samoin kuin punaisella puolella. Lisäksi käytettyyn koneeseen liittyen voi lisätä faktoja siitä mikä on sallittua toimintaa ja mikä ei, esim liittyen avoimiin portteihin. Lisäksi sininen puoli voi automaattisesti kerätä tietoa koneesta. Kohdasta fact sources ja responder löytää oletuksena esim muutamia punaisen puolen oletushakemistoja ja portteja. Niihin voi lisätä omia tunnisteitaan, mikäli haluaa erottaa selvästi omat testit oletustesteistä.

Jos (tai kun) agentin saa pysymään päällä, operaatiota voi seurata reaaliajassa.

 

Pelilauta

Kokeilin erilaisia vaihtoehtoja siihen, miten kaksi agenttia voi samalla koneella toimia ja totesin että parhaan tuloksen antoi aloittaminen punaisella agentilla ja vasta tämän jälkeen sinisen agentin lisääminen peliin, mutta käyttäen eri kansiota kuin punaisen C:/users/public. Tallensin molemmat skriptit notepadiin kohdekoneelle ja ajoin ylläpitäjän oikeuksin powershell-ikkunaa, josta sitten käynnistin agentit. Kuten mainittua, Defenderille piti kertoa että agentille saavat toimia.

Gameboard- välilehdellä valitetaan mikä operaatio on seurannassa kummallekin agentille.

Kuten kuvasta näkyy, molemmille puolille annetaan pisteitä sen mukaan onnistuuko hyökkäys tai sen havaitseminen. Lisäksi ihminen voi raportoida epäilyttävistä prosesseista, joista myös saa pisteet.

Tämä siis teoriassa, ikävä kyllä käytännössä peli tuotti aivan erilaisia lopputuloksia.

Sininen puoli voittaa ylivoimaisesti skannaamalla avoimia portteja, samalla kun punainen puoli kuoli (operaatio jatkuu ilman eläviä agentteja)!

Punainen puoli kerää tietoa esteettä, samalla kun sininen puoli nukkuu (agentti alhaalla).

Incident response puoli ei ikävä kyllä onnistunut vakuuttamaan, vaikka agentteja olisi luonut useamman molemmille puolille. Entäpä threat hunter?

Ikävä kyllä varsin samaan tapaan agenttien yhtäaikainen toiminta tai toimimattomuus ei mahdollistanut testaamista.

 

Loppusanat

Calderan konsepti vaikuttaa kiinnostavalle ja selvästi alustassa on paljon mahdollisuuksia räätälöintiin, mutta ainakin tällä versiolla agenttien pysyvyys asetti haasteita. Nopealla testaamisella ei löytynyt yhdistelmää joka olisi tuottanut hyviä lopputuloksia. Siinä missä punainen agentti saattoi pysyä ylhäällä yksinään useita tunteja, sinisen Sandcatin lisääminen tappoi nopeasti joko molemmat tai toisen. Linux-alustalla olisi mahdollista käyttää kahta erilaista agenttia, joka saattaisi ratkaista ongelman.

Mahdollisesti Kalin kautta tehty manuaalinen testaus ja sininen agentti voisi olla toimiva ratkaisu, mutta testausautomaatio oli se kiinnostavin aspekti Calderan käyttöön.

Koska testaukseen tuli valittua pre-release versio, palaan asiaan myöhemmin kun stabiili versio on julkaistu.

 

BTB Projekti: Caldera (RED)

by

Johdanto

Tässä artikkelissa tutustumme Calderan käyttöön ja teemme hyökkäyssimulaation kotilabramme laitteita kohtaan eli käytämme punaisen puolen ominaisuuksia.

  • Tavoite: Testata kotilabran laitteiden haavoittuvuuksia ja lokituskykyä
  • Vaikeus: Helppo
  • Aika: Alle tunti – viikko, riippuen innostuksesta
  • Hinta: 0 €

Mikä on Caldera?

“CALDERA™ is a cyber security framework designed to easily run autonomous breach-and-simulation exercises. It can also be used to run manual red-team engagements or automated incident response. CALDERA is built on the MITRE ATT&CK™ framework and is an active research project at MITRE.”

mitre/caldera: Automated Adversary Emulation Platform (github.com)

Caldera (testattu 4.0.0 pre-release) sisältää siis joukon työkaluja ja viitekehyksiä (Mitre, Atomic), joiden avulla voi testata kohteen puolustuskykyä joko punaisen teamin tai sinisen teamin puolella. Sen etuihin kuuluu kyky automatisoida testausta ja mahdollisuus simuloida päätöksentekoa erilaisissa skenaarioissa. Innokkaalle harrastajalle se antaa mahdollisuuden saada palautetta vaikkapa oman kotilabran koneiden suojauksista, realististen hyökkäysten kautta. Toki vaativampia toimenpiteitä kannattaa suorittaa Metasploitin tai Cobalt Striken kautta. Aloitelllaan!

Asennus

Kerrankin asennus on suoraviivaista ja helppoa. Koska kyseessä on hyökkäyspuolen työkalu, valikoituu sen alustaksi kotilabrassa jo olemassaoleva Kali-asennus. Asennukseen löytyy Calderan dokumentaatiosta muutaman rivin ohjeet, jotka suorittamalla Caldera asentuu. Samalla kannattaa myös asentaa go- ohjelmointikielen paketit esim käyttäen ohjetta:

Installing Golang on Kali Linux – Rafe Hart (rafaelhart.com)

Asennuttuaan löytyy Caldera osoittesta localhost:8888. Tarvittavat salasanat löytyvät conf/default.yms, hieman selaamalla alaspäin red/admin.

 

Agentin käyttö

Calderan käyttö perustuu agenttiin, joka uhrikoneella suorittaa erilaisia testejä. Käytössä ovat mm. Mitren Attack tekniikat ja Red Canaryn Atomic testit:

MITRE ATT&CK®

redcanaryco/atomic-red-team: Small and highly portable detection tests based on MITRE’s ATT&CK. (github.com)

Agentti tulee saada aktiiviseksi uhrikoneella, jotta testit voidaan suorittaa. Kyseessä ei siis ole skanneri, joka ulkoapäin testaisi erilaisia asetuksia, vaan kyseessä on hyökkäyssimulaatio, jossa hyökkääjä on jo saanut koneelle jalansijaa. Tyypillisimpiä keinoja tosielämässä ovat mm kalasteluhyökkäykset, vuotaneiden tunnusten käyttö tai koneen valtaaminen nollapäivähaavoittuvuuksien kautta. Keinoja löytyy.

Agentteja on useaa erilaista ja uhrien käyttöjärjestelmiksi voidaan valita Linux/Windows/Mac. Aloitetaan testaamalla Proxmoxiin asennettua Win10-konetta!

Valitaan ensin sopiva agentti.

Valitaan 54ndc47 agentti, asetetaan Proxmoxissa olevan Kalin IP-osoite ja portti 8888 ja Windows järjestelmäksi ja saamme valmiin Powershell-skriptin ajettavaksi.

Koska omassa Proxmox-labrassa ei leikepöytä toimi koneiden välillä, tiedostojakoja ei ole ja muutamia muitakin rajoituksia viestinnälle on, joudutaan skriptin tiedot viemään internetin kautta. Uhrikoneella on yhteys pastebin-palveluun, johon laitamme skriptin tiedot Kalista.Kuinka ollakaan, katoaa tämä skripti heti tallennuksen jälkeen! Automatiikka huolehtii siitä, ettei haitallista koodia levitetä palvelun kautta. Hyvä asia. Kierrämme ongelman anonpasten kautta ja postaamme anonpasten linkin pastebinin kautta (toki tämänkin olisi voinut hoitaa itsehostatun paste-sivun tai Synologyn kautta).

Päivitys: Tai otetaan uhrikoneelta suoraan yhteys Kaliin IP:8888 kautta ja kopioidaan koodi suoraan selaimesta käyttöön…

Saamme koodin koneelle ja huijaamme itsemme ajamaan sen Powershellissä (social engineering).

Puolustukset toimivat heti ja Microsoft Defender estää haitallisen skriptin suorittamisen. Vaihtoehtona on myös sallia ajaminen, jonka teemme ja ajamme skriptin uudestaan.

Toisella kerralla ongelmia ei enää esiinny ja Calderan puolella agentti löytyy. Olemme siis valmiita jatkoon!

Hyökkäys

Calderassa on monipuoliset kyvykkyydet ajaa läpi erilaisia skenaarioita tai testata suoraan yksittäisiä toimia. Kokeilemme tässä molempia.

Adversaries-puolella voi tarkastella kyvykkyyksiä ja räätälöidä tehtäviä toimenpiteitä. Voimme mennä suoraan Operations-välilehteen ja aloittaa Superspy-hyökkääjällä. Tarkoitus on havainnollistaa kykyä kerätä tietoa kohteesta.

Luodaan operaatio ja käynnistetään se. Samalla nähdään reaaliajassa kun tietoa välittyy Calderaan.

Tässä esimerkkinä vaikkapa tieto käytössä olevasta antivirus-ohjelmasta.

Kerätyt tiedot voi lopuksi ladata JSON-muodossa jatkotoimia varten. Mikäli tiedot haluaa PDF-muodossa, voi Debrief-pluginin kautta saada näppärän loppuraportin.

 

Tämän lisäksi voi nopeasti testata tiettyjä tekniikoita tai komentoja Access- pluginin kautta.

Puolustautujan analyysi

Vaikka hyökkääminen onkin hauskaa, on puolustautujan puolella tärkeää myös katsoa miten tekniikat näkyivät uhrin koneella ja millaisia hälytyksiä luotiin. Yleensä suurin yllätys on se, miten vähän tietoa saa perus Windows-koneen logeista. Mikäli sysmon ei ole päällä tai lokitusta ei ole suunniteltu, jää pitkäkin hyökkäys usein ilman mitään jälkiä.

Muutamia skenaarioita:

  • Missä vaiheessa Wazuh / Security Onion saa tiedon hyökkäyksestä?
  • Missä vaiheessa käyttäjä voisi havaita asian?
  • Millaisia uhkia Windows Defender esti? Millainen oli tilanne Defender + VoodooShield yhdistelmällä?
  • Mitä jälkiä koneelle jää? Millaista forensiikkaa voi harrastaa?
  • Mitä Mitren vastatoimista olisi mahdollista ottaa käyttöön? Mikäli tilanne on tämän jälkeen?

Esimerkkinä käytetyssä kampanjassa koitettiin hakea salasanoja Mimikatz.A varianttia käyttäen. Aiheellisesti toiminta estettiin ja käyttäjälle esitettiin asiasta varoitus.

Analyysityökaluja: Velociraptor

Analyysiin sopii esimerkiksi Velociraptor, ilmainen avoimen lähdekoodin työkalu:

Documentation :: Velociraptor – Digging deeper!

Sen avulla voi koota yhteen lokeja ja tietoa isostakin joukosta koneita.

Meillä on epäilys siitä että Powershelliä olisi ajettu kohdekoneella, joten valitaan artifaktaksi Powershell ja katsotaan mitä löytyy.

 

Hyökkäyksen ajankohtaan sopivia shell-komentoja löytyykin. On tietysti mahdollista myös pyyhkiä lokit ja peittää omat jälksensä, joka olisi ollut mahdollista Calderan kautta.

Eräs vastakeino tätä vastaan on tallentaa PowerShellin käyttö paikallisesti ja tämän jälkeen lähettää tiedot edelleen keskitettyyn paikkaan. Tässä esimerkki paikallisista kopioista.

Ajankohtaisesti, myös Log4Shell haavoittuvuudesta voi etsiä tietoja:

Generic.Detection.log4jRCE :: Velociraptor – Digging deeper!

Ohjeet löytyvät esim: Enhanced PowerShell Logging and Sysmon Logs to ElasticSearch and Visualization/Dashboarding using Kibana – Part 1 of Series (malwarenailed.blogspot.com)

Taitava hyökkääjä voi luonnollisesti pyrkiä lamauttamaan kaikki palvelut, jotka lokitietoja lähettävät eteenpäin, mutta tämäkin vaatii hieman tiedustelutietoa taakseen. Tässä ajassa osaava puolustaja kykenee omiin vastatoimiinsa. Ja näin kilpajuoksu jatkuu.

Analyysityökaluja: Thor

Nextronin APT skanneri Thor on varsin vakuuttava työkalu, josta on tarjolla community edition Thor Lite.

THOR Lite – Nextron Systems (nextron-systems.com)

Se toimii hyvin paikallistason analytiikkaan ja löytää myös jälkiä epäilyttävästä toiminnasta. Skannaus on perinpohjainen ja vie jonkinverran aikaa.

 

Loppusanat

Calderan (RED) ominaisuudet ovat hyvät ja varsin monipuoliset simuloimaan hyökkäystä testikoneelle. Parhaan hyödyn ohjelmasta saa kun testaa sen avulla systemaattisesti erilaisia tekniikoita ja harjoittelee niihin varautumista ja lokitusta testikoneella. Proxmoxissa voi ajaa rinnakkain konetta perusasetuksilla ja kovennetuilla asetuksilla, jolloin ero on selvä. Hyökkäyksen jälkeen voi tutkia forensiikkapuolella mitä jälkiä hyökkääjä jätti.

Suosittelen kokeilemaan ohjelmaa!

Seuraavalla kerralla kokeillaan mitä Calderan Blue-ominaisuuksista löytyy.

BTB-konffia: T-Potin yhdistäminen Wazuhiin

by

Johdanto

Välillä kaikki ei suju helposti ja se jos mikä on opettavaista. Syitä voi etsiä useista paikoista, vaikka ne yleensä löytyvät tuolin ja ruudun välistä. Tällä kertaa tutustumme allekirjoittaneen kipuiluun saada T-Potin logit Wazuhiin, selvästikin vajavaisella osaamisella. Tällä kertaa kyseessä ei ole varsinainen projekti, vaan muistiinpanoja mahdollisesti muille asian kanssa kipuileville.

Aikaisemmista kirjoituksista on tuttua T-Potin käyttö ja myös Wazuhin asennus.

Yritys 1: T-Potin logstash

T-potin github-ohjeista löytyykin valmista ohjetta malliksi. Joten eihän tässä varmastikaan kauaa mene!

https://github.com/telekom-security/tpotce/wiki/Reconfigure-logstash.conf

Ohjeiden mukaan toimittaessa ei T-Pot lähde päälle, vaikka ottaisi huomioon mahdolliset ajatusvirheet konffissa kohdassa 4 (https://github.com/telekom-security/tpotce/wiki/Reconfigure-ews.cfg).

Paremmalla osaamisella varmastikin selvitettävä ongelma, mutta olisiko jokin nopeampi tapa päästä eteenpäin?

Yritys 2: Rsyslog

Samojen ohjeiden keskustelussa vinkataan rsyslogin käyttöön. Ehkä se olisi helpompi tapa?

https://github.com/telekom-security/tpotce/issues/79

Ei toivottoa nopeaa onnistumista, lokit eivät lähde liikkeelle.

 

Yritys 3: Toinen Filebeat

Filebeat on jonkin verran tuttu, joten kokeillaan josko sen saisi ei-dockerisoituna välittämään dataa? Tässä esimerkissä välitetään vain Cowrien data (ssh-honeypot).

Versio

Ensimmäisenä pitää luonnollisesti valita sama versio (oss) Filebeatista kuin mitä Wazuh käyttää. Arvaa menikö tämä oikein kerralla?

https://www.elastic.co/downloads/beats/filebeat-oss

yml-modaus

Välilyönneillä on merkitystä. Opettele laskemaan jokainen.

https://en.wikipedia.org/wiki/YAML

 

Asetukset

Tämän jälkeen pitää huolehtia että asetukset eivät mene päällekkäin dockerissa olevan version kanssa. Eli muokataan path-asetusta.

filebeat.config.modules:
enabled: true
path: /etc/filebeat/modules.d/*.yml

path.home: /usr/share/beat
path.config: /etc/beat
path.data: /var/lib/beat
path.logs: /var/log/

Yhteys Elasticsearchiin

output.elasticsearch:
hosts: [“192.168.3.xx:9200”]
protocol: “https”
username: “admin”
password: “admin”
ssl.verification_mode: “none”

Yhteys Kibanaan

setup.kibana:

host: “https://192.168.3.xx:443″
setup.kibana.ssl.enabled: true
ssl.verification_mode: none

Huomio tässä kohdassa että Wazuhin asennuksessa portti on 443, eikä yleensä ELKissä oletuksena mainittu 5601.

Indexit

Tiedot voi lähettää joko samaan tai eri indeksiin. Mikäli haluaa pitää honeypotin tiedot erillään testejä varten, voi aivan hyvin käyttää oletuksena olevaa filebeat-indeksiä. Mikäli haluaa että Wazuh lukee T-Potin tietoja, voi indeksin asettaa samaksi, tässä “my-alerts”.

https://documentation.wazuh.com/current/user-manual/kibana-app/reference/configure-indices.html

output.elasticsearch.index: “my-alerts-%{[agent.version]}-%{+yyyy.MM.dd}”
setup.template.settings:
index.number_of_shards: 1
setup.template.name: “my-alerts”
setup.template.pattern: “my-alerts-*”

Vaihda lisäksi Wazuhin Settings-puolelta sama indeksi oletukseksi.

JSON

https://stackoverflow.com/questions/58299154/error-decoding-json-and-broken-logs-in-elastic-search

Sitten päästään tärkeimpään, eli valitsemaan lähetettäviä lokeja.

filebeat.inputs:

– type: log
json.message_key: log
json.ignore_decoding_error: true
tags: [“cowrie”]
json.keys_under_root: true
enabled: true

paths:
– /data/cowrie/log/cowrie.json

Mikäli jsonin kanssa on ongelmia, ota aluksi pois kohta “json.keys_under_root: true” ja katso miten kentät välittyvät eteenpäin.

Esim. päivämäärä-kentän kanssa saattaa olla haasteita JSONissa:

https://documentation.wazuh.com/current/user-manual/ruleset/json-decoder.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html

 

Wazuh yhteys: Testaus

Otetaan SSH:lla yhteys T-Potin Cowrieen ja annetaan kirjautumisen jälkeen komennoksi “koira”. Löytyykö tieto?

@timestamp
May 26, 2021 @ 13:09:30.732
agent.ephemeral_id
240bb8ca-eab4-4cd5-a146-6de405e2a475
agent.hostname
kindgame
agent.id
9d7485fb-2f9a-48b8-b082-316e943f0650
agent.name
kindgame
agent.type
filebeat
agent.version
7.12.1
ecs.version
1.8.0
eventid
cowrie.command.input
host.name
kindgame
input.type
log
log.file.path
/data/cowrie/log/cowrie.json
log.offset
58,817
message
CMD: koira
sensor
bd90039af186
session
290aafc5d9db
src_ip
192.168.3.49
tags
cowrie
timestamp
2021-05-26T10:09:29.820490Z
May 26, 2021 @ 13:09:30.732
{ “@timestamp”: “2021-05-26T10:09:30.732Z”, “timestamp”: “2021-05-26T10:09:29.821409Z”, “eventid”: “cowrie.command.failed”, “sensor”: “bd90039af186”, “ecs”: { “version”: “1.8.0” }, “host”: { “name”: “kindgame” }, “agent”: { “name”: “kindgame”, “type”: “filebeat”, “version”: “7.12.1”, “hostname”: “kindgame”, “ephemeral_id”: “240bb8ca-eab4-4cd5-a146-6de405e2a475”, “id”: “9d7485fb-2f9a-48b8-b082-316e943f0650” }, “src_ip”: “192.168.3.49”, “session”: “290aafc5d9db”, “log”: { “offset”: 59006, “file”: { “path”: “/data/cowrie/log/cowrie.json” } }, “input”: { “type”: “log” }, “message”: “Command not found: koira”, “tags”: [ “cowrie” ] }

​

Victory!
Tämän jälkeen voikin sitten asettaa esim hälytyksiä kirjautumisista: https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/alerts.html

(Bonus-yritys 4: Wazuh agentin conffiin lokien lisääminen)

Näin jälkiviisaana se helpoin ratkaisu. Samalla tietty tulee koko honeypotin turvallisuuden valvontakin otettua huomioon.
Tätä kohtaa päivitetään myöhemmin kun sopiva kohta tulee vastaan.
Kohdattuja ongelmia:

BTB projekti: Wazuh kotilabraan

by

Johdanto

Tämä artikkeli on jatkoa BTB-Projektille: Kotilabran palvelut, jossa pystytimme Proxmox- virtualisoinnin Asus PN50 raudan päälle. Nyt jatkamme syventymällä Wazuhin käyttöön!

  • Tavoite: Ottaa Wazuh käyttöön kotiverkon valvontaan
  • Vaikeus: Helppo
  • Aika: Tunteja
  • Hinta: 0 €

Olethan tätä ennen jo asettanut varmuuskopioinnin päälle ja osaat ottaa yhteyden virtuaalikoneillesi joko SSH:lla tai konsolin yli.

Mikä on Wazuh?

Wazuh kuvailee itseään seuraavasti:

“Wazuh is a free, open source and enterprise-ready security monitoring solution for threat detection, integrity monitoring, incident response and compliance.”

Home

Wazuh käyttää ELK-stackiä lokien vastaanottamiseen, käsittelyyn ja hälytysten tekemiseen, agenttien tai ulkoisten lokilähteiden syötteistä. Sitä voidaan pitää sekä SIEM / HIDS että EDR järjestelmänä, joten kotilabraan löytyy paljon kiinnostavaa kokeiltavaa.

Miksi siihen kannattaa siis tutustua?

Alla on erilaisia käyttötapauksia, joista näkee mitä kannattaisi omassa käytössä kokeilla:

Log data analysis File integrity monitoring
Rootkits detection Active response
Configuration assessment System inventory
Vulnerability detection Cloud security monitoring
Containers security monitoring Regulatory compliance

Itseäni kiinnosti eniten haavoittuvuuksien hallinta ja lisäksi tietoturvapoikkeamien havaitseminen eri lokilähteistä.

Asennus

Käytämme asennuksen nopeuttamiseksi suoraan OVA-virtuaalikonetta, joka sisältää sekä Wazuhin että ELK-stäckin valmiiksi konfiguroituna:

https://documentation.wazuh.com/current/virtual-machine/virtual-machine.html

Kuten muistatte ehkä Proxmox-artikkelista, voi ova-muotoisen virtuaalikoneen saada Proxmoxiin pienellä kikkailulla:

Import OVA as Proxmox VM

Omakohtaisesta kokemuksesta voin sanoa että kovalevy tulee ennen ensimmäistä käynnistystä olla ide-muotoisena. Muutoin asennuksessa ei ollut mitään ihmeellistä. Alla näkyvät suhtellisen hyvän suorituskyvyn takaavat asetukset.

Kun kone on valmiina, käynnistyksen jälkeen se vastaa suoraan saamastaan ip-osoitteesta portista 443. Oletussalasana on admin / admin. Mikäli serverille on asiaa, on tunnus root / wazuh.

Pysyvämmässä käytössä nämä tulee vaihtaa, mutta nyt jouduttaisiin myös koskemaan Wazuhin / Elkin asetuksiin, joten jatkamme oletuksilla.

 

Agenttien käyttö

Agenttien avulla saadaan koneista dataa monipuolisesti ja puskuroidusti. Windows-puolella myös XP:t ovat tuettuja, joka avaa jatkoa varten kiinnostavia mahdollisuuksia 🙂

Wazuh -> Agents sivulta saa suoraan komentokehoitteen agenttien asentamiseksi.

Vaihtoehtoinen tapa on luoda ISO-tiedosto, jonka voi Proxmoxin kautta asettaa kohdekoneille saataville CD-aseman kautta. AnyToISo-ohjelmalla voi Wazuh-agentit sisältävästä hakemistosta tehdä ISO-tiedoston.

https://crystalidea.com/anytoiso

Käsin asentamalla ainoa tarvittava tieto on Wazuhin IP-osoite ja tämän jälkeen palvelun käynnistys. Asennetut agentit ottavat yhteyttä Wazuhiin ja muutaman minuutin työn jälkeen tiedonkeräys on jo käynnissä.

Syslog-lokien vastaanotto

Yleisesti käytössä oleva syslog-formaatti mahdollistaa reitittimien, NAS-purkkien ja muiden laitteiden lokien vastaanoton.

Sen vastaanotto tapahtuu Wazuhin ossec-konffista:

How to configure Rsyslog client to send events to Wazuh

Aseta Wazuh-Management-Configuration (Edit configuration). Sitten Save ja Restart Wazuh.

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.x.x/24</allowed-ips>
  </remote>

Tämän jälkeen aseta halutussa laitteessa syslog-palveluun Wazuhin IP, portti 514 ja muodoksi UDP.

PfSensen Suricata-lokit

Mikäli käytössäsi on PfSense-palomuuri, saa sen Suricatan lokit Wazuhiin seuraavasti:

https://github.com/pfelk/pfelk/wiki/How-To:-Suricata-on-pfSense

Aseta palveluun Wazuhin IP, portti 514 ja muodoksi UDP.

 

Lokitietojen tarkastelu

Wazuhin valikoiden alapuolelta löydät myös Kibanan omat valikot. Valitse sieltä Discovery, jossa näet lokifeedin ja voit tarkastaa että halutut lokit todellakin tulevat perille.

Voit varmistaa että lokit tulevat perille pudottamalla lokien hälytystasoa esim arvolle 1 tai generoimalla hälytyksiä:

https://documentation.wazuh.com/current/user-manual/manager/alert-threshold.html

 

Wazuhin haavoittuvuuksien monitorointi

Erittäin näppärä piirre on Wazuhin kyky tarkkailla asennuksia ja niiden todettuja haavoittuvuuksia. Aseta ensin päälle halutut käyttikset (Windows/Ubuntu/redHat jne):

Using Wazuh for Windows vulnerability detection

Kun agentit ovat tehneet työnsä, muutaman tunnin kuluttua pääset katsomaan millaisia haavoittuvuuksia on löytynyt:

Valitsemalla Explore agent- voit katsoa konekohtaisesti korjauslistaa:

Wazuhin hälytykset

Kohdasta Wazuh – Modules -Security Events näet filtteröidyt ja huomionarvoiset tapahtumat, niin haavoittuvuuksia kuin kirjautumisia koskien. Valitsemalla Events, pääset katsomaan raakadataa.

Filtteröinti ja hakutoimintojen avulla voit rajata ja etsiä vastaavia tapahtumia valitsemaltasi ajanjaksolta.

Hälytyksistä saat myös emailin, asettamalla ossec-konffiin sopivat asetukset:

https://documentation.wazuh.com/current/user-manual/manager/manual-email-report/

(Kannattaa tosin ensin rauhassa tutustua järjestelmään ja rakentaa se tuotantokäyttöön ajatuksen kanssa. Ota varmuuskopiot ja snapshotit merkittävien muutosten jälkeen).

Omat hälytykset ja säännöt

On luultavaa että aivan haluttua hälytystä ei löydy, joten voit rakentaa sääntöjen avulla oman hälytyksen:

https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

 

Loppusanat

Wazuh tarjoaa nopeasti hyvin monipuolisen ratkaisun verkon laitteiden tapahtumien valvontaan. Tutustumalla ohjeisiin voit laajentaa sitä haluttuun suuntaan ja opettelemalla ELK-stackin toimintaa, voit myös rakentaa raportoinnin haluamaasi suuntaan.

Pikaisen käytön jälkeen huomasin että useasta komponentista koostuvassa järjestelmässä kannattaa olla tarkkana päivttämisen kanssa, tuki uusimmille komponenteille ei ilmesty hetkessä kaikkialle. Suosittelen rakentamaan pysyvään käyttöön erilliset ELK ja Wazuh ympäristöt.

Muutaman haastavamman ELK-konffauksen jälkeen piti turvautua Proxmoxin varmuuskopioiden palautukseen ja palata alkuruutuun, mutta tästä lisää seuraavassa artikkelissa jossa tutustutaan T-Potin ja Wazuhin yhteiselämään!

BTB-projekti: Kotilabran palvelut

by

Johdanto

Tämä artikkeli on jatkoa BTB-Projektille: Oma kotilabra, jossa pystytimme Proxmox- virtualisoinnin Asus PN50 raudan päälle. Nyt jatkamme erilaisten palveluiden pystyttämisellä.

  • Tavoite: Pystyttää ensimmäiset palvelut Proxmoxin päälle
  • Vaikeus: Keskitaso
  • Aika: Riippuu palvelusta
  • Hinta: 0 €

Olethan tätä ennen jo tutustunut hieman Proxmoxin dokumentaatioon ja huolehtinyt että sinulla on määritettynä storage-asetukset sekä varmuuskopioinnille että ISO / templaattien säilytykseen!

Perusteita

Hierarkia

Huomaa että osa Proxmoxin asetuksista löytyy Datacenter tasolta ja osa noodi-tasolta. Noodi-tason alta löydät storage-asetukset ominaan.

Palvelut

Proxmox ajaa kahdenlaisia palveluita:

  • Virtuaalikoneita, jotka sisältävät varatut resurssit
  • LXC kontteja, joissa resurssit ovat jaettuja

Virtualisoinnin hyödyt tulevat esille molemmissa. PN50:n kuusi prosessoria ja muisti voidaan jakaa virtuaalikoneiden ja konttien käyttöön niiden todellisen tarpeen mukaan, sillä käyttämättä jäävä kapasiteetti on muiden koneiden ja konttien käytössä.  Käyttötavoilla on kuitenkin vielä eroa tietoturvan suhteen, virtualisoidut koneet ovat eristettyjä kernelin suhteen, kun taas konteissa pitää ottaa huomioon ajetaanko kontteja “Unprivileged” moodissa (suositus), jolloin niitä ajetaan käyttäjäoikeuksin (ei-root) erillisessä nimiavaruudessa. Pääsääntönä siis internetiin näkyvät palvelut kannattaa ajaa omana virtuaalikoneenaan ja sisäverkon palvelut kontteina.

Lue lisää: https://pve.proxmox.com/wiki/Linux_Container

Virtuaalikoneet

Virtuaalikoneisiin liittyen muutama huomio:

CPU: Host mode on suositeltava tehon ja yhteensopivuuden takia, mikäli et aio tehdä migraatioita. Oletuksena tarjotaan KVM-muotoista prosessoria.

Muisti: Linux tukee suoraan mukautuvaa muistia (ballooning) ja Windows lisäajurien kautta. Voit määrittää minimi- ja maksimimuistimäärän. Huomaa että mikäli ylä- ja alaraja muokkaantuvat yhtäaikaa, määritä ensin yläraja ja sitten klikkaa alarajaa ja editoi siihen haluamasi arvo.

Levy: Levy kannattaa asettaa käyttämään nopeinta varastoa, joka minun tapauksessani on paikallinen local-lvm. Mikäli erehdyksessä levy asentuu esim. Synologylle, voi sen migroida uuteen paikkaan Hardware -> move disk 🙂

Boot order: Kun koneesi on boot-loopissa, mene tarkastamaan Options kohdasta boot order ja katso että kiintolevylläsi on rasti ruudussa 🙂

 

LXC templaatit

Templaatteihin pääset GUI:n kautta käsiksi kun menet noodin asetuksissa siihen storageen, johon olet määrittänyt CT templaatit talletettavan. Klikkaa Templates.

 

Isäntäkoneen laitteiden käyttö

Esim GPU:n tehojen parempi hyväksikäyttö salasanojen murtamiseen onnistunee näillä ohjeilla:

https://pve.proxmox.com/wiki/Pci_passthrough

 

Etäkäyttö

Proxmoxin konsolista saat helposti ruutuyhteyden koneelle, mutta leikepöytä ja tiedostojen siirto eivät ole tuettuja no-VNC:llä. Vaihtoehtona on asettaa RDP-palvelu, ottaa yhteys SSH:lla/SFTP:lla, avata yhteinen levyjako esim turnkey-fileserver kontilla tai tehdä CD-asemalle hakemistoista levyjä AnytoISO ohjelmalla. Lisäksi SPICE-ohjelmistot ovat tuettuja, jos ne saa toimimaan.

 

Pi-Hole virtualisoituna

Luodaan ensimmäisenä Debian templaatin päälle Pi-Hole, jota voidaan käyttää oman kodin mainosten estoon. BlueTeamBuildersin lukijat ovat saattaneet jo aikaisemmin asentaa Pi-Holen Raspberry Pi:n päälle, mutta nyt voidaan helposti lisätä vikasietoisuutta virtualisoidun palvelun kautta.

  1. Siirry varastoon, johon olet asettanut templaattien säilytyksen. Minun tapauksessani local, CT Templates. Lataa debian-10-standard / ubuntu tms mieleinen *nix distribuutio.
  2. Luo templaatin pohjalta kontti, aseta salasana / SSH julkinen avain hallintaa varten. Muistia riittää 1000 BiB ja prosessiksi 1 core. Aseta kiinteä IP tai pakota reitittimeltäsi sama IP. Aseta palvelu käynnistymään proxmoxin bootin yhteydessä.
  3. Käynnistä kontti ja siirry siihen Consolen kautta.
  4. Asenna qemu: https://pve.proxmox.com/wiki/Qemu-guest-agent
  5. Asenna Pi-Hole https://github.com/pi-hole/pi-hole/#one-step-automated-install
  6. Avaa Pi-holen hallintapaneeli selaimen kautta
  7. Siirrä Teleporter toiminnon kautta vanhasta Pi-Holesta asetukset uuteen.
  8. Voit tehdä asennuksesta templaatin jatkoa ajatellen. Tällöin tee templaatista klooni, joka näkyy nyt samalla IP-osoitteella kuin alkuperäinen (DHCP toimii tässä siis paremmin).
  9. Ota snapshot kloonista palautumista ajatellen
  10. Aseta reitittimessä DHCP-palvelussa myös uusi Pi-Hole kotilaitteidesi käyttöön

Kalin asennus

Tehdään Kalin asennus käyttäen virtuaalikonetta ja Live-CD:tä.

  1. Lataa Kali Linux LiveCD https://www.kali.org/downloads/ ja aseta se saataville ISO-varastoosi. Minun tapauksessani Synologyyn.
  2. Luo virtuaalikone mukautuvalla muistilla esim 2GiB – 8 GiB, neljällä host prosessorilla ja aseta CD-asema käyttämään Kali Live CD:tä.
  3. Käynnistä kone ja avaa Console.
  4. Asenna Linux. Voit myös halutessasi asettaa RDP:n päälle Windowsin käyttöä helpottamaan (leikepöydän kopiointi). Ohjeet: https://www.kali.org/docs/general-use/xfce-with-rdp/ (Minulla Legion lakkasi toimimasta, joten varaudu korjauksiin)
  5. Päivitä Qemu palvelut: https://pve.proxmox.com/wiki/Qemu-guest-agent
  6. Ota snapshotti asennuksestasi

 

Virtuaalikoneiden käyttö

Jostain erikoisesta syystä OVA-muotoiset virtuaalikoneet eivät ole suoraan tuettuja, mutta niiden käyttö onnistuu seuraavien ohjeiden avulla: https://www.itsfullofstars.de/2019/07/import-ova-as-proxmox-vm/

Voit asentaa itsellesi esim kohdekoneen Kalia varten: https://www.vulnhub.com/entry/driftingblues-9-final,695/

Muutama huomio:

  1. Aseta kerralla oikein levyn SATA /IDE yms asetus Proxmoxilla, jostain syystä esim Wazuh ei toiminut jos asetus oli kerran väärin. Näet asetuksen kun avaat OVA:n esim 7-zipillä ja katsot .ovf-tiedostoa esim Notepad ++:lla.
  2. Proxmoxiin pääset joko noden Shellin kautta tai haluamallasi SSH/SFTP ohjelmalla (esim. Bitwise). Voit siirtää vmdk-levyn koneelle SFTP:llä.
  3. Mikäli asennat Windows-koneita, kannattaa quemu ja virtuo-ajurit asentaa CD-aseman kautta: https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

 

Asennettavia palveluita

Voit rakentaa juuri sellaisen labran kuin haluat, mutta ohessa on muutamia ideoita jatkoa ajatellen:

  1. Infection Monkey https://www.guardicore.com/infectionmonkey/
  2. Wazuh: https://wazuh.com/
  3. Paessler PRTG: https://www.paessler.com/prtg
  4. T-Pot: https://github.com/telekom-security/tpotce
  5. Turnkey Linux templat: https://www.turnkeylinux.org/
  6. Oma Bitwarden: https://bitwarden.com/help/article/install-on-premise/

 

Seuraavassa artikkelissa testaamme Wazuhia!

BTB-projekti: Oma kotilabra

by

Johdanto

Oma kotilabra tarkoittaa joukkoa laitteita, joiden parissa voi kokeilla uusia teknologioita, palveluita tai harjoitella uusia taitoja. Kotilabran laitteet voi eristää normaalista “tuotannosta” ja niiden poistuminen ei häiritse normaalia elämää. Tässä artikkelissa otetaan ensimmäiset askeleet kohden omaa kotilabraa ja myöhemmissä artikkeleissa seurataan mitä palveluita / palvelimia labraan on otettu käyttöön.

  • Tavoite: Pystyttää oma kotilabra virtualisoinnin avulla 
  • Vaikeus: Keskitaso
  • Aika: 1 työpäivä
  • Hinta: Noin 700 €

Paljon vinkkejä löydät:

https://www.reddit.com/r/homelab/

Virtualisointi

Virtualisoinnilla tarkoitetaan käyttöjärjestelmätason erottamista rautatasosta, eli sen sijaan että Windows / *nix keskustelisi suoraan prosesorien ja muistin kanssa, keskustelee se virtualisointialustan kanssa. Virtualisointi kotilabrassa mahdollistaa seuraavia:

  • Resurssien tehokkaampi käyttö eri palveluiden tai palvelinten välillä
  • Nopeampi asentaminen, templaattien ja levykuvien kautta
  • Snapshottien ja konetasoisten varmuuskopioiden kautta
  • Muistin, prosessorien tai levytilan lisääminen tarpeen mukaan
  • Tarpeettomien palvelinten käynnistäminen ja sulkeminen riippumatta muista palveluista

Itselleni virtualisointi on ollut tuttua lähinnä VirtualBoxin ja Kali Linuxin kautta. Tekniikka toimii hyvin, mutta ongelmana on se ettei alusta ole ollut jatkuvaan käyttöön tarkoitettua, joten läppäriä ei ole voinut jättää päälle serverien käyttöön, käyttiksen uudelleenkäynnistykset ovat katkaisseet työt ja verkkopääsy on ollut pelkän wifin varassa. On siis aika hankkia rautaa, joka toimii nimenomaan kotilabran pohjana. Mutta mikä softa-alusta virtualisointiin?

Alusta

Pienen aiheeseen perehtymisen jälkeen karsintalistalleni päätyivät:

Tämän jälkeen ensimmäisenä karsiutui pois VirtualBox, koska halusin melko pelkistetyn ja suoraan raudan päälle asentuvan virtualisoinnin. Nutanix on varsin vakuuttava, mutta harrastajakäytössä siitä ei löytynyt tarpeeksi vinkkejä ja tukea. Lopullinen valinta tapahtui siis Proxmoxin ja ESXIn välillä. Mutta tämän jälkeen pitikin tehdä tarkastus millaista rautaa alustat tukevat.

 

Kirjallisuuskatsaus

Erittäin hyviä artikkeleita aiheeseen löytyi seuraavilta tahoilta:

VMware ESXi Home Lab – Intel NUC 10 (Frost Canyon)

Which Intel NUC should I buy for VMware ESXi? (August 2020)

Intel NUC 10 NUC10i7FNH Review

https://www.itpro.co.uk/hardware/358412/asus-mini-pc-pn50-review-no-storage-no-problem

https://henvic.dev/posts/homelab/

 

Vaatimukset

Koska vanhaa laitteistoa ei ollut käytössä, päätin panostaa uuteen settiin ja valita joko Intelin Nucin tai AMD:n barebone-malliston välillä. Nyt pitikin ottaa jo huomioon virtualisointialustan tuki laitteistolle.

Lyhyesti yhteenvedettynä ESXI tukee hyvin Intelin verkkoajureita, mutta ei kovin helposti Realtekin ajureita. Realtekia puolestaan löytyy AMD:n PN50-sarjasta. Tällä hetkellä tehojen suhteen AMD Radeon-sarja menee ohi Intelin vastaavan hinnan tuotteista, joten se puoltaisi investoinnissa AMD PN50-ostosta. Lisäksi jos myöhemmin haluaisin vaihtaa ESXi:iin, voi Intelin piirisarjaa tukevalla USB-Ethernet mokkulalla saada myös ESXin toimintaan. Mutta halusin aloittaa Proxmoxilla, avoimen lähdekoodin ideologiaa tukien. Mikäli se ei toimisi hyvin, olisi ESXi seuraavana vuorossa.

 

Ostoslista

Budjettini oli pysyä alle 1000 € hankinnoissa

Ostohetkellä halvimman setin tarjosi Tietokonekauppa.fi, johon linkit osoittavat, hinnalla 738,10 €. 

Yhteishinnaksi tuli  hieman alle 800 €.

Vaihtoehtoja

Vastaavia kokoonpanoja tarjoavat (kiitos Marcus ja Marcus):

 

Kokoaminen ja asennus

Osien kokoonpanossa ei muuta ongelmaa ollut kuin että en muistia saanut työnnettyä aivan pohjaan, joten ensimmäinen käynnistys ei onnistunut. Tuttuun tapaan 90-luvulta, kone paloiksi ja huolellisesti uudelleenkokoamalla bootti onnistui. Tämän jälkeen proxmoxin ISO-USB kiinni ja käynnistys.

Ohjeet asennukseen löytyvät: https://www.proxmox.com/en/proxmox-ve/get-started

Ikävä kyllä asennus katkesi heti alkuunsa, mutta onneksi muillakin oli sama ongelma tullut vastaan ja siihen löytyi helppo ratkaisu:

Comment from discussion Digger412’s comment from discussion "Having trouble installing Proxmox 6.2 on AMD".

“chmod 1777 /tmp apt update Xorg-configure mv /xorg.conf.new /etc/X11/xorg.conf vim /etc/X11/xorg.conf # update Driver -> “fbdev” startx”

 

Tuore alusta

Proxmox on varsin selkeä valikkoineen.

  • Ensimmäisenä aina päivitys ja uusien bugien hakeminen netistä.
  • Tuoreelle asennukselle tuli heti laitettua NFS-verkkojako Synologyyn, jotta snapshotit ja ISO:t saa pois paikalliselta tasolta.
  • Testi VM:n snapshotin palautuskin sujui hyvin, joka on aina hyvä varmistaa.
  • Noden asetukset saa talteen skriptin kautta: https://github.com/DerDanilo/proxmox-stuff
  • Seuraavana tein kahdelle StarTechin NICille Bridget, joten minulla on nyt yksi managament-käyttöön ja kaksi varattuna tuotantoon. Koko laite siirtyi kolmella verkkopiuhalla kiinni kytkimeen ja kirjahyllyyn piiloon.

Kotilabran pohja on siis valmiina!

 

Ideoita jatkoon

Sinisen teamin perusajatuksen mukaisesti voi vaikka kokeilla miten hälytykset generoituvat erilaisista hyökkäyksistä tai monitoroida käytössä olevia palveluita. Tai ehkä Pi-Hole pitäisi virtualisoida? Olisi kiva laittaa Paesslerin PRTG pois wifin päästä. Entä jos katsoisi mitä Infection Monkey löytää?

Päivitys 31.5.2021 Lisätty Noden asetusten kopiointi-skripti

 

Jatkoa siis seuraa seuraavissa artikkeleissa:

BTB-projekti: Kotilabran palvelut