problem with rotation of /dailylogs

[sa_zh]

Hi

I've just installed the security onion Version 20110321 and seem to
have problems with the rotation of ..../dailylogs/.
The folder for the current day is not created automatically, I have to
manually run nsm --sensor --restart. The effect is that I can't open
trancripts on the SGUIL-server because the application is looking for
files in the wrong folder. After the manual restart of the sensor,
transcripts open as expected.

Here's what it looks like:

XXX:/nsm/sensor_data/XXX/dailylogs# date
Tue Apr 19 08:11:30 CEST 2011

XXX:/nsm/sensor_data/XXX/dailylogs# ls -l
total 36
drwxrwxr-x 2 sguil sguil 4096 2011-04-11 00:00 2011-04-10
drwxrwxr-x 2 sguil sguil 4096 2011-04-12 18:32 2011-04-11
drwxrwxr-x 2 sguil sguil 4096 2011-04-13 00:00 2011-04-12
drwxrwxr-x 2 sguil sguil 4096 2011-04-14 18:04 2011-04-13
drwxrwxr-x 2 sguil sguil 4096 2011-04-15 00:00 2011-04-14
drwxrwxr-x 2 sguil sguil 4096 2011-04-16 17:08 2011-04-15
drwxrwxr-x 2 sguil sguil 4096 2011-04-17 00:00 2011-04-16
drwxrwxr-x 2 sguil sguil 4096 2011-04-18 14:52 2011-04-17
drwxrwxr-x 2 sguil sguil 4096 2011-04-19 00:00 2011-04-18

root@FAMSYSMON01:/nsm/sensor_data/FAMSYSMON01-eth0/dailylogs# nsm --
sensor --restart
Restarting: XXX
* stopping: pcap_agent
(sguil)
[ OK ]
[...]


XXX:/nsm/sensor_data/XXX/dailylogs# ls -l
total 40
drwxrwxr-x 2 sguil sguil 4096 2011-04-11 00:00 2011-04-10
drwxrwxr-x 2 sguil sguil 4096 2011-04-12 18:32 2011-04-11
drwxrwxr-x 2 sguil sguil 4096 2011-04-13 00:00 2011-04-12
drwxrwxr-x 2 sguil sguil 4096 2011-04-14 18:04 2011-04-13
drwxrwxr-x 2 sguil sguil 4096 2011-04-15 00:00 2011-04-14
drwxrwxr-x 2 sguil sguil 4096 2011-04-16 17:08 2011-04-15
drwxrwxr-x 2 sguil sguil 4096 2011-04-17 00:00 2011-04-16
drwxrwxr-x 2 sguil sguil 4096 2011-04-18 14:52 2011-04-17
drwxrwxr-x 2 sguil sguil 4096 2011-04-19 00:00 2011-04-18
drwxrwxr-x 2 sguil sguil 4096 2011-04-19 08:14 2011-04-19


Also, /var/log/syslog suggests that the sensor was restarted:
Apr 19 00:00:01 XXX CRON[4150]: (root) CMD (/usr/local/sbin/nsm --
sensor --restart --only-snort-logging >> /var/log/nsm/sensor-
newday.log)


Thanks in advance for your help
Oli

[Doug Burks]

Hi Oli,

Thanks for using Security Onion!

I haven't had any other reports of this issue. Some questions for you:
- Your directory listing shows dailylogs back to 2011-04-10. Have you
had to do this manually for every single one of those days? Or was it
working at some point in time?
- Have you made any changes to the system since installation? For
example, any permissions changes, or perhaps symlinking /nsm to a
different mount point?
- Are there any errors in /var/log/ that would correspond to the "nsm
--sensor --restart" cronjob?

Thanks,
--
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[sa_zh]

Hi Doug

Thanks for the quick reply. As for your questions:

> - Your directory listing shows dailylogs back to 2011-04-10. Have you
> had to do this manually for every single one of those days? Or was it
> working at some point in time?

I can't tell if it ever worked. We restarted the server a couple of
times since. My guess is that it never worked.

> - Have you made any changes to the system since installation? For
> example, any permissions changes, or perhaps symlinking /nsm to a
> different mount point?

We have two NICs in the sensor where snort is listening, I remember
having to create a directory manually for the second NIC somewhere. I
don't recall where it was though, maybe for log files?
But I did not fiddle with the configuration settings, i.e. change
pathes of conf-files, symlinking directories or similar. The
permissions are out of the box as well...

