[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-13 Thread Jochen Schalanda
Hi Rob,

the Graylog Collector Sidecar simply configures and starts the actual 
collectors (Filebeat or nxlog), so you'll have to check with their docs if 
that's possible:

https://nxlog.co/docs/nxlog-ce/nxlog-reference-manual.html
https://www.elastic.co/guide/en/beats/filebeat/current/index.html

Cheers,
Jochen

On Thursday, 9 February 2017 23:16:11 UTC+1, Rob Repp wrote:
>
> The files are definitely updating. One interesting thing, I tried do 
> establish this by just tailing the file with both Notepad++ and with a 
> freeware "tail" utility for Windows and it never updated. I had to manually 
> reload the file to see any changes. Further, I never saw any update in the 
> file Date Modified. Is there some way to force collector sidecar to poll 
> the files even if they don't show any obvious activity?
>
> On Tuesday, February 7, 2017 at 1:55:07 AM UTC-6, Jochen Schalanda wrote:
>>
>> Hi Rob,
>>
>> this sounds like either there is simply no new content in the files 
>> you've configured nxlog to watch, or that the file pattern is wrong. Try 
>> using another File pattern in the nxlog im_file input or switch to 
>> Filebeat.
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 6 February 2017 23:22:59 UTC+1, Rob Repp wrote:
>>>
>>> Okay, I did a packet capture that's showing traffic between the two 
>>> boxes. There seems to be the Graylog host sending a json of the nxlog.conf 
>>> config data to the DHCP server once every four seconds or so, and the DHCP 
>>> server sending back HTTP requests on port 9000. None of the exchanges look 
>>> like they contain data from the DHCP logs.
>>>
>>> On Monday, February 6, 2017 at 10:37:44 AM UTC-6, Jochen Schalanda wrote:

 Hi Rob,

 since the configuration doesn't show any obvious errors, please use 
 Wireshark or a similar tool like tcpdump to check if the log messages from 
 nxlog are sent to the correct host and if the UDP packets actually arrive 
 at the Graylog GELF UDP input.

 Cheers,
 Jochen

 On Monday, 6 February 2017 17:08:21 UTC+1, Rob Repp wrote:
>
> The traffic is not being blocked. There's no firewall on either 
> machine, and the network path is unobstructed. Further, the Collector 
> status for that Collector is showing green, with Backend "Nxlog: 
> running." 
> It looks like it's connected and responsive. It's just that there never 
> seem to be any messages on the associated Input.
> Tks,
> R.
>
> On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda 
> wrote:
>>
>> Hi Rob,
>>
>> the configuration looks good so far. Make sure that the host 
>> "re.da.ct.ed" can be accessed by your Windows machine and that port 
>> 5441/udp is open and not blocked by a firewall.
>>
>> Cheers,
>> Jochen
>>
>> On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>>>
>>> Okay, in order:
>>>
>>> 1. I'm using the OVA VM image from Graylog, so most of the 
>>> configuration is already done. All I did was add a Connector with one 
>>> nxlog 
>>> input and one nxlog output, and then the GELF UDP input that the 
>>> WinDHCP 
>>> json created.
>>>
>>> The WinDHCP input is configured like this:
>>>
>>> WinDHCPLogs-gelf GELF UDP RUNNING
>>> On node 771f3128 / graylog 
>>> 
>>>
>>>- bind_address:
>>>0.0.0.0
>>>- decompress_size_limit:
>>>8388608
>>>- override_source:
>>>**
>>>- port:
>>>5441
>>>- recv_buffer_size:
>>>1048576
>>>
>>>
>>> 2. The nxlog.conf file is:
>>>
>>> define ROOT C:\Program Files (x86)\nxlog
>>>
>>> 
>>>   Module xm_gelf
>>> 
>>>
>>> Moduledir %ROOT%\modules
>>> CacheDir %ROOT%\data
>>> Pidfile %ROOT%\data\nxlog.pid
>>> SpoolDir %ROOT%\data
>>> LogFile %ROOT%\data\nxlog.log
>>> LogLevel INFO
>>>
>>> 
>>> Module  xm_fileop
>>> 
>>> When@daily
>>> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>>>  
>>> 
>>>
>>> 
>>> Module im_file
>>> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
>>> PollInterval 1
>>> SavePos True
>>> ReadFromLast True
>>> Recursive False
>>> RenameCheck True
>>> Exec $FileName = file_name(); # Send file name with each message
>>> 
>>>
>>> 
>>> Module om_udp
>>> Host re.da.ct.ed
>>> Port 5441
>>> OutputType  GELF
>>> Exec $short_message = $raw_event; # Avoids truncation of the 
>>> short_message field.
>>> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
>>> Exec $Hostname = hostname_fqdn();
>>> 
>>>
>>> 
>>>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
>>> 
>>>
>>> 3. collector_sidecar.yml is this:
>

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-09 Thread Rob Repp
The files are definitely updating. One interesting thing, I tried do 
establish this by just tailing the file with both Notepad++ and with a 
freeware "tail" utility for Windows and it never updated. I had to manually 
reload the file to see any changes. Further, I never saw any update in the 
file Date Modified. Is there some way to force collector sidecar to poll 
the files even if they don't show any obvious activity?

On Tuesday, February 7, 2017 at 1:55:07 AM UTC-6, Jochen Schalanda wrote:
>
> Hi Rob,
>
> this sounds like either there is simply no new content in the files you've 
> configured nxlog to watch, or that the file pattern is wrong. Try using 
> another File pattern in the nxlog im_file input or switch to Filebeat.
>
> Cheers,
> Jochen
>
> On Monday, 6 February 2017 23:22:59 UTC+1, Rob Repp wrote:
>>
>> Okay, I did a packet capture that's showing traffic between the two 
>> boxes. There seems to be the Graylog host sending a json of the nxlog.conf 
>> config data to the DHCP server once every four seconds or so, and the DHCP 
>> server sending back HTTP requests on port 9000. None of the exchanges look 
>> like they contain data from the DHCP logs.
>>
>> On Monday, February 6, 2017 at 10:37:44 AM UTC-6, Jochen Schalanda wrote:
>>>
>>> Hi Rob,
>>>
>>> since the configuration doesn't show any obvious errors, please use 
>>> Wireshark or a similar tool like tcpdump to check if the log messages from 
>>> nxlog are sent to the correct host and if the UDP packets actually arrive 
>>> at the Graylog GELF UDP input.
>>>
>>> Cheers,
>>> Jochen
>>>
>>> On Monday, 6 February 2017 17:08:21 UTC+1, Rob Repp wrote:

 The traffic is not being blocked. There's no firewall on either 
 machine, and the network path is unobstructed. Further, the Collector 
 status for that Collector is showing green, with Backend "Nxlog: running." 
 It looks like it's connected and responsive. It's just that there never 
 seem to be any messages on the associated Input.
 Tks,
 R.

 On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda 
 wrote:
>
> Hi Rob,
>
> the configuration looks good so far. Make sure that the host 
> "re.da.ct.ed" can be accessed by your Windows machine and that port 
> 5441/udp is open and not blocked by a firewall.
>
> Cheers,
> Jochen
>
> On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>>
>> Okay, in order:
>>
>> 1. I'm using the OVA VM image from Graylog, so most of the 
>> configuration is already done. All I did was add a Connector with one 
>> nxlog 
>> input and one nxlog output, and then the GELF UDP input that the WinDHCP 
>> json created.
>>
>> The WinDHCP input is configured like this:
>>
>> WinDHCPLogs-gelf GELF UDP RUNNING
>> On node 771f3128 / graylog 
>> 
>>
>>- bind_address:
>>0.0.0.0
>>- decompress_size_limit:
>>8388608
>>- override_source:
>>**
>>- port:
>>5441
>>- recv_buffer_size:
>>1048576
>>
>>
>> 2. The nxlog.conf file is:
>>
>> define ROOT C:\Program Files (x86)\nxlog
>>
>> 
>>   Module xm_gelf
>> 
>>
>> Moduledir %ROOT%\modules
>> CacheDir %ROOT%\data
>> Pidfile %ROOT%\data\nxlog.pid
>> SpoolDir %ROOT%\data
>> LogFile %ROOT%\data\nxlog.log
>> LogLevel INFO
>>
>> 
>> Module  xm_fileop
>> 
>> When@daily
>> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>>  
>> 
>>
>> 
>> Module im_file
>> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
>> PollInterval 1
>> SavePos True
>> ReadFromLast True
>> Recursive False
>> RenameCheck True
>> Exec $FileName = file_name(); # Send file name with each message
>> 
>>
>> 
>> Module om_udp
>> Host re.da.ct.ed
>> Port 5441
>> OutputType  GELF
>> Exec $short_message = $raw_event; # Avoids truncation of the 
>> short_message field.
>> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
>> Exec $Hostname = hostname_fqdn();
>> 
>>
>> 
>>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
>> 
>>
>> 3. collector_sidecar.yml is this:
>>
>> server_url: http://re.da.ct.ed:9000/api 
>> update_interval: 10
>> tls_skip_verify: false
>> send_status: true
>> list_log_files:
>> node_id: NS1
>> collector_id: file:C:\Program 
>> Files\graylog\collector-sidecar\collector-id
>> cache_path: C:\Program Files\graylog\collector-sidecar\cache
>> log_path: C:\Program Files\graylog\collector-sidecar\logs
>> log_rotation_time: 86400
>> log_max_age: 604800
>> tags: dhcp
>> backends:
>> - name: nxlog
>>   enabled: true

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-06 Thread Jochen Schalanda
Hi Rob,

this sounds like either there is simply no new content in the files you've 
configured nxlog to watch, or that the file pattern is wrong. Try using 
another File pattern in the nxlog im_file input or switch to Filebeat.

Cheers,
Jochen

On Monday, 6 February 2017 23:22:59 UTC+1, Rob Repp wrote:
>
> Okay, I did a packet capture that's showing traffic between the two boxes. 
> There seems to be the Graylog host sending a json of the nxlog.conf config 
> data to the DHCP server once every four seconds or so, and the DHCP server 
> sending back HTTP requests on port 9000. None of the exchanges look like 
> they contain data from the DHCP logs.
>
> On Monday, February 6, 2017 at 10:37:44 AM UTC-6, Jochen Schalanda wrote:
>>
>> Hi Rob,
>>
>> since the configuration doesn't show any obvious errors, please use 
>> Wireshark or a similar tool like tcpdump to check if the log messages from 
>> nxlog are sent to the correct host and if the UDP packets actually arrive 
>> at the Graylog GELF UDP input.
>>
>> Cheers,
>> Jochen
>>
>> On Monday, 6 February 2017 17:08:21 UTC+1, Rob Repp wrote:
>>>
>>> The traffic is not being blocked. There's no firewall on either machine, 
>>> and the network path is unobstructed. Further, the Collector status for 
>>> that Collector is showing green, with Backend "Nxlog: running." It looks 
>>> like it's connected and responsive. It's just that there never seem to be 
>>> any messages on the associated Input.
>>> Tks,
>>> R.
>>>
>>> On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda 
>>> wrote:

 Hi Rob,

 the configuration looks good so far. Make sure that the host 
 "re.da.ct.ed" can be accessed by your Windows machine and that port 
 5441/udp is open and not blocked by a firewall.

 Cheers,
 Jochen

 On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>
> Okay, in order:
>
> 1. I'm using the OVA VM image from Graylog, so most of the 
> configuration is already done. All I did was add a Connector with one 
> nxlog 
> input and one nxlog output, and then the GELF UDP input that the WinDHCP 
> json created.
>
> The WinDHCP input is configured like this:
>
> WinDHCPLogs-gelf GELF UDP RUNNING
> On node 771f3128 / graylog 
> 
>
>- bind_address:
>0.0.0.0
>- decompress_size_limit:
>8388608
>- override_source:
>**
>- port:
>5441
>- recv_buffer_size:
>1048576
>
>
> 2. The nxlog.conf file is:
>
> define ROOT C:\Program Files (x86)\nxlog
>
> 
>   Module xm_gelf
> 
>
> Moduledir %ROOT%\modules
> CacheDir %ROOT%\data
> Pidfile %ROOT%\data\nxlog.pid
> SpoolDir %ROOT%\data
> LogFile %ROOT%\data\nxlog.log
> LogLevel INFO
>
> 
> Module  xm_fileop
> 
> When@daily
> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>  
> 
>
> 
> Module im_file
> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
> PollInterval 1
> SavePos True
> ReadFromLast True
> Recursive False
> RenameCheck True
> Exec $FileName = file_name(); # Send file name with each message
> 
>
> 
> Module om_udp
> Host re.da.ct.ed
> Port 5441
> OutputType  GELF
> Exec $short_message = $raw_event; # Avoids truncation of the 
> short_message field.
> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
> Exec $Hostname = hostname_fqdn();
> 
>
> 
>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
> 
>
> 3. collector_sidecar.yml is this:
>
> server_url: http://re.da.ct.ed:9000/api 
> update_interval: 10
> tls_skip_verify: false
> send_status: true
> list_log_files:
> node_id: NS1
> collector_id: file:C:\Program 
> Files\graylog\collector-sidecar\collector-id
> cache_path: C:\Program Files\graylog\collector-sidecar\cache
> log_path: C:\Program Files\graylog\collector-sidecar\logs
> log_rotation_time: 86400
> log_max_age: 604800
> tags: dhcp
> backends:
> - name: nxlog
>   enabled: true
>   binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\nxlog.conf
> - name: winlogbeat
>   enabled: false
>   binary_path: C:\Program 
> Files\graylog\collector-sidecar\winlogbeat.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\winlogbeat.yml
> - name: filebeat
>   enabled: false
>   binary_path: C:\Program 
> Files\graylog\collector-sidecar\filebeat.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\f

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-06 Thread Rob Repp
Okay, I did a packet capture that's showing traffic between the two boxes. 
There seems to be the Graylog host sending a json of the nxlog.conf config 
data to the DHCP server once every four seconds or so, and the DHCP server 
sending back HTTP requests on port 9000. None of the exchanges look like 
they contain data from the DHCP logs.

On Monday, February 6, 2017 at 10:37:44 AM UTC-6, Jochen Schalanda wrote:
>
> Hi Rob,
>
> since the configuration doesn't show any obvious errors, please use 
> Wireshark or a similar tool like tcpdump to check if the log messages from 
> nxlog are sent to the correct host and if the UDP packets actually arrive 
> at the Graylog GELF UDP input.
>
> Cheers,
> Jochen
>
> On Monday, 6 February 2017 17:08:21 UTC+1, Rob Repp wrote:
>>
>> The traffic is not being blocked. There's no firewall on either machine, 
>> and the network path is unobstructed. Further, the Collector status for 
>> that Collector is showing green, with Backend "Nxlog: running." It looks 
>> like it's connected and responsive. It's just that there never seem to be 
>> any messages on the associated Input.
>> Tks,
>> R.
>>
>> On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda wrote:
>>>
>>> Hi Rob,
>>>
>>> the configuration looks good so far. Make sure that the host 
>>> "re.da.ct.ed" can be accessed by your Windows machine and that port 
>>> 5441/udp is open and not blocked by a firewall.
>>>
>>> Cheers,
>>> Jochen
>>>
>>> On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:

 Okay, in order:

 1. I'm using the OVA VM image from Graylog, so most of the 
 configuration is already done. All I did was add a Connector with one 
 nxlog 
 input and one nxlog output, and then the GELF UDP input that the WinDHCP 
 json created.

 The WinDHCP input is configured like this:

 WinDHCPLogs-gelf GELF UDP RUNNING
 On node 771f3128 / graylog 
 

- bind_address:
0.0.0.0
- decompress_size_limit:
8388608
- override_source:
**
- port:
5441
- recv_buffer_size:
1048576


 2. The nxlog.conf file is:

 define ROOT C:\Program Files (x86)\nxlog

 
   Module xm_gelf
 

 Moduledir %ROOT%\modules
 CacheDir %ROOT%\data
 Pidfile %ROOT%\data\nxlog.pid
 SpoolDir %ROOT%\data
 LogFile %ROOT%\data\nxlog.log
 LogLevel INFO

 
 Module  xm_fileop
 
 When@daily
 Execfile_cycle('%ROOT%\data\nxlog.log', 7);
  
 

 
 Module im_file
 File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
 PollInterval 1
 SavePos True
 ReadFromLast True
 Recursive False
 RenameCheck True
 Exec $FileName = file_name(); # Send file name with each message
 

 
 Module om_udp
 Host re.da.ct.ed
 Port 5441
 OutputType  GELF
 Exec $short_message = $raw_event; # Avoids truncation of the 
 short_message field.
 Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
 Exec $Hostname = hostname_fqdn();
 

 
   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
 

 3. collector_sidecar.yml is this:

 server_url: http://re.da.ct.ed:9000/api 
 update_interval: 10
 tls_skip_verify: false
 send_status: true
 list_log_files:
 node_id: NS1
 collector_id: file:C:\Program 
 Files\graylog\collector-sidecar\collector-id
 cache_path: C:\Program Files\graylog\collector-sidecar\cache
 log_path: C:\Program Files\graylog\collector-sidecar\logs
 log_rotation_time: 86400
 log_max_age: 604800
 tags: dhcp
 backends:
 - name: nxlog
   enabled: true
   binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
   configuration_path: C:\Program 
 Files\graylog\collector-sidecar\generated\nxlog.conf
 - name: winlogbeat
   enabled: false
   binary_path: C:\Program 
 Files\graylog\collector-sidecar\winlogbeat.exe
   configuration_path: C:\Program 
 Files\graylog\collector-sidecar\generated\winlogbeat.yml
 - name: filebeat
   enabled: false
   binary_path: C:\Program 
 Files\graylog\collector-sidecar\filebeat.exe
   configuration_path: C:\Program 
 Files\graylog\collector-sidecar\generated\filebeat.yml





 On Friday, February 3, 2017 at 3:21:21 AM UTC-6, Jochen Schalanda wrote:
>
> Hi Rob,
>
> How did you configure Graylog? Which inputs did you create and how did 
> you configure them?
> How did you configure the Graylog Collector Sidecar and what's the 
> generated nxlog configuration?
>
> Cheers,
> Jochen
>
> On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:
>

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-06 Thread Jochen Schalanda
Hi Rob,

since the configuration doesn't show any obvious errors, please use 
Wireshark or a similar tool like tcpdump to check if the log messages from 
nxlog are sent to the correct host and if the UDP packets actually arrive 
at the Graylog GELF UDP input.

Cheers,
Jochen

On Monday, 6 February 2017 17:08:21 UTC+1, Rob Repp wrote:
>
> The traffic is not being blocked. There's no firewall on either machine, 
> and the network path is unobstructed. Further, the Collector status for 
> that Collector is showing green, with Backend "Nxlog: running." It looks 
> like it's connected and responsive. It's just that there never seem to be 
> any messages on the associated Input.
> Tks,
> R.
>
> On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda wrote:
>>
>> Hi Rob,
>>
>> the configuration looks good so far. Make sure that the host 
>> "re.da.ct.ed" can be accessed by your Windows machine and that port 
>> 5441/udp is open and not blocked by a firewall.
>>
>> Cheers,
>> Jochen
>>
>> On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>>>
>>> Okay, in order:
>>>
>>> 1. I'm using the OVA VM image from Graylog, so most of the configuration 
>>> is already done. All I did was add a Connector with one nxlog input and one 
>>> nxlog output, and then the GELF UDP input that the WinDHCP json created.
>>>
>>> The WinDHCP input is configured like this:
>>>
>>> WinDHCPLogs-gelf GELF UDP RUNNING
>>> On node 771f3128 / graylog 
>>> 
>>>
>>>- bind_address:
>>>0.0.0.0
>>>- decompress_size_limit:
>>>8388608
>>>- override_source:
>>>**
>>>- port:
>>>5441
>>>- recv_buffer_size:
>>>1048576
>>>
>>>
>>> 2. The nxlog.conf file is:
>>>
>>> define ROOT C:\Program Files (x86)\nxlog
>>>
>>> 
>>>   Module xm_gelf
>>> 
>>>
>>> Moduledir %ROOT%\modules
>>> CacheDir %ROOT%\data
>>> Pidfile %ROOT%\data\nxlog.pid
>>> SpoolDir %ROOT%\data
>>> LogFile %ROOT%\data\nxlog.log
>>> LogLevel INFO
>>>
>>> 
>>> Module  xm_fileop
>>> 
>>> When@daily
>>> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>>>  
>>> 
>>>
>>> 
>>> Module im_file
>>> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
>>> PollInterval 1
>>> SavePos True
>>> ReadFromLast True
>>> Recursive False
>>> RenameCheck True
>>> Exec $FileName = file_name(); # Send file name with each message
>>> 
>>>
>>> 
>>> Module om_udp
>>> Host re.da.ct.ed
>>> Port 5441
>>> OutputType  GELF
>>> Exec $short_message = $raw_event; # Avoids truncation of the 
>>> short_message field.
>>> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
>>> Exec $Hostname = hostname_fqdn();
>>> 
>>>
>>> 
>>>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
>>> 
>>>
>>> 3. collector_sidecar.yml is this:
>>>
>>> server_url: http://re.da.ct.ed:9000/api 
>>> update_interval: 10
>>> tls_skip_verify: false
>>> send_status: true
>>> list_log_files:
>>> node_id: NS1
>>> collector_id: file:C:\Program 
>>> Files\graylog\collector-sidecar\collector-id
>>> cache_path: C:\Program Files\graylog\collector-sidecar\cache
>>> log_path: C:\Program Files\graylog\collector-sidecar\logs
>>> log_rotation_time: 86400
>>> log_max_age: 604800
>>> tags: dhcp
>>> backends:
>>> - name: nxlog
>>>   enabled: true
>>>   binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
>>>   configuration_path: C:\Program 
>>> Files\graylog\collector-sidecar\generated\nxlog.conf
>>> - name: winlogbeat
>>>   enabled: false
>>>   binary_path: C:\Program 
>>> Files\graylog\collector-sidecar\winlogbeat.exe
>>>   configuration_path: C:\Program 
>>> Files\graylog\collector-sidecar\generated\winlogbeat.yml
>>> - name: filebeat
>>>   enabled: false
>>>   binary_path: C:\Program 
>>> Files\graylog\collector-sidecar\filebeat.exe
>>>   configuration_path: C:\Program 
>>> Files\graylog\collector-sidecar\generated\filebeat.yml
>>>
>>>
>>>
>>>
>>>
>>> On Friday, February 3, 2017 at 3:21:21 AM UTC-6, Jochen Schalanda wrote:

 Hi Rob,

 How did you configure Graylog? Which inputs did you create and how did 
 you configure them?
 How did you configure the Graylog Collector Sidecar and what's the 
 generated nxlog configuration?

 Cheers,
 Jochen

 On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:
>
> I set up a Graylog 2.1.2 server by deploying the downloadable OVA from 
> graylog.org. I'm trying to monitor a Windows 2008 R2 server with the 
> DHCP role installed. The DHCP server deposits activity data into log 
> files 
> at C:\Windows\System32\dhcp\DhcpSrvLog-*.log. I have collector-sidecar 
> and 
> nxlog installed on the Windows machine, and configured to send the log 
> data 
> back to a collector input on the Graylog server.
>
> My configuration is based on the WindowsDHCP content pack available in 
> the Graylog marketplace. I

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-06 Thread Rob Repp
The traffic is not being blocked. There's no firewall on either machine, 
and the network path is unobstructed. Further, the Collector status for 
that Collector is showing green, with Backend "Nxlog: running." It looks 
like it's connected and responsive. It's just that there never seem to be 
any messages on the associated Input.
Tks,
R.

On Saturday, February 4, 2017 at 3:30:18 AM UTC-6, Jochen Schalanda wrote:
>
> Hi Rob,
>
> the configuration looks good so far. Make sure that the host "re.da.ct.ed" 
> can be accessed by your Windows machine and that port 5441/udp is open and 
> not blocked by a firewall.
>
> Cheers,
> Jochen
>
> On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>>
>> Okay, in order:
>>
>> 1. I'm using the OVA VM image from Graylog, so most of the configuration 
>> is already done. All I did was add a Connector with one nxlog input and one 
>> nxlog output, and then the GELF UDP input that the WinDHCP json created.
>>
>> The WinDHCP input is configured like this:
>>
>> WinDHCPLogs-gelf GELF UDP RUNNING
>> On node 771f3128 / graylog 
>> 
>>
>>- bind_address:
>>0.0.0.0
>>- decompress_size_limit:
>>8388608
>>- override_source:
>>**
>>- port:
>>5441
>>- recv_buffer_size:
>>1048576
>>
>>
>> 2. The nxlog.conf file is:
>>
>> define ROOT C:\Program Files (x86)\nxlog
>>
>> 
>>   Module xm_gelf
>> 
>>
>> Moduledir %ROOT%\modules
>> CacheDir %ROOT%\data
>> Pidfile %ROOT%\data\nxlog.pid
>> SpoolDir %ROOT%\data
>> LogFile %ROOT%\data\nxlog.log
>> LogLevel INFO
>>
>> 
>> Module  xm_fileop
>> 
>> When@daily
>> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>>  
>> 
>>
>> 
>> Module im_file
>> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
>> PollInterval 1
>> SavePos True
>> ReadFromLast True
>> Recursive False
>> RenameCheck True
>> Exec $FileName = file_name(); # Send file name with each message
>> 
>>
>> 
>> Module om_udp
>> Host re.da.ct.ed
>> Port 5441
>> OutputType  GELF
>> Exec $short_message = $raw_event; # Avoids truncation of the 
>> short_message field.
>> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
>> Exec $Hostname = hostname_fqdn();
>> 
>>
>> 
>>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
>> 
>>
>> 3. collector_sidecar.yml is this:
>>
>> server_url: http://re.da.ct.ed:9000/api 
>> update_interval: 10
>> tls_skip_verify: false
>> send_status: true
>> list_log_files:
>> node_id: NS1
>> collector_id: file:C:\Program Files\graylog\collector-sidecar\collector-id
>> cache_path: C:\Program Files\graylog\collector-sidecar\cache
>> log_path: C:\Program Files\graylog\collector-sidecar\logs
>> log_rotation_time: 86400
>> log_max_age: 604800
>> tags: dhcp
>> backends:
>> - name: nxlog
>>   enabled: true
>>   binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
>>   configuration_path: C:\Program 
>> Files\graylog\collector-sidecar\generated\nxlog.conf
>> - name: winlogbeat
>>   enabled: false
>>   binary_path: C:\Program 
>> Files\graylog\collector-sidecar\winlogbeat.exe
>>   configuration_path: C:\Program 
>> Files\graylog\collector-sidecar\generated\winlogbeat.yml
>> - name: filebeat
>>   enabled: false
>>   binary_path: C:\Program Files\graylog\collector-sidecar\filebeat.exe
>>   configuration_path: C:\Program 
>> Files\graylog\collector-sidecar\generated\filebeat.yml
>>
>>
>>
>>
>>
>> On Friday, February 3, 2017 at 3:21:21 AM UTC-6, Jochen Schalanda wrote:
>>>
>>> Hi Rob,
>>>
>>> How did you configure Graylog? Which inputs did you create and how did 
>>> you configure them?
>>> How did you configure the Graylog Collector Sidecar and what's the 
>>> generated nxlog configuration?
>>>
>>> Cheers,
>>> Jochen
>>>
>>> On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:

 I set up a Graylog 2.1.2 server by deploying the downloadable OVA from 
 graylog.org. I'm trying to monitor a Windows 2008 R2 server with the 
 DHCP role installed. The DHCP server deposits activity data into log files 
 at C:\Windows\System32\dhcp\DhcpSrvLog-*.log. I have collector-sidecar and 
 nxlog installed on the Windows machine, and configured to send the log 
 data 
 back to a collector input on the Graylog server.

 My configuration is based on the WindowsDHCP content pack available in 
 the Graylog marketplace. I imported the content pack json, 
 configured collector-sidecar on Windows and the Graylog collector starting 
 from the sample code at https://github.com/JulioQc/WinDHCP. 
 Unfortunately, when I do "show messages" for the collector, there's 
 nothing 
 coming in.

 Has anyone had any success with this configuration? If not, is there a 
 better method for monitoring Windows DHCP activity with Graylog? Thanks!

>>>

-- 
You received this message because you are subscribed to the Googl

[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-04 Thread Jochen Schalanda
Hi Rob,

the configuration looks good so far. Make sure that the host "re.da.ct.ed" 
can be accessed by your Windows machine and that port 5441/udp is open and 
not blocked by a firewall.

Cheers,
Jochen

On Friday, 3 February 2017 23:10:50 UTC+1, Rob Repp wrote:
>
> Okay, in order:
>
> 1. I'm using the OVA VM image from Graylog, so most of the configuration 
> is already done. All I did was add a Connector with one nxlog input and one 
> nxlog output, and then the GELF UDP input that the WinDHCP json created.
>
> The WinDHCP input is configured like this:
>
> WinDHCPLogs-gelf GELF UDP RUNNING
> On node 771f3128 / graylog 
> 
>
>- bind_address:
>0.0.0.0
>- decompress_size_limit:
>8388608
>- override_source:
>**
>- port:
>5441
>- recv_buffer_size:
>1048576
>
>
> 2. The nxlog.conf file is:
>
> define ROOT C:\Program Files (x86)\nxlog
>
> 
>   Module xm_gelf
> 
>
> Moduledir %ROOT%\modules
> CacheDir %ROOT%\data
> Pidfile %ROOT%\data\nxlog.pid
> SpoolDir %ROOT%\data
> LogFile %ROOT%\data\nxlog.log
> LogLevel INFO
>
> 
> Module  xm_fileop
> 
> When@daily
> Execfile_cycle('%ROOT%\data\nxlog.log', 7);
>  
> 
>
> 
> Module im_file
> File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
> PollInterval 1
> SavePos True
> ReadFromLast True
> Recursive False
> RenameCheck True
> Exec $FileName = file_name(); # Send file name with each message
> 
>
> 
> Module om_udp
> Host re.da.ct.ed
> Port 5441
> OutputType  GELF
> Exec $short_message = $raw_event; # Avoids truncation of the short_message 
> field.
> Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
> Exec $Hostname = hostname_fqdn();
> 
>
> 
>   Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0
> 
>
> 3. collector_sidecar.yml is this:
>
> server_url: http://re.da.ct.ed:9000/api 
> update_interval: 10
> tls_skip_verify: false
> send_status: true
> list_log_files:
> node_id: NS1
> collector_id: file:C:\Program Files\graylog\collector-sidecar\collector-id
> cache_path: C:\Program Files\graylog\collector-sidecar\cache
> log_path: C:\Program Files\graylog\collector-sidecar\logs
> log_rotation_time: 86400
> log_max_age: 604800
> tags: dhcp
> backends:
> - name: nxlog
>   enabled: true
>   binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\nxlog.conf
> - name: winlogbeat
>   enabled: false
>   binary_path: C:\Program 
> Files\graylog\collector-sidecar\winlogbeat.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\winlogbeat.yml
> - name: filebeat
>   enabled: false
>   binary_path: C:\Program Files\graylog\collector-sidecar\filebeat.exe
>   configuration_path: C:\Program 
> Files\graylog\collector-sidecar\generated\filebeat.yml
>
>
>
>
>
> On Friday, February 3, 2017 at 3:21:21 AM UTC-6, Jochen Schalanda wrote:
>>
>> Hi Rob,
>>
>> How did you configure Graylog? Which inputs did you create and how did 
>> you configure them?
>> How did you configure the Graylog Collector Sidecar and what's the 
>> generated nxlog configuration?
>>
>> Cheers,
>> Jochen
>>
>> On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:
>>>
>>> I set up a Graylog 2.1.2 server by deploying the downloadable OVA from 
>>> graylog.org. I'm trying to monitor a Windows 2008 R2 server with the 
>>> DHCP role installed. The DHCP server deposits activity data into log files 
>>> at C:\Windows\System32\dhcp\DhcpSrvLog-*.log. I have collector-sidecar and 
>>> nxlog installed on the Windows machine, and configured to send the log data 
>>> back to a collector input on the Graylog server.
>>>
>>> My configuration is based on the WindowsDHCP content pack available in 
>>> the Graylog marketplace. I imported the content pack json, 
>>> configured collector-sidecar on Windows and the Graylog collector starting 
>>> from the sample code at https://github.com/JulioQc/WinDHCP. 
>>> Unfortunately, when I do "show messages" for the collector, there's nothing 
>>> coming in.
>>>
>>> Has anyone had any success with this configuration? If not, is there a 
>>> better method for monitoring Windows DHCP activity with Graylog? Thanks!
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/b5d0ddb0-009a-4f2a-8164-b3a3641f5acf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-03 Thread Rob Repp
Okay, in order:

1. I'm using the OVA VM image from Graylog, so most of the configuration is 
already done. All I did was add a Connector with one nxlog input and one 
nxlog output, and then the GELF UDP input that the WinDHCP json created.

The WinDHCP input is configured like this:

WinDHCPLogs-gelf GELF UDP RUNNING
On node 771f3128 / graylog 


   - bind_address:
   0.0.0.0
   - decompress_size_limit:
   8388608
   - override_source:
   **
   - port:
   5441
   - recv_buffer_size:
   1048576
   

2. The nxlog.conf file is:

define ROOT C:\Program Files (x86)\nxlog


  Module xm_gelf


Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO


Module  xm_fileop

When@daily
Execfile_cycle('%ROOT%\data\nxlog.log', 7);
 



Module im_file
File 'C:\Windows\System32\dhcp\DhcpSrvLog-*.log'
PollInterval 1
SavePos True
ReadFromLast True
Recursive False
RenameCheck True
Exec $FileName = file_name(); # Send file name with each message



Module om_udp
Host re.da.ct.ed
Port 5441
OutputType  GELF
Exec $short_message = $raw_event; # Avoids truncation of the short_message 
field.
Exec $gl2_source_collector = '9960a8cd-7abe-4021-939f-89b22909aa32';
Exec $Hostname = hostname_fqdn();



  Path 588bc33f682c990374bab049 => 588bc2db682c990374baafe0


3. collector_sidecar.yml is this:

server_url: http://re.da.ct.ed:9000/api 
update_interval: 10
tls_skip_verify: false
send_status: true
list_log_files:
node_id: NS1
collector_id: file:C:\Program Files\graylog\collector-sidecar\collector-id
cache_path: C:\Program Files\graylog\collector-sidecar\cache
log_path: C:\Program Files\graylog\collector-sidecar\logs
log_rotation_time: 86400
log_max_age: 604800
tags: dhcp
backends:
- name: nxlog
  enabled: true
  binary_path: C:\Program Files (x86)\nxlog\nxlog.exe
  configuration_path: C:\Program 
Files\graylog\collector-sidecar\generated\nxlog.conf
- name: winlogbeat
  enabled: false
  binary_path: C:\Program Files\graylog\collector-sidecar\winlogbeat.exe
  configuration_path: C:\Program 
Files\graylog\collector-sidecar\generated\winlogbeat.yml
- name: filebeat
  enabled: false
  binary_path: C:\Program Files\graylog\collector-sidecar\filebeat.exe
  configuration_path: C:\Program 
Files\graylog\collector-sidecar\generated\filebeat.yml





On Friday, February 3, 2017 at 3:21:21 AM UTC-6, Jochen Schalanda wrote:
>
> Hi Rob,
>
> How did you configure Graylog? Which inputs did you create and how did you 
> configure them?
> How did you configure the Graylog Collector Sidecar and what's the 
> generated nxlog configuration?
>
> Cheers,
> Jochen
>
> On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:
>>
>> I set up a Graylog 2.1.2 server by deploying the downloadable OVA from 
>> graylog.org. I'm trying to monitor a Windows 2008 R2 server with the 
>> DHCP role installed. The DHCP server deposits activity data into log files 
>> at C:\Windows\System32\dhcp\DhcpSrvLog-*.log. I have collector-sidecar and 
>> nxlog installed on the Windows machine, and configured to send the log data 
>> back to a collector input on the Graylog server.
>>
>> My configuration is based on the WindowsDHCP content pack available in 
>> the Graylog marketplace. I imported the content pack json, 
>> configured collector-sidecar on Windows and the Graylog collector starting 
>> from the sample code at https://github.com/JulioQc/WinDHCP. 
>> Unfortunately, when I do "show messages" for the collector, there's nothing 
>> coming in.
>>
>> Has anyone had any success with this configuration? If not, is there a 
>> better method for monitoring Windows DHCP activity with Graylog? Thanks!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/543d176c-bd2f-42fb-9fc9-66aa36a474d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[graylog2] Re: Monitoring Windows DHCP Server Activity

2017-02-03 Thread Jochen Schalanda
Hi Rob,

How did you configure Graylog? Which inputs did you create and how did you 
configure them?
How did you configure the Graylog Collector Sidecar and what's the 
generated nxlog configuration?

Cheers,
Jochen

On Thursday, 2 February 2017 23:30:20 UTC+1, Rob Repp wrote:
>
> I set up a Graylog 2.1.2 server by deploying the downloadable OVA from 
> graylog.org. I'm trying to monitor a Windows 2008 R2 server with the DHCP 
> role installed. The DHCP server deposits activity data into log files 
> at C:\Windows\System32\dhcp\DhcpSrvLog-*.log. I have collector-sidecar and 
> nxlog installed on the Windows machine, and configured to send the log data 
> back to a collector input on the Graylog server.
>
> My configuration is based on the WindowsDHCP content pack available in the 
> Graylog marketplace. I imported the content pack json, 
> configured collector-sidecar on Windows and the Graylog collector starting 
> from the sample code at https://github.com/JulioQc/WinDHCP. 
> Unfortunately, when I do "show messages" for the collector, there's nothing 
> coming in.
>
> Has anyone had any success with this configuration? If not, is there a 
> better method for monitoring Windows DHCP activity with Graylog? Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/graylog2/556abf93-9eb8-4de3-bd37-209742509186%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.