[PATCH] suricata 6.0.8 - suggested change in 'suricata.yaml': set app-layer mqtt: enabled: yes
Signed-off-by: Matthias Fischer matthias.fischer@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
Good morning,
Why would we need this change?
-Michael
On 29 Sep 2022, at 21:35, Matthias Fischer matthias.fischer@ipfire.org wrote:
Signed-off-by: Matthias Fischer matthias.fischer@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-- 2.34.1
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"
Best, Matthias
-Michael
On 29 Sep 2022, at 21:35, Matthias Fischer matthias.fischer@ipfire.org wrote:
Signed-off-by: Matthias Fischer matthias.fischer@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-- 2.34.1
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@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@ipfire.org wrote:
Signed-off-by: Matthias Fischer matthias.fischer@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-- 2.34.1
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@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@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@ipfire.org wrote:
Signed-off-by: Matthias Fischer matthias.fischer@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
-
Matthias Fischer -
Michael Tremer -
Peter Müller