Git Product home page Git Product logo

stenographer's Introduction

Stenographer

Overview

Stenographer is a full-packet-capture utility for buffering packets to disk for intrusion detection and incident response purposes. It provides a high-performance implementation of NIC-to-disk packet writing, handles deleting those files as disk fills up, and provides methods for reading back specific sets of packets quickly and easily.

It is designed to:

  • Write packets to disk, very quickly (~10Gbps on multi-core, multi-disk machines)
  • Store as much history as it can (managing disk usage, storing longer durations when traffic slows, then deleting the oldest packets when it hits disk limits)
  • Read a very small percentage (<1%) of packets from disk based on analyst needs

It is NOT designed for:

  • Complex packet processing (TCP stream reassembly, etc)

  • It’s fast because it doesn’t do this.  Even with the very minimal, single-pass processing of packets we do, processing ~1Gbps for indexing alone can take >75% of a single core.

  • Processing the data by reading it back from disk also doesn’t work:  see next bullet point.

  • Reading back large amounts of packets (> 1% of packets written)

  • The key concept here is that disk reads compete with disk writes… you can write at 90% of disk speed, but that only gives you 10% of your disk’s time for reading.  Also, we’re writing highly sequential data, which disks are very good at doing quickly, and generally reading back sparse data with lots of seeks, which disks do slowly.

For further reading, check out DESIGN.md for a discussion of stenographer's design, or read INSTALL.md for how to install stenographer on a machine.

Querying

Query Language

A user requests packets from stenographer by specifying them with a very simple query language. This language is a simple subset of BPF, and includes the primitives:

host 8.8.8.8          # Single IP address (hostnames not allowed)
net 1.0.0.0/8         # Network with CIDR
net 1.0.0.0 mask 255.255.255.0  # Network with mask
port 80               # Port number (UDP or TCP)
ip proto 6            # IP protocol number 6
icmp                  # equivalent to 'ip proto 1'
tcp                   # equivalent to 'ip proto 6'
udp                   # equivalent to 'ip proto 17'

# Stenographer-specific time additions:
before 2012-11-03T11:05:00Z      # Packets before a specific time (UTC)
after 2012-11-03T11:05:00-07:00  # Packets after a specific time (with TZ)
before 45m ago        # Packets before a relative time
after 3h ago         # Packets after a relative time

NOTE: Relative times must be measured in integer values of hours or minutes as demonstrated above.

Primitives can be combined with and/&& and with or/||, which have equal precendence and evaluate left-to-right. Parens can also be used to group.

(udp and port 514) or (tcp and port 8080)

Stenoread CLI

The stenoread command line script automates pulling packets from Stenographer and presenting them in a usable format to analysts. It requests raw packets from stenographer, then runs them through tcpdump to provide a more full-featured formatting/filtering experience. The first argument to stenoread is a stenographer query (see 'Query Language' above). All other arguments are passed to tcpdump. For example:

# Request all packets from IP 1.2.3.4 port 6543, then do extra filtering by
# TCP flag, which typical stenographer does not support.
$ stenoread 'host 1.2.3.4 and port 6543' 'tcp[tcpflags] & tcp-push != 0'

# Request packets on port 8765, disabling IP resolution (-n) and showing
# link-level headers (-e) when printing them out.
$ stenoread 'port 8765' -n -e

# Request packets for any IPs in the range 1.1.1.0-1.1.1.255, writing them
# out to a local PCAP file so they can be opened in Wireshark.
$ stenoread 'net 1.1.1.0/24' -w /tmp/output_for_wireshark.pcap

Downloading

To download the source code, install Go locally, then run:

$ go get github.com/google/stenographer

Go will handle downloading and installing all Go libraries that stenographer depends on. To build stenotype, go into the stenotype directory and run make. You may need to install the following Ubuntu packages (or their equivalents on other Linux distros):

  • libaio-dev
  • libleveldb-dev
  • libsnappy-dev
  • g++
  • libcap2-bin
  • libseccomp-dev

Obligatory Fine Print

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

This code is not intended (or used) to watch Google's users. Its purpose is to increase security on our networks by augmenting our internal monitoring capabilities.

stenographer's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

stenographer's Issues

Support for capturing on multiple interfaces.

I'm not sure how it would exactly go, but it'd be handy to support capture on multiple interfaces. In the config file, the interface entry could accept an array of interface names.

As for implementation, I think this would require a multiple of interfaces for thread options. i.e. listening on 2 interfaces requires 2 * n threads, where n is the number of threads per interface.

This simplifies configuration for multi-interface collection. I'm not even sure if it would be reasonable to start 2 or more stenographer sessions simultaneously (I'm thinking no due to the certs and the stenographer front end w/ stenoread).

stenotype make fail

Trying to compile on Raspberry Pi raspbian.
4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l GNU/Linux

~/.go/src/github.com/google/stenographer# make
errors with

