Alpine Lunix IDS – Snort no Suricata

So I was trying to get directions on how to install and configure Suricata on the Alpine flavor or Linux on the Raspberry Pi B+ model that is my DMZ services platform. I’d settled on Suricata as somewhat better than the older Snort. For some “odd reason” my searches were coming up empty. (Well, really, full of irrelevant and orthogonal crap…)

Eventually I just tried it.

dnspi:/home/chiefio# apk add suricata
ERROR: unsatisfiable constraints:
  suricata (missing):
    required by: world[suricata]

Oh Dear, no target for “suricata”. It isn’t built on Alpine. Digging further, I found a reference to a problem with one of the musl libraries causing a build fail.

http://forum.alpinelinux.org/forum/installation/problem-compiling-software-because-musl-toolchain-cpusett-issue

Sat, 2014-07-26 13:37

I am compiling suricata; I get error at reputation.c using util-affinity.c util-affinity.h, the cpu_set_t typedef is not set or correct #include or something;

cpu_brio_iniit
cpu_prime_init

#define cpu_set_t cpuset_t

#include

I beileve it is because of use of msul usage in Alpine. I need the correct compile time falgs, and libraires to configure and complie suricata.

Second, I compiled xombrero browser from github, It compiles alright but I get segmentation fault as it opens and closes.

Can somebody make suricata and xomberero for Alpine Linux x86-64

Thanks.

This is a relatively common kind of error. Programmers work in a context, a ‘programming environment’. Once the thing works, they feel they are done. Management asks “Does it work?” and when the answer is “Yes”, they move resources to another task. Lost in the shuffle is “Work in ALL environments?”.

I’m particularly sensitive on this one as, at one time, I ran Q.A. for a compiler tool chain that ran in 72 different platforms and crosses (compile on one machine, target another). That meant 72 different QA environments to assure things really worked everywhere. It also meant some of the code was “ugly” as it either had to avoid a ‘neat feature’ on one (or a few) of the environments that was missing in others, OR have paths around the variations (so longer and more complex).

In this case, either of three things is the most likely issue:

Suricata uses a ‘feature’ in glibc that isn’t in musl (and the Suricata programmers didn’t care or didn’t test on musl). That “feature’ can be real and intended or an unintended side effect. If ‘real’, Suricata needs a programming path around it for musl, if unintended, it’s using a ‘bug’ as a ‘feature’ and Suricata needs to not do that.

The musl library writers may have missed that real ‘feature’ in their coding. (It is considered horrid practice to code in ‘side effects’ or ‘bugs’ of the other code just to make things work the same…) This can be an omission, a coding error (bug) in musl, or failure to detect a ‘side effect’ in glibc that ought not to be used and often isn’t documented. If it is an omission or failure in musl, they need to fix it.

Finally, it can also be a ‘bug’ in glibc that just happens to let Suricata work with it despite something being ‘wrong’. While unlikely, given the long use of glibc, it is still a possible.

There will be finger pointing between glibc, Suricata, and musl developers until resolved… “Who owns the bug” only comes after agreeing “what is the bug?” It looks like it has been festering for about 2 years now…

Ah, the joys of the Free Software Culture… /sarc;

Now if I really Really REALLY cared, or had a salary from a company that really cared, I could join up, take that bug as mine, and work it to a solution. Figure out who owns it (musl library issue? Suricata issue? Or glibc doing a stupid thing?) and then either work THAT issue, or put a ‘patch’ or ‘work around’ either in musl or Suricata to make it run anyway since I didn’t want to wait for [whoever] to fix [whatever].

There are never enough hands and eyes to fix everything fast… especially in ‘specialty’ or ‘minor’ Linux flavors.

Now I’m more interested at the moment in just getting an IDS running, so I’m going to swap over to Snort (that IS on Alpine Linux musl) instead and “press on” for now. Later, I’ll give a shot at Suricata on a different OS (likely Debian since it has the most folks whacking it into shape; perhaps Ubuntu as “Debian with more features & fixes” and worst case Red Hat as ‘commercially manicured if obtuse and haughty’).

