Log Inspector

Connecting Windows Server

On Windows, unlike Linux, logfiles cannot be forwarded with a simple configuration. Dispatching relies on an agent, from which you have several to choose. Graylog itself recommends two: Graylog Sidecar or NXLog (used in this example). The agent reads the logfiles from Windows and applications and forwards them to a defined Graylog port. Agents require their own configuration (discussed later).

The first step in connecting a Windows server to Graylog is to define an input under System | Inputs , choosing GELF UDP and then Launch new input . The window that then opens has seven self-explanatory fields. In the example for this article, Graylog listens on port 1515 (Figure 2).

Figure 2: Defining an input for Graylog.

The open source NXLog agent supports RFC 3164 standards, log formats from RFC 5424 to 5426, and many other formats, including CSV, GELF, JSON, and XML. The agent reads the logs and sends the data to the Graylog port. The best solution for collecting log data is rsyslogd [4]. Because Windows does not support this, you must tell the agent in which format the data will arrive and in which format they should be forwarded.

Writing the specifications to the NXLog configuration file defines input to and output from NXLog. Prefabricated modules can be used for both, but self-defined input or output formats are also possible. More about that later.

For the NXLog installation, run the downloaded EXE file on the Windows server. Installation under C:\Program Files (x86) creates an nxlog directory, and below it a conf directory where the configuration file (Listing 4) resides and where you save the pm_buffer module, which buffers the data on the hard drive when Graylog is not reachable. Finally, you can start the NXLog service under Windows by typing:

sc start nxlog

01 define ROOT C:\Program Files (x86)\nxlog
02 Moduledir %ROOT%\modules
03 CacheDir %ROOT%\data
04 Pidfile %ROOT%\data\nxlog.pid
05 SpoolDir %ROOT%\data
06 LogFile %ROOT%\data\nxlog.log
07 <extension gelf>
08 Modules xm_gelf
09 </Extension>
10 <Input in>
11 # Use for windows vista/2008 and higher:
12 modules in the_msvistalog
13
14 # Use for windows Windows XP/2000/2003:
15 # Modules in_mseventlog
16 </Input>
17
18 <processor buffer>
19 Modules pm_buffer
20 MaxSize 102400 # 100 MByte buffer on the hard disk
21 Type disk
22 </Processor>
23
24 <Output out>
25 Modules om_udp
26 Host GraylogServerName
27 Port 15150
28 OutputType GELF
29 </Output>
30
31 <Route 1>
32 Path in => out
33 </Route>

From this point on, you will find the incoming log entries in Graylog under System | Inputs by clicking Show received messages in the Windows section (Figure 3).

Figure 3: New incoming messages in Graylog.

Now it is possible to search for certain events with the Graylog search function. For example, you might be interested in finding failed logins in Active Directory (Figure 4), because these could be indicative of a brute force attack. You will find the EventID for all events on TechNet [5]; for a failed login, EventID is 4625. By searching for this number, you can list all failed login attempts, along with the corresponding information, such as the IP address of the client.

Figure 4: Failed logon attempts to Active Directory.

If you need more information in graphical form, open the TargetUserName field and click Quick values . The result is an infographic and list showing the most common logins. Figure 4 shows 237 Active Directory attempts with the name SRR-NB-01$ and 121 Active Directory attempts with the login name razorblader . These usernames are unknown on the system, so they are probably genuine attacks. On the other hand, 132 attempts (green arrow) were made by a registered user.

NXLog for Any Format

In special cases (e.g., logs that do not follow standard rules), the NXLog agent itself might have to monitor a logfile, convert it, and then send it to the Graylog server. The following example uses the in_file module in the <Input in> section, changes the content of the log, and passes everything to the output. The Output out tag determines whether the result is sent to Graylog via UDP or TCP. The syntax of the configuration is similar to Perl syntax (Listing 5).

01 <Extension gelf>
02 Modules xm_gelf
03 </Extension>
04
05 <Input in>
06 Modules in_file
07 File C:\Program Files (x86)\App\log\app.log"
08
09 # If there is a date and time in the logfile, extract it. If the date and time are not available, take the system time.
10 Exec if $raw_event =~ /(\d\d\d\d\d\-\d\d\d-\d\d \d\d:\d\d:\d\d\d)/
11 $EventTime = parsedate($1);
12
13 # Normally the hostname is set by default, for security's sake it can be entered in this way.
14 Exec $Hostname = 'myhost';
15
16 # Now the type of message (severity level) is set. The example uses the default syslog values.
17
18 # ALERT: 1, CRITICAL: 2, ERROR: 3, WARNING: 4, NOTICE: 5, INFO: 6, DEBUG: 7
19 Exec if $raw_event =~ /ERROR/ $SyslogSeverityValue = 3; else $SyslogSeverityValue = 6;
20
21 # The name of the file is also sent with the file
22 Exec $FileName = file_name();
23
24 # The SourceName variable is set by default to 'NXLOG'. To send the application names, too, use $SourceName = 'AppName' instead.
25 Exec $SourceName = ' AppName';
26 </Input>
27
28 <Output out>
29 Modules om_udp
30 Host GraylogServerName
31 Port 12201
32 OutputType GELF
33 </Output>
34
35 <Route r>
36 Path in => out
37 </Route>

Connecting Linux Servers

As already mentioned, Linux has supported log forwarding and remote logging for a long time. The syslogd system daemon receives all messages, sorts them by urgency and source, and archives them in one or more logfiles in the /var/log/ directory.

Syslog only supports UDP. Rsyslog, a later project from 2004, is an extension and uses the Reliable Event Logging Protocol (RELP), which is based on TCP and can therefore also be used with TLS. An important extension of rsyslog over syslog is that it can buffer local messages if the remote server is not ready to receive. The example in this article uses rsyslog.

The main configuration file is usually found in /etc/ as syslog.conf; rsyslog.d also resides in /etc/. Here, you need to create a new file, as shown in Listing 6.

*.* <@host.domain.org>:1516;RSYSLOG_SyslogProtocol23Format
 **
*.* @@<host.domain.org>:1516;RSYSLOG_SyslogProtocol23Format

The expression *.* means "forward everything the syslog daemon processes." The @ character stands for the UDP protocol on the transport route. Note that this protocol is not suitable for encryption. The @@ entry means that TCP must be used for the transport. Finally, RSYSLOG_SyslogProtocol23Format: stands for a built-in function that determines the format.

Now Graylog should be able to receive something. Under System/Inputs | Syslog TCP , click Launch new input and fill in the form. The most important parameters are shown in Listing 7.

allow_override_date: true
bind_address: 0.0.0.0
expand_structured_data: true
force_rdns: false
max_message_size: 2097152
override_source: <empty>
port: 1516
recv_buffer_size: 1048576
store_full_message: true
tcp_keepalive: true
tls_cert_file: /path...
tls_client_auth: disabled
tls_client_auth_cert_file: <empty>
tls_enable: true
tls_key_file: /path...
tls_key_password: ********
use_null_delimiter: false