Sc_err_invalid_signature 39

Getting Started with IPFire
1

I came in to work this morning to find that multiple people had DNS issues resolving names that normally have no problems, and nobody could get into our ERP system. I rebooted the clients, and I rebooted the ERP database server, and I shut down a clone of the ERP Database server that I started to set up, which fixed the issue.

Now I’m going back to diagnosing what happened. I am seeing errors in /var/log/messages like this. If I read this correctly this is just an attempted break in by a trojan, not a compromised host on the LAN that is transmitting, can anyone confirm this for me?

Dec 21 08:30:22 ipfire suricata: [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"INDICATOR-COMPROMISE msiexec.exe command execution over DNS attempt"; flow:to_client,no_stream; byte_test:1,&,0x80,2,bitmask 0x87; content:"|00 10 00 01|"; content:"msiexec /i"; within:20; distance:7; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, service dns; reference:url,www.virustotal.com/gui/file/32b8afb4deb90660514214df426f38a92ba24fbc92a834a8b8bfa55371aeda48; classtype:trojan-activity; sid:53985; rev:1;)" from file /var/lib/suricata/indicator-compromise.rules at line 35
2

Hi,

which FQDNs are you referring to here?

No, this just a note from Suricata complaining about an unparseable IPS signature. That rule has not triggered in your network.

Given that sketchy information, I am unfortunately unable to tell what went wrong in your case.

Thanks, and best regards,
Peter Müller

3

These names were not fully qualified domain names (public), just internal only. The name in question was dylanschoeneck.inside.. Normally the names resolve without any problems. I could ping the IP address of the machine without issue, but I could not ping by name using just the dylanschoeneck or the full domain name.

I had further problems later in the day with IP addresses. Note I am on IPFire 2.25(x86_64 Core update 152. I had one machine named BRIANHAYES10. This is a pretty standard Dell XPS Windows 10 Pro machine, with a DHCP Reservation of 10.5.1.108.

image
image946×35 1.24 KB

He was having problems with network drives that were online, then 10 seconds later offline, then online, then offline. At first I thought his machine had a virus, but full scans with two different tools revealed nothing.

I then looked in IPFire and there was a second mac address that was listed with the same IP address 10.5.1.108 even WITH the reservation entry saved and in use in the DHCP area!?!

The other machine was a vmware virtual machine that I had just set up to test out CentOS Stream. The CentOS box was just set to DHCP, and I had not configured any reservations for that mac address yet.

I then looked back at the DHCP area and noticed there was not just one, but 14 different entries for Brian’s machine:

image
image649×765 15.6 KB

Has anyone experienced this before where a reserved IP address was given out via DHCP to a different mac address, even though the IP was reserved?

Has anyone experienced this before, I need some help!

Chris

4

Another disturbing discovery. If you mistakenly put in a reservation DHCP entry for a given Mac address, the system allows you to do it, there is no warning or error saying the address is already in use like there was in previous versions.

The package or structure is definitely flawed with DHCP in 152

5

I just entered a duplicate ip address in my Core 152 system and it shows the ip address in bold as it has previously. I tried the same thing with a duplicate mac address and that also showed up in bold.

So it doesn’t look to be a universal thing with Core 152 that no warning is given of duplicate addresses.