Bug#895342: suricata: new version fails to start if eth0 not present

[Steve Langasek]

Package: suricata
Version: 1:4.0.4-1
Severity: serious
User: ubuntu...@lists.ubuntu.com
Usertags: origin-ubuntu bionic autopkgtest

Dear maintainers,

The latest version of suricata is failing its autopkgtests in Ubuntu because
the suricata daemon does not start in the test environment. This appears to
be due to the fact that the default suricata config assumes eth0 as an
interface name, but the testbed has ens2 as its default interface:

# /usr/bin/suricata --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid
10/4/2018 -- 05:31:56 - <Notice> - This is Suricata version 4.0.4 RELEASE
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/botcc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/ciarmy.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/compromised.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/drop.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/dshield.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-attack_response.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-chat.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-current_events.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dns.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dos.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-exploit.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-ftp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-imap.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-malware.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-misc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-mobile_malware.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-netbios.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-p2p.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-policy.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-pop3.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-rpc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-scan.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-smtp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-snmp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-sql.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-telnet.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-tftp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-trojan.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-user_agents.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-voip.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-web_client.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-web_server.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-worm.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/tor.rules
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Unable to find type for iface "eth0": No such device
10/4/2018 -- 05:31:56 - <Notice> - all 1 packet processing threads, 4 management threads initialized, engine started.
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Unable to find iface eth0: No such device
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't init AF_PACKET socket, fatal error
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - thread W#01-eth0 failed
#

Previous versions of suricata also had a default interface name of eth0
configured, but this was not a fatal error; the suricata daemon still
started and the tests could be run.

I'm filing this as serious because it seems to me that neither of these
behaviors - either starting up and being ineffective because it's running on
the wrong interface, or failing to start up because the interface is
hard-coded and not present - is a reasonable default behavior for an IDS. I
think the interface should either be autodetected or prompted for at install
time.

Feel free to downgrade if you disagree.

In any case, while the autopkgtests do not pass, the new version of suricata
will not be included in the Ubuntu release, as regressing autopkgtests are
considered release blockers there.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org

[Arturo Borrero Gonzalez]

Control: severity -1 normal

On Wed, 18 Apr 2018 10:30:56 -0700 Steve Langasek
<steve.l...@canonical.com> wrote:
>
> There is at least one bug here in the package, which is that the
> autopkgtests make a brittle assumption that eth0 will be available in the
> test bed. eth0 is a legacy interface name in the kernel, and despite the
> fact that eth0 is currently present on the ci.debian.net testbeds, this is
> not a robust assumption. If you want to reorder the tests so that the
> config file setup is done first, then that would address the bug in the
> autopkgtests.
>

Hi,

thanks for taking the time to elaborate.

I talked to upstream to know if they plan to implement something for
interface names at runtime. No plans.
And I don't have time to work on that myself.

Downgrading the severity to avoid the package removal from testing.

On a side note: you mentioned the daemon should be up and running to
consider the package being OK installed.
While I agree that by installing the package we should get a daemon
ready to use, How would you do that?
given suricata acts as a firewall, the config is strictly baked per
environment and no preset could be used as default?

[Sascha Steinbiss]

Hi Steve and Arturo,

just a few comments from my side…

I might agree that the tests make some fragile assumptions, and I think that this
problem can be solved quickly by wrapping the suricatasc calls, making sure
that there is a Suricata instance running (in IDS mode) on an existing interface.

The other issue raised by Steve is a bit more complex. Suricata is an IDS/IPS
system, which rarely is used 'out of the box' but usually requires setup by a
knowledgeable person. I think, however, that we can arrive at some sensible
default configuration that leaves the least moment of surprise to a user who
just installed the software.

AFAICS we have several options here:

a) Explicitly disable the service by default and display a note (via debconf)
that informs the user that configuration is required before the system
is usable. This is probably the easiest way -- but in essence avoiding the
problem altogether ;)

b) Use debconf to let the user choose a set of interfaces detected at install
time (or pre-define at pressed, obviously), and pre-generate a config file
that uses a lowest common denominator of basic but likely configuration
choices (e.g. AF_PACKET, IDS mode, default bundled ruleset, ...) for
monitoring the chosen interfaces, staying as close
to upstream’s default config file as possible. If a user wants
something more involved, then they can customize the setup by themselves.
I have just played around with debconf a bit and it looks like this is quite
straightforward to do. I'm just not sure yet how to handle non-interactive
cases (such as the autopkgtests), but my first suggestion would be to go
with the interface that provides the default route.

What do you think?

Cheers
Sascha