g++ -std=c++0x -g -Wall -fno-strict-aliasing -rdynamic -O2 -fPIC -fPIE -pie -fstack-protector -D_FORTIFY_SOURCE=2 -c -o stenotype_gcc.o stenotype.cc In file included from packets.h:31:0, from aio.h:24, from stenotype.cc:80: stenotype.cc: In function ‘void st::CommonPrivileges(scmp_filter_ctx)’: stenotype.cc:290:41: error: ‘__NR_mmap’ was not declared in this scope SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0); ^ util.h:219:44: note: in definition of macro ‘CHECK_SUCCESS’ ::st::Error __check_success_error__ = (x); \ ^ stenotype.cc:290:3: note: in expansion of macro ‘SECCOMP_RULE_ADD’ SECCOMP_RULE_ADD(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0); ^ util.h: At global scope: util.h:55:6: warning: ‘{anonymous}::run_init_time’ defined but not used [-Wunused-variable] bool run_init_time = InitTime(); ^ Makefile:80: recipe for target 'stenotype_gcc.o' failed make: *** [stenotype_gcc.o] Error 1

Any help?

Stenographer should clean up old hidden files.

There should only ever be one hidden file in either the PKT or IDX directories... if steno sees more than that, it should delete the old ones. It should probably also just delete if they're over a certain age.

These files can appear due to crashes in stenotype, where it doesn't get a chance to properly close/rename blockfiles or indexes.

adjust packet/index timeframe from 1 minute?

It there a way to adjust the timeframe of a packet/index file to make it more than 1 minute?

We have the issue of hitting 30,000 files in a directory, but we'd like to keep more data. Wanted to know if it was possible to change the file time duration instead.

Also in the Threads section of Install.md, for the MaxDirectoryFiles variable, it states that with the 30.000 files limit, you can only store 8.3 days worth of data. It should be 20.833333 days. 1440 files/minutes per day. 30000 / 1440 = 20.833333

Thank you for any help.

Stenographer Performance Issue

Been running into a wall trying to get Stenographer to write more than 500/700 MiB/s to disk while monitoring 40gbyte/sec of traffic off of four bonded 10gBe interfaces.

We are running with 20 threads on a 44-core Xeon machine with 256GB of RAM and 20 raw 2TB SATA3 disks spread across three PCIe x8 controllers.

We have used ext3 and XFS with similar results, and have adjusted basically every tunable we can find, including with both cfq and deadline schedulers.

Any thoughts? The machines don't seem to be disk I/O-bound, CPU-bound, or even memory-bound. Pasted some strace stats below.

$ strace -cp 5034 -f

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 92.81  402.716075        8396     47966           clock_nanosleep
  3.75   16.284029         326     49875           poll
  1.96    8.508364      146696        58           restart_syscall
  1.48    6.404961         476     13457           io_submit
  0.00    0.018308           0    178853           clock_gettime
  0.00    0.004958           0     50392           io_getevents
  0.00    0.000030           0       134           getsockopt
  0.00    0.000000           0       134           write
------ ----------- ----------- --------- --------- ----------------
100.00  433.936725                340869           total

stenoread timeout

I am trying to find why the stenoread timeout was set to a nonconfigurable 890 seconds.

I've traced the change back to 2ddbee0. Was there a particular reason that a timeout was set, other than as a means to let the user know that the number of packets returned was a LOT?

spec file appears to not install jq or bring the stenokeys.sh with it.

When building from source and using the current spec file after creating the RPM, stenokeys.sh, does not appear anywhere on the system it is install on. Also when running 'which jq' the system is not able to locate it either. After manually installing jq and moving the stenokeys.sh onto the system it all works again. I haven't built a spec file before but after a weekend of research I should be able to submit fixes for this.

Add basic stats api

Add a call to our API for some basic stats. Some ideas are disk use, files tracked, config, more detailed info on indices (ips seen + count, ports ....).

Not set on what will go in here (and these are more than one call btw), but can start small and then keep adding.

Steno still behaves poorly on zero-packet interfaces

Stenotype still has issues with zero-packet interfaces. The integration test is a good example of this: often, stenotype must be kill -9'd, because it's unresponsive unless it gets some non-zero number of packets regularly.

Query Language Documentation Inconsistency

Under the sub-section "Query Language" on the main README.md there is a flaw in the query language referencing time specific queries. In the BPF subset definitions, underneath "#Stenographer-specific time additions:", the fourth line defines packets after a relative time as "before 3h ago" and should be corrected to "after 3h ago".

Fanout and the PacketsV3 object

I believe with the current setup, our SetFanout happens too late in the game. Basically, if we're using multiple threads, our SetFanout happens after the socket is already capturing, so there's a chance that all N threads will see the same packets between when they start and when SetFanout is called.

The best case here would probably be to have a PacketsV3 builder object that we create, configure, then activate:

PacketsV3* v3;
Error result = PacketsV3::Builder().SetFilter(...).SetFanout(...).Whatever(...).Build(&v3);

Not all packets in time range returned.

Or could be user error.

I am constructing a time based query that Stenographer is logging as: (after 2016-02-12T17:24:00Z and before 2016-02-12T17:27:00Z)

My goal is to get all packets between 17:24 and 17:27. However, this will only return packets between 17:25:29 and 17:26:29.

To get packets right up to 17:27 I have to extend my before to 2016-02-12T17:28:00Z. Likewise, to get packets that occured at 17:24:00 to 17:25:00 I have to extend my after time to 17:23.

Stenoread produces bad error messages for invalid filters

I'm running stenographer on Ubuntu 14.04.2 fresh, minimal install though vagrant (ubuntu/trusty64). Stenographer runs with minimal fuss to get setup (needs more ram or it just crashes), but when I run stenoread to pull back a traffic sample, I get the following:

