ExtraHD / samba / IPS in core 199 / no access anymore

Security Intrusion Prevention
1

Since upgrade to core 199 my ExtraHD samba shares are not any more accessible from my laptop nor from my mobile phone nor my tablet.

When I switch off IPS, access is possible again.

With switched on IPS, the log message in the IPS log viewer is

ET INFO NTLM Session Setup Request - Negotiate for the access from the samba client to port 445 of the IPFire server.

An internal smbclient invoked on the IPFire server is running properly:

smbclient -L localhost -N

    Sharename       Type      Comment
    ---------       ----      -------
    MyShare         Disk      Shared Folder
    IPC$            IPC       IPC Service (Samba on IPFire)

When I am trying to access the samba form my laptop, the following error message can bee seen

tail -f /var/log/samba/log.smbd
smbd version 4.23.2 started.
Copyright Andrew Tridgell and the Samba Team 1992-2025
[2026/01/28 08:54:55.290220, 0] ../../source3/smbd/smb2_process.c:115(read_packet_remainder)
read_fd_with_timeout failed for client 192.168.2.16 read error = NT_STATUS_END_OF_FILE.

On my laptop, I am getting

smbclient -L ``//192.168.1.1`` -N -t 30
smb2cli_req_compound_submit: Insufficient credits. 0 available, 1 needed
session setup failed: NT_STATUS_INTERNAL_ERROR

How can I get access to my samba share again without disabling the rule ‘ET INFO NTLM Session Setup Request - Negotiate’ of the IPS?

2

Firewall → Intrusion Prevention
Click button Customize Ruleset
Search emerging-info.rules → click show link
Search ET INFO NTLM Session Setup Request
uncheck the rule.
Click button Apply

1 Like
3

Thanks, Phil. However, I intentionally don’t want to go for the trivial solution of disabling the rule. Is there a smarter way with keeping or modifying the rule for ‘ET INFO NTLM Session Setup Request’?

4

Try adding the host and clients’ Samba addresses to Whitelisted Hosts at the bottom of the Intrusion Prevention page

1 Like
5

Would this not drill an even bigger security hole into my system?

I am aware that NTLM is outdated, however, how can an IPFire ExtraHD Share be accessed from the internal network (blue, green) without Kerberos and NTLM?

6

The security vulnerability lies in the use of Samba within IPFire.
It would be safer to use a NAS or another Samba server on your local network.
Behind a VPN or WireGuard

3 Likes
7

IPFire is offering the ExtraHD feature in conjunction with a samba share since many years. This feature is very helpful to exchange data between my computers and my Apple devices. I am using am USB Stick as ExtraHD.

Running an external NAS is too power hungry for my private purpose. In Germany 1 Watt 24/7 equals to 3 Euro per anno.

If the ExtraHD feature in conjunction with a samba share would be a security vulnerability, I am questioning why it is a feature of IPFire.

Since I am using guest account only and therefore there is nothing to authorize anyway, is there a setting to avoid usage of NTLM?

8

Because at some point, someone thought it would be a good idea to integrate SMB directly into IPFire as an add-on

I would never do so, in my eyes, stupid Things ^^

A FW is a FW and is not designed for Sharing Data

3 Likes
9

I digged a bit deeper into my problem and found that the root cause was an update of some NTLM related emerging-info.rules located at /var/lib/suricata/emerging-info.rules on 26th January 2026:

