search

jasonish / docker-suricata

A Suricata Docker image.
https://hub.docker.com/r/jasonish/suricata/
MIT License
250 stars 76 forks source link

Date issue - Year 1900 #17

Closed jerkball closed 3 years ago

jerkball commented 3 years ago

Rapberry Pi4 - Raspberry OS

Starting fresh with empty volumes log timestamps look like this:

`Creating /etc/suricata/classification.config.

Creating /etc/suricata/reference.config.

Creating /etc/suricata/suricata.yaml.

Creating /etc/suricata/threshold.config.

Creating /etc/suricata/update.yaml.

Checking for capability sys_nice: yes

Checking for capability net_admin: yes

25/4/2071 -- 06:28:56 - - This is Suricata version 6.0.1 RELEASE running in SYSTEM mode

25/4/2071 -- 06:22:40 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules

25/4/2071 -- 06:24:32 - - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded!

25/4/2071 -- 06:27:12 - - all 4 packet processing threads, 4 management threads initialized, engine started.`

Starting a console in docker and typing date gives the following:

/ $ date Sun Jan 0 00:100:4174038 1900 / $

environment TZ=Europe/Berlin Volume /etc/localtime:/etc/localtime:ro

Where is my mistake?

Docker Version:

root@rpi-docker03:/opt/docker/suricata# docker --version Docker version 20.10.3, build 48d30b5

Thanks a lot...

jasonish commented 3 years ago

Date correct on the host? My Pi is offline at the moment so I can't test on a real Pi.. Under binary emulation its working tho, but thats not really a direct comparison to testing on a Pi.

jerkball commented 3 years ago

Thanks for your quick reply...

checked instantly:

root@rpi-docker03:/opt/docker/suricata# date Di 23. Feb 22:09:14 CET 2021

GMT+1

jerkball commented 3 years ago

Really appreciate your quick help...

Tried on my amd64 host....

Date is working there flawlessly:

`Creating /etc/suricata/classification.config.

Creating /etc/suricata/reference.config.

Creating /etc/suricata/suricata.yaml.

Creating /etc/suricata/threshold.config.

Creating /etc/suricata/update.yaml.

Checking for capability sys_nice: yes

Checking for capability net_admin: yes

23/2/2021 -- 22:17:00 - - This is Suricata version 6.0.1 RELEASE running in SYSTEM mode

23/2/2021 -- 22:17:00 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules

23/2/2021 -- 22:17:00 - - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded!

23/2/2021 -- 22:17:00 - - all 4 packet processing threads, 4 management threads initialized, engine started.`

Console:

sh-4.4$ date Tue Feb 23 22:18:55 CET 2021 sh-4.4$

jerkball commented 3 years ago

New Update:

Tried on an older Raspberry Pi 2 (Armv7)

Same behavior as aarch64

Creating /etc/suricata/classification.config. Creating /etc/suricata/reference.config. Creating /etc/suricata/suricata.yaml. Creating /etc/suricata/threshold.config. Creating /etc/suricata/update.yaml. Checking for capability sys_nice: yes Checking for capability net_admin: yes 22/4/2037 -- 16:06:48 - <Notice> - This is Suricata version 6.0.1 RELEASE running in SYSTEM mode 22/4/2037 -- 16:00:32 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules 22/4/2037 -- 16:02:24 - <Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded! 22/4/2037 -- 16:05:04 - <Notice> - all 4 packet processing threads, 4 management threads initialized, engine started.

Console:

/ $ date Sun Jan 0 00:100:4174038 1900

Was hoping to tear down the error to a specific plattform.. but no luck :(

//EDIT

Code brackets are awefull in githup... really :D

jasonish commented 3 years ago

Ok, so my pi got a fresh update.. I know this was working on it before, but I restored it with a fresh raspberry pi last night, and I do see this now.. Simply:

root@pi4:/home/pi# docker run --rm -it arm32v6/alpine:latest date
Sun Jan  0 00:100:4174038  1900

So its nothing specific to the Suricata image, but seems more of a general issue. Doesn't seem specific to Alpine Linux either, the Ubuntu image also has an issue:

root@pi4:/home/pi# docker run --rm -it ubuntu:latest date
Wed Feb 25 20:57:31 UTC 1970
jerkball commented 3 years ago

Hmm with alpine same effect...

But why do other docker images print correct timestamps in their logs?

Is there anything to be done during start to set the correct date?

It's no secret, that Raspi's don't have a rtc...

But we don't talk about a realtime application... its just setting the correct date on start...

jasonish commented 3 years ago

Do you have a Docker image that shows you the correct time on the Raspberry Pi? I couldn't find one.

I think its an with libseccomp, something like documented here: https://docs.linuxserver.io/faq

jerkball commented 3 years ago

phpmysql

root@rpi-docker01:~# docker run --rm -it phpmyadmin Unable to find image 'phpmyadmin:latest' locally latest: Pulling from library/phpmyadmin db574d82360c: Pull complete cc4e7c5500d5: Pull complete a30745314a6f: Pull complete 0061ef8da45b: Pull complete 226dc87e52cf: Pull complete 9b7594692659: Pull complete 0c7cd574b5f7: Pull complete d56893060319: Pull complete e630469897ca: Pull complete b43fe4400f99: Pull complete 9e463c3140f3: Pull complete 601892f37b21: Pull complete 989b27926bea: Pull complete 7384d470999a: Pull complete f4671cbd9484: Pull complete a7ffe016484c: Pull complete bbe5784fa6fb: Pull complete ab4b8a52b5f9: Pull complete Digest: sha256:ee03678fae19e0f8e5d932d039aafa9eb8a03b3fdc1ca8645888125e796096a0 Status: Downloaded newer image for phpmyadmin:latest AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message [Wed Feb 24 18:15:25.883064 2021] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.4.15 configured -- resuming normal operations [Wed Feb 24 18:15:25.883466 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

jasonish commented 3 years ago

Interesting. This appears to be based on a Debian image which does not have this issue. The Alpine, and Ubuntu 20.04 images have the issue, but Ubuntu 18.04 doesn't. Something is up with the newer distros.. I'm going to try and see if there are any changes coming down that will fix this for me, as I'd rather not change based images at this time.

jerkball commented 3 years ago

Thank you very much for your effort as you are not using raspberrys natively...

Rebasing the image to another distro would be to much I guess...

I googled everything that came to my mind for this "time setting" error... But anybody seems to recognize it...

I'm not into docker creating things, but if I can help, I would try to rebase your image to a debian one to see if it runs as it does on ubuntu 20....

But even forking is something I never did before ;-)

jasonish commented 3 years ago

So I guess this is a known issue. The fix is to get "libseccomp2" from the backports repo.. Basically: 1) Enable the bester-backports repo 2) sudo apt install -t buster-backports libseccomp2

I leave 1) up to the reader to figure out as I'm not familiar enough with Debian/Ubuntu to know if I did this correctly.

jerkball commented 3 years ago

As your docker is alpine based there is no use here...

/ # cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.13.1 PRETTY_NAME="Alpine Linux v3.13" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/"

switch back to ubuntu or even better.. migrate to debian ;-)

jerkball commented 3 years ago

This is the way to do it:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138 echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list sudo apt update sudo apt install -t buster-backports libseccomp2

jasonish commented 3 years ago

As your docker is alpine based there is no use here...

Not sure what you mean. This needs to be done on the host OS, so Raspberry Pi OS. Not in the guest.

I believe you have to do the same if running Ubuntu on your Pi.

jerkball commented 3 years ago

Oh... I see....

Big sorry... my mistake...

Trying that and will report back soon... thanks a lot...

jerkball commented 3 years ago

That's it... even without reboot... working like a charm... maybe a hint in the Readme.md for that?

Checking for capability sys_nice: yes Checking for capability net_admin: yes usermod: no changes 2/3/2021 -- 21:17:02 - <Notice> - This is Suricata version 6.0.1 RELEASE running in SYSTEM mode 2/3/2021 -- 21:17:02 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules 2/3/2021 -- 21:17:02 - <Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded! 2/3/2021 -- 21:17:02 - <Notice> - all 4 packet processing threads, 4 management threads initialized, engine started.