# sudo -u stenographer stenoread  port=80
Running stenographer query 'port=80', piping to 'tcpdump '
tcpdump: unknown file format

tcpdump version info:

tcpdump -help
tcpdump version 4.5.1
libpcap version 1.5.3

Lastly, from the documentation, I assume that the format on disk should also be pcap, but the file magic doesn't line up:

sudo hexdump 1427121832309089 | head
0000000 0002 0000 0030 0000 0021 0000 0054 0000
0000010 0030 0000 3640 0000 0001 0000 0000 0000
0000020 26a8 5510 5e9b 0c96 26b2 5510 7089 0272
0000030 00b0 0000 26a9 5510 a6e3 3ab5 005a 0000

The standard tcpdump pcap magic is 0xa1b2c3d4.

My kernel (just in case it's useful) info:

# uname -a
Linux vagrant-ubuntu-trusty-64 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Mac OS X port?

Out of curiosity, what sort of effort do you think would be required to port stenographer to Mac OS X? I'm getting one error from go build:

# github.com/google/stenographer/blockfile
blockfile/blockfile.go:36:11: fatal error: 'linux/if_packet.h' file not found
 #include <linux/if_packet.h>
          ^
1 error generated.

Is that a more performant mechanism to get the raw packets than going through libpcap? If so, would it be possible to fall back on a libpcap implementation for other platforms? (I don't really know what I'm talking about here!)

Connection cutoff, like Time Machine

We assume that most of the "interesting" data is found in the first few packets of a connection. Scott Campbell et. al describe a "heavy tail flow effect," wherein a small number of flows dominate the overall volume of data. To address this, Time Machine supports a "connection cutoff," which I understand is very efficient. For example, in LBNL's infrastructure, limiting HTTP flows to 5MB results in a 480GB capture size, from 6100GB actual traffic.

Why not support it in Stenographer? And... thanks for the open source!

Edit: fixed link to Scott Campbell

Parse BPF into stenographer query

It would be really cool if stenoread could take in a BPF and:

  • parse out the stuff it can filter
  • send request to stenographer
  • send received packets through tcpdump for remaining filtering

It would have to translate:

net 10.0.0.0/8 and not port 53 -> ip=10.0.0.0-10.255.255.255
etc.

Note that things get really complicated when (), and/or, and especially multiple nested not/! come into play, like:

not (not (1.1.1.1 and 2.2.2.2)) -> ip=1.1.1.1 ip=2.2.2.2

Note also that there's some queries we can easily do by constructing query stuff that our current horrible syntax doesn't do, like: (host 1.1.1.1 and host 2.2.2.2) or (host 3.3.3.3 and host 4.4.4.4).

Queries are inefficient - don't use timestamps (?)

The effect (and the real problem) is that I got timeouts instead of any packets on stenoread/curl, even on simple queries like:
stenoread 'after 2017-07-31T14:05:00Z and before 2017-07-31T14:06:00Z and icmp' -n
or:
stenoread 'after 10m ago and icmp' -n

My config is:
2x Xeon E5-2660 v2
80 GB RAM
18 x 4 TB WD HDDs as JBOD for data with xfs
3 x 4 TB WD HDDs as RAID5 for indexes with xfs
Stenographer is configured to work with 18 threads - one for each disk (and not more than one thread on every physical CPU core).
1-2 Gbit/s of network traffic.

Capturing packets causes very low utilization: 4% CPU, 1% disks.

When disks are in 85% full (DiskFreePercentage=15) indexes tend to be ~4-6 TB large.

Using stenoread as from above examples causes 100% util (constant reads of 150-200 MB/s) on indexes for 15 minutes and timeouts.

Such small periods in queries (1 minute or 10 minutes) shouldn't require reading so much. Is it possible, that queries doesn't use timestamps and are trying to read whole indexes on every query?

I'm able to get results only when disks are filled in less than about 1/4. For example, if i delete all indexes and all data, I got results in seconds. Answer time increses by few seconds with every minute.

Syslog messages sometimes not prefixed correctly

Here's a sample of syslog messages from my /var/log/messages:

Mar  3 19:27:29 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:27:29.755193Z T:921fd7 [aio.cc:190] Opening packet file /tmp/stenographer551644138/PKT0/.1457058449627005: 4
2016-03-04T02:27:29.756744Z T:919fc7 [index.cc:269] Wrote all index files for /tmp/stenographer551644138/IDX0/.1457058388538817, moving to /tmp/stenographer551644138/IDX0/1457058388538817
Mar  3 19:27:50 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:27:50.795461Z T:921fd7 [stenotype.cc:499] Thread 0 stats: MB=2413 secs=15934.3 MBps=0.151434 packets=3425698 blocks=2413 polls=16248 drops=0 drop%=0
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.872843Z T:921fd7 [aio.cc:122] Closing /tmp/stenographer551644138/PKT0/.1457058449627005 (4), truncating to 7MB and moving to /tmp/stenographer551644138/PKT0/1457058449627005
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.872979Z T:921fd7 [aio.cc:190] Opening packet file /tmp/stenographer551644138/PKT0/.1457058510749942: 4
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.874880Z T:919fc7 [index.cc:269] Wrote all index files for /tmp/stenographer551644138/IDX0/.1457058449627005, moving to /tmp/stenographer551644138/IDX0/1457058449627005
Mar  3 19:27:29 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:27:29.749447Z T:921fd7 [aio.cc:122] Closing /tmp/stenographer551644138/PKT0/.1457058388538817 (4), truncating to 6MB and moving to /tmp/stenographer551644138/PKT0/1457058388538817
Mar  3 19:27:29 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:27:29.755193Z T:921fd7 [aio.cc:190] Opening packet file /tmp/stenographer551644138/PKT0/.1457058449627005: 4
2016-03-04T02:27:29.756744Z T:919fc7 [index.cc:269] Wrote all index files for /tmp/stenographer551644138/IDX0/.1457058388538817, moving to /tmp/stenographer551644138/IDX0/1457058388538817
Mar  3 19:27:50 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:27:50.795461Z T:921fd7 [stenotype.cc:499] Thread 0 stats: MB=2413 secs=15934.3 MBps=0.151434 packets=3425698 blocks=2413 polls=16248 drops=0 drop%=0
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.872843Z T:921fd7 [aio.cc:122] Closing /tmp/stenographer551644138/PKT0/.1457058449627005 (4), truncating to 7MB and moving to /tmp/stenographer551644138/PKT0/1457058449627005
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.872979Z T:921fd7 [aio.cc:190] Opening packet file /tmp/stenographer551644138/PKT0/.1457058510749942: 4
Mar  3 19:28:30 rockyduck.bld.corp.google.com stenographer[10202]: 2016-03-04T02:28:30.874880Z T:919fc7 [index.cc:269] Wrote all index files for /tmp/stenographer551644138/IDX0/.1457058449627005, moving to /tmp/stenographer551644138/IDX0/1457058449627005

Note the two lines that start with 2016, which are missing the normal "Month Day Time Host Daemon[PID]:" prefix.

open file error,Permission denied

After install the sevice , while i run

bash tesh.sh
everything is ok on dummy test.

however, if i run

sudo service stenographer start
sevice cannot be started, i check the syslog and found:
Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.146272Z T:7e9757 [stenotype.cc:525] Stenotype running with these arguments: Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.146401Z T:7e9757 [stenotype.cc:527] 0:#011"/usr/bin/stenotype"#0122016-01-28T02:26:00.146412Z T:7e9757 [stenotype.cc:527] 1:#011"-v"#0122016-01-28T02:26:00.146419Z T:7e9757 [stenotype.cc:527] 2:#011"-v"#0122016-01-28T02:26:00.146425Z T:7e9757 [stenotype.cc:527] 3:#011"-v"#0122016-01-28T02:26:00.146430Z T:7e9757 [stenotype.cc:527] 4:#011"--threads=1"#0122016-01-28T02:26:00.146436Z T:7e9757 [stenotype.cc:527] 5:#011"--iface=em1"#0122016-01-28T02:26:00.146441Z T:7e9757 [stenotype.cc:527] 6:#011"--dir=/tmp/stenographer097104063"#0122016-01-28T02:26:00.146446Z T:7e9757 [stenotype.cc:529] Starting...#0122016-01-28T02:26:00.146455Z T:7e9757 [stenotype.cc:550] Setting up AF_PACKET sockets for packet reading Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.692983Z T:7e9757 [stenotype.cc:233] Dropping privileges#0122016-01-28T02:26:00.693021Z T:7e9757 [stenotype.cc:244] Staying with GID=65534#0122016-01-28T02:26:00.693025Z T:7e9757 [stenotype.cc:258] Staying with UID=105 Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693106Z T:7e9757 [stenotype.cc:624] Starting writing threads#0122016-01-28T02:26:00.693112Z T:7e9757 [stenotype.cc:627] Starting thread 0#0122016-01-28T02:26:00.693132Z T:7e9757 [stenotype.cc:638] Starting indexing threads Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693142Z T:fcca77 [stenotype.cc:407] Handling signals Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693250Z T:fbca57 [stenotype.cc:375] Starting WriteIndexes thread 0 Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693342Z T:7e9757 [stenotype.cc:652] ===============Waiting for thread============== Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693999Z T:fc4a67 [stenotype.cc:430] Thread 0 starting to process packets Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.693999Z T:fbca57 [stenotype.cc:383] Waiting for index Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.694085Z T:fc4a67 [aio.cc:190] Opening packet file /tmp/stenographer097104063/PKT0/.1453947960694052: -1 Jan 28 10:26:00 ubuntu stenographer[4296]: 2016-01-28T02:26:00.694099Z T:fc4a67 [stenotype.cc:442] CHECK(SUCCEEDED(__check_success_error__)) output.Rotate(file_dirname, micros, flag_preallocate_file_mb << 20): Permission denied <- open#012ABORTABORTABORT Jan 28 10:26:00 ubuntu stenographer[4296]: /usr/bin/stenotype(_ZN2st7LogLineD1Ev+0x288) [0x7f367e752da8]#012/usr/bin/stenotype(_ZN2st9RunThreadEiPNS_21ProducerConsumerQueueEPNS_7PacketsE+0x5ca) [0x7f367e779b8a] Jan 28 10:26:00 ubuntu stenographer[4296]: #012/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a40) [0x7f367d840a40]#012/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7f367dcb2182]#012/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f367d2ae47d] Jan 28 10:26:00 ubuntu stenographer[4296]: 2016/01/28 10:26:00 Stenotype stopped after 824.055894ms: stenotype wait failed: signal: aborted (core dumped) Jan 28 10:26:00 ubuntu stenographer[4296]: 2016/01/28 10:26:00 Stenotype ran for too little time, crashing to avoid stenotype crash loop Jan 28 10:26:00 ubuntu kernel: [74364.330113] init: stenographer main process (4296) terminated with status 1 Jan 28 10:26:00 ubuntu kernel: [74364.330124] init: stenographer respawning too fast, stopped

It looks like permisson problem, any suggestions?

Slow start up time for `stenographer`

When stenographer starts up, it tries to recover all the existing
packet/index files. While doing so, it will call the NewIndexFile ()
function in which it tries few small reads of leveldb for initialization
and version confirmation... And this recovery is done serially for
each thread (here)[https://github.com/google/stenographer/blob/master/env/env.go#L258-L262]
while preventing any query from stenoread.

On a system will tens of thousand files, this process could take a
non-negligible amount of time,

So, @gconnell, would like to ask if you know about the problem and
if you do any workaround to speed it up,

Usage statement for stenoread is invalid

The usage statement from stenoread provides the following examples which conflict with the documentation in the main README. Fought this for about an hour.

Examples:
 # Print all packets for source IP 1.1.1.1 without DNS resolution (-n).
 /usr/bin/stenoread ip=1.1.1.1 -n src ip 1.1.1.1
 # Print all PSH packets between 1.1.1.1 and 2.2.2.2:
 /usr/bin/stenoread 'ip=1.1.1.1 ip=2.2.2.2' -n 'tcp[tcpflags] & tcp-push != 0'
 # Write all packets between 1.1.1.1 and 2.2.2.2 to disk.
 /usr/bin/stenoread 'ip=1.1.1.1 ip=2.2.2.2' -w /tmp/out.pcap

Ability to move pcap & indexes to "cold storage"

I've had some users of RockNSM express the need for longtime archival of pcap data, potentially from multiple sensors. I'm curious if it would be sufficient to simply move the matching data and index files to another filesystem, and move back and query stenographer after a restart to pull that pcap.

So, there could be a main thread directory, for instance. On beefier sensors I put this on NVMe storage. From there, I can move to regular SSD or perhaps a SAN, which is more affordable for long-term storage. If this could be managed with something like filerotate or similar as noted above, then easy, peasy. Otherwise, it could be useful to allow an option to move the file (with some magic so we don't tie up the thread) rather than unlink the file.

RPM packaging

both deb and rpm packaging should be relatively simple using FPM. Just need to determine dependencies (which is the more annoying part anyway).

stenotype build error: __NR_fstat64’ was not declared in this scope

Trying to build/install the current master on Ubuntu.

-- output of ./install.sh
Making sure we have sudo access
Killing aleady-running processes
stop: Unknown instance:
Checking for package 'libaio-dev'
Checking for package 'libleveldb-dev'
Checking for package 'libsnappy-dev'
Checking for package 'g++'
Checking for package 'libcap2-bin'
Checking for package 'libseccomp-dev'
Building stenographer
stenographer' ->/usr/bin/stenographer'
Building stenotype
/data/stenographer/gopath/src/github.com/google/stenographer/stenotype /data/stenographer/gopath/src/github.com/google/stenographer
g++ -std=c++0x -g -Wall -fno-strict-aliasing -rdynamic -O2 -fPIC -fPIE -pie -fstack-protector -D_FORTIFY_SOURCE=2 -c -o stenotype_gcc.o stenotype.cc
stenotype.cc: In function ‘void st::CommonPrivileges(scmp_filter_ctx)’:
stenotype.cc:269:3: error: ‘__NR_fstat64’ was not declared in this scope
stenotype.cc:278:3: error: ‘__NR_mmap2’ was not declared in this scope
stenotype.cc:286:3: error: ‘__NR_sigreturn’ was not declared in this scope

util.h: At global scope:
util.h:55:6: warning: ‘{anonymous}::run_init_time’ defined but not used [-Wunused-variable]
make: *** [stenotype_gcc.o] Error 1

rpmbuild-steno-centos errors out at the end of the installation

I'm running CentOS Linux release 7.2.1511 (Core) minimal fresh install. I then proceed to execute the following:

yum -y update && reboot

# once rebooted
yum install -y epel-release
yum groupinstall -y base "development tools" mock
reboot

# I install go in the instructions provided on the official website

go get github.com/google/stenographer
cd src/github.com/google/stenographer
bash ./rpmbuild-steno-centos

When I go to build the rpm from bash ./rpmbuild-steno-centos every thing seems to be running fine until the end when the script errors out with the following:

ERROR: Cannot find/open srpm: /tmp/tmp.TqThtYPYDy/rpmbuild/SRPMS/stenographer-*a12106b.el7.src.rpm.
Error: [Errno 2] No such file or directory: '/tmp/tmp.TqThtYPYDy/rpmbuild/SRPMS/stenographer-*a12106b.el7.src.rpm'

Am I missing something?

Process terminated with panic.

The following panic has occurred. What is the reason?

Dec 28 01:16:00 cloud-worker2 stenographer[9936]: panic: runtime error: index out of range
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: goroutine 6 [running]:
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/thread.(*Thread).pruneOldestThreadFiles(0xc420089720)
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/thread/thread.go:229 +0x2ee
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/thread.(*Thread).cleanUpOnLowDiskSpace(0xc420089720)
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/thread/thread.go:206 +0x498
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/thread.(*Thread).SyncFiles(0xc420089720)
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/thread/thread.go:353 +0x52
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/env.(*Env).syncFiles(0xc42007f6c0)
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/env/env.go:260 +0x4f
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/env.(*Env).(github.com/google/stenographer/env.syncFiles)-fm()
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/env/env.go:131 +0x2a
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: github.com/google/stenographer/env.(*Env).callEvery(0xc42007f6c0, 0xc420010cb0, 0x37e11d600)
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/env/env.go:179 +0x8b
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: created by github.com/google/stenographer/env.New
Dec 28 01:16:00 cloud-worker2 stenographer[9936]: #011/root/work/src/github.com/google/stenographer/env/env.go:131 +0x3d1
Dec 28 01:16:00 cloud-worker2 systemd[1]: stenographer.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Stenoread certificate error

When using stenocurl on the CentOS 7.2, I get an error indicating that the certificate usage type is incorrect.

vagrant@simplerockbuild ~]$ stenocurl /debug/
curl: (60) Certificate type not approved for application.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

I've used the -k as a work around, but this is obviously less than ideal. I'm running this in Vagrant using SimpleRock [1] (of which I'm an author).

I checked the certificates and they appear to be correct for the roles I would expect. The server cert has TLS web server auth + certificate sign and the client cert has TLS client auth. I'm wondering if there was a change in OpenSSL that it causing this to occur. I haven't been able to trace it down yet. I'm happy to do the leg work if I can just figure out why this is occurring.

In the meantime, I'm using the -k curl option, which I'd rather not do.

thanks!

[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/server_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6c:c1:6c:34:e9:18:98:17:62:32:be:50:f8:c0:24:dd
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Stenographer, CN=127.0.0.1
        Validity
            Not Before: Dec 24 20:19:05 2015 GMT
            Not After : Dec 23 20:19:05 2016 GMT
        Subject: O=Stenographer, CN=127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ae:df:27:70:f8:fe:dc:e8:33:f9:22:84:08:1b:
                    a3:32:46:16:57:01:3f:a9:96:66:aa:7b:8c:5d:5b:
                    46:6d:c9:73:a3:f8:38:2d:92:45:90:b8:a0:96:c7:
                    ba:5b:bd:d2:c6:a2:1d:63:08:56:9f:19:e4:12:4f:
                    1e:c4:84:69:e9:fa:35:4a:0b:32:39:5c:3c:5e:43:
                    2b:dd:9c:79:dc:aa:d6:b2:b6:75:c0:00:71:d1:6d:
                    52:18:11:32:19:24:b0:19:9b:5c:15:9c:54:94:1d:
                    e9:e0:89:25:59:a8:69:0e:bc:b9:d8:97:31:0a:5d:
                    03:c8:a4:cb:21:18:d7:04:7d:de:51:40:ac:28:55:
                    4e:c5:1b:43:9a:8f:44:84:6b:f8:02:22:1c:6b:60:
                    8a:a5:25:1e:98:55:e2:37:ea:1d:2a:b2:bd:15:1a:
                    49:5b:bb:ce:9a:3e:92:09:d6:fc:b3:f8:1a:cc:f5:
                    16:e3:18:8d:84:5d:7f:e9:a0:28:02:39:62:f6:71:
                    1f:9d:62:bc:53:e1:5c:39:1a:41:ff:37:d5:45:44:
                    04:21:0c:66:33:c9:76:87:71:d9:50:50:ee:d6:27:
                    0d:8f:90:c8:5e:8b:7c:61:05:92:d6:97:0d:34:af:
                    5e:a6:72:78:f9:f2:ec:f8:89:3a:59:ca:0b:77:08:
                    02:3d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
    Signature Algorithm: sha256WithRSAEncryption
         48:7a:43:4a:1b:b6:47:ca:47:88:91:48:51:1e:3b:e6:4b:f2:
         20:80:93:3d:a0:84:73:0a:2f:5e:97:0f:dd:79:7e:ff:89:d9:
         09:f4:2f:cd:65:f1:19:62:35:df:b8:ce:c4:28:14:b7:9a:a7:
         73:07:d1:71:db:69:1b:b7:0f:e1:95:f4:cf:97:00:7a:8a:65:
         3e:dc:3d:c0:35:22:10:8c:88:58:f0:0d:eb:a8:f7:10:4f:48:
         d7:13:9b:42:7b:a6:b0:e5:1c:aa:fd:b3:a3:91:9d:cf:63:fb:
         1a:06:74:6e:91:0b:01:bb:73:8f:49:b5:85:59:a5:a1:f6:1d:
         87:75:11:49:c0:75:f0:40:05:31:9c:a4:56:58:9f:4a:b1:8a:
         5d:60:c3:0d:1f:00:c6:05:17:18:c9:0c:b7:dd:fc:34:7f:79:
         d6:65:15:d4:a6:cf:38:97:dd:5f:a4:45:03:dd:ac:6a:9d:5a:
         9b:eb:d3:e0:9c:7c:9b:7d:ac:d4:15:c4:d5:bb:e3:df:73:c3:
         66:cd:8d:fe:78:0a:88:e6:b0:b5:52:f5:da:af:e8:07:d9:0d:
         d0:fa:2b:b1:dc:99:2e:2d:66:e0:ba:70:b7:d8:b4:1f:02:9a:
         6c:c6:a9:d0:21:c5:f1:74:62:9b:9c:11:f9:60:16:d1:11:06:
         4d:78:d5:68
[vagrant@simplerockbuild ~]$ openssl x509 -in /etc/stenographer/certs/client_cert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2f:ef:54:2a:ee:96:83:23:eb:12:d0:ec:80:c4:b5:cd
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Stenographer, CN=127.0.0.1
        Validity
            Not Before: Dec 24 20:19:04 2015 GMT
            Not After : Dec 23 20:19:04 2016 GMT
        Subject: O=Stenographer, CN=127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c8:54:35:c0:ad:f5:48:b9:a1:43:f4:17:4b:25:
                    b2:ac:0b:a2:07:39:51:66:97:c7:27:5f:bd:90:e3:
                    cd:ce:b8:61:9b:f4:6f:bb:26:47:7e:62:d8:25:7d:
                    01:91:6d:37:79:42:70:b7:0e:1a:a7:a6:e7:5a:33:
                    ff:70:38:e4:f0:f9:29:01:88:bb:15:c2:ec:9a:65:
                    8d:fb:7b:12:72:8b:e8:f4:9e:7c:c9:09:4d:ca:81:
                    e4:5d:63:76:20:df:dd:ef:eb:5c:43:e7:bb:eb:b1:
                    c4:10:47:af:7a:e1:5e:de:0f:e1:a5:35:34:67:57:
                    40:fa:46:32:62:57:29:66:c5:3b:59:9b:ce:19:6e:
                    2a:3e:b9:2e:79:65:21:7c:4e:d7:7f:8e:31:d5:24:
                    1d:62:a6:45:fc:aa:1d:1a:80:a4:d9:7e:07:79:a4:
                    3a:de:35:0d:b7:2a:1b:60:27:2c:0f:c1:b0:a6:49:
                    8f:fc:79:b2:6a:67:9e:0a:a5:4d:9c:19:7a:68:4a:
                    cc:6c:b6:8d:94:6d:f0:e0:d5:a1:16:ca:b5:65:ba:
                    38:f0:37:6f:83:cb:87:d6:c1:14:1b:4c:3a:a1:0b:
                    30:11:b1:04:b0:69:f7:f8:45:a3:b6:36:17:47:bb:
                    dc:41:d2:6f:9f:00:b8:70:40:54:dc:06:a6:e1:9d:
                    68:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
    Signature Algorithm: sha256WithRSAEncryption
         43:d5:e2:95:9f:5f:98:d7:34:23:3f:f9:ba:6d:6c:76:65:69:
         a0:6c:92:9b:7c:83:0d:86:9e:60:af:8b:7e:73:fc:4d:2b:b5:
         c8:7b:2f:f0:37:e5:61:86:99:b3:38:3d:6e:c6:19:1f:d4:dd:
         02:20:ff:1f:bd:46:11:ac:07:19:23:3b:ac:96:53:10:de:5b:
         7e:34:f2:69:59:0c:06:93:f4:3b:7f:93:ef:2b:77:8a:7a:d4:
         fe:d3:de:5e:2a:31:cc:fd:cf:dd:ea:4c:7c:60:b8:99:e9:01:
         b7:d2:05:b6:e4:d8:ad:71:c2:1e:ae:59:2c:a4:82:f8:0d:a1:
         fd:0f:75:63:9c:53:f5:f2:18:5a:69:0f:e2:42:6b:8e:f9:65:
         90:b0:0d:71:69:ce:e6:f7:48:de:20:1f:a5:89:fc:21:16:81:
         4f:10:4c:51:90:e6:00:35:4f:23:c6:df:7c:83:69:7c:1f:86:
         83:ad:92:de:c9:f1:05:df:ab:6a:8d:0e:9b:1a:3b:40:10:c7:
         8e:ff:86:48:d2:37:18:3a:2e:2a:b5:ec:3a:3c:d1:53:63:43:
         59:7a:f7:3e:6e:e6:8a:b3:f7:b6:d6:d3:47:99:f9:38:d0:d9:
         fe:12:e4:0d:ad:62:47:53:5a:cb:a2:fd:a8:08:f5:b4:c7:a3:
         ad:4c:63:eb

References:
[1] SimpleRock, http://rocknsm.io/

Stenotype blocks forever if it gets zero packets

Currently, if stenotype is watching an interface that gets exactly zero packets, it will block forever in PollForPacket, because we pass in -1 (block forever), and it does exactly what we ask it to do.

Apparently even though we have a timeout on AF_PACKET, poll continues to block past multiple timeouts until at least one packet is seen.

Certificates are not created with ClientAuth EKU

I'm a little confused that I would be the only one to come across this, but it appears that when the default Client certificates are made for authentication with stenoread, the ClientAuth EKU is not getting included into the certificate generation, and I cannot connect to stenographer with stenoread because of this.

Adding "-extensions ${TYP}_ext" into the arguments for the certificate generation fixes the issue for me.

build failes at 'blockfile'

github.com/google/stenographer/blockfile

blockfile/blockfile.go:93: pkt.tp_sec undefined (type *C.struct_tpacket3_hdr has no field or method tp_sec)
blockfile/blockfile.go:93: pkt.tp_nsec undefined (type *C.struct_tpacket3_hdr has no field or method tp_nsec)
blockfile/blockfile.go:94: pkt.tp_len undefined (type *C.struct_tpacket3_hdr has no field or method tp_len)
blockfile/blockfile.go:95: pkt.tp_snaplen undefined (type *C.struct_tpacket3_hdr has no field or method tp_snaplen)
blockfile/blockfile.go:98: pkt.tp_mac undefined (type *C.struct_tpacket3_hdr has no field or method tp_mac)
blockfile/blockfile.go:138: a.block.num_pkts undefined (type *C.struct_tpacket_hdr_v1 has no field or method num_pkts)
blockfile/blockfile.go:150: baseHdr.hdr undefined (type *C.struct_tpacket_block_desc has no field or method hdr)
blockfile/blockfile.go:157: a.block.offset_to_first_pkt undefined (type *C.struct_tpacket_hdr_v1 has no field or method offset_to_first_pkt)
blockfile/blockfile.go:158: a.pkt.tp_next_offset undefined (type *C.struct_tpacket3_hdr has no field or method tp_next_offset)
blockfile/blockfile.go:159: a.pkt.tp_next_offset undefined (type *C.struct_tpacket3_hdr has no field or method tp_next_offset)
blockfile/blockfile.go:159: too many errors

Disk usage monitoring may not be working correctly

I tried running the new code on our test machine, and it didn't keep disk usage down correctly. Maybe this could be easier to test if we allowed the percentage to be configurable per thread in the Config, so we could set it super high/low and watch the results?

ulimit nofiles reached on systems with large amounts of retention

I have a system with 35 threads writing 2-6 MB index files and ~250 MB packet files.

This worked great up until we had more than 20 days of retention and then we hit the nofile ulimit since Stenographer keeps a handle open for every index. It would be pretty awesome to have some sort of system that enables large amounts of retention by opening/closing old index files as needed.

Crash: index out of range

Package: stenographer-0-1.20170718git907b3ab.el7.centos.x86_64 (built from stenographer spec file)

Backtrace:

Aug 29 11:45:37 host stenographer[121832]: panic: runtime error: index out of range
Aug 29 11:45:37 host stenographer[121832]: goroutine 82 [running]:
Aug 29 11:45:37 host stenographer[121832]: panic(0x8f6d60, 0xc82000e030)
Aug 29 11:45:37 host stenographer[121832]: /usr/lib/golang/src/runtime/panic.go:481 +0x3e6
Aug 29 11:45:37 host stenographer[121832]: github.com/google/stenographer/thread.(*Thread).pruneOldestThreadFiles(0xc82018eb40)
Aug 29 11:45:37 host stenographer[121832]: /builddir/build/BUILD/stenographer-907b3abf3e877b671e4d43bdb628948feaee2c22/src/github.com/google/stenographer/thread/thread.go:234 +0x3c2
Aug 29 11:45:37 host stenographer[121832]: github.com/google/stenographer/thread.(*Thread).cleanUpOnLowDiskSpace(0xc82018eb40)
Aug 29 11:45:37 host stenographer[121832]: /builddir/build/BUILD/stenographer-907b3abf3e877b671e4d43bdb628948feaee2c22/src/github.com/google/stenographer/thread/thread.go:206 +0xa44

Config:

{
  "Threads": [
      { "PacketsDirectory": "/data/1", "IndexDirectory": "/index/1", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/2", "IndexDirectory": "/index/2", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/3", "IndexDirectory": "/index/3", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/4", "IndexDirectory": "/index/4", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/5", "IndexDirectory": "/index/5", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/6", "IndexDirectory": "/index/6", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/7", "IndexDirectory": "/index/7", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/8", "IndexDirectory": "/index/8", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/9", "IndexDirectory": "/index/9", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/10", "IndexDirectory": "/index/10", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/11", "IndexDirectory": "/index/11", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/12", "IndexDirectory": "/index/12", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/13", "IndexDirectory": "/index/13", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/14", "IndexDirectory": "/index/14", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/15", "IndexDirectory": "/index/15", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/16", "IndexDirectory": "/index/16", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/17", "IndexDirectory": "/index/17", "DiskFreePercentage": 50}
    , { "PacketsDirectory": "/data/18", "IndexDirectory": "/index/18", "DiskFreePercentage": 50}
  ]
  , "StenotypePath": "/usr/bin/stenotype"
  , "Interface": "bond0"
  , "Port": 1234
  , "Host": "127.0.0.1"
  , "Flags": []
  , "CertPath": "/etc/stenographer/certs"
}

Feature Request: Option to run with disabled stenotype

It would be helpful to have a configuration option that disables stenotype altogether. This would allow the stenographer server to run and serve an existing database to clients, which is useful for testing (e.g really helps with memory allocation in API testing) or to serve an existing PCAP library that is no longer collecting. I would think this would prevent old PCAP from ageing off since no new files would be created.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.