Suricata IPS for running server

Posted on by Andy

Make sure that suricata is started with “-q 0” parameter so it uses NFQUEUE!

In /etc/suricata/suricata.yaml change to:

nfq:
    mode: repeat
    repeat-mark: 1
    repeat-mask: 1

In /etc/ufw/before.rules and /etc/ufw/before6.rules insert section:

### SURICATA ###
-I INPUT 1 -p tcp --dport 22 -j NFQUEUE --queue-bypass
-I OUTPUT 1 -p tcp --sport 22 -j NFQUEUE --queue-bypass
-I FORWARD 1 -m mark ! --mark 1/1 -j NFQUEUE
-I INPUT 2 -m mark ! --mark 1/1 -j NFQUEUE
-I OUTPUT 2 -m mark ! --mark 1/1 -j NFQUEUE
### END SURICATA ###

In case you are on RHEL or alike edit /etc/firewalld/direct.xml:

IPTABLES (passthrough):

<?xml version="1.0" encoding="utf-8"?>
<direct>
  <passthrough ipv="ipv4">-I INPUT 1 -p tcp --dport 22 -m mark ! --mark 1/1 -j NFQUEUE --queue-bypass</passthrough>
  <passthrough ipv="ipv6">-I INPUT 1 -p tcp --dport 22 -m mark ! --mark 1/1 -j NFQUEUE --queue-bypass</passthrough>
  <passthrough ipv="ipv4">-I INPUT 2 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
  <passthrough ipv="ipv6">-I INPUT 2 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
  <passthrough ipv="ipv4">-I OUTPUT 1 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
  <passthrough ipv="ipv6">-I OUTPUT 1 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
  <passthrough ipv="ipv4">-I FORWARD 1 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
  <passthrough ipv="ipv6">-I FORWARD 1 -m mark ! --mark 1/1 -j NFQUEUE</passthrough>
</direct>

NFTABLES (rule):

<?xml version="1.0" encoding="utf-8"?>
<direct>
  <rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-p tcp --dport 22 -j NFQUEUE --queue-bypass</rule>
  <rule ipv="ipv4" table="filter" chain="INPUT" priority="1">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
  <rule ipv="ipv4" table="filter" chain="OUTPUT" priority="1">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
  <rule ipv="ipv6" table="filter" chain="INPUT" priority="0">-p tcp --dport 22 -j NFQUEUE --queue-bypass</rule>
  <rule ipv="ipv6" table="filter" chain="INPUT" priority="1">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
  <rule ipv="ipv6" table="filter" chain="OUTPUT" priority="1">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
  <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
  <rule ipv="ipv6" table="filter" chain="FORWARD" priority="0">-m mark '!' --mark 1/1 -j NFQUEUE</rule>
</direct>

Access Denied to Administrative Shares

Posted on by Andy

As described in MS KB article 951916, Microsoft introduced as part of UAC a little known feature called “UAC remote restrictions”. It filters the access token for connections made with local user accounts or Microsoft accounts (the latter typically have the format MicrosoftAccount\EMailAddress). In other words, it removes the SID for “Administrators”. Connections made with domain accounts remain unchanged.

From KB951016:

If the user wants to administer the workstation with a Security Account Manager (SAM) account, the user must interactively log on to the computer that is to be administered with Remote Assistance or Remote Desktop, if these services are available.

One may like this or not, the solution is luckily pretty simple. UAC remote restrictions can be disabled by setting the registry value LocalAccountTokenFilterPolicy to 1. Open Powershell as Administrator and run:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Now the connection for local computer account should work.

Source: https://helgeklein.com/blog/access-denied-trying-to-connect-to-administrative-shares-on-windows-7/

Repairing the Domain Trust Relationship

Posted on by Andy

If a computer is restored from an old restore point or a snapshot that was created before the computer’s password was changed in AD, the machine password in the snapshot will differ from the AD computer object password.

When the trust relationship between a workstation and the Active Directory domain is broken, you will encounter errors such as:

The trust relationship between this workstation and the primary domain failed.

or

The security database on the server does not have a computer account for this workstation trust relationship.

To restore trust between the machine and the domain, you must log on to the computer locally using an account with local administrator privileges. Open your elevated terminal session and check if you have a valid trust relationship with the AD Domain with following PowerShell command:

Test-ComputerSecureChannel -Verbose

Should the result be something like

VERBOSE: The secure channel between the local computer and the domain <DOMAIN> is broken.

You can fix it by running the repair command:

Test-ComputerSecureChannel -Repair -Credential <DOMAIN>\<ADMINUSER> -Verbose

Result should be like this:

VERBOSE: The secure channel between the local computer and the domain <DOMAIN> was successfully repaired.

No reboot or delete/add to AD is needed.