> - Are there any errors in /var/log/ that would correspond to the "nsm
> --sensor --restart" cronjob?

Nope, no errors - nothing special.

grep restart /var/log/syslog.1
Apr 19 00:00:01 XXXX CRON[4150]: (root) CMD (/usr/local/sbin/nsm --

sensor --restart --only-snort-logging >> /var/log/nsm/sensor-
newday.log)

If all fails, we could make a clean re-install of the system, since
installation and setup is pretty straightforward. That would show
whether the problem is reproducable or if I made a mistake somewhere.
Still, if not necessary I'd rather not :)

Regards
Oli

[Doug Burks]

Hello again Oli,

/etc/cron.d/sensor-newday should run every day at midnight and log to
/var/log/nsm/sensor-newday.log. Is there anything in this log file?
Can you include it in your reply?

Based on the separate issue that you created
(http://code.google.com/p/security-onion/issues/detail?id=100), is it
possible that you weren't able to log into the server when you ran
Setup on the sensor? If that were the case, that would explain if you
had to manually create a directory for the sensor in
/nsm/sensor_data/securityonion/rules/.

Thanks,
--
Doug Burks, GSE, CISSP

President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[sa_zh]

Hi Doug

It seems that entries get written to the logfile, but without
timestamp. I have added the output of the logfile below.
As for the question about SSH, that's entirely possible. We have SSH
listening on another port than 22, to reduce noise of automated
scans.
Might be that the port was changed before the sensor connected to the
server, that would also explain the missing authorized_keys file.
But could that mess up log rotation? I have the same problem on server
& sensor...

It gets a bit confusing, having one issue open in the issue tracker
and a discussion on this group. What would be the best way to handle
issues in the future?
First ask questions here, and after confirmation it's really an issue
enter it into the tracker? Sorry for that :)

Here are the logfiles you asked for...

Thanks
Oli



~$ ls -l /etc/cron.d
total 16
-rw-r--r-- 1 root root 288 2010-03-05 03:29 anacron
-rw-r--r-- 1 root root 607 2009-12-21 23:23 john
-rw-r--r-- 1 root root 499 2010-09-17 15:53 php5
-rw-r--r-- 1 root root 300 2010-10-09 18:18 sensor-newday

~$ ls -l /var/log/nsm/sensor-newday.log
-rw-r--r-- 1 root root 8570 2011-04-21 00:00 /var/log/nsm/sensor-
newday.log

~$ cat /var/log/nsm/sensor-newday.log
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 3%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 7%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 7%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 16%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 16%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 17%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 17%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 22%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 22%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 34%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 34%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 49%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 49%
Restarting: xxxx-eth1
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 61%
Restarting: xxxx-eth2
* restarting with overlap: snort (full packet data)
* starting: snort (full packet
data)
[ OK ]
- stopping old process: snort (full packet
data)
[ OK ]
* disk space currently at 61%

