Important Splunk update for timestamp issue starting 01.01.2020

Splunk has identified an issue regarding timestamps, which are intensivly used for data correlation in many Splunkbased logging and SIEM systems. Affected versions are Splunk Enterprise, Splunk Light and Splunk Cloud. This issue has potential significant impact on data ingestion - including causing inaccurate, unsearchable, or prematurely-deleted data - starting January 1, 2020.

Cause of the issue: Timestamps using two-digit years will stop being correctly recognized. Full details around this issue, including workarounds and product fixes, are documented in Release Notes for each Splunk Version: https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/FixDatetimexml2020
 

Possible Solutions:

1. Manual Change of "datetimes.xml"

Change on all Splunk systems (search heads, indexers, heavy forwards etc) the file "datetimes.xml" with the following file: http://download.splunk.com/products/ingest2020/datetime.zip
In order to do that, put the downloaded in $SPLUNK_HOME/etc. (mostly found in /opt/splunk/etc). Then restart the system (in a Indexer Cluster a rolling-restart is possible). Until a splunk patch is available, the warning will be shown, that this file is not part of the splunk manifest. This will be fixed in the future splunk versions.

2. Update to a version with a fix

Splunk will ship minor releases with fixes, soon:

Major Release --- Minor Release with patch
6.6 --- 6.6.12.1 (not yet released)
7.0 --- 7.0.13.1 (not yet released)
7.1 --- 7.1.10 (not yet released)
7.2 --- 7.2.9.1 (not yet released)
7.3 --- 7.3.3 (Installationguide)
8.0 --- 8.0.1 (not yet released)

FortiOS XSS in DHCP-Monitor

Fortinet has released PSIRT FG-IR-19-184 (CVE-2019-6697) about a vulnerability in FortiOS of the FortiGate firewall. A DHCP packet may contain a stored XSS in the hostname parameter field.

Affected Versions and Update

Affected Products are FortiOS 6.2.1 and below & FortiOS 6.0.6 and below.

FortiOS 6.2.2 and FortiOS 6.0.7 fix the vulnerability

PoC/Vulnerability Details from ssd-disclosure.com

Source: https://ssd-disclosure.com/archives/3987/ssd-advisory-fortigate-dhcp-stored-xss

An unauthenticated attacker can trigger a Stored XSS Vulnerability via a malicious DHCP packet in the Fortigate DHCP Monitor.

This can happen if Device Detection is enabled through Network >Interface > Edit Interface > Device Detection

  


 When this option is enabled the attacker may perform the following steps in order to exploit the vulnerability:

1. Install dhtest or any other tool that can send arbitrary DHCP packets.
   (https://sargandh.wordpress.com/2012/02/23/linux-dhcp-client-simulation-tool/)
2. Send a malicious DHCP packet. For example:
   
   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x" [Option] -m : mac address -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

   1 2 3 4

   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x"     [Option]     -m : mac address     -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

Linux show all cronjobs of all users

How to Linux show all cronjobs of all users (not ldap or nis users): Use the following command as root:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

Example:

linuxhost001:~ # for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done
no crontab for bin
no crontab for daemon
no crontab for ftp
no crontab for lp
no crontab for mail
no crontab for man
no crontab for messagebus
no crontab for news
no crontab for nobody
no crontab for nscd
no crontab for openslp
no crontab for polkitd
no crontab for postfix
no crontab for root
no crontab for rpc
no crontab for sshd
no crontab for statd
no crontab for systemd-bus-proxy
no crontab for systemd-timesync
no crontab for uucp
no crontab for wwwrun
no crontab for ntp
no crontab for nagios
no crontab for radiusd 

Intel NUC running VMware ESXi 6.5.3

Because there are some people on the internet asking for experience on "is my Intel NUC supporting ESXi version x.y.z?", so I will provide short feedback regarding that: Using an Intel NUC NUC7i7DNHE "Intel NUC 8th Gen Commercial" (https://www.intel.de/content/www/de/de/products/boards-kits/nuc.html) I'm running VMware ESXi 6.5 update 3 without any additional drivers necessary.

VMware updates can be found here: http://www.vmware.com/patchmgr/download.portal

Apple iPhone/iPad iOS IPSec IKEv2 Proposals

When setting up VPN-tunnel from an Apple iPhone or iPad running iOS using IPSec with IKEv2 you need to know, which IPSec proposals the iPhone/iPad/iOS device are supporting/offering:

Offered proposals from iOS

Testing with an iPhone running iOS 12.4.1 and iPad 13.1.2:

• AES256-SHA256-DH14 (2048-bit MODP Group) <------ (✔ okay)
• AES256-SHA256-DH19 (256-bit random ECP group) <------ (✅ recommended)
• AES256-SHA256-DH5 (1536-bit MODP Group) <------ (❌not recommended)
• AES128-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)
• 3DES-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)

