Hello,
Is there any documented method of getting Suricata to work on ARM64 architectures?
Nothing specific, but it shouldn’t be much different than our current documentation on building from source. If you run into issues you could ask here.
I currently build in Docker for Alpine Linux/arm32 which I use on a Raspberry Pi. I’ll kick off a build here for Alpine Linux/arm64v8 and see how it goes, but I suspect it will OK.
Hey @ish,
Thank you for getting back to me. Is it possible to cross compile Suricata for ARM on an x86 machine?
I’m going to say likely, but we do have some issues with cross compilers and our ./configure, so your experience may vary. You’d probably want to test your cross compile setup with something more trivial first.
To avoid this I use Linux’s support to execute arm binaries then just use an Arm32/64 distribution inside a Docker container. I do this to build Suricata for the arm32, and it appears to work for Arm 64… I’ve just pushed up an Arm64 Docker image if you are curious to try it:
docker pull jasonish/suricata:5.0.3-arm64v8
Sorry, I’m not able to help much with the more classic cross compiling approaches.
FYI - If it is useful - you can try the Suricata 5.0.3 stable arm64 pkg from our PPA repo too.
Feedback is welcome.
https://launchpad.net/~oisf/+archive/ubuntu/suricata-stable
Hi Jason,
I pulled your image and I am testing it on this device https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=282
This is awesome!!!
1 Like
Hi Jason,
Could it be that the logrotate program is not in the image? Am I missing something?
Thanks
Tamas
Logrotate is missing from the ARM images. Rebuilding now.
Thanks.
1 Like
HI Jason,
It is working. Thank you so much. The device has just 1GB RAM which seems to be too small for the “standard” update (OOM-ed during testing and reload). I did find the ‘sudo kill -USR2 $(cat /var/run/suricata.pid)’ for the ‘–reload-command=’ but would you be able to suggest a simple command for testing which is not that resource-intensive? I think this is a fantastic option to run a full-scale IDS/IPS/NSM system on such cheap hardware. Thumbs up.
I’m not too sure if there is much can be done. In your typically suricata-update scenario, suricata-update is going pass the rules to suricata -T which will consume memory to do a full rule load, similar to Suricata initializing.
Then when you ask Suricata to reload its rules while running, it loads a complete context with the new rules before making them live, so you have 2 full sets of rules in memory until the internal swap occurs. This is likely where you are to run out of memory.
The only things I can think of off the top of my head are to:
- use
--no-testoption forsuricata-update - restart suricata instead of reloading the rules (SIGUSR2)
Or run a limited ruleset where everything can be done within the confines of your memory limitations.
1 Like
Hi Jason,
This sounds about right. The container runs around 400M without the update and the OpenWRT had around 750M total available before I started the container.
- I started suricata-update with --no-test and --no-reload
- I set a 700M hard memory limit on the container. SIGSUR2 went up to 700M and it stayed there (It seemed to me that the previous ruleset was not unloaded but I could be wrong. I tried to wait but it did not finish.)
- I restarted the container after suricata-update --no-test and --no-reload (I assume with the already updated ruleset). The container is back to 400M which is manageable.
- I removed the memory limit and tested point 3 again. It is working. This is a bit more work but it is running with an updated full set.
This is very good. Thank you so much.
Tamas
Hi Jason,
The timestamps were not accurate. When I tried to check the timezone I could not find /etc/localtime and /etc/timezone. I installed tzdata and openntpd and set the correct timezone which solved the problem. This post “https://www.ivankrizsan.se/2015/10/31/time-in-docker-containers/” suggests timezone setting is not part of the base image but it can be added. I think it is needed for an accurate time-stamping. Thank you for your time.
Tamas
Were the timestamps actually inaccurate? Or just the wrong timezone?
Hi Jason,
I think it’s just the timezone. I started a new container from the original image(6.0.0-rc1-arm64v8) to test this. Apologies I am new to docker so if I understood it correctly the container uses the same clock as the host which means I just have to make sure that the time on the OpenWRT is synchronized all the time. If the timezone is correct it should be pretty easy to read the logs. Thank you for your help.
Tamas
Correct. Docker container should see the same real time as the host, just the timezone might be off. I think this could be fixed with a volume mount like -v /etc/localtime:/etc/localtime:ro.