On Apr 20, 12:04 pm, Doug Burks <doug.bu...@gmail.com> wrote:
> Hello again Oli,
>
> /etc/cron.d/sensor-newday should run every day at midnight and log to
> /var/log/nsm/sensor-newday.log.  Is there anything in this log file?
> Can you include it in your reply?
>
> Based on the separate issue that you created
> (http://code.google.com/p/security-onion/issues/detail?id=100), is it
> possible that you weren't able to log into the server when you ran
> Setup on the sensor?  If that were the case, that would explain if you
> had to manually create a directory for the sensor in
> /nsm/sensor_data/securityonion/rules/.
>
> Thanks,
> --
> Doug Burks, GSE, CISSP

> President, Greater Augusta ISSAhttp://augusta.issa.orghttp://securityonion.blogspot.com

[Doug Burks]

Hey Oli,

I closed your issue in the Issue Tracker since it was due to the
non-standard SSH port. The mailing list is more conducive to
discussion, so it's probably better to ask about an issue on the
mailing list first and then add it to the Issue Tracker once we've
confirmed it.

Unfortunately, I'm not sure why your dailylogs aren't being rotated
properly. I've verified that my servers and sensors are rotating
dailylogs correctly. At this point, I would recommend the following:
-Download the ISO from:
http://sourceforge.net/projects/security-onion/files/
-Make sure that you verify the checksum! We've had strange issues in
the past that turned out to be due to a corrupt ISO download.
-Install your server and sensor per the following:
http://securityonion.blogspot.com/2011/04/security-onion-20110321-distributed.html
-Keep the default SSH port and make sure that the sensor correctly
logs into the server during Setup.
-Make no other changes to the system and check the next day for proper
rotation of dailylogs.

Please let us know how it goes!

Thanks,
--
Doug Burks, GSE, CISSP

President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[Der Pflanzer]

Hi Doug


I think I may be on to something. Our servers are in the CEST timezone. I suspect that the NSMnow scripts are somehow based on UTC. What leads me to this belief is that I entered a cronjob in /etc/crontab executing the exact same command that creates the folder for the current day:

*********************************

05 0    * * *   root    nsm --sensor --restart

********************************

The cronjob executes without problem, but the new folders don't show up.
I looked into the NSMnow scripts and found the following lines:

********************************

cat /usr/local/sbin/nsm_sensor_ps-restart

[...]
TODAY=$(date $DATE_OPTIONS "+%Y-%m-%d")      #-u option sets TZ to GMT
        if [ ! -d "$SENSOR_LOG_DIR/dailylogs/$TODAY" ]
        then
            mkdir -p $SENSOR_LOG_DIR/dailylogs/$TODAY
            chown $SENSOR_USER:$SENSOR_GROUP $SENSOR_LOG_DIR/dailylogs/$TODAY
            chmod 775 $SENSOR_LOG_DIR/dailylogs/$TODAY
        fi
[...]
********************************

I didn't find where $DATE_OPTIONS is set, but I think that might be related to our problem:

********************************

root@XXXX:/nsm/sensor_data/XXXX-eth0/dailylogs# date "+%Y-%m-%d-%H" && date -u "+%Y-%m-%d-%H"
2011-04-27-15
2011-04-27-13

********************************


I will now change the entry in /etc/crontab so that the command gets executed after 2am. I'll let you know about the outcome tomorrow.


Regards
Oli

2011/4/22 Doug Burks <doug....@gmail.com>

[Doug Burks]

Hello again Oli,

It sounds like you've pinpointed it. Thanks for your persistence so
far in tracking this down!

Going back through the Issue Tracker, I found an older issue that was
probably related, so I copied your description to it:
http://code.google.com/p/security-onion/issues/detail?id=76

Please let us know if your change works.

Thanks,
--
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[Der Pflanzer]

Hi Doug


That was it.

*********************

root@xxxx:~# date && ls -l /nsm/sensor_data/xxxx-eth0/dailylogs/ | tail -1
Thu Apr 28 08:32:19 CEST 2011
drwxrwxr-x 2 sguil sguil 4096 2011-04-28 02:05 2011-04-28

root@xxxx:~# cat /etc/crontab | grep nsm
05 2    * * *   root    nsm --sensor --restart

*********************

It really seems that somewhere in the nsm-scripts $DATE_OPTIONS is set to "-u", which leads to the incorrect timezone.
Do you know where that happens so we can change it?


Regards
Oli

2011/4/28 Doug Burks <doug....@gmail.com>

[Doug Burks]

I believe this is controlled by the SENSOR_UTC setting in
/etc/nsm/SENSOR_NAME/sensor.conf. Try changing it from Y to N and
restarting the sensor. Do this for all sensors to maintain
consistency. Please let us know whether or not that helps.

Thanks,
--
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[sa_zh]

Hi Doug

I changed the setting, and the logfiles rotate correctly now. That was
it. Thanks for your help with that one!

However, shortly after making the change, we started having problems
(not always, but almost always) opening transcript files in sguil.
I am not 100% sure if the problems were related, but I strongly
suspect so:

When opening the transcript file for an alert in sguil, the transcript
window said "No Data Sent."

Debug Message output:

"""
Your request has been sent to the server.
Please be patient as this can take some time.
Raw data request sent to xxxx-eth1.
Making a list of local log files.
Looking in /nsm/sensor_data/xxxx-eth1/dailylogs/2011-05-12.
Making a list of local log files in /nsm/sensor_data/xxxx-eth1/
dailylogs/2011-05-12.
Available log files:
1305208591 1305208315 1305207991 1305207447 1305206793 1305206094
1305205558 1305204852 1305204340 1305204272 1305203693 1305203329
1305203198 1305203052 1305202732 1305202039 1305201530 1305200740
1305200078 1305199377 1305198488 1305197930 1305197381 1305196808
1305196340 1305195924 1305195398 1305194897 1305194408 1305193863
1305193363 1305193136 1305192551 1305191957 1305191306 1305190740
1305190142 1305189760 1305189146 1305188580 1305188099 1305187796
1305187322 1305186833 1305186236 1305185651 1305185196 1305184834
1305184109 1305183518 1305182340 1305181344 1305180679 1305179753
1305178712 1305176913 1305176050 1305173566 1305170428 1305166878
1305164772 1305162760 1305160575 1305158426 1305154296 1305151914
1305151202
Creating unique data file: /usr/sbin/tcpdump -r /nsm/sensor_data/xxxx-
eth1/dailylogs/2011-05-12/snort.log.1305208591 -w /tmp/xxx.xxx.xxx.xxx:
60329_xxx.xxx.xxx.xxx:80-6.raw host xxx.xxx.xxx.xxx and host
xxx.xxx.xxx.xxx and port 80 and port 60329 and proto 6
Error running /usr/sbin/tcpdump -r /nsm/sensor_data/xxxx-eth1/
dailylogs/2011-05-12/snort.log.1305208591 -w /tmp/xxx.xxx.xxx.xxx:
60329_xxx.xxx.xxx.xxx:80-6.raw host xxx.xxx.xxx.xxx and host
xxx.xxx.xxx.xxx and port 80 and port 60329 and proto 6: reading from
file /nsm/sensor_data/xxxx-eth1/dailylogs/2011-05-12/snort.log.
1305208591, link-type EN10MB (Ethernet)
Receiving raw file from sensor.
Finished.
""""

In the sguil main window however, the packet data for the alert showed
up:

CC.8.C-:WP. %:4.
.8E.;&U.......A7
<..YK.U.....V.A+
JY.#,"U...M...AY
YB6TCCU..)Q...AY
YY..=!U..X&*0.A7
(IYY..>..?CF2$1'
....5S.O.LCR/NDC
CCH9@CCCCCCCCCCC
CCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCC
CCCCCC..........
................
................
................
......



I have found a thread on gmane mentioning something about verifying
that the timezone on sensor and server are both set to GMT.
http://blog.gmane.org/gmane.comp.security.sguil.general/month=20090401


So I ran
sudo dpkg-reconfigure tzdata
on sensor and server and made sure to set the same timezone (not GMT
as proposed in the thread on gmane though but our local timezone
instead) and rebooted.

I have generated some false alerts, transcript data shows up again.
That does not necessarily mean that the problem is solved, but it
seems ok so far.

Regards
Oli

On Apr 30, 4:50 am, Doug Burks <doug.bu...@gmail.com> wrote:
> I believe this is controlled by the SENSOR_UTC setting in
> /etc/nsm/SENSOR_NAME/sensor.conf.  Try changing it from Y to N and
> restarting the sensor.  Do this for all sensors to maintain
> consistency.  Please let us know whether or not that helps.
>
> Thanks,
> --
> Doug Burks, GSE, CISSP

> President, Greater Augusta ISSAhttp://augusta.issa.orghttp://securityonion.blogspot.com

>
> On Thu, Apr 28, 2011 at 2:43 AM, Der Pflanzer <der.pflan...@gmail.com> wrote:
> > Hi Doug
>
> > That was it.
>
> > *********************
>
> > root@xxxx:~# date && ls -l /nsm/sensor_data/xxxx-eth0/dailylogs/ | tail -1
> > Thu Apr 28 08:32:19 CEST 2011
> > drwxrwxr-x 2 sguil sguil 4096 2011-04-28 02:05 2011-04-28
>
> > root@xxxx:~# cat /etc/crontab | grep nsm
> > 05 2    * * *   root    nsm --sensor --restart
>
> > *********************
>
> > It really seems that somewhere in the nsm-scripts $DATE_OPTIONS is set to
> > "-u", which leads to the incorrect timezone.
> > Do you know where that happens so we can change it?
>
> > Regards
> > Oli
>

> > 2011/4/28 Doug Burks <doug.bu...@gmail.com>

>
> >> Hello again Oli,
>
> >> It sounds like you've pinpointed it.  Thanks for your persistence so
> >> far in tracking this down!
>
> >> Going back through the Issue Tracker, I found an older issue that was
> >> probably related, so I copied your description to it:
> >>http://code.google.com/p/security-onion/issues/detail?id=76
>
> >> Please let us know if your change works.
>
> >> Thanks,
> >> --
> >> Doug Burks, GSE, CISSP
> >> President, Greater Augusta ISSA
> >>http://augusta.issa.org
> >>http://securityonion.blogspot.com
>

> >> On Wed, Apr 27, 2011 at 9:21 AM, Der Pflanzer <der.pflan...@gmail.com>

> >> > 2011/4/22 Doug Burks <doug.bu...@gmail.com>

>
> >> >> Hey Oli,
>
> >> >> I closed your issue in the Issue Tracker since it was due to the
> >> >> non-standard SSH port.  The mailing list is more conducive to
> >> >> discussion, so it's probably better to ask about an issue on the
> >> >> mailing list first and then add it to the Issue Tracker once we've
> >> >> confirmed it.
>
> >> >> Unfortunately, I'm not sure why your dailylogs aren't being rotated
> >> >> properly.  I've verified that my servers and sensors are rotating
> >> >> dailylogs correctly.  At this point, I would recommend the following:
> >> >> -Download the ISO from:
> >> >>http://sourceforge.net/projects/security-onion/files/
> >> >> -Make sure that you verify the checksum!  We've had strange issues in
> >> >> the past that turned out to be due to a corrupt ISO download.
> >> >> -Install your server and sensor per the following:
>

> >> >>http://securityonion.blogspot.com/2011/04/security-onion-20110321-dis...

> >> >> -Keep the default SSH port and make sure that the sensor correctly
> >> >> logs into the server during Setup.
> >> >> -Make no other changes to the system and check the next day for proper
> >> >> rotation of dailylogs.
>
> >> >> Please let us know how it goes!
>
> >> >> Thanks,
> >> >> --
> >> >> Doug Burks, GSE, CISSP
> >> >> President, Greater Augusta ISSA
> >> >>http://augusta.issa.org
> >> >>http://securityonion.blogspot.com
>

> ...
>
> read more »

[Doug Burks]

Hello again Oli,

Thanks for your feedback. You basically have two options:

1. (RECOMMENDED) Set the server OS and all sensor OSs to GMT. As you
saw in the Sguil mailing list thread, this is recommended by Bamm
Visscher himself. This is assumed in Security Onion and that's why
the sensors are set that way.

2. If you really want to use local time instead of GMT, then the
server OS and all sensor OSs will need to be configured for the same
time zone. You will need to manually set SENSOR_UTC to "N" in all
sensor.conf files.

I hope to document this on the blog and hopefully an official manual
at some point in the future. Anybody interested in contributing to
the Security Onion project with some technical writing? :)