Recommendation

Therefore I recommened 🔒✅ to use for your IPSec IKEv2 proposals:

• IKEv2 Phase1: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)
• IKEv2 Phase2: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)

DH-Grp 19 ECP 256Bit > DH-Grp 14 RSA 2048Bit
-> For example see BSI recommendation for crypto IPSec page 13 section 3.2.4  or NIST recommendation page 9 line 264

-> Details for ECP (Elliptic Curve from NIST) for IKEv1/v2 see RFC5903 or IANA ipsec registry

Details to reverse engineering

iPhone iOS 12.4.1 IKEv2 RAW output:

2019-10-27 16:25:15.519164 ike 4: incoming proposal:
2019-10-27 16:25:15.519176 ike 4: proposal id = 1:
2019-10-27 16:25:15.519185 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519195 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519205 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519215 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519224 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519234 ike 4:         type=DH_GROUP, val=MODP2048.
2019-10-27 16:25:15.519246 ike 4: proposal id = 2:
2019-10-27 16:25:15.519255 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519264 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519274 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519283 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519293 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519303 ike 4:         type=DH_GROUP, val=ECP256.
2019-10-27 16:25:15.519314 ike 4: proposal id = 3:
2019-10-27 16:25:15.519323 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519332 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519342 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519353 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519365 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519374 ike 4:         type=DH_GROUP, val=MODP1536.
2019-10-27 16:25:15.519384 ike 4: proposal id = 4:
2019-10-27 16:25:15.519392 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519400 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519408 ike 4:         type=ENCR, val=AES_CBC (key_len = 128)
2019-10-27 16:25:15.519416 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519424 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519432 ike 4:         type=DH_GROUP, val=MODP1024.
2019-10-27 16:25:15.519443 ike 4: proposal id = 5:
2019-10-27 16:25:15.519451 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519459 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519466 ike 4:         type=ENCR, val=3DES_CBC
2019-10-27 16:25:15.519474 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519482 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519490 ike 4:         type=DH_GROUP, val=MODP1024.

 

Windows Server 2016 Backup - error with user of network share

If you are running a Windows Server 2016, are using the integrated Windows Server Backup utility and you want to save the backup to a remote destination, which is a CIFS/SMB network share, then during the setup the following error might occur:

"The user name being used for accessing the remote share folder is not recognized by the local computer."

Soltuion

1. Create a local user at your Windows Server, which has the same username and password as the cifs/smb user
2. Add this user to the "Backup Operators" user group:

3. Go back to setup the backup job using the "Previous" button and click next/finish again -> Your scheduled backup job using a cifs/smb network share should now be created successfully.

Outlook connection protocol, auth, encryption & status

A quick way to check or beginn to troubleshoot the used protocol, authentication, encryption and connection status of Microsofts Outlook client as well as to find out which version is running on your Microsoft Exchange server or Microsoft Office 365 server is to use:

1. CTRL + right-click on the outlook icon:
    
2. Select "connection status":
   
3. The following window will appear:
   
   There the server, the proxy-server, the used protocol, the authentication method, the encryption, the status and the exchange-server version can be quickly checked.

