[PATCH] suricata 6.0.8 - suggested change in 'suricata.yaml': set app-layer mqtt: enabled: yes

[PATCH] suricata 6.0.8 - suggested change in 'suricata.yaml': set app-layer mqtt: enabled: yes

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org>
---
 config/suricata/suricata.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/suricata/suricata.yaml b/config/suricata/suricata.yaml
index 03a7a83af..fb4f9426b 100644
--- a/config/suricata/suricata.yaml
+++ b/config/suricata/suricata.yaml
@@ -371,7 +371,7 @@ app-layer:
         dp: 5900, 5901, 5902, 5903, 5904, 5905, 5906, 5907, 5908, 5909
     # MQTT, disabled by default.
     mqtt:
-      # enabled: no
+      enabled: yes
       # max-msg-length: 1mb
     krb5:
       enabled: yes
-- 
2.34.1

Re: [PATCH] suricata 6.0.8 - suggested change in 'suricata.yaml': set app-layer mqtt: enabled: yes

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]

Hello *,


> On 30.09.2022 06:57, Michael Tremer wrote:
>> Good morning,
> 
> Hi,
> 
>> Why would we need this change?
> 
> I'm not sure if we *really* need this change. My first thought was to
> enable it to avoid this "ERRCODE"-message during startup:
> 
> ...
> [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol mqtt enable
> status not set, so enabling by default. This behavior will change in
> Suricata 7, so please update your config. See ticket #4744 for more details.
> ...
> 
> v6.0.8 comes with a new rules file for app-layer-events: 'mqtt.rules' to
> detect and avoid mqtt flooding attacks. Current standard action is 'alert'.
> 
> =>
> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/AppLayer :
> 
> What is 'mqtt'?
> 
> => https://www.opc-router.com/what-is-mqtt/ :
> 
> "MQTT – Message Queuing Telemetry Transport
> 
> MQTT (Message Queuing Telemetry Transport) is a messaging protocol for
> restricted low-bandwidth networks and extremely high-latency IoT
> devices. Since Message Queuing Telemetry Transport is specialized for
> low-bandwidth, high-latency environments, it is an ideal protocol for
> machine-to-machine (M2M) communication.
> 
> MQTT works on the publisher / subscriber principle and is operated via a
> central broker. This means that the sender and receiver have no direct
> connection. The data sources report their data via a publish and all
> recipients with interest in certain messages (“marked by the topic”) get
> the data delivered because they have registered as subscribers. In IoT
> and IIoT, MQTT is used all the way to connecting cloud environments..."
> 
> I wanted to test v6.0.8 in its (new) standard config, so I activated
> this protocol.
> 
> Until now, I found no information what "this behavioir will change in
> Suricata 7" really means.
> 
> The only information I just found:
> =>
> https://suricata.readthedocs.io/en/latest/upgrade.html#upgrading-6-0-to-7-0
> 
> "Upgrading 5.0 to 6.0
> ...
> Major changes:
> ...
> New protocols enabled by default: mqtt, rfb
> ..."
> 
> 'rfb' is already enabled in our config. If we don't want 'mqtt' we
> should set 'mqtt' to "enabled: no"

just my two cents: I think it cannot hurt to enable this; if it gets us some
more coverage on malicious IoT activity (a pleonasm, I know), there is a benefit
from it.

Acked-by: Peter Müller <peter.mueller(a)ipfire.org>

@Michael: What is your opinion on that?

Thanks, and best regards,
Peter Müller

> 
> Best,
> Matthias
> 
>> -Michael
>>
>>> On 29 Sep 2022, at 21:35, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>
>>> Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org>
>>> ---
>>> config/suricata/suricata.yaml | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/config/suricata/suricata.yaml b/config/suricata/suricata.yaml
>>> index 03a7a83af..fb4f9426b 100644
>>> --- a/config/suricata/suricata.yaml
>>> +++ b/config/suricata/suricata.yaml
>>> @@ -371,7 +371,7 @@ app-layer:
>>>         dp: 5900, 5901, 5902, 5903, 5904, 5905, 5906, 5907, 5908, 5909
>>>     # MQTT, disabled by default.
>>>     mqtt:
>>> -      # enabled: no
>>> +      enabled: yes
>>>       # max-msg-length: 1mb
>>>     krb5:
>>>       enabled: yes
>>> -- 
>>> 2.34.1
>>>
>>
> 

Re: [PATCH] suricata 6.0.8 - suggested change in 'suricata.yaml': set app-layer mqtt: enabled: yes

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

Hello,

MQTT seems to be getting more and more popular and I have seen this in a couple of networks.

So I do not see any reason not to enable this.

-Michael

> On 2 Oct 2022, at 12:07, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> 
>> On 30.09.2022 06:57, Michael Tremer wrote:
>>> Good morning,
>> 
>> Hi,
>> 
>>> Why would we need this change?
>> 
>> I'm not sure if we *really* need this change. My first thought was to
>> enable it to avoid this "ERRCODE"-message during startup:
>> 
>> ...
>> [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - App-Layer protocol mqtt enable
>> status not set, so enabling by default. This behavior will change in
>> Suricata 7, so please update your config. See ticket #4744 for more details.
>> ...
>> 
>> v6.0.8 comes with a new rules file for app-layer-events: 'mqtt.rules' to
>> detect and avoid mqtt flooding attacks. Current standard action is 'alert'.
>> 
>> =>
>> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/AppLayer :
>> 
>> What is 'mqtt'?
>> 
>> => https://www.opc-router.com/what-is-mqtt/ :
>> 
>> "MQTT – Message Queuing Telemetry Transport
>> 
>> MQTT (Message Queuing Telemetry Transport) is a messaging protocol for
>> restricted low-bandwidth networks and extremely high-latency IoT
>> devices. Since Message Queuing Telemetry Transport is specialized for
>> low-bandwidth, high-latency environments, it is an ideal protocol for
>> machine-to-machine (M2M) communication.
>> 
>> MQTT works on the publisher / subscriber principle and is operated via a
>> central broker. This means that the sender and receiver have no direct
>> connection. The data sources report their data via a publish and all
>> recipients with interest in certain messages (“marked by the topic”) get
>> the data delivered because they have registered as subscribers. In IoT
>> and IIoT, MQTT is used all the way to connecting cloud environments..."
>> 
>> I wanted to test v6.0.8 in its (new) standard config, so I activated
>> this protocol.
>> 
>> Until now, I found no information what "this behavioir will change in
>> Suricata 7" really means.
>> 
>> The only information I just found:
>> =>
>> https://suricata.readthedocs.io/en/latest/upgrade.html#upgrading-6-0-to-7-0
>> 
>> "Upgrading 5.0 to 6.0
>> ...
>> Major changes:
>> ...
>> New protocols enabled by default: mqtt, rfb
>> ..."
>> 
>> 'rfb' is already enabled in our config. If we don't want 'mqtt' we
>> should set 'mqtt' to "enabled: no"
> 
> just my two cents: I think it cannot hurt to enable this; if it gets us some
> more coverage on malicious IoT activity (a pleonasm, I know), there is a benefit
> from it.
> 
> Acked-by: Peter Müller <peter.mueller(a)ipfire.org>
> 
> @Michael: What is your opinion on that?
> 
> Thanks, and best regards,
> Peter Müller
> 
>> 
>> Best,
>> Matthias
>> 
>>> -Michael
>>> 
>>>> On 29 Sep 2022, at 21:35, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>> 
>>>> Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org>
>>>> ---
>>>> config/suricata/suricata.yaml | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> 
>>>> diff --git a/config/suricata/suricata.yaml b/config/suricata/suricata.yaml
>>>> index 03a7a83af..fb4f9426b 100644
>>>> --- a/config/suricata/suricata.yaml
>>>> +++ b/config/suricata/suricata.yaml
>>>> @@ -371,7 +371,7 @@ app-layer:
>>>> dp: 5900, 5901, 5902, 5903, 5904, 5905, 5906, 5907, 5908, 5909
>>>> # MQTT, disabled by default.
>>>> mqtt:
>>>> - # enabled: no
>>>> + enabled: yes
>>>> # max-msg-length: 1mb
>>>> krb5:
>>>> enabled: yes
>>>> -- 
>>>> 2.34.1