dcode

Generic Structure for File Events

The purpose of this document is to provide examples of metadata that describe "file events". These events are events that describe analysis of file objects as is currently done in cyber security.

Proposed ECS Event (non-ECS data dropped)

{
    "file": {
        "name": "eicar.com",
        "size": 68,

dcode

Structure for x509 File Events

The purpose of this document is to provide examples of metadata that describe "file events" for x509 file objects. These file objects are commonly used in TLS handshakes, digital signatures, file encryption, and entity authentication for directory services.

Proposed ECS Event (non-ECS data dropped)

{
    "@timestamp": "blah",
    "file": {

dcode

filter {
  cidr {
    add_tag => [ "local_source" ]
    address => [ "%{[source][ip]}" ]
    network => [ "10.0.0.0/8", "172.16.0.0/20", "192.168.0.0/16" ]
  }
  cidr {
    add_tag => [ "local_destination" ]
    address => [ "%{[destination][ip]}" ]
    network => [ "10.0.0.0/8", "172.16.0.0/20", "192.168.0.0/16" ]

dcode

containers=(
  docker.io/library/consul:latest
  docker.io/library/vault:latest
  docker.io/library/redis:alpine
  docker.io/library/nginx:alpine
  docker.io/library/alpine:latest
)

urlencode() {
    # urlencode <string>

dcode

---
# Mostly working, but weird cartesian products of groups
scenario:
  name: single-node  # optional
dependency:
  name: galaxy
driver:
  name: delegated
  options:
    managed: True

dcode

Setup CoreDNS w/ etcd backend

Why CoreDNS

[CoreDNS][coredns] was designed from the ground up to provide robust, plugin-based DNS server for use in cloud environments. Namely, it serves as the default primary service discovery mechanism for Kubernetes.

Using CoreDNS allows us to have a lightweight DNS server on RockNSM (11 Mb binary is all that's needed!) to facilitate multi-node service discovery. Alternatively, if another existing DNS service is available, this can be used instead. Aligning with the way the Kubernetes manages service discovery also allows us to build new RockNSM features in parallel with the coming Kubernetes support.

RockNSM Application

dcode

Podman has recently added support for named volumes, which is super handy. As of today (2018-01-17), it supports the local driver, which effectively will bind-mount a tracked directory into one or more containers. It's helpful to be able to limit the size of data volumes though so that one container doesn't exhaust the resources of another.

Fortunately, the XFS filesystem let's us handle this natively using "project quotas". XFS allows setting quotas based on username, group, or project. The project quota effectively maps a project ID to a path on a filesystem.

dcode

#!/bin/bash 

set -eu -o pipefail

export CERT_URL='https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/zip/unclass-certificates_pkcs7_DoD.zip'

# Download & Extract DoD root certificates
cd ~/Downloads/ || exit 1
/usr/bin/curl -LOJ "${CERT_URL}"

dcode

# Creates new pod named `test` with `running` status with `infra` container only
sudo podman pod create --name test

# Pauses the named pod and all containers in the pod
sudo podman pod pause test

# Unpauses the named pod and all containers in the pod
sudo podman pod unpause test

# Show all pods and their status

dcode

#!/usr/bin/env python3
import argparse
from pathlib import Path
import csv
from elasticsearch import Elasticsearch
from elasticsearch.exceptions import TransportError
from elasticsearch.helpers import bulk, streaming_bulk

parser = argparse.ArgumentParser(description='Simple upload of a CSV to Elasticsearch for analysis')
#group = parser.add_mutually_exclusive_group()