More in the Microsoft support article.

Security fixes in PRTG 19.3.51/19.4.52

The current version PRTG 19.3.51/19.4.52 includes some security fixes:

• PRTG Core Server XSS Cross-Site-Scripting
  We fixed potential reflected XSS vulnerabilities with medium severity on the PRTG core server. The potential vulnerabilities affected tag filters, object IDs, and the contact support/feedback page. Please note that the fixed vulnerabilities required a logged in PRTG user account to be exploited.
• Sensors DoS
  We fixed a potential Denial of Service (DoS) vulnerability of the HTTP Full Web Page sensor. Please note that the fixed vulnerability required a logged in PRTG user account with elevated rights to be exploited. (CVE-2019-11074) 

Besides those security fixes some new improvements made it into the release, too. More information can be found in the release notes https://www.de.paessler.com/prtg/history/stable or in the blog of the vendor: https://blog.paessler.com/prtg-release-19.3.51-and-19.4.52-news-roundup. Information regarding previous security issues with proof of concept are listed here: https://sensepost.com/blog/2019/being-stubborn-pays-off-pt.-1-cve-2018-19204/

SonicWALL E-Mail-Security AntiSpam Troubleshooting & Firmware

If you are using SonicWALL E-Mail-Security as your antispam solution there are some useful ways to troubleshoot issues using different logs. They help to understand what happend to a certain mail, why communication to another mailserver is slow/lost and how the SNWL E-Mail-Security or your ES Remote Analyzers work internally.
These logs contain very sensible information in terms of privacy, make sure your data protection & legal processes are fully in place.

1. Which firmware to use?

SonicWALL uses the SNWL E-Mail-Security themselfs. The version of the used SonicWALL E-Mail-Security is written in their SMTP Banner:

1. DNS-Query to find MX-Records:
   > set q=mx
   > sonicwall.com
   Server:  dns9.quad9.net
   Address:  9.9.9.9
   
   Non-authoritative answer:
   sonicwall.com   MX preference = 15, mail exchanger = mail1.sonicwall.com
   sonicwall.com   MX preference = 15, mail exchanger = mail3.sonicwall.com
   sonicwall.com   MX preference = 15, mail exchanger = mail2.sonicwall.com
   
   
2. Connecting to them using a TCP-Session on TCP-Port 25 (e.g. telnet 25 or nc -C 25):
   nc -C mail1.sonicwall.com 25
   220 mail.sonicwall.com ESMTP SonicWall (9.1.2.3763)
   220 mail.sonicwall.com ESMTP SonicWall (9.1.1.3121)
   220 mail.sonicwall.com ESMTP SonicWall (9.1.2.3761)

There you can see which firmware SonicWALL themselfs are using.

2. Audit log

Use the audit log. It helps you most of the time and is very easy to understand.

3. Log level

Set the loglevel to "level 2" or "debug". That gerenates a lot of logs, but is necessary for fully troubleshooting mail-problems, either with other or your own mailservers or with mails "lost" in antispam.

1. Login to the SonicWall and navigate to Manage -> Anti-Spam -> Advanced Settings
   
2. Now select the Log Level 2 and then select the Type of Log file and then click on Download. We have chosen MlfAsgSMTP in the screenshot shown below to download the SMTP Logs, however depending on the issue the desired log files may be selected.
   
3. Save the logs in the desired location.
   Source: https://www.sonicwall.com/support/knowledge-base/how-to-obtain-smtp-logs-from-anti-spam/170503798824694/

You can use the CLI to adjust the maximum log filesize:

Logfile names:
Some log file names, such as those found in the commonlogs directory, contain a two-digit number such as 12.log. The "12" indicates that the log is for the 12th day of the most recent month. Some log file names end with a digit, such as MlfThumbUpdate_2.log. The "2" indicates that this is an older log. The current log is MlfThumbUpdate.log. The next most recent log is MlfThumbUpdate_0.log, followed by MlfThumbUpdate_1.log, and so forth.