Why not take on the bug? Well, I’m already about 2 x over committed, and I’m not particularly skilled in either glibc or musl libraries (and those things are rather critical and subtle in obscure ways some times). I also don’t have a ‘test rig’ with enough hardware variations to be sure my ‘fix’ didn’t break some other configuration. I could likely write a ‘shim’ between Suricata and whatever library was the problem (to supply what was missing) but that’s just a short term hack to avoid the problem, not a real fix. ALL of those costing way more than a $25 Pi (that is currently not doing anything in my desk drawer) brought up on Debian…

So for now, at least, no Suricata on the Alpine base system. This opens a longer term question of “Abandon Alpine for the DMZ server?” but I’m not there [yet] as there is a lot to like about Alpine. As it matures this kind of thing will eventually get fixed [if enough people use and support it]. So I’m going to place myself in that band of folks “using and supporting” and not in the group of “debugging code with musl compatibility issues”. At least for now.

Snort

Snort is an older, but still quite capable, IDS. It basically sucks up any network traffic that goes by and inspects it / lets you look at it. I’m OK with swapping to Snort for now. I’m also OK with putting Suricata on a different Raspberry Pi card. I may do both. For now, though, it is ‘Snort on a Pi’:

dnspi:/home/chiefio# apk add snort
(1/9) Installing libdnet (1.12-r6)
(2/9) Installing libpcap (1.7.4-r0)
(3/9) Installing daq (2.0.6-r0)
(4/9) Installing keyutils-libs (1.5.9-r1)
(5/9) Installing libverto (0.2.5-r0)
(6/9) Installing krb5-libs (1.14.3-r0)
(7/9) Installing libtirpc (0.3.2-r1)
(8/9) Installing libuuid (2.28-r3)
(9/9) Installing snort (2.9.8.2-r2)
Executing snort-2.9.8.2-r2.pre-install
Executing busybox-1.24.2-r11.trigger
OK: 46 MiB in 78 packages

I’ll need to configure it, and after I do that, I’ll add the config here. Since I’d been running after Suricata for the last week, I wasn’t expecting to be doing a Snort config instead, so that part is going to be “light” until sometime later in the day (or night…)

The Alpine boards are helpful with lots of good advice. Unfortunately, as a young port, some of it is less than authoritative:

https://wiki.alpinelinux.org/wiki/Intrusion_Detection_using_Snorthttps://wiki.alpinelinux.org/wiki/Intrusion_Detection_using_Snort

This material is work-in-progress …

Do not follow instructions here until this notice is removed.
(Last edited by Fab on 10 Jan 2013.)

So 3 years of “WIP” and…?

(Bold by me)

This guide will set up (list subject to change):

Snort
Barnyard (maybe)
BASE

This guide will assume:

You have a knowledge of your network setup (at least know which subnets exist).
You have Alpine 2.0.2 installed and working with networking setup.
You have had at least three cups of coffee this morning. And not decaf.

Well I’ve only had 2 cups of caf coffee, but I also had a large Earl Grey Tea that I find focuses the mind better than coffee… so I think I’m up to the task…

But that page is mostly about unpacking a tarball and doing a make install and such long hand. I’ve just installed via apk, so I think I don’t need to do those steps. “We’ll see”…

https://wiki.alpinelinux.org/wiki/Intrusion_Detection_using_Snort,_Sguil,_Barnyard_and_more

Points to the prior one as a merger candidate, then goes on…

This material is work-in-progress …

Do not follow instructions here until this notice is removed.
(Last edited by Dubiousjim on 1 Jun 2012.)

4 years ago? Really? Maybe my “highest and best use” will be signing up to update the ‘docs’ after I get it running…

With that, I think I’m going to wander over to other systems docs on Snort and see if they are more enlightening, then take on the config tasks without a custom ‘how to’ guide (i.e. seat of pants…)

http://www.aboutdebian.com/snort.htm

Looks like it might be helpful.

As completion, here’s the Snort home page:

https://www.snort.org/

Oh, and remember to do an ‘lbu commit’ after installing or changing the configs in Alpine…

Subscribe to feed