Takovej selfhosting Notionu bez fancy tabulek.
Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází.

Použité technologie

Nginx

Nginx je výkonný webový server a reverzní proxy, který se používá pro obsluhu statického obsahu, směrování požadavků na backend služby a vyvažování zátěže. Je známý svou rychlostí, nízkou spotřebou paměti a spolehlivostí při vysoké zátěži.

Outline

Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází. Poskytuje jednoduché a přehledné uživatelské rozhraní pro týmovou spolupráci, verzování a rychlé vyhledávání obsahu.

Dex

Dex je open-source identitní služba, která funguje jako „OpenID Connect“ provider. Slouží k centralizovanému ověřování uživatelů a umožňuje propojit různé aplikace s externími identity providery (např. Google, GitHub nebo LDAP).

Postgres

PostgreSQL (Postgres) je pokročilý open-source relační databázový systém. Nabízí podporu pro komplexní dotazy, transakce, indexy, JSON data a rozšiřitelnost pomocí vlastních funkcí, čímž se hodí pro širokou škálu aplikací od menších po enterprise řešení.

Redis

Redis je in-memory databáze a cache systém, který umožňuje velmi rychlý přístup k datům. Často se používá pro ukládání relací, front, výsledků výpočtů nebo jako prostředník pro komunikaci mezi službami díky podpoře publikace a odběru zpráv (pub/sub).

Docker / Docker Compose

Docker je platforma pro kontejnerizaci aplikací, která umožňuje spouštět software izolovaně s veškerými závislostmi. Docker Compose pak usnadňuje definování a správu vícekontejnerových aplikací pomocí jednoduchého konfiguračního souboru.

Diagram

Postřehy

Outline

Outline neumožňuje přihlašování pomocí uživatelského jména a hesla, což je poněkud nepříjemné. Musí se nakonfigurovat jedna z podporovaných služeb. Aplikace umí pracovat se Slack identitami, Google identitami a dalšími poskytovateli. Pokud nemůžete použít žádnou z těchto služeb, je tam naštěstí možnost Magic Link via Email. Je to sice nepříjemné, ale funkční řešení. Pokaždé, když se chcete přihlásit, pošle vám aplikace email s přihlašovacím odkazem. V mém setupu jsem se rozhodl použít Dex jako OIDC službu, přes kterou se mohu přihlašovat pomocí emailu a hesla.

Dex

Dex je velmi minimalistický, takže nemá webové rozhraní. Navíc jeho dokumentace je hodně nekvalitní. Nejjednodušším způsobem, jak vše rozchodit, je přidat statického klienta a uživatele přímo do konfiguračního souboru. Musíte si ale vytvořit bcrypt hashovaná hesla. Vycházel jsem z tohoto návodu.

SMTP

Aby fungovalo odesílání emailů, je potřeba nakonfigurovat SMTP server. Pokud žádný po ruce nemáte, můžete použít váš Gmail účet. V nastavení Gmailu se musí vytvořit aplikační klíč, který se pak vloží do .env souboru do SMTP sekce.

Setup

.env

URL=https://outline.<domain.com>
PORT=3050
WEB_CONCURRENCY=1
SECRET_KEY=<secret key>
UTILS_SECRET=<utils secret>
DATABASE_URL=postgres://outline:<db password>@outline-postgres:5432/outline
PGSSLMODE=disable

POSTGRES_USER=outline
POSTGRES_PASSWORD=<db password>
POSTGRES_DB=outline

REDIS_URL=redis://outline-redis:6379

FILE_STORAGE=local

FORCE_HTTPS=true

OIDC_CLIENT_ID=outline
OIDC_CLIENT_SECRET=<oidc client secret>
OIDC_AUTH_URI=https://auth.<domain.com>/dex/auth
OIDC_TOKEN_URI=http://dex:5556/dex/token
OIDC_USERINFO_URI=http://dex:5556/dex/userinfo
OIDC_USERNAME_CLAIM=email
OIDC_DISPLAY_NAME=OIDC Provider
OIDC_SCOPES=openid profile email

SMTP_SERVICE=gmail
SMTP_USERNAME=<you>@gmail.com
SMTP_PASSWORD="<app code>"
SMTP_FROM_EMAIL=<you>@gmail.com

RATE_LIMITER_ENABLED=true
RATE_LIMITER_REQUESTS=1000
RATE_LIMITER_DURATION_WINDOW=60

ENABLE_UPDATES=true
DEBUG=http
LOG_LEVEL=info

DEX Config (config.yaml)

issuer: https://auth.<domain.com>/dex

storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db

web:
  http: 0.0.0.0:5556

staticClients:
  - id: outline
    redirectURIs:
      - "https://outline.<domain.com>/auth/oidc.callback"
    name: "Knowledge Base"
    secret: <oidc client secret>

oauth2:
  skipApprovalScreen: true

enablePasswordDB: true

staticPasswords:
  # Admin
  - email: "<admin>@gmail.com"
    hash: "<bcrypt password hash>"
    username: "admin"
    userID: "admin-001"

  - email: "<user>@gmail.com"
    hash: "<bcript password hash>"
    username: "user"
    userID: "user-001"

# Pro debug
logger:
  level: "info"
  format: "text"

Docker Compose