Thanks,
--
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

[sa_zh]

Hi Doug


I tried setting SENSOR_UTC to "N" and configuring the same timezone on
sensor and server (dpkg-reconfigure tzdata).
Not only did I restart the services, I rebooted the machines just in
case. It did not work though, the "No Data sent" problem popped up
again.

I have set SENSOR_UTC to "Y" again keeping our local timezone. That
worked well until now, except for the problem with log rotation.
I will re-implement our cronjob that triggers 2h after midnight, so I
can set the time through ntp. I'd rather have the same time on all
machines network-wide, if all it costs is a custom cronjob for log
rotation...

Thanks for your help and all the work you put into the project!
Oli

On May 13, 12:19 pm, Doug Burks <doug.bu...@gmail.com> wrote:
> Hello again Oli,
>
> Thanks for your feedback.  You basically have two options:
>
> 1.  (RECOMMENDED) Set the server OS and all sensor OSs to GMT.  As you
> saw in the Sguil mailing list thread, this is recommended by Bamm
> Visscher himself.  This is assumed in Security Onion and that's why
> the sensors are set that way.
>
> 2.  If you really want to use local time instead of GMT, then the
> server OS and all sensor OSs will need to be configured for the same
> time zone.  You will need to manually set SENSOR_UTC to "N" in all
> sensor.conf files.
>
> I hope to document this on the blog and hopefully an official manual
> at some point in the future.  Anybody interested in contributing to
> the Security Onion project with some technical writing?  :)
>
> Thanks,
> --
> Doug Burks, GSE, CISSP

> President, Greater Augusta ISSAhttp://augusta.issa.orghttp://securityonion.blogspot.com
>

> ...
>
> read more »