0

We have an TrueNAS System running TrueNAS-13.0-U5.3. It is bound to Active Directory and used solely for SMB file sharing. Recently there have been periodic event where SMB service quality is degraded - performance decreases and the service stops accepting new connections. Once the SMB service is stopped and restarted, the issue is temporarily resolved.

During these events the /var/log/messages contains messages as indicated below:

Sep 15 11:03:28 FS.example.lan kernel: pid 41336 (smbd), jid 0, uid 0: exited on signal 6 Sep 15 11:03:28 FS.example.lan kernel: pid 42956 (smbd), jid 0, uid 0: exited on signal 6 Sep 15 11:03:28 FS.example.lan kernel: pid 90877 (smbd), jid 0, uid 0: exited on signal 6 

Upon inspection of the var/log/samba4/log.smbd there appears to be a flood of authentication attempts by the guest user. For example, in a two hour period today there are approximately 10,000 of these attempts across the 5 shares on this server. Guest access is not permitted on any share.

[2023/09/15 11:22:38.582960, 1] ../../source3/smbd/service.c:399(create_connection_session_info) create_connection_session_info: guest user (from session setup) not permitted to access this share (exampleshare) [2023/09/15 11:22:38.583037, 1] ../../source3/smbd/service.c:588(make_connection_snum) create_connection_session_info failed: NT_STATUS_ACCESS_DENIED [2023/09/15 11:22:38.589570, 1] ../../source3/smbd/service.c:399(create_connection_session_info) create_connection_session_info: guest user (from session setup) not permitted to access this share (exampleshare) 

There are approximately 300 client computers on the network, mixed macOS, Windows, Linux.

My questions are:

  1. What if any method is there to determine the source IP or hostname of the device from which the guest authentication request is originating?
  2. Is there any normal activity that could account for these observations?

1 Answer 1

1

I have not used the TrueNAS OS personally, but it-appears to have no issue with being able to SSH in, and it supports tcpdump. SO you should be able to trap SMB traffic in a packet capture and see this information with zero issues.

tcpdump -W 10 -C 50 -w smb.pcap -s 0 port 445 

The above will capture the SMB traffic packets specifically in a rng buffer the values for -W and -C are (-W how many files to keep) and (-C what size in MB to keep) the files will be sequentially numbered, and operate FIFO, adjust as needed to catch the traffic you need. That sample will get 10x50Mb so 500Mb of capture. you could easily make it 1000 x 100 and get 100Gb, depends on your normal SMB load and how long it takes to get the sample live.

Opening the subsequent files in wireshark will allow you to see the conversation to the SMB server, what is trying to authenticate, and the IP/MAC it is coming from (MAC helps you sometimes ID the device as well) and if you let it do DNS lookups may even tell you system name. But warning that can be hella resource intensive and slow if you do enable it.

5
  • Do you have any suggests for narrowing the scope of the capture so it captures only the authentication portion of the conversation? The transaction volume is too high and the files are filling and splitting so quickly that I am having a hard time even locating a file that contains an authentication with filtering on the capture. I need to capture less. Commented Sep 21, 2023 at 0:47
  • You can try to filter as such 'tcp port 445 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x72)' that should get the SMB header from each packet, then check the message field type to see if it is a session setup., those packets contain the username attempted. I do not have a system handy to test though. IF that does not work, and you can get tshark on the system, tshark will let you filter based on a string and we could likely target it that way. Commented Sep 21, 2023 at 15:07
  • Hmm just tried that and it looks like it's only giving me NetBIOS Session Service packets now. Commented Sep 21, 2023 at 15:20
  • Let me build a test system later, and will get back to you, netbios should not be on 445, it should be 139 :/ Commented Sep 21, 2023 at 17:33
  • 1
    Yeah, I cannot seem to strip out the specific NTLMSSP_AUTH details in tcpdump, wire shark it is fine because of the dissectors. Aside from catching all the SMB traffic in a ring buffer and parsing with wireshark, snort would be about the only other direction I could point you in, because its dissectors could likely handle it as well. I just tested it catching it all and then reading the PCAP in wireshark, I can see the data. Commented Sep 21, 2023 at 18:43

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.