The following logs are very useful:

• pmta:logs
• logs:MlfAsgSMTP
• logs:smtp

Use the timestamp, unique-message-id or the destination-address in order to follow a mail. Sometimes the E-Mail-Security sends a mail to localhost on another internal tcp socket. You can see that, because the destination is 127.0.0.1:*highport*. Because sometimes an action is done while the second inspection time, you need to follow that session, which will be documented in the logs, too.

FortiOS update with versions 5.2.14/5.4.12/5.6.10/6.0.5/6.2.1

Fortinet released two "Customer Support Bulletins" (check fortinet support portal) regarding a possible issue with uninterruptible upgrade in FortiGate HA-clusters running version FortiOS 5.2.14 or 5.4.12 or 5.6.10 or 6.0.5 or 6.2.1. Please check the two Customer Support Bulletins before upgrading and plan a possible short downtime for the update.

Securing Layer 2 / Switing Level

Ideas for securing your layer 2 switching infrastructure

No matter if you use Cisco, Extreme Networks, HP or any other vendor, most of them have the same basic security features, which are rarely used, but actually really should be. Here are some ideas, which you should use for ideal protection:

Securing Switch Management Interfaces

• ACLs --> to limit all management interfaces (SSH, SNMP, etc) to very few dedicated ip-addresses
• Use SSH
• Disable telnet
• SNMPv3 AuthPriv AES+SHA
• Disable SNMPv1/v2c
• Disable HTTP/HTTPS
• Delete default users, groups & communities
• Use radius authentication and two local backup-accounts with long passwords (30+ characters), those should be only useable when the radius-servers are not reachable anymore, otherwise they should not work
• Use syslog (reliable & encrypted if possible) --> send these logs to a SIEM and define alerts/SIEM use cases
• Fail2ban or similar login protection
• Use Out-of-band management interfaces
• Think about using serial-to-ip adapters for out-of-band-management, if you have a dedicated seperated out-of-band-mgmt network
• Disable LLDP/CDP/EDP/etc where possible
• Setup IT-Monitoring (PRTG, Icinga2, Nagios,..) and check CPU, RAM, NIC-Utilization & Errors of critial links like LAGs, Uplinks, Mgmt, etc, 802.1x-Auth-Errors-per-Min, Temperature, Fans, Hardware-Status, 
• Setup IT-Monitoring to do negative testing like try to access the switch via Telnet/HTTP/SNMPv1/v2c or SSH/SNMPv3 with default accounts or try to access the switches from a forbidden ip-address (which is not part of the ACL) in order to find possible cfg-errors, holes or cfg mistakes after a switch got replaced, reconfigured or a firmware-update
• Limit Access to VirtualStacking/MultiChassis-Links like MLAG, VSS etc using dedicated ACLs; If possible use internal ip-addresses like 169.254.0.0/16 if you have to use ip-addresses for them

Securing Traffic passing the switches

• Use 802.1x Authentication with certificates from your pki
• Port-Level Traffic Controls and port security mechanisms to provide protection against MAC flooding attacks
• Private VLAN (PVLAN) 
• Access Lists on Switches if necessary, normally done on a firewall
• Spanning Tree Protocol Features 
• Dynamic Host Configuration Protocol (DHCP) Snooping 
• IP Source Guard 
• Dynamic ARP Inspection (DAI) 
• Advanced Integrated Security Features on High-End Catalyst Switches 
• Control Plane Policing (CoPP) Feature 
• CPU Rate Limiters 
• M/BCast Limitations or Warnings 
• Loop Protection as BPDU Guard, Loopguard, ELRP, BCast-Storm-Control, (M/R)STP, Root Guard, etc
• Use VLAN tagging to seperate user-traffic from network traffic like LLDP, (M)STP, OSPF, BGP, BFD, etc. --> Then those protocols are not mixed with user-traffic (example: STP is send untagged while user-traffic is sent tagged)
• Shut down or disable all unused ports on the switch
• Use small subnets, not bigger than /24 for good performance/stability and for small segmentation --> in general: the more segmentation, the better