grep -i ntlm /var/lib/suricata/emerging-info.rules
drop smb $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Outbound SMB NTLM Auth Attempt to External Address"; flow:established,to_server; content:"|ff|SMB|73|"; content:"NTLMSSP|00 03 00 00 00|"; within:200; fast_pattern; cla
sstype:misc-activity; sid:2044665; rev:3; metadata:attack_target Client_and_Server, created_at 2023_03_16, deployment Perimeter, performance_impact Significant, confidence High, signature_severity Minor, updated_at 2023_09_16,
reviewed_at 2023_09_16;)
drop smb $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Outbound SMB2 NTLM Auth Attempt to External Address"; flow:established,to_server; content:"|fe|SMB"; content:"NTLMSSP|00 03 00 00 00|"; within:200; fast_pattern; classt
ype:misc-activity; sid:2051116; rev:1; metadata:attack_target Client_and_Server, created_at 2024_02_27, deployment Perimeter, performance_impact Significant, confidence High, signature_severity Minor, updated_at 2024_02_27; tar
get:src_ip;)
drop smb $HOME_NET any -> $HOME_NET any (msg:"ET INFO Outbound SMB2 NTLM Auth Attempt to Internal Address"; flow:established,to_server; content:"|fe|SMB"; content:"NTLMSSP|00 03 00 00 00|"; within:200; fast_pattern; classtype:
misc-activity; sid:2059126; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, affected_product Windows_11, affected_product Windows_8, affected_product Windows_10, attack_target Client_Endpoint, tls_sta
te plaintext, created_at 2025_01_10, deployment Internal, performance_impact Significant, confidence High, signature_severity Informational, updated_at 2025_01_10; target:src_ip;)
drop tcp-pkt $HOME_NET any -> any 445 (msg:"ET INFO NTLM Session Setup Request - Negotiate"; flow:established,to_server; content:"NTLMSSP|00 01 00 00 00|"; fast_pattern; threshold:type limit,count 1,seconds 300,track by_src; c
lasstype:misc-activity; sid:2067085; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, tls_state plaintext, created_at 2026_01_26, deployment Perimeter, deployment Interna
l, performance_impact Significant, confidence Medium, signature_severity Informational, updated_at 2026_01_26; target:src_ip;)
drop tcp-pkt any 445 -> $HOME_NET any (msg:"ET INFO NTLMv1 Session Setup Response - Challenge"; flow:established,to_client; content:"|2b 06 01 04 01 82 37 02 02 0a|"; content:"NTLMSSP|00 02 00 00 00|"; fast_pattern; threshold:
type limit,count 1,seconds 300,track by_dst; classtype:misc-activity; sid:2067086; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, tls_state plaintext, created_at 2026_0
1_26, deployment Perimeter, deployment Internal, performance_impact Significant, confidence Medium, signature_severity Informational, updated_at 2026_01_26; target:dest_ip;)
drop tcp-pkt $HOME_NET any -> any 445 (msg:"ET INFO NTLM Session Setup Request - Auth"; flow:established,to_server; content:"NTLMSSP|00 03 00 00 00|"; fast_pattern; threshold:type limit,count 1,seconds 300,track by_src; classt
ype:misc-activity; sid:2067087; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, tls_state plaintext, created_at 2026_01_26, deployment Perimeter, deployment Internal, pe
rformance_impact Significant, confidence Medium, signature_severity Informational, updated_at 2026_01_26; target:src_ip;)

Root cause is NOT the upgrade to IPFire core 199.

Above suricata rules are INFO type rules, but are actually, in case of a hit, dropping the concerning packet and connection.

They get even more strict, since IPFire’s suricata environment is using

suricata --dump-config

…

vars.address-groups.EXTERNAL_NET = any

…

Therefore in above NTLM related rules, $EXTERNAL_NET is triggered also for an access of the IPFire server’s ExtraHD samba share, e.g. at 192.168.1.1.

As a mitigation (I am aware that this is not a perfect solution), I rewrote above rules as custom rules allowing purely internal NTLM accesses and put them into ‘/var/lib/suricata/local.rules’.
According to a ‘grep -i load /var/log/messages’, these custom rules were successfully loaded. In consequence, above rules were disabled. At least, my samba services are working again, both to ExtraHD and my NAS server.

The local.rules is not shown in the WEB UI of IDS. This seems to be a limitation of ‘/var/ipfire/ids-functions.pl’. in case of an automatic rule upgrade, the file /var/lib/suricata/local.rules is kept, but the SIDs of the custom rules are not extracted and inserted into ‘/var/lib/suricata/sid-msg.map’.