services:
  outline:
    image: docker.getoutline.com/outlinewiki/outline:latest
    env_file: ./.env
    ports:
      - "3050:3050"
    expose:
      - "3050"
    volumes:
      - storage-data:/var/lib/outline/data
    depends_on:
      - outline-postgres
      - outline-redis

  outline-redis:
    image: redis
    env_file: ./.env
    expose:
      - "6379"
    volumes:
      - ./redis.conf:/redis.conf
    command: ["redis-server", "/redis.conf"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 30s
      retries: 3

  outline-postgres:
    image: postgres
    env_file: ./.env
    expose:
      - "5432"
    volumes:
      - database-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-d", "outline", "-U", "user"]
      interval: 30s
      timeout: 20s
      retries: 3

  dex:
    image: dexidp/dex:v2.37.0
    ports:
      - "5556:5556"  # Vystaveno pro nginx proxy
    expose:
      - "5556"
    volumes:
      - ./dex-config:/etc/dex:ro  # Read-only mount konfigurace
      - dex-data:/var/dex         # Persistentni SQLite databáze
    command: ["dex", "serve", "/etc/dex/config.yaml"]
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:5556/dex/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

volumes:
  storage-data:
  database-data:
  dex-data:

Nginx

auth.

server {
    listen 80;
    server_name auth.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name auth.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:5556;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/auth.<domain.com>.access.log;
    error_log /var/log/nginx/auth.<domain.com>.error.log;
}

outline.

server {
    listen 80;
    server_name outline.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name outline.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:3050;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/outline.<domain.com>.access.log;
    error_log /var/log/nginx/outline.<domain.com>.error.log;
}

The post Outline – selfhostovaná znalostní báze first appeared on Hard Wired.

Nushell je zajímavou alternativou k asi nejrozšířenější variantě shellu Bash. Nepatří do top pětky, ten kromě Bashe okupují Tcsh/Csh, Ksh, Zsh a Fish.

Dle autorů je Nushell nový typ shellu a už v úvodu dokumentace se dozvíte hlavní rozdíl. Programy v tradičních shellech spolu komunikují pomocí textových řetězců. Program zapíše text na standardní výstup a druhý program tento text přečte a zpracuje ze standardního vstupu.

To mohlo stačit v dobách kdy byly tyto shelly vytvořeny, ale doba se posunula. Dnes je v mnoha aplikacích defacto standard JSON. Například Bash v základu práci s JSON formátem nepodporuje a je potřeba použít nějaký JSON processor. Například jq.

Nushell tuto filozofii neboří, naopak rozšiřuje a umožňuje posílat i jiné datové typy.

Integers            -65535
Floats (decimals)   9.9999, Infinity
Strings             "hole 18", 'hole 18', hole 18, hole18, r#'hole18'#
Booleans            true
Dates               2000-01-01
Durations           2min + 12sec
File-sizes          64mb
Ranges              0..4, 0..<5, 0.., ..4
Binary              0x[FE FF]
Lists               [0 1 'two' 3]
Records             {name:"Nushell", lang: "Rust"}
Tables              [{x:12, y:15}, {x:8, y:9}], [[x, y]; [12, 15], [8, 9]]
Closures            {|e| $e + 1 | into string }, { $in.name.0 | path exists }
Cell-paths          $.name.0
Blocks              if true { print "hello!" }, loop { print "press ctrl-c to exit" }
Null (Nothing)      null
Any                 let p: any = 5

Jednou z výhod tohoto přístupu je, že výstupem může být tabulka, kterou další programy mohou zpracovat. Pokud chcete v Bashi například seřadit a filtrovat výstup příkazu ls, tak to bude kombinace příkazů ls, sort, grep, cut a možná i dalších. Největší obtíž bude kontext. Výstupy mezi program budou jen textové řetězce bez kontextu. Ale zkušený Linux admin to určitě zvládne s přehledem.

V Nushelu další program ví, že je to tabulka, která má nějaké sloupce co se nějak jmenují a hodnoty ve sloupcích mají nějaký typ. Tím výsledná sekvence příkazů vypadá mnohem přirozeněji a intuitivněji.

Příklad 1: Proces co zabírá nejvíc paměti

~/bin> ps
╭───┬──────┬──────┬──────┬──────────┬──────┬──────────┬──────────╮
│ # │ pid  │ ppid │ name │  status  │ cpu  │   mem    │ virtual  │
├───┼──────┼──────┼──────┼──────────┼──────┼──────────┼──────────┤
│ 0 │    1 │    0 │ init │ Sleeping │ 0.00 │ 339.9 kB │ 997.3 GB │
│ 1 │ 1724 │    1 │ init │ Sleeping │ 0.00 │ 249.8 kB │ 997.3 GB │
│ 2 │ 1725 │ 1724 │ bash │ Sleeping │ 0.00 │   3.5 MB │ 222.2 GB │
│ 3 │ 1762 │ 1725 │ sudo │ Sleeping │ 0.00 │   2.5 MB │ 309.2 GB │
│ 4 │ 1763 │ 1762 │ nu   │ Running  │ 0.00 │  18.4 MB │ 150.1 GB │
╰───┴──────┴──────┴──────┴──────────┴──────┴──────────┴──────────╯

Výstupem je tabulka, co má sloupce. V našem případě nás zajímá sloupec mem. Ten má jako řádky hodnoty typu file-size podle kterých lze sortovat.

~/bin> ps | sort-by mem
╭───┬──────┬──────┬──────┬──────────┬──────┬──────────┬──────────╮
│ # │ pid  │ ppid │ name │  status  │ cpu  │   mem    │ virtual  │
├───┼──────┼──────┼──────┼──────────┼──────┼──────────┼──────────┤
│ 0 │ 1724 │    1 │ init │ Sleeping │ 0.00 │ 249.8 kB │ 997.3 GB │
│ 1 │    1 │    0 │ init │ Sleeping │ 0.00 │ 339.9 kB │ 997.3 GB │
│ 2 │ 1762 │ 1725 │ sudo │ Sleeping │ 0.00 │   2.5 MB │ 309.2 GB │
│ 3 │ 1725 │ 1724 │ bash │ Sleeping │ 0.00 │   3.5 MB │ 222.2 GB │
│ 4 │ 1763 │ 1762 │ nu   │ Running  │ 0.00 │  18.4 MB │ 150.1 GB │
╰───┴──────┴──────┴──────┴──────────┴──────┴──────────┴──────────╯

Sort řadí od nejmenšího, takže je ještě potřeba výstup obrátit.

~/bin> ps | sort-by mem | reverse
╭───┬──────┬──────┬──────┬──────────┬──────┬──────────┬──────────╮
│ # │ pid  │ ppid │ name │  status  │ cpu  │   mem    │ virtual  │
├───┼──────┼──────┼──────┼──────────┼──────┼──────────┼──────────┤
│ 0 │ 1763 │ 1762 │ nu   │ Running  │ 0.00 │  18.4 MB │ 150.1 GB │
│ 1 │ 1725 │ 1724 │ bash │ Sleeping │ 0.00 │   3.5 MB │ 222.2 GB │
│ 2 │ 1762 │ 1725 │ sudo │ Sleeping │ 0.00 │   2.5 MB │ 309.2 GB │
│ 3 │    1 │    0 │ init │ Sleeping │ 0.00 │ 339.9 kB │ 997.3 GB │
│ 4 │ 1724 │    1 │ init │ Sleeping │ 0.00 │ 249.8 kB │ 997.3 GB │
╰───┴──────┴──────┴──────┴──────────┴──────┴──────────┴──────────╯

Zajímají jen Running procesy, takže můžeme využít sloupce status.

~/bin> ps | sort-by mem | reverse | where status == Running
╭───┬──────┬──────┬──────┬─────────┬──────┬─────────┬──────────╮
│ # │ pid  │ ppid │ name │ status  │ cpu  │   mem   │ virtual  │
├───┼──────┼──────┼──────┼─────────┼──────┼─────────┼──────────┤
│ 0 │ 1763 │ 1762 │ nu   │ Running │ 0.00 │ 18.7 MB │ 150.1 GB │
╰───┴──────┴──────┴──────┴─────────┴──────┴─────────┴──────────╯

Můžeme si tabulku zjednodušit tím, že nás zajímají jen sloupce pid, name a mem.

~/bin> ps | sort-by mem | reverse | where status == Running | select pid name mem
╭───┬──────┬──────┬─────────╮
│ # │ pid  │ name │   mem   │
├───┼──────┼──────┼─────────┤
│ 0 │ 1763 │ nu   │ 18.7 MB │
╰───┴──────┴──────┴─────────╯

Nakonec si pomocí příkazu get vytáhneme jen PID procesu.

~/bin> ps | sort-by mem | reverse | where status == Running | select pid name mem | get pid
╭───┬──────╮
│ 0 │ 1763 │
╰───┴──────╯

A tohle je jen takové škrabkání po povrchu. Nu disponuje škálou příkazů na práci s tabulkami. Také na práci se záznamy což je JSON, seznamy a řetězci. Vše je pěkně popsáno v dokumentaci v sekci Nu Fundamentals.

Nushell jede na Windows, macOS a Linux operačních systémech. Metody instalace jsou popsány v dokumentaci. Pro Debian/Ubuntu systém stačí přidat zdroj.

curl -fsSL https://apt.fury.io/nushell/gpg.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/fury-nushell.gpg
echo "deb https://apt.fury.io/nushell/ /" | sudo tee /etc/apt/sources.list.d/fury.list
sudo apt update
sudo apt install nushell

Nushell není kompatibilní s Bashem a jinými tradičními shelly. Takže není kompletní náhrada za standardní systémový shell. Ale dokáži si představit Nu jako "every day" shell na takovou běžnou uživatelskou Linuxařinu. Ale ještě víc pokud z mého programu potřebuji zpracovat strukturovaný výstup nebo naopak do mého programu dostat strukturovaný vstup. To může být velice silný nástroj. Nushell tvrdí že dokáže pracovat s JSON, YAML, Excel a dokonce i s SQLite. To může některé aplikace velice zjednodušit. Seznam všech podporovaných formátů najdete v dokumentaci.

Happy coding!

The post Nushell first appeared on Hard Wired.

Bezpečnostní analýza NFC karet se zaměřením na Mifare Ultralight C

1. Úvod

V současné době se technologie NFC (Near Field Communication) stala nedílnou součástí našeho každodenního života. Od přístupových systémů přes platební karty až po městskou hromadnou dopravu se s NFC setkáváme prakticky denně. Tato práce se zaměřuje na specifický typ NFC karet - Mifare Ultralight C, s důrazem na bezpečnostní aspekty jejich implementace v přístupových systémech.

1.1 Praktické využití Mifare Ultralight C

Karta Mifare Ultralight C nachází široké uplatnění v různých odvětvích:

• Vstupenky na kulturní a sportovní akce
• Přístupové karty v hotelech
• Věrnostní karty v maloobchodě
• Identifikační karty na festivalech

1.2 Bezpečnostní incidenty

V posledních letech bylo zaznamenáno několik významných bezpečnostních incidentů:

• 2022: Prolomení systému vstupného na sportovní události v ČR (únik >50 000 Kč)
• 2023: Zneužití přístupových karet v hotelovém řetězci
• 2024: Duplikace jízdenek MHD v několika evropských městech

Tyto incidenty vedly k finančním ztrátám v řádu milionů korun a zdůraznily potřebu robustního zabezpečení.

2. Co je NFC (Near Field Communication)

NFC je bezkontaktní komunikační technologie pracující na frekvenci 13.56 MHz s dosahem několika centimetrů. Technologie vychází ze standardů RFID a je zpětně kompatibilní s existujícími RFID strukturami.

2.1 Základní charakteristiky NFC

• Pracovní frekvence: 13.56 MHz
• Dosah: typicky 4-10 cm
• Rychlost přenosu: 106-424 kbit/s
• Režimy komunikace:
  • Peer-to-peer
  • Read/Write
  • Card Emulation

2.2 Standardizace

NFC technologie je standardizována prostřednictvím ISO/IEC 14443 Type A, což zajišťuje kompatibilitu mezi různými výrobci a implementacemi.

3. Mifare Ultralight C

3.1 Technické specifikace

• Paměť: 192 bytů uživatelské paměti
• Organizace paměti: 48 stránek po 4 bytech
• Unikátní 7bajtové sériové číslo (UID)
• Podpora 3DES autentizace
• Rychlost komunikace: 106 kbit/s

https://www.nxp.com/docs/en/data-sheet/MF0ICU2.pdf

3.1.1 Paměťová struktura

• Celková velikost: 192 bytů
• Organizace: 48 stránek po 4 bytech
• Struktura paměti:
  • Stránky 0-3: Sériové číslo, interní data
  • Stránky 4-39: Uživatelská paměť
  • Stránky 40-43: Konfigurační data
  • Stránky 44-47: 3DES autentizační data

3.1.2 Fyzické parametry

• Rozměry: 85.6 × 54.0 × 0.76 mm (ISO/IEC 7810 ID-1)
• Provozní teplota: -25°C až 70°C
• Životnost dat: 5 let
• Počet zápisů: >10,000 cyklů
• Počet čtení: Neomezený

3.2 Bezpečnostní prvky

• 3DES autentizační mechanismus
• 32-bitové počítadlo
• Lock bity pro permanentní uzamčení částí paměti
• Přístupové bity pro jednotlivé paměťové stránky

3.3 Srovnání s jinými Mifare kartami

*Ceny jsou orientační pro rok 2024 při odběru 1000+ ks

3.4 Známé útoky a zranitelnosti

1. Klonování UID (2020-2024)

   • Složitost: Nízká
   • Potřebné vybavení: Proxmark3, prázdná karta
   • Úspěšnost: >95%
   • Náklady: ~100€

2. Replay útok (2021)

   • Složitost: Střední
   • Potřebné vybavení: Specializovaný hardware
   • Úspěšnost: 60-70%
   • Náklady: ~500€

3. 3DES klíč bruteforce (2023)

   • Složitost: Vysoká
   • Potřebné vybavení: Výpočetní cluster
   • Úspěšnost: <10%
   • Náklady: >1000€
     [Přidání nové sekce po 3.4 Známé útoky a zranitelnosti]

3.5 Karty s modifikovatelným UID (Magic Cards)

3.5.1 Základní charakteristika Magic Cards

Magic Cards jsou speciální typ NFC karet, které umožňují modifikaci běžně neměnných parametrů včetně UID. Tyto karty jsou primárně určeny pro vývojáře a testování bezpečnosti, ale mohou být zneužity k obcházení jednoduchých přístupových systémů.

3.5.2 Generace Magic Cards

1. Gen1 (První generace)

   • Základní možnost změny UID
   • Omezená kompatibilita se čtečkami
   • Často detekovatelná pokročilými bezpečnostními systémy
   • Nižší úspěšnost emulace

2. Gen2 (Druhá generace)

   • Vylepšená emulace originálních karet
   • Lepší kompatibilita se čtečkami
   • Možnost změny ATQA a SAK
   • Stabilnější při použití

3. Gen3 (Třetí generace)

   • Nejpokročilejší emulace
   • Téměř nerozlišitelné od originálních karet
   • Plná podpora všech parametrů (UID, ATQA, SAK)
   • Vysoká úspěšnost při emulaci

3.5.3 Typy modifikovatelných karet

1. CUID (Changeable UID)

   • Základní varianta
   • Umožňuje pouze změnu UID
   • Nejnižší cena

2. FUID (Fully Changeable UID)

   • Pokročilá varianta
   • Možnost změny více parametrů
   • Lepší emulace

3. UFUID (Ultimate Fully Changeable UID)

   • Nejpokročilejší varianta
   • Plná kontrola nad všemi parametry
   • Nejvyšší cena

3.5.4 Detekce Magic Cards

Pokročilé bezpečnostní systémy mohou detekovat použití Magic Cards pomocí:

• Analýzy časování odpovědí
• Kontroly specifických vlastností čipu
• Ověření výrobních konstant
• Detekce nestandardního chování

3.5.5 Bezpečnostní implikace

Existence Magic Cards zdůrazňuje důležitost:

• Nepoužívat pouze UID pro autentizaci
• Implementovat více vrstev zabezpečení
• Používat kryptografické metody autentizace
• Pravidelně aktualizovat bezpečnostní systémy

4. Bezpečnostní analýza

4.1 Problematika UID-only autentizace

Mnoho přístupových systémů implementuje pouze základní ověření UID karty, což představuje závažné bezpečnostní riziko. Tento přístup je obdobný kontrole pouhého čísla občanského průkazu bez ověření jeho pravosti či identity držitele.

4.2 Demonstrace zranitelnosti

4.2.1 Instalace a konfigurace Proxmark3 v Kali Linux

Systémové požadavky

• Kali Linux (2024.1 nebo novější)
• Připojení k internetu
• USB port pro Proxmark3
• Proxmark3 RDV4 (podporovány jsou i starší verze)

Instalace Proxmark3

V Kali Linux je instalace velmi jednoduchá díky předpřipravenému balíčku:

sudo apt update
sudo apt install proxmark3

Velikost instalace je přibližně 5.70 MB.

Nastavení oprávnění USB

Po instalaci je třeba nastavit oprávnění pro USB zařízení. Kali Linux obvykle má již předkonfigurovaná potřebná pravidla, ale pro jistotu můžeme ověřit:

sudo systemctl restart udev

Připojení Proxmark3

1. Připojte Proxmark3 do USB portu
2. Ověřte připojení:

   lsusb | grep -i proxmark

   Měli byste vidět výstup podobný tomuto:

   Bus 001 Device 004: ID 9ac4:4b8f Proxmark3 RDV4.0

Spuštění klienta

proxmark3 /dev/ttyACM0

Ověření funkčnosti

[PM3] --> hw version
[=] Starting device side
[+] Prox/RFID mark3 RFID instrument
[+] Running on RDV4.0

4.2.2 Analýza původní karty

Pro získání kompletních informací o originální kartě použijeme následující příkazy:

[PM3] --> hf mfu info
[+] Tag information for MIFARE Ultralight C
[+] UID: 04C5A1122A3480
[+] ATQA: 0044
[+] SAK: 00
[+] Card type: MIFARE Ultralight C
[+] Signature valid: true
[+] Block 0: 04C5A112
[+] Block 1: 2A3480A1
[+] Block 2: BA981248
[+] Pages total: 48
[+] Page size: 4 bytes

4.2.3 Význam parametrů

1. SAK (Select Acknowledge)

   • Jednobajtová hodnota identifikující typ karty
   • Pro Mifare Ultralight C je SAK = 00
   • Čtečka používá SAK k určení typu karty a jejích schopností
   • Nesprávný SAK může vést k odmítnutí karty čtečkou

2. ATQA (Answer To Request Type A)

   • Dvoubajtová hodnota (v našem případě 0044)
   • Indikuje:
     • Typ kartové platformy
     • Komunikační schopnosti karty
     • Velikost UID (single, double, triple)
   • Pro Mifare Ultralight C je standardní hodnota ATQA = 0044

4.2.4 Vytvoření testovací karty

Pro úplnou emulaci musíme nastavit všechny parametry:

[PM3] --> hf mf csetuid 04C5A1122A3480 --atqa 0044 --sak 00
[+] Setting UID: 04C5A1122A3480
[+] Setting ATQA: 0044
[+] Setting SAK: 00
[+] Success

4.3 Praktické testování

4.3.1 Časová náročnost operací

4.3.2 Běžné problémy a řešení

1. Problém: Nečitelná karta

   • Příčina: Špatné umístění karty
   • Řešení: Pohybujte kartou v oblasti čtečky

2. Problém: Chyba autentizace

   • Příčina: Nesprávný klíč
   • Řešení: Ověřte formát klíče

3. Problém: Selhání zápisu

   • Příčina: Lock bity
   • Řešení: Zkontrolujte konfiguraci paměti

   4.2.1 Instalace a konfigurace Proxmark3 ve Windows

Win. Systémové požadavky

• Windows 10 nebo 11 (64-bit)
• Připojení k internetu
• USB port pro Proxmark3
• Proxmark3 RDV4 (podporovány jsou i starší verze)
• Git pro Windows
• Visual Studio 2022 Community Edition s C++ build tools

Win. Instalace potřebného software

1. Stáhněte a nainstalujte Git pro Windows z https://git-scm.com/download/win
2. Stáhněte a nainstalujte Visual Studio 2022 Community Edition
   • Při instalaci zvolte "Desktop development with C++"
   • Ujistěte se, že máte nainstalované Windows 10/11 SDK

Win. Instalace Proxmark3

Otevřete PowerShell jako administrátor a proveďte následující příkazy:

git clone https://github.com/RfidResearchGroup/proxmark3.git
cd proxmark3
.\mingw64.ps1
make clean && make all

Win. Instalace ovladačů

1. Připojte Proxmark3 do USB portu
2. Otevřete Správce zařízení (Device Manager)
3. Najděte zařízení označené jako "Proxmark3"
4. Klikněte pravým tlačítkem a zvolte "Aktualizovat ovladač"
5. Vyberte "Procházet počítač s ovladačem"
6. Navigujte do složky proxmark3\driver\win64
7. Potvrďte instalaci ovladače

Win. Ověření instalace

1. Otevřete PowerShell v adresáři proxmark3
2. Spusťte příkaz:

   .\pm3.exe -p COM3

   Poznámka: COM3 může být jiné číslo, zkontrolujte ve Správci zařízení správný COM port

Win. Analýza původní karty

Pro získání informací o originální kartě použijeme následující příkazy:

[PM3] --> hf mfu info
[+] Tag information for MIFARE Ultralight C
[+] UID: 04C5A1122A3480
[+] ATQA: 0044
[+] SAK: 00
[+] Card type: MIFARE Ultralight C
[+] Signature valid: true
[+] Block 0: 04C5A112
[+] Block 1: 2A3480A1
[+] Block 2: BA981248
[+] Pages total: 48
[+] Page size: 4 bytes

Win. Význam parametrů

SAK (Select Acknowledge)

• Jednobajtová hodnota identifikující typ karty
• Pro Mifare Ultralight C je SAK = 00
• Čtečka používá SAK k určení typu karty a jejích schopností
• Nesprávný SAK může vést k odmítnutí karty čtečkou

ATQA (Answer To Request Type A)

• Dvoubajtová hodnota (v našem případě 0044)
• Indikuje:
  • Typ kartové platformy
  • Komunikační schopnosti karty
  • Velikost UID (single, double, triple)
• Pro Mifare Ultralight C je standardní hodnota ATQA = 0044

Win. Vytvoření testovací karty

Pro úplnou emulaci musíme nastavit všechny parametry:

[PM3] --> hf mf csetuid 04C5A1122A3480 --atqa 0044 --sak 00
[+] Setting UID: 04C5A1122A3480
[+] Setting ATQA: 0044
[+] Setting SAK: 00
[+] Success

Řešení běžných problémů ve Windows

Win. Problém s COM portem

• Řešení: Zkontrolujte ve Správci zařízení správné číslo COM portu
• Případně zkuste odpojit a znovu připojit zařízení

Win. Chyba při kompilaci

• Řešení: Ujistěte se, že máte nainstalované všechny požadované komponenty Visual Studia
• Zkuste spustit make clean před novou kompilací

Win. Ovladač není podepsaný

• Řešení: Dočasně vypněte vynucení podpisu ovladačů v režimu spouštění Windows
• Nebo použijte testovací režim Windows

Win. Problémy s právy

• Řešení: Ujistěte se, že PowerShell běží jako administrátor
• Zkontrolujte práva v složce instalace

4.4 Pokročilé zabezpečení

4.4.1 3DES Autentizace

Mifare Ultralight C podporuje 3DES autentizaci, která by měla být implementována v každém bezpečném systému:

[PM3] --> hf mfu auth k 49454D4B41455242214E4143554F5946
[+] Authentication successful

Proces 3DES autentizace zahrnuje:

1. Generování náhodného čísla kartou
2. Šifrování čísla čtečkou pomocí 3DES klíče
3. Verifikace správnosti šifrování kartou
4. Vzájemná autentizace

4.4.2 Ekonomické aspekty zabezpečení

Náklady na implementaci

1. Základní systém (pouze UID)

   • Hardware: 100-200€ na čtečku
   • Software: 500-1000€
   • Údržba: 100€/rok

2. Plné zabezpečení (3DES)

   • Hardware: 200-400€ na čtečku
   • Software: 2000-3000€
   • Údržba: 500€/rok

Návratnost investice

• Snížení rizika podvodu o 95%
• Ochrana reputace
• Snížení pojistných nákladů

4.4.3 Bezpečnostní doporučení

Pro maximální zabezpečení systému doporučujeme:

1. Implementace 3DES autentizace

   • Použití unikátních klíčů pro každou kartu
   • Pravidelná obměna klíčů
   • Monitoring neúspěšných pokusů o autentizaci

2. Zabezpečení paměti

   • Nastavení lock bitů pro kritické sektory
   • Implementace přístupových podmínek
   • Pravidelná kontrola integrity dat

3. Monitoring a auditing

   • Logování všech přístupů
   • Detekce neobvyklých vzorů použití
   • Systém automatických alertů

Závěr

Spoléhání pouze na UID představuje kritické bezpečnostní riziko, které může mít fatální následky pro organizaci. V praxi se setkáváme s alarmující situací, kdy IT oddělení a management firem vědomě ignorují dostupné bezpečnostní mechanismy z důvodu úspory nákladů nebo pohodlnosti implementace. Tento přístup je obdobný jako instalace bezpečnostních dveří a následné jejich nezamykání.

Bezpečnostní aspekty přístupových systémů vyžadují důkladnou analýzu implementovaných technologií a jejich potenciálních zranitelností. Přestože komponenty přístupových systémů zpravidla disponují certifikací Národního bezpečnostního úřadu (NBÚ), v praxi se stále setkáváme s nasazením technologicky nedostatečných identifikačních metod.

Současná praxe využívání RFID (Radio-Frequency Identification) technologie, především v podobě bezkontaktních čipových karet, vykazuje značné bezpečnostní nedostatky. Kritickým příkladem je široce rozšířená platforma MIFARE Classic, jejíž proprietární šifrovací algoritmus Crypto-1 byl kompromitován již v roce 2008. Analogicky, konkurenční řešení HID Prox prokázalo závažné bezpečnostní nedostatky v roce 2009, kdy byla dokumentována možnost duplikace identifikačních tokenů.

Zvláště alarmující je rozšířená praxe implementace přístupových systémů založených výhradně na čtení unikátního identifikátoru karty (UID), která zcela opomíjí dostupné kryptografické zabezpečení. Tato metodika představuje významné bezpečnostní riziko.

Pro zajištění adekvátní úrovně zabezpečení je esenciální implementace moderních přístupových systémů využívajících robustní kryptografické algoritmy (3DES, AES). Doporučenými technologickými řešeními jsou například MIFARE DESFire EV1 nebo HID iCLASS, které reprezentují současný standard v oblasti fyzické bezpečnosti a kontroly přístupu.

Problémy současné praxe

• IT oddělení často volí nejjednodušší řešení bez ohledu na bezpečnostní dopady
• Management není ochoten investovat do "neviditelných" bezpečnostních opatření
• Bezpečnostní incidenty jsou často řešeny až po jejich vzniku
• Chybí proaktivní přístup k bezpečnosti

Důsledky nedbalého přístupu

• Přímé finanční ztráty dosahující milionů korun
• Poškození reputace firmy
• Ztráta důvěry zákazníků a partnerů
• Právní následky při úniku citlivých dat
• Zvýšené náklady na následné řešení incidentů

Výzva k změně

Implementace plných bezpečnostních mechanismů není volitelným luxusem, ale nezbytností v současném bezpečnostním prostředí. Je kritické, aby organizace:

1. Přehodnotily svůj přístup k zabezpečení
2. Implementovaly dostupné bezpečnostní mechanismy v plném rozsahu
3. Pravidelně školily zaměstnance v oblasti bezpečnosti
4. Prováděly pravidelné bezpečnostní audity

Náklady na prevenci jsou vždy výrazně nižší než potenciální škody způsobené bezpečnostním incidentem. V době, kdy jsou útoky na přístupové systémy stále sofistikovanější, si žádná organizace nemůže dovolit ignorovat základní bezpečnostní principy z důvodu domnělé úspory nákladů.

Srovnání nákladů

Základní implementace (pouze UID)

• Počáteční náklady: 50 000 Kč
• Roční údržba: 10 000 Kč
• Riziko incidentu: Vysoké
• Potenciální škody: 1-10 milionů Kč

Plná implementace (3DES)

• Počáteční náklady: 200 000 Kč
• Roční údržba: 50 000 Kč
• Riziko incidentu: Minimální
• Potenciální škody: <100 000 Kč

The post Špatné zabezpečení NFC docházkových systémů UID-only autentizace first appeared on Hard Wired.

Článek navazuje na Gitea v Dockeru s daty na Synology a Gitea na veřejné subdoméně. Tentokrát si ukážeme, jak vytvořit nový soukromý repozitář a posílat do něj změny.

Předpoklady

• Máme funkční Giteu na vlastní subdoméně, do které se dokážeme přihlásit
• Byly provedeny všechny kroky z předchozích návodů
• Článek se zaměřuje na Windows ale na Linuxu to bude to samé nebo hodně podobné
• Na počítači máme funkční SSH a GIT.

Vytvoření soukromého repozitáře

Přihlásíme se do naší Gitey. Pluskem zvolíme nový repozitář. Zadáme název repozitáře, soukromy-repo-na-smazani. Vybereme Nastavit repozitář jako soukromý a potvrdíme. Vytvoří se prázdný repozitář.

Vytvoření SSH klíče

Pro komunikaci s repozitářem budeme používat SSH. Budeme muset vytvořit pár klíčů, soukromý a veřejný. Soukromý bude u nás na počítači a veřejný budeme nahrajeme k repozitáři, jako přístupový.

Ujistíme se že v c:\Users\<username> máme složku .ssh. Poté v terminálu zadáme příkaz na vygenerování klíče pro přístup do Gitea.

ssh-keygen -t rsa -b 4096 -C "<váš email>" -f ~/.ssh/gitea-example-com

To ve složce .ssh vytvoří dva soubory. gitea-example-com a gitea-example-com.pub. Ten druhý musíme nahrát k repozitáři.

Přidání klíče do Gitea repozitáře

Otevřeme si repozitář. Nastavení > Klíče pro nasazení > Přidat klič pro nasazení. Pojmenujeme si ho, například Domácí klíč. A obsah gitea-example-com.pub zkopírujeme do pole Obsah. Nesmíme zapomenout zaškrtnout volbu Povolit zápis a potvrdit.

Nastavení SSH na počítači

Pokud ve složce c:\Users\<username>\.ssh nemáte soubor config, vytvořte ho a přidejte následující.

Host gitea.example.com
  HostName gitea.example.com
  User git
  Port 222
  IdentityFile c:\Users\<username>\.ssh\gitea-example-com
  IdentitiesOnly yes

Pro hosta gitea.example.com se nastaví odpovídající host name, uživatel, port pro připojení a cesta k privátnímu klíči. Volba IdentitiesOnly zajistí, že pro konkrétního hosta se použijí parametry, které jsou nastaveny.

Připojení repozitáře

Buď můžete připojit už existující repozitář z vašeho počítače, nebo vytvoříte nový. Vytvoříme nový.

Vytvořte složku kde bude nový repozitář. Obecně se pojmenuje názvem repozitáře co jsme vytvořili na naší Gitea.

mkdir soukromy-repo-na-smazani

Přesuneme se do něj.

cd soukromy-repo-na-smazani

Inicializujeme prázdný repozitář.

git init

Vytvoříme první soubor README.md.

touch README.md

Vytvoříme hlavní větev main.

git checkout -b main

Přidáme soubor README.md do git repozitáře.

git add README.md

Vytvoříme první commit.

git commit -m "První commit"

Napojíme náš repozitář z Gitea.

git remote add origin git@gitea.example.com:<gitea username>/soukromy-repo-na-smazani.git

Odešleme změny do vzdáleného repozitáře.

git push -u origin main

Když se nyní podíváme do repozitáře na gitea.example.com, uvidíme náš první commit.

The post Gitea a první soukromý repozitář first appeared on Hard Wired.

Volné pokračování Gitea v Dockeru s daty na Synology. Tentokrát nastavíme aby nám naše self-hostovaná Gitea jela na naší veřejné doméně.

Předpoklady

• Máme nainstalovanou Giteu podle předchozího návodu.
• Máme koupenou vlastní doménu. (pro tutoriál to bude example.com)
• Používáme Nginx jako reverzní proxy.
• Máme přistup do routeru nebo možnost přesměrovávat porty.
• Už jste Giteu jednou spustili a nastavili admin účet.

Nastavení reverzní proxy

Vytvoříme soubor gitea.example.com.

nano /etc/nginx/sites-available/gitea.example.com

server {
    listen 80;
    server_name gitea.example.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name gitea.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Při zadání gitea.example.com budou všechny požadavky přesměrovávány na server, kde sedí Gitea a naslouchá na portu 3000. Také se automaticky provede přesměrování z HTTP na HTTPS.

Certifikáty jsou pomocí Let's Encrypt a Certbot, ale to je na jiný návod.

Poté je potřeba dostat symlink do /etc/nginx/sites-enabled.

sudo ln -s /etc/nginx/sites-available/gitea.example.com /etc/nginx/sites-enabled/

Pak je dobré zkontrolovat, jestli Nginx naši novou konfiguraci vezme za svou.

sudo nginx -t

Jestli je vše OK, tak bude potřeba Nginx restartovat.

sudo systemctl restart nginx

Od teď bude gitea.example.com směrovat na naši Giteu.

Nastavení Gitea

Předpoklad je, že Gitea běží v kontejneru. Musíme upravit nastavení. Do Docker kontejneru se můžete dostat pomocí příkazové řádky docker exec -it <container_name_or_id> /bin/bash. Pokud máte rozchozený Portainer, stačí v něm kliknout na ikonku shellu a připojíte se do kontejneru jako root.

Po připojení do kontejneru bude pravděpodobně jako uživatel root. Gitea (v závislosti na typu image) má data uložena v /data. Ale jako uživatel git. Proto než začnete něco měnit, tak je dobré se přepnout za uživatele git. To provedete pomocí su git.

Bude potřeba udělat pár úprav v souboru app.ini, ten se nachází v /data/gitea/conf. (v Gitea kontejneru je dostupný editor VI)

DOMIAN = gitea.example.com
SSH_DOMAIN = gitea.example.com
ROOT_URL = https://gitea.example.com

Tím nastavíme Giteu na naši doménu.

Je předpoklad, že je to soukromý git server, takže nechceme aby se tam mohli lidé samovolně registrovat. Takže je potřeba vypnout registrace.

DISABLE_REGISTRATIONS = true

Poté je potřeba kontejner restartovat.

Přesměrování portů

Gitea cotainer (pokud jste to nezměnili) propaguje porty 3000 (web) a 222 (ssh). Proto je potřeba zajistit aby byl port 222 zvenku dostupný a přesměrovával na server kde Gitea sedí. Jestli máte domácí router který sedí na veřejné IP adrese tak provedete přesměrování portů na něm.

Závěr

Existují ještě další nastavení, ale po těchto pár krocích by už měla Gitea fungovat na vaší doméně.

The post Gitea na veřejné subdoméně first appeared on Hard Wired.

Gitea je self-hostovaná varianta Bitbucketu nebo GitHubu. V následujícím krátkém návodu se podíváme jak nainstalovat Giteu pomocí Dockeru a ukládat data na Synology NAS.

Prerekvizity

• Nainstalovaný a nastavený Docker
• Nainstalovaný a nastavený Synology NAS

Myšlenka

Pro spuštění Gitea serveru použijeme docker compose. Gitea bude používat PostgreSQL databázi. Pro ukládání dat jak pro Giteu, tak i pro Postgres, použijeme docker volumes. Docker volumes nebudou lokální, ale přes protokol NFS budou směřovat na Synology NAS.

Pro potřeby tutoriálu bude mít server IP adresu 192.168.10.1 a Synology NAS 192.168.10.2.

Nastavení Synology

Ovládací panel > Souborové služby > NFS povolte službu NFS.

Ovládací panel > Sdílená složka > Vytvoření sdílené složky. Název docker-volumes. Nepřiřazujeme oprávnění pro uživatele nebo skupiny.

Klikneme na složku docker-volumes a zvolíme upravit. Poté Oprávnění NFS. Klikneme na tlačítko Vytvořit. Do pole Název hostitele nebo IP adresa vložíme IP adresu našeho serveru, tedy 192.168.10.1. Tím umožníme našemu serveru přístup k této složce. Dále nastavíme:

• Oprávnění: Čtení/Zápis
• Squash: Žádné mapování
• Zabezpečení: sys
• Povolit asynchronní
• Povolit připojení z portů bez oprávnění (porty vyšší než 1024)
• Umožňuje uživatelům přístup k připojeným podsložkám

A uložíme.

Poté otevřeme File Station a v naší složce docker-volumes vytvoříme následující podsložky:

• gitea-data
• gitea-postgres

To je na Synology vše.

docker-compose.yaml

Konfigurační soubor vytvoří síť gitea kde na sebe uvidí kontejnery gitea a gitea-db. Vytvoří dva volumes a pomocí protokolu NFS je nasměruje na námi sdílenou složku v Synology NAS.

Docker-compose soubor můžeme spustit pomocí docker-compose up -d. Pokud máte na serveru nainstalovaný a spuštěný Portainer, tak jde docker-compose konfigurace spustit jako stack.

Webové rozhraní poté bude přístupné na http://192.168.10.1:3000.

networks:
  gitea:

volumes:
  gitea-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-data"

  gitea-postgres:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-postgres"

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=gitea-db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=supersecretpassword
    restart: always
    networks:
      - gitea
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - gitea-db

  gitea-db:
    image: postgres:16
    container_name: gitea-db
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=supersecretpassword
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - gitea-postgres:/var/lib/postgresql/data

The post Gitea v Dockeru s daty na Synology first appeared on Hard Wired.

Úvod

Tails 6.0 přináší řadu nových funkcí a vylepšení, které dále posilují anonymitu a soukromí uživatelů. Tails je operační systém zaměřený na anonymitu a soukromí, který je navržen tak, aby byl snadno použitelný i pro začátečníky. Používá se k ochraně uživatelů před sledováním a odposlechem online aktivit. Tails je založen na Debianu a je vybaven řadou nástrojů pro anonymní komunikaci a ochranu soukromí, včetně Tor Browseru, KeePassXC pro správu hesel a Electrum pro bitcoinové transakce.

Tails – anonymní operační systém, svobodný a soukromí přístup na internet

Nové funkce v Tails 6.0

Mezi nejvýznamnější funkce patří. Automatické připojení externích zařízení: Tails 6.0 automaticky připojí externí úložná zařízení, USB klíčenky a externí pevné disky. Pokud úložné zařízení obsahuje šifrovaný oddíl, Tails 6.0 vám nabídne automatické odemknutí šifrování.

Ochrana před škodlivými USB zařízeními: Tails 6.0 ignoruje všechna USB zařízení, která jsou připojena, když je vaše obrazovka zamčená. To chrání před útoky, kdy by útočník mohl připojit k vašemu počítači škodlivé zařízení USB a spustit software, který by prolomil zabezpečení Tails.

Tmavý režim a noční světlo: Tails 6.0 umožňuje přepínat mezi světlým a tmavým režimem a aktivovat noční režim s teplejšími barvami a nižším jasem.

Snadnější screenshoty a screencasty: GNOME 43 v Tails 6.0 zavádí novou zkratku v systémové nabídce, která usnadňuje pořizování snímku obrazovky nebo nahrávání screencastu.

Snazší Gmail v Thunderbirdu: Díky změnám v Thunderbirdu i Gmailu je mnohem snazší nakonfigurovat účet Gmail v Thunderbirdu v Tails 6.0~rc1.

Diceware přístupové fráze v dalších 5 jazycích: Navrhované přístupové fráze pro trvalé úložiště se nyní generují také v katalánštině, němčině, italštině, portugalštině a španělštině.

Další změny a aktualizace:

• Tails 6.0 aktualizuje mnoho aplikací obsažených v Tails, včetně Electrum, KeePassXC, Metadata Cleaner, OnionShare, textového editoru, Inkscape, Audacity, GIMP a Kleopatra.
• Byly odebrány funkce, které nejsou dostatečně spolehlivé nebo užitečné, včetně možnosti odebrat metadata ze souborů a vymazat volné místo na disku.
• Byly opraveny některé problémy se speciálními znaky a nelatinkovými skripty na klávesnici na obrazovce.
• Vylepšená ochrana před malwarem: Tails 6.0 přichází s aktualizovanými virovými databázemi a pokročilejšími nástroji na detekci a zneškodnění malwaru, čímž zaručuje ještě robustnější ochranu před online hrozbami.
• Automatické připojování externích zařízení: Tails 6.0 automaticky připojí a zpřístupní v souborovém manažeru externí úložná zařízení, USB klíčenky a externí pevné disky. Pro šifrovaná zařízení nabídne možnost automatického odemknutí pomocí hesla či klíčového souboru. To šetří čas a minimalizuje riziko omylného připojení nezabezpečeného zařízení, které by mohlo ohrozit uživatele.

Známé potíže v Tails 6.0~rc1

• Tails 6.0~rc1 není spolehlivě reprodukovatelný.
• OnionShare 2.6 má několik problémů, které můžou mít bezpečnostní důsledky.
• Automatické připojení externích zařízení může narušovat některé funkce, jako je zálohování trvalého úložiště a Tails Cloner.

Stažení Tails 6.0

Tails 6.0 je stále ve vývoji, ale testovací verzi 6.0~rc1 si můžete stáhnout z webu Tails.

Další informace:

• Novinky v Tails 6.0: https://tails.net/news/version_6.0/index.en.html
• Známé potíže v Tails 6.0~rc1: [neplatná adresa URL byla odstraněna]_
• Dokumentace Tails: https://tails.net/doc/index.en.htmlÚvod do Tails

Závěr

Tails 6.0 je významná aktualizace, která přináší řadu nových funkcí a vylepšení, které dále posilují anonymitu a soukromí

The post Vyšel Tails 6.0 – Svoboda na internetu je ještě bezpečnější. first appeared on Hard Wired.

Dostupnost jednodeskových počítačů Raspberry Pi se sice již podstatně zlepšila, ale stále existují modely, ke kterým se někteří prostě nedostanou protože je jich málo a je velká poptávka. Jeden z takových modelů je RPI Zero 2W. Pro ty, kteří hledají alternativu s podobnými možnostmi a výkonem, ale přesto odlišným přístupem, přichází do hry nový hráč: Orange Pi Zero 2W.

Podíváme se na to co Orange Pi Zero 2W nabízí a proč by mohl být zajímavou volbou pro ty, kteří se chtějí ponořit do světa jednodeskových počítačů. Porovnáme ho s RPI Zero 2W a zjistíme, jaký potenciál a možnosti přináší. Ať už jste začínající nadšenec do elektroniky nebo zkušený vývojář, Orange Pi Zero 2W by vás mohl překvapit svými schopnostmi a flexibilitou.

Pokud hledáte kompaktní, ale i výkonný jednodeskový počítače pro své projekty v oblasti IoT, inteligentní domácnosti nebo televizních boxů, Orange Pi Zero 2W by mohl být tím pravým řešením. Tento malý, ale výkonný SBC počítač je poháněno čtyřjádrovým procesorem Allwinner H618 Cortex-A53 s frekvencí až 1,5 GHz a nabízí širokou škálu možností a funkcí.

Podíváme se podrobněji na Orange Pi Zero 2W a zjistíme, proč je to tak výjimečné jednodeskové řešení. Prozkoumáme jeho specifikace, rozšiřitelnost, kompatibilitu s operačními systémy a mnoho dalšího. Pokud máte zájem o vývojové projekty, které vyžadují kompaktní a výkonný hardware, nebo jednoduše hledáte způsob, jak využít IoT technologie ve svém domově, tento článek vám poskytne všechny potřebné informace.

Podíváme se na jejich parametry:

Vlastnosti

Raspberry

Orange Pi Zero 2W a Raspberry Pi Zero 2W jsou dva malé jednodeskové počítače, které nabízejí kompaktní a cenově dostupnou řešení pro vývojové projekty a domácí automatizaci. I když mají některé společné vlastnosti, jako je podpora Wi-Fi a Bluetooth, existují mezi nimi některé významné rozdíly.

Prvním rozdílem je procesor. Orange Pi Zero 2W je vybaven čtyřjádrovým procesorem Allwinner H618 Cortex-A53 s frekvencí 1,5 GHz, zatímco Raspberry Pi Zero 2W používá procesor Broadcom BCM2710B0 Cortex-A53 s frekvencí 1,2 GHz. To dává Orange Pi mírnou výhodu výkonu.

Dalším rozdílem je grafický čip. Orange Pi Zero 2W používá Mali G31 MP2 s podporou OpenGL ES 1.0/2.0/3.2, OpenCL 2.0 a Vulkan 1.1, zatímco Raspberry Pi Zero 2W má VideoCore VI s podporou OpenGL ES 3.2, Vulkan a dalších standardů.

Co se týče paměti, Orange Pi Zero 2W nabízí různé konfigurace RAM, zatímco Raspberry Pi Zero 2W má pevně stanovenou 512 MB RAM.

Raspberry Pi Zero 2W má také některé výhody v oblasti ekosystému a komunity. Raspberry Pi je známý svým rozsáhlým ekosystémem a obrovskou komunitou uživatelů, což znamená, že je k dispozici široká škála dokumentace, projektů a podpory.

Závěrem lze říci, že oba počítače mají svá specifická využití a výhody. Orange Pi Zero 2W nabízí větší výkon a flexibilitu v konfiguraci paměti, zatímco Raspberry Pi Zero 2W má silnou komunitu a ekosystém. Volba mezi nimi závisí na konkrétních požadavcích a potřebách vašeho projektu.

Orange Pi Zero 2W přináší kompaktní a výkonné řešení pro vývojové projekty a domácí automatizaci. S Micro HDMI 2.0 a dvěma USB-C porty nabízí široké možnosti připojení periferií, a to včetně napájení. Duální WiFi5 a Bluetooth 5.0 s externí anténou zajišťují stabilní a rychlé bezdrátové připojení.

Navíc, s rozšiřující deskou, která obsahuje USB 2.0 konektory, RJ45 10/100 Mb/s, 3,5 mm audio jack, tlačítka a IR přijímač, je možné rozšířit funkcionalitu Orange Pi Zero 2W dle potřeby. S cenou od 16 (pro verzi s 1 GB RAM) do 24 dolarů (pro verzi s 4 GB RAM) je to cenově dostupný a výkonný mini počítač pro vaše projekty.

Rozšiřující deska je k dispozici za pouhých 5 dolarů, což je skvělý způsob, jak přizpůsobit Orange Pi Zero 2W vašim potřebám. Využijte tuto kompaktní a cenově dostupnou platformu pro své kreativní nápady a projekty.

Závěr

Pro technické nadšence, vývojáře a experimentátory nabízí Orange Pi Zero 2W kompaktní a cenově dostupnou platformu, která otevírá brány k různým inovativním projektům. S čtyřjádrovým procesorem, podporou Wi-Fi a Bluetooth, a širokým spektrem rozhraní pro rozšíření funkcí se stává ideálním společníkem pro tvorbu domácích automatizací, IoT zařízení, či vzdělávacích experimentů. Jeho výkon a flexibilita jej řadí mezi zajímavé alternativy na trhu jednodeskových počítačů. Orange Pi Zero 2W představuje nejen technickou výzvu, ale také základ pro vytvoření zajímavých projektů, které posunou vaše dovednosti a nápady na novou úroveň.

The post Orange Pi Zero 2W first appeared on Hard Wired.

O co jde

Uděláme bota co načte webovou stránku, klikne na čudlík a stáhne soubor.

Použijeme k tomu knihovnu Puppeteer a samotný kód budeme pouštět v Dockeru.

Větší podrobnosti a vysvětlení zakládání NodeJs projektu v Dockeru najde v článku NodeJS develompent v Dockeru.

Příprava projektu

Založíme nový projekt:

mkdir puppet
cd puppet
npm init -y

Upravíme package.json a přidáme do něj knihovnu puppeteer:

{
  "name": "puppet",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "puppeteer": "^19.2.0"
  }
}

Vytvoříme Dockerfile, který použije jako základ obraz s node v16, nainstaluje Chrome prohlížeč a nakopíruje projekt do Docker obrazu.

FROM node:16

RUN apt-get update && apt-get install gnupg wget -y && \
  wget --quiet --output-document=- https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor > /etc/apt/trusted.gpg.d/google-archive.gpg && \
  sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
  apt-get update && \
  apt-get install google-chrome-stable -y --no-install-recommends && \
  rm -rf /var/lib/apt/lists/*

ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true \
    PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome-stable

WORKDIR /app
COPY package*.json .
RUN npm install
COPY . ./

Vytvoříme index.js soubor a necháme ho jen vypsat zprávu do konzole.

touch index.js

console.log('Hello from docker')

Není úplně špatné vytvořit i .dockerignore soubor.

node_modules
Dockerfile
.dockerignore
.git
.gitignore
README.md
docker-compose*

Sestavíme obraz.

docker build -t puppet-app-image .

A spustíme Docker kontejner.

# %cd% je aktuální složka ve Windows, pro jiné systémy použijte adekvátní náhradu

docker run -d --tty --name puppet-app -v %cd%:/app -v /app/node_modules puppet-app-image

--tty parametr je nutný. V opačném případě se Docker kontejner spustí a pak hned úspěšně ukončí. Za normálních okolností předpokládá, že v něm něco poběží a až se to ukončí tak skončí taky. TTY toto chování potlačí.

Jakmile kontejner běží, můžeme se do něj přihlásit:

docker exec -it puppet-app bash

Vevnitř se ocitneme ve složce /app, kde je náš projekt a můžeme zkusit spustit náš program.

nodejs index.js

Měl by nám odpovědět Hello from docker.

Bot

Pro ukázku bude bot stahovat zdrojový kód puppeteeru z githubu. Upravíme index.js následovně.

const puppeteer = require('puppeteer')

;(async () => {
    const browser = await puppeteer.launch({
        headless: true,
        args: ['--no-sandbox'],
    })

    const page = await browser.newPage()
    page.setViewport({ width: 1920, height: 1080 })

    const client = await page.target().createCDPSession()
    await client.send("Page.setDownloadBehavior", {
        behavior: "allow",
        downloadPath: './'
    })

    await page.goto(
        'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
        { waitUntil: 'networkidle2' }
    )
    await page.waitForTimeout(1000)

    await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
    await page.waitForTimeout(5000)

    await page.screenshot({ path: './screen.jpg', fullPage: true })

    await browser.close()
})()

Naimportujeme do našeho projektu knihovnu puppeteer.

const puppeteer = require('puppeteer')

Budeme volat asynchronní funkce v java scriptu a budeme používat klíčové slovo await, které čeká na provedení asynchronní funkce. Problém je to, že await se může objevit jen v asynchronní funkci. Tudíž náš kód musíme do jedné takové zabalit a rovnou spustit.

;(async () => {
    // code
})()

Vytvoříme nový headless prohlížeč.

const browser = await puppeteer.launch({
    headless: true,
    args: ['--no-sandbox'],
})

Vytvoříme novou stránku/tab a nastavíme rozlišení.

const page = await browser.newPage()
page.setViewport({ width: 1920, height: 1080 })

Pro tuto konkrétní stránku nastavíme automatické stahovaní do určitého adresáře. V našem případě adresář s projektem. Takhle nebudeme vyvolávat dialog pro umístění stahovaného souboru.

const client = await page.target().createCDPSession()
await client.send("Page.setDownloadBehavior", {
    behavior: "allow",
    downloadPath: './'
})

V naší stránce/tabu otevřeme požadovanou github stránku.

await page.goto(
    'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
    { waitUntil: 'networkidle2' }
)
await page.waitForTimeout(1000)

Klikneme na odkaz pro stažení a chvíli počkáme, než se soubor stáhne

await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
await page.waitForTimeout(5000)

K definování toho na co se má kliknout se používá CSS Selector (draft, mdn). Ten pomocí html elementů, tříd, atributů a dalších dokáže sestavit unikátní cestu k prvku na stránce. Stránky generované nějakým frameworkem umí potrápit i s takhle dlouhým selektorem, jako v tomto případě.

Pak už si jen uděláme momentku, v jakém stavu stránku opouštíme.

await page.screenshot({ path: './screen.jpg', fullPage: true })

A prohlížeč korektně zavřeme.

await browser.close()

Spuštění kódu

V konzoli se připojíme k našemu kontejneru.

docker exec -it puppet-app bash

A spustíme našeho bota.

node index.js

Pokud vše proběhne, jak má, tak ve složce projektu budete mít jak stažený soubor, tak fotku stránky těsně před tím než jste ji opustili.

Toto je velice hrubý nástřel toho, co Puppeteer dokáže na konkrétním případě. Výhodou je, že se opravdu spustí prohlížeč, ve kterém můžeme ovládat i dynamicky generované single page aplikace. Nevýhodou je, že pokud se struktura stránky změní moc, tak musíte upravit i váš kód.

Happy coding!

The post Puppeteer download BOT first appeared on Hard Wired.

Nepravidelný občasník, který jednou za čas ukáže nějakou užitečnou nebo zajímavou tui (terminal user interface) aplikaci.

du příkaz vám za normálních okolností vrátí využití disku. Musíte ho teda trochu "potunit", abyste nedostali kilometr dlouhý výpis, ale z trochou cviku se dá efektivně používat.

Když budete chtít zjistit kolik která složka v aktuálním adresáři zabírá, stačí do terminálu napsat:

du -h --max-depth=1

A dostanete pěkný výpis aktuální složky. Například:

4.0K    ./.config
26M     ./.local
7.8M    ./.node-red
27M     ./.npm
0       ./bin
67M     .

Co se vše dá s du dělat najdete v dokumentaci.

Ale pokud jste jako já a stejně vždy ty parametry nějak zapomenete, tak pro vás existuje řešení v podobě ncdu. NCurses disk usage (ncdu) je tui aplikace nad du, která vám umožní interaktivně procházet složky a zjišťovat jejich velikosti.

Na debianím systému se aplikace nachází v repozitářích.

sudo apt install ncdu

Pak už jen stačí do terminálu napsat:

ncdu

A začít zkoumat velikosti složek o trochu více interaktivně.

The post TUI #1 – NCDU first appeared on Hard Wired.