unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
/* Copyright (C) 2012 Open Information Security Foundation
|
|
|
|
*
|
|
|
|
* You can copy, redistribute or modify this Program under the terms of
|
|
|
|
* the GNU General Public License version 2 as published by the Free
|
|
|
|
* Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* version 2 along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
|
|
|
* 02110-1301, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "suricata-common.h"
|
|
|
|
#include "tm-threads.h"
|
|
|
|
#include "conf.h"
|
|
|
|
#include "runmodes.h"
|
|
|
|
#include "runmode-pcap-file.h"
|
|
|
|
#include "output.h"
|
|
|
|
|
|
|
|
#include "util-debug.h"
|
|
|
|
#include "util-time.h"
|
|
|
|
#include "util-cpu.h"
|
|
|
|
#include "util-affinity.h"
|
|
|
|
#include "unix-manager.h"
|
|
|
|
|
|
|
|
#include "detect-engine.h"
|
|
|
|
|
|
|
|
#include "flow-manager.h"
|
|
|
|
#include "flow-timeout.h"
|
|
|
|
#include "stream-tcp.h"
|
|
|
|
#include "output.h"
|
|
|
|
#include "host.h"
|
|
|
|
#include "defrag.h"
|
|
|
|
|
|
|
|
#include "util-profiling.h"
|
|
|
|
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
static const char *default_mode = NULL;
|
|
|
|
|
|
|
|
int unix_socket_mode_is_running = 0;
|
|
|
|
|
|
|
|
typedef struct PcapFiles_ {
|
|
|
|
char *filename;
|
|
|
|
char *output_dir;
|
|
|
|
TAILQ_ENTRY(PcapFiles_) next;
|
|
|
|
} PcapFiles;
|
|
|
|
|
|
|
|
typedef struct PcapCommand_ {
|
|
|
|
TAILQ_HEAD(, PcapFiles_) files;
|
|
|
|
int running;
|
|
|
|
char *currentfile;
|
|
|
|
} PcapCommand;
|
|
|
|
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
const char *RunModeUnixSocketGetDefaultMode(void)
|
|
|
|
{
|
|
|
|
return default_mode;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef BUILD_UNIX_SOCKET
|
|
|
|
|
|
|
|
static int unix_manager_file_task_running = 0;
|
|
|
|
static int unix_manager_file_task_failed = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* \brief return list of files in the queue
|
|
|
|
*
|
|
|
|
* \retval 0 in case of error, 1 in case of success
|
|
|
|
*/
|
|
|
|
static TmEcode UnixSocketPcapFilesList(json_t *cmd, json_t* answer, void *data)
|
|
|
|
{
|
|
|
|
PcapCommand *this = (PcapCommand *) data;
|
|
|
|
int i = 0;
|
|
|
|
PcapFiles *file;
|
|
|
|
json_t *jdata;
|
|
|
|
json_t *jarray;
|
|
|
|
|
|
|
|
jdata = json_object();
|
|
|
|
if (jdata == NULL) {
|
|
|
|
json_object_set_new(answer, "message",
|
|
|
|
json_string("internal error at json object creation"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
jarray = json_array();
|
|
|
|
if (jarray == NULL) {
|
|
|
|
json_decref(jdata);
|
|
|
|
json_object_set_new(answer, "message",
|
|
|
|
json_string("internal error at json object creation"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
TAILQ_FOREACH(file, &this->files, next) {
|
|
|
|
json_array_append_new(jarray, json_string(file->filename));
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
json_object_set_new(jdata, "count", json_integer(i));
|
|
|
|
json_object_set_new(jdata, "files", jarray);
|
|
|
|
json_object_set_new(answer, "message", jdata);
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static TmEcode UnixSocketPcapFilesNumber(json_t *cmd, json_t* answer, void *data)
|
|
|
|
{
|
|
|
|
PcapCommand *this = (PcapCommand *) data;
|
|
|
|
int i = 0;
|
|
|
|
PcapFiles *file;
|
|
|
|
|
|
|
|
TAILQ_FOREACH(file, &this->files, next) {
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
json_object_set_new(answer, "message", json_integer(i));
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static TmEcode UnixSocketPcapCurrent(json_t *cmd, json_t* answer, void *data)
|
|
|
|
{
|
|
|
|
PcapCommand *this = (PcapCommand *) data;
|
|
|
|
|
|
|
|
if (this->currentfile) {
|
|
|
|
json_object_set_new(answer, "message", json_string(this->currentfile));
|
|
|
|
} else {
|
|
|
|
json_object_set_new(answer, "message", json_string("None"));
|
|
|
|
}
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void PcapFilesFree(PcapFiles *cfile)
|
|
|
|
{
|
|
|
|
if (cfile == NULL)
|
|
|
|
return;
|
|
|
|
if (cfile->filename)
|
|
|
|
SCFree(cfile->filename);
|
|
|
|
if (cfile->output_dir)
|
|
|
|
SCFree(cfile->output_dir);
|
|
|
|
SCFree(cfile);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* \brief Add file to file queue
|
|
|
|
*
|
|
|
|
* \param this a UnixCommand:: structure
|
|
|
|
* \param filename absolute filename
|
|
|
|
* \param output_dir absolute name of directory where log will be put
|
|
|
|
*
|
|
|
|
* \retval 0 in case of error, 1 in case of success
|
|
|
|
*/
|
|
|
|
TmEcode UnixListAddFile(PcapCommand *this, const char *filename, const char *output_dir)
|
|
|
|
{
|
|
|
|
PcapFiles *cfile = NULL;
|
|
|
|
if (filename == NULL || this == NULL)
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
cfile = SCMalloc(sizeof(PcapFiles));
|
|
|
|
if (unlikely(cfile == NULL)) {
|
|
|
|
SCLogError(SC_ERR_MEM_ALLOC, "Unable to allocate new file");
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
memset(cfile, 0, sizeof(PcapFiles));
|
|
|
|
|
|
|
|
cfile->filename = SCStrdup(filename);
|
|
|
|
if (unlikely(cfile->filename == NULL)) {
|
|
|
|
SCFree(cfile);
|
|
|
|
SCLogError(SC_ERR_MEM_ALLOC, "Unable to dup filename");
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (output_dir) {
|
|
|
|
cfile->output_dir = SCStrdup(output_dir);
|
|
|
|
if (unlikely(cfile->output_dir == NULL)) {
|
|
|
|
SCFree(cfile->filename);
|
|
|
|
SCFree(cfile);
|
|
|
|
SCLogError(SC_ERR_MEM_ALLOC, "Unable to dup output_dir");
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TAILQ_INSERT_TAIL(&this->files, cfile, next);
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* \brief Command to add a file to treatment list
|
|
|
|
*
|
|
|
|
* \param cmd the content of command Arguments as a json_t object
|
|
|
|
* \param answer the json_t object that has to be used to answer
|
|
|
|
* \param data pointer to data defining the context here a PcapCommand::
|
|
|
|
*/
|
|
|
|
TmEcode UnixSocketAddPcapFile(json_t *cmd, json_t* answer, void *data)
|
|
|
|
{
|
|
|
|
PcapCommand *this = (PcapCommand *) data;
|
|
|
|
int ret;
|
|
|
|
const char *filename;
|
|
|
|
const char *output_dir;
|
|
|
|
#ifdef OS_WIN32
|
|
|
|
struct _stat st;
|
|
|
|
#else
|
|
|
|
struct stat st;
|
|
|
|
#endif /* OS_WIN32 */
|
|
|
|
|
|
|
|
json_t *jarg = json_object_get(cmd, "filename");
|
|
|
|
if(!json_is_string(jarg)) {
|
|
|
|
SCLogInfo("error: command is not a string");
|
|
|
|
json_object_set_new(answer, "message", json_string("command is not a string"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
filename = json_string_value(jarg);
|
|
|
|
#ifdef OS_WIN32
|
|
|
|
if(_stat(filename, &st) != 0) {
|
|
|
|
#else
|
|
|
|
if(stat(filename, &st) != 0) {
|
|
|
|
#endif /* OS_WIN32 */
|
|
|
|
json_object_set_new(answer, "message", json_string("File does not exist"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
|
|
|
|
json_t *oarg = json_object_get(cmd, "output-dir");
|
|
|
|
if (oarg != NULL) {
|
|
|
|
if(!json_is_string(oarg)) {
|
|
|
|
SCLogInfo("error: output dir is not a string");
|
|
|
|
json_object_set_new(answer, "message", json_string("output dir is not a string"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
output_dir = json_string_value(oarg);
|
|
|
|
} else {
|
|
|
|
SCLogInfo("error: can't get output-dir");
|
|
|
|
json_object_set_new(answer, "message", json_string("output dir param is mandatory"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef OS_WIN32
|
|
|
|
if(_stat(output_dir, &st) != 0) {
|
|
|
|
#else
|
|
|
|
if(stat(output_dir, &st) != 0) {
|
|
|
|
#endif /* OS_WIN32 */
|
|
|
|
json_object_set_new(answer, "message", json_string("Output directory does not exist"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = UnixListAddFile(this, filename, output_dir);
|
|
|
|
switch(ret) {
|
|
|
|
case TM_ECODE_FAILED:
|
|
|
|
json_object_set_new(answer, "message", json_string("Unable to add file to list"));
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
case TM_ECODE_OK:
|
|
|
|
SCLogInfo("Added file '%s' to list", filename);
|
|
|
|
json_object_set_new(answer, "message", json_string("Successfully added file to list"));
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* \brief Handle the file queue
|
|
|
|
*
|
|
|
|
* This function check if there is currently a file
|
|
|
|
* being parse. If it is not the case, it will start to
|
|
|
|
* work on a new file. This implies to start a new 'pcap-file'
|
|
|
|
* running mode after having set the file and the output dir.
|
|
|
|
* This function also handles the cleaning of the previous
|
|
|
|
* running mode.
|
|
|
|
*
|
|
|
|
* \param this a UnixCommand:: structure
|
|
|
|
* \retval 0 in case of error, 1 in case of success
|
|
|
|
*/
|
|
|
|
TmEcode UnixSocketPcapFilesCheck(void *data)
|
|
|
|
{
|
|
|
|
PcapCommand *this = (PcapCommand *) data;
|
|
|
|
if (unix_manager_file_task_running == 1) {
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
if ((unix_manager_file_task_failed == 1) || (this->running == 1)) {
|
|
|
|
if (unix_manager_file_task_failed) {
|
|
|
|
SCLogInfo("Preceeding task failed, cleaning the running mode");
|
|
|
|
}
|
|
|
|
unix_manager_file_task_failed = 0;
|
|
|
|
this->running = 0;
|
|
|
|
if (this->currentfile) {
|
|
|
|
SCFree(this->currentfile);
|
|
|
|
}
|
|
|
|
this->currentfile = NULL;
|
|
|
|
|
|
|
|
/* handle graceful shutdown of the flow engine, it's helper
|
|
|
|
* threads and the packet threads */
|
|
|
|
FlowKillFlowManagerThread();
|
|
|
|
TmThreadDisableReceiveThreads();
|
|
|
|
FlowForceReassembly();
|
|
|
|
TmThreadDisablePacketThreads();
|
|
|
|
FlowKillFlowRecyclerThread();
|
|
|
|
|
|
|
|
/* kill the stats threads */
|
|
|
|
TmThreadKillThreadsFamily(TVT_MGMT);
|
|
|
|
TmThreadClearThreadsFamily(TVT_MGMT);
|
|
|
|
|
|
|
|
/* kill packet threads -- already in 'disabled' state */
|
|
|
|
TmThreadKillThreadsFamily(TVT_PPT);
|
|
|
|
TmThreadClearThreadsFamily(TVT_PPT);
|
|
|
|
|
|
|
|
/* mgt and ppt threads killed, we can run non thread-safe
|
|
|
|
* shutdown functions */
|
|
|
|
SCPerfReleaseResources();
|
|
|
|
RunModeShutDown();
|
|
|
|
FlowShutdown();
|
|
|
|
HostCleanup();
|
|
|
|
StreamTcpFreeConfig(STREAM_VERBOSE);
|
|
|
|
DefragDestroy();
|
|
|
|
TmqResetQueues();
|
|
|
|
#ifdef PROFILING
|
|
|
|
if (profiling_rules_enabled)
|
|
|
|
SCProfilingDump();
|
|
|
|
SCProfilingDestroy();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
if (!TAILQ_EMPTY(&this->files)) {
|
|
|
|
PcapFiles *cfile = TAILQ_FIRST(&this->files);
|
|
|
|
TAILQ_REMOVE(&this->files, cfile, next);
|
|
|
|
SCLogInfo("Starting run for '%s'", cfile->filename);
|
|
|
|
unix_manager_file_task_running = 1;
|
|
|
|
this->running = 1;
|
|
|
|
if (ConfSet("pcap-file.file", cfile->filename) != 1) {
|
|
|
|
SCLogInfo("Can not set working file to '%s'", cfile->filename);
|
|
|
|
PcapFilesFree(cfile);
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
if (cfile->output_dir) {
|
|
|
|
if (ConfSet("default-log-dir", cfile->output_dir) != 1) {
|
|
|
|
SCLogInfo("Can not set output dir to '%s'", cfile->output_dir);
|
|
|
|
PcapFilesFree(cfile);
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
this->currentfile = SCStrdup(cfile->filename);
|
|
|
|
if (unlikely(this->currentfile == NULL)) {
|
|
|
|
SCLogError(SC_ERR_MEM_ALLOC, "Failed file name allocation");
|
|
|
|
return TM_ECODE_FAILED;
|
|
|
|
}
|
|
|
|
PcapFilesFree(cfile);
|
|
|
|
#ifdef PROFILING
|
|
|
|
SCProfilingRulesGlobalInit();
|
|
|
|
SCProfilingKeywordsGlobalInit();
|
|
|
|
SCProfilingInit();
|
|
|
|
#endif /* PROFILING */
|
|
|
|
DefragInit();
|
|
|
|
FlowInitConfig(FLOW_QUIET);
|
|
|
|
StreamTcpInitConfig(STREAM_VERBOSE);
|
|
|
|
RunModeInitializeOutputs();
|
|
|
|
SCPerfInitCounterApi();
|
|
|
|
RunModeDispatch(RUNMODE_PCAP_FILE, NULL);
|
|
|
|
FlowManagerThreadSpawn();
|
|
|
|
FlowRecyclerThreadSpawn();
|
|
|
|
SCPerfSpawnThreads();
|
|
|
|
/* Un-pause all the paused threads */
|
|
|
|
TmThreadContinueThreads();
|
|
|
|
}
|
|
|
|
return TM_ECODE_OK;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
void RunModeUnixSocketRegister(void)
|
|
|
|
{
|
|
|
|
#ifdef BUILD_UNIX_SOCKET
|
|
|
|
RunModeRegisterNewRunMode(RUNMODE_UNIX_SOCKET, "single",
|
|
|
|
"Unix socket mode",
|
|
|
|
RunModeUnixSocketSingle);
|
|
|
|
default_mode = "single";
|
|
|
|
#endif
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
void UnixSocketPcapFile(TmEcode tm)
|
|
|
|
{
|
|
|
|
#ifdef BUILD_UNIX_SOCKET
|
|
|
|
switch (tm) {
|
|
|
|
case TM_ECODE_DONE:
|
|
|
|
unix_manager_file_task_running = 0;
|
|
|
|
break;
|
|
|
|
case TM_ECODE_FAILED:
|
|
|
|
unix_manager_file_task_running = 0;
|
|
|
|
unix_manager_file_task_failed = 1;
|
|
|
|
break;
|
|
|
|
case TM_ECODE_OK:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
/**
|
|
|
|
* \brief Single thread version of the Pcap file processing.
|
|
|
|
*/
|
|
|
|
int RunModeUnixSocketSingle(void)
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
{
|
|
|
|
#ifdef BUILD_UNIX_SOCKET
|
|
|
|
PcapCommand *pcapcmd = SCMalloc(sizeof(PcapCommand));
|
|
|
|
|
|
|
|
if (unlikely(pcapcmd == NULL)) {
|
|
|
|
SCLogError(SC_ERR_MEM_ALLOC, "Can not allocate pcap command");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
TAILQ_INIT(&pcapcmd->files);
|
|
|
|
pcapcmd->running = 0;
|
|
|
|
pcapcmd->currentfile = NULL;
|
|
|
|
|
|
|
|
UnixManagerThreadSpawn(1);
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
|
|
|
|
unix_socket_mode_is_running = 1;
|
|
|
|
|
|
|
|
UnixManagerRegisterCommand("pcap-file", UnixSocketAddPcapFile, pcapcmd, UNIX_CMD_TAKE_ARGS);
|
|
|
|
UnixManagerRegisterCommand("pcap-file-number", UnixSocketPcapFilesNumber, pcapcmd, 0);
|
|
|
|
UnixManagerRegisterCommand("pcap-file-list", UnixSocketPcapFilesList, pcapcmd, 0);
|
|
|
|
UnixManagerRegisterCommand("pcap-current", UnixSocketPcapCurrent, pcapcmd, 0);
|
|
|
|
|
|
|
|
UnixManagerRegisterBackgroundTask(UnixSocketPcapFilesCheck, pcapcmd);
|
unix-manager: add unix command socket and associated script
This patch introduces a unix command socket. JSON formatted messages
can be exchanged between suricata and a program connecting to a
dedicated socket.
The protocol is the following:
* Client connects to the socket
* It sends a version message: { "version": "$VERSION_ID" }
* Server answers with { "return": "OK|NOK" }
If server returns OK, the client is now allowed to send command.
The format of command is the following:
{
"command": "pcap-file",
"arguments": { "filename": "smtp-clean.pcap", "output-dir": "/tmp/out" }
}
The server will try to execute the "command" specified with the
(optional) provided "arguments".
The answer by server is the following:
{
"return": "OK|NOK",
"message": JSON_OBJECT or information string
}
A simple script is provided and is available under scripts/suricatasc. It
is not intended to be enterprise-grade tool but it is more a proof of
concept/example code. The first command line argument of suricatasc is
used to specify the socket to connect to.
Configuration of the feature is made in the YAML under the 'unix-command'
section:
unix-command:
enabled: yes
filename: custom.socket
The path specified in 'filename' is not absolute and is relative to the
state directory.
A new running mode called 'unix-socket' is also added.
When starting in this mode, only a unix socket manager
is started. When it receives a 'pcap-file' command, the manager
start a 'pcap-file' running mode which does not really leave at
the end of file but simply exit. The manager is then able to start
a new running mode with a new file.
To start this mode, Suricata must be started with the --unix-socket
option which has an optional argument which fix the file name of the
socket. The path is not absolute and is relative to the state directory.
THe 'pcap-file' command adds a file to the list of files to treat.
For each pcap file, a pcap file running mode is started and the output
directory is changed to what specified in the command. The running
mode specified in the 'runmode' YAML setting is used to select which
running mode must be use for the pcap file treatment.
This requires modification in suricata.c file where initialisation code
is now conditional to the fact 'unix-socket' mode is not used.
Two other commands exists to get info on the remaining tasks:
* pcap-file-number: return the number of files in the waiting queue
* pcap-file-list: return the list of waiting files
'pcap-file-list' returns a structured object as message. The
structure is the following:
{
'count': 2,
'files': ['file1.pcap', 'file2.pcap']
}
14 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int RunModeUnixSocketIsActive(void)
|
|
|
|
{
|
|
|
|
return unix_socket_mode_is_running;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|