Not really security related, but I always recommend to use LACP in fast mode for LAGs (let LACPDUs work for you), BFD for faster failover in (dynamic) routing-protocols and protocols like MLAG instead of stacking for better firmware-update-situations (often stacking requires the whole stack-topology to be rebooted). The more you harden your switch infrastructure, the less often they are attackable and the less often you have to update the firmware.

Extend ZFS zpool of Linux Ubuntu NextCloud VM

If you are running a virtual machine with NextCloud v16 on linux ubuntu and you want to extend /mnt/ncdata, then:

1. Make sure your backup is fine, think about creating a vm snapshot
2. Extend second virtual harddrive disk in VMWare virtual machine settings (e.g. from 40Gb to 170Gb)
3. Login using SSH/VMWare-Console, change to root user using sudo su or sudo -i
4. Check the zpool size using zpool list
5. Check the /mnt/ncdata size using df -h
6. Read the new partition size using parted -l with the answer "fix" for the adjustment
7. You can delete the buffer partition 9 using parted /dev/sdb rm 9
8. Extend the first partition using to 100% of the available size parted /dev/sdb resizepart 1 100%
9. Using zpool online -e ncdata /dev/sdb you can adjust the partition to the correct size
10. Check the new zpool size using zpool list
11. Check the new /mnt/ncdata size using df -h

Example with nextcloud 16 on Ubuntu 18.04:

root@nextcloud:/mnt# zpool list
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
ncdata  39.8G  15.2M  39.7G         -     0%     0%  1.00x  ONLINE  - 
root@nextcloud:/mnt#
root@nextcloud:/mnt#
root@nextcloud:/mnt# df -Th
Filesystem                     Type      Size  Used Avail Use% Mounted on
[...]
ncdata                         zfs        39G  896K   39G   1% /mnt/ncdata
[...]
root@nextcloud:/mnt#
root@nextcloud:/mnt# parted -l
[...]
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 183GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  42.9GB  42.9GB  zfs          zfs-28cd7
 9      42.9GB  42.9GB  8389kB[...]
root@nextcloud:/mnt#
root@nextcloud:/mnt#
root@nextcloud:/mnt# parted /dev/sdb rm 9
Information: You may need to update /etc/fstab.
root@nextcloud:/mnt#
root@nextcloud:/mnt# parted /dev/sdb resizepart 1 100%
Information: You may need to update /etc/fstab.
root@nextcloud:/mnt#
root@nextcloud:/mnt# zpool online -e ncdata /dev/sdb
root@nextcloud:/mnt#
root@nextcloud:/mnt# zpool list
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
ncdata   170G  2.51M   170G         -     0%     0%  1.00x  ONLINE  -
root@nextcloud:/mnt#
root@nextcloud:/mnt# df -h
Filesystem                      Size  Used Avail Use% Mounted on[...]
ncdata                          165G  896K  165G   1% /mnt/ncdata[...]
root@nextcloud:/mnt#



Update 25.12.2020: If you are running Ubuntu 20/Nextcloud VM 20, then follow the instrutions here starting point 7: https://how2itsec.blogspot.com/2020/12/increase-disk-and-zfs-of-nextcloud-vm.html

Hint when VMWare doesnt show a snapshot

If VMWare ESXi/vCenter/your vSphere environment does not show a virtual machine snapshot, however it is there and the virtual machine is using it, here is a little trick which might help you:

1. Make sure you have some free space left in your datastore, in which the vm is stored.
2. Create another virtual machine snapshot 
3. Click on "delete all snapshots"

This can trigger the ESXi to delete all snapshots, including the one which isn't shown. However this does not always work, in which case working with a clone of the VM and vmkfstools can help.

FortiGate default configuration does not verify the LDAP server identity - CVE-2019-5591

I have found a vulnerability in all FortiOS versions, including the current 5.4/5.6/6.0/6.2 branches. The issue has been fixed in 6.0.3/6.2.1 by using the new feature "server-identity-check":
 

The vulnerability is in the LDAPS connection of the FortiGate to a LDAP-Server. The FortiGate does not properly check the certificate sent from the LDAP-Server, allthough the correct CA certificate is configured. More details will be published later.

Fortinet PSIRT-team responded quickly, has acknowledged the issue, told me that some one else also reported the issue, assigned CVE-2019-5591 to it and released the following PSIRT advisory: https://fortiguard.com/psirt/FG-IR-19-037

Solution:

Update to FortiOS 6.0.3+ or 6.2.1+ and set the following option:


config user ldap
edit ldap-server
set server-identity-check enable

 

Migrate nextcloud v15 with mariadb database to nextcloud v16 with postgresql

If you are running nextcloud v15 with mariadb and want to upgrade from nextcloud version 16, then you have to migrate the database from mariadb to postgresql.

This can be done using the following commands, which I adjusted for ubuntu 16.04 and is originally from the following site: https://www.techandme.se/we-migrated-to-postgresql/
 

#!/bin/bash

## Convert to PostgreSQL ##
# Tested on Ubuntu Server 16.04
# Make sure you have a full backup of your nextcloud installation


# Make sure only root can run our script
if [[ $EUID -ne 0 ]]; then
 echo "This script must be run as root, please type sudo -i and run it again." 1>&2
 exit 1
fi

service apache2 stop

. <(curl -sL https://raw.githubusercontent.com/nextcloud/vm/master/lib.sh)

NCUSER=pgsql_user_nextcloud

# Install PostgreSQL
apt update
check_command apt install postgresql-9.5

# Create DB
cd /tmp || exit
sudo -u postgres psql <<END
CREATE USER $NCUSER WITH PASSWORD '$PGDB_PASS';
CREATE DATABASE nextcloud_db WITH OWNER $NCUSER TEMPLATE template0 ENCODING 'UTF8';
END
check-command service postgresql restart

# Convert DB
sudo -u www-data php /var/www/nextcloud/occ db:convert-type --all-apps --password "$PGDB_PASS" pgsql $NCUSER 127.0.0.1 nextcloud_db
sudo -u www-data php /var/www/nextcloud/occ maintenance:repair

# Remove MySQL / MariaDB
read -p "Are you sure you want to remove MySQL?" -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]
then
    apt clean
    apt update
    dpkg -r mariadb-client-10.2
    dpkg -r mariadb-server-10.2
    dpkg -r libmysqlclient20:i386
    dpkg -r libmysqlclient20:amd64
    dpkg -r libmysqlclient18:amd64
    dpkg -r mysql
    apt purge mysql\* libmysql\* libmariadb\*
    apt autoremove -y
    rm -R /var/lib/mysql /var/lib/mysql-files /var/lib/mysql-keyring /var/mysql-upgrade /etc/mysql /var/lib/mysql
fi

# Remove mysql.utf8mb4
if grep -q "mysql.utf8mb4" /var/www/nextcloud/config/config.php
then
sed -i "s|'mysql.utf8mb4' => true,||g" /var/www/nextcloud/config/config.php
sed '/^\s*$/d' /var/www/nextcloud/config/config.php
fi

# Show password
echo "Your new PostgreSQL password is: $PGDB_PASS. It's also written in your Nextcloud config.php file."

# Start Apache2
echo "Apache will start in 30 seconds... Press CTRL+C to abort."
sleep 30
service apache2 start

# Fetch the correct update script
if [ -f "$SCRIPTS"/update.sh ]
then
 rm "$SCRIPTS"/update.sh
 wget https://raw.githubusercontent.com/nextcloud/vm/master/static/update.sh -P "$SCRIPTS"
 chmod +x "$SCRIPTS"/update.sh
fi

exit

Testing FortiGate FortiOS nested adress object groups

Sometimes it is useful to know, if a device really supports nested groups. This little test shows, that a Fortinet FortiGate 60D running FortiOS 5.6 actually supports an address object, which is nested into five different groups:

address object "h-192.168.2.2" is in group "srcgrp05"
address object group "srcgrp05" is in group "srcgrp04"
address object group "srcgrp04" is in group "srcgrp03"
address object group "srcgrp03" is in group "srcgrp02"
address object group "srcgrp02" is in group "srcgrp01"
address object group "srcgrp01" is used in firewall policy with id 10:

srcgrp01/
├──srcgrp02/
│   └──  srcgrp03/
│       └──  srcgrp04/
│           └── srcgrp05/
│               └── h-192.168.2.2/

dstgrp01/
├──dstgrp02/
│   └──  dstgrp03/
│       └──  dstgrp04/
│           └── dstgrp05/
│               └── h-172.16.0.182/ 

Firewall policy 10 uses srcgrp1 and dstgrp05 (by mistake, should have been dstgrp01)

Config:

config firewall address
    edit "h-192.168.2.2"
        set subnet 192.168.2.2 255.255.255.255
    next
    edit "h-172.16.0.182"
        set subnet 172.16.0.182 255.255.255.255
    next
end

config firewall addrgrp
    edit "srcgrp05"
        set member "h-192.168.2.2"
    next
   edit "srcgrp04"
        set member "srcgrp05"
    next
    edit "srcgrp03"
        set member "srcgrp04"
    next
    edit "srcgrp02"
        set member "srcgrp03"
    next
    edit "srcgrp01"
        set member "srcgrp02"
    next
    edit "dstgrp05"
        set member "h-172.16.0.182"
    next
    edit "dstgrp04"
        set member "dstgrp05"
    next
    edit "dstgrp03"
        set member "dstgrp04"
    next
    edit "dstgrp02"
        set member "dstgrp03"
    next
    edit "dstgrp01"
        set member "dstgrp02"
    next
end

config firewall policy
    edit 10
        set srcintf "internal3"
        set dstintf "wan1"
        set srcaddr "srcgrp01"
        set dstaddr "dstgrp05"
        set action accept
        set schedule "always"
        set service "SSH"
        set logtraffic all
        set fsso disable
        set nat enable
    next
end  

Test using diag debug flow:

FGT60D123456789 # id=20085 trace_id=4 func=print_pkt_detail line=5455 msg="vd-root received a packet(proto=6, 192.168.2.2:58871->172.16.0.182:22) from internal3. flag [S], seq 1083753677, ack 0, win 64240"
id=20085 trace_id=4 func=init_ip_session_common line=5614 msg="allocate a new session-0005ea9f"
id=20085 trace_id=4 func=vf_ip4_route_input line=1604 msg="find a route: flags=00000000 gw-172.16.0.182 via wan1"
id=20085 trace_id=4 func=fw_forward_handler line=746 msg="Allowed by Policy-10: SNAT"
id=20085 trace_id=4 func=__ip_session_run_tuple line=3284 msg="SNAT 192.168.2.2->172.16.255.254:58871"
id=20085 trace_id=5 func=print_pkt_detail line=5455 msg="vd-root received a packet(proto=6, 172.16.0.182:22->172.16.255.254:58871) from wan1. flag [S.], seq 3921820808, ack 1083753678, win 29200"
id=20085 trace_id=5 func=resolve_ip_tuple_fast line=5530 msg="Find an existing session, id-0005ea9f, reply direction"
id=20085 trace_id=5 func=__ip_session_run_tuple line=3298 msg="DNAT 172.16.255.254:58871->192.168.2.2:58871"
id=20085 trace_id=5 func=vf_ip4_route_input line=1604 msg="find a route: flags=00000000 gw-192.168.2.2 via internal3"
id=20085 trace_id=5 func=npu_handle_session44 line=919 msg="Trying to offloading session from wan1 to internal3, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x00000000"
id=20085 trace_id=5 func=ip_session_install_npu_session line=270 msg="npu session intallation succeeded"
id=20085 trace_id=6 func=print_pkt_detail line=5455 msg="vd-root received a packet(proto=6, 192.168.2.2:58871->172.16.0.182:22) from internal3. flag [.], seq 1083753678, ack 3921820809, win 1026"
id=20085 trace_id=6 func=resolve_ip_tuple_fast line=5530 msg="Find an existing session, id-0005ea9f, original direction"
id=20085 trace_id=6 func=npu_handle_session44 line=919 msg="Trying to offloading session from internal3 to wan1, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x00002000"
id=20085 trace_id=6 func=ip_session_install_npu_session line=270 msg="npu session intallation succeeded"
id=20085 trace_id=6 func=__ip_session_run_tuple line=3284 msg="SNAT 192.168.2.2->172.16.255.254:58871"
id=20085 trace_id=7 func=print_pkt_detail line=5455 msg="vd-root received a packet(proto=6, 172.16.0.182:22->172.16.255.254:58871) from wan1. flag [F.], seq 3921820867, ack 1083753680, win 229"
id=20085 trace_id=7 func=resolve_ip_tuple_fast line=5530 msg="Find an existing session, id-0005ea9f, reply direction"
id=20085 trace_id=7 func=__ip_session_run_tuple line=3298 msg="DNAT 172.16.255.254:58871->192.168.2.2:58871"
id=20085 trace_id=7 func=npu_handle_session44 line=919 msg="Trying to offloading session from wan1 to internal3, skb.npu_flag=00000000 ses.state=00010204 ses.npu_state=0x00003000"
id=20085 trace_id=8 func=print_pkt_detail line=5455 msg="vd-root received a packet(proto=6, 192.168.2.2:58871->172.16.0.182:22) from internal3. flag [F.], seq 1083753680, ack 3921820868, win 1026"
id=20085 trace_id=8 func=resolve_ip_tuple_fast line=5530 msg="Find an existing session, id-0005ea9f, original direction"
id=20085 trace_id=8 func=npu_handle_session44 line=919 msg="Trying to offloading session from internal3 to wan1, skb.npu_flag=00000000 ses.state=00010204 ses.npu_state=0x00003000"
id=20085 trace_id=8 func=__ip_session_run_tuple line=3284 msg="SNAT 192.168.2.2->172.16.255.254:58871" 

Result

The working with an address object, which is nested in 5 address object groups works.

Ideas for your SIEM or Logging-System - Monitoring of critical commands, files and folders

Your are searching for some use cases for your SIEM or your logging/audit/log-alerting system?

How about monitoring some possibly critical commands, files and folders? Here are some examples, which could be helpful. You can use those ideas and adjust them to your environment:

1. vi /etc/passwd
   or anything that interacts with /etc/passwd


2. john
   When john the ripper is used


3. msfconsole
   When metalspoit console is called


4. rm –rf /
   If someone/something wants to delete "too much"
   


5. passwd root
   Changing the password of the root user might be interesting to monitor


6. /etc/init.d/apache2 stop
   Stopping, Restarting (with changed cfg/libs/files?) of important services might be something to investigate


7. vi /etc/postfix/ssl.conf
   Editing or looking at your SSL/TLS configuration of your mailserver could be fishy


8. /var/opt/researchdevelopmentdata or /var/opt/paymenttransactiondata
   Folders with critical business, payment, personal, research-and-development or other data could be interesting to watch


9. /etc/payment-system/configuration.conf
   Folders with configuration files of applications with with critical business, payment, personal, research-and-development data should be closly monitored


10. Windows: useradd Administrator
    Also Windows systems of course have lots of critical commands or folders and files, which should be monitored, e.g. when an administrator user is added


11. Windows Domain Controller: vssadmin create shadow /for=C: (or on which partition NTDS.dit is stored)
    Intensivly Monitor NTDS.dit (Active Directory database) and possible attemps to copy/modify it (e.g. using vssadmin)

Of course there are many more critical commands, files and folders and not all eleven examples fit for everybody. Adjusting them to your needs is key for additional security.