In order for Windows computers to function properly in Active Directory, they must have their time in sync with the domain. In the AD environment, domain controllers act as the time source for client devices. Kerberos AD authentication will fail if the clock offset between the client and the domain controller (KDC) is greater than 5 minutes.
Understanding the Time Hierarchy in the Active Directory Domain
There is a strict hierarchy to time synchronization in an Active Directory domain:
The domain controller with the PDC emulator FSMO role is the main source of time in the domain. This DC synchronizes the time with an external time source or NTP server;
Other domain controllers synchronize their time with the PDC domain controller;
The domain workstations and the Windows member servers synchronize their time with the domain controller that is closest to them (in accordance with AD sites and subnets configuration);
The AD domain controller should be used as the time source on the workstation after you have joined it to the domain. On Windows 10 or 11, go to Settings > Time and Language and make sure your DC is used as the last time sync source.
You can also get the NTP source on your computer by using the command:
w32tm /query /source
The command should return the name of one of the domain controllers in your AD domain.
List details of the status of time synchronization on the client device:
w32tm /query /status
The command returns the following useful information:
Leap Indicator (time sync status)
Last Successful Sync Time
Source (your DC)
Poll Interval (1024 seconds by default)
Get a list of the AD domain controllers which can be used to synchronize time:
w32tm /monitor
In this example, there are three domain controllers available for the client to synchronize time with.
To re-enable time synchronization with a DC for computers in an Active Directory domain, use the following commands:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
If the domain computer is configured to synchronize its time following to the AD DS Time hierarchy, the value of the Type parameter in the HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters registry key should be NT5DS.
If the Windows client fails to synchronize time with the AD domain controller, you must to reset the Windows Time service configuration. To do this, open a command prompt as an administrator and run the following commands:
The first command unregisters the w32time service and removes the settings from the registry:w32tm /unregister
Then register w32tm service and restore the default time settings:w32tm /register
Set AD as the time sync source for the client (by changing the Type registry parameter to NT5DS):REG add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type /d NT5DS
Restart the service:net stop w32time && net start w32time
Update settings:w32tm /config /update
Synchronize the time:w32tm /resync
Check your current sync settings:w32tm /query /status
The screenshot below shows that Windows is now synchronizing with DC (Source).
Time Sync Issues on Windows Domain Joined Computers
The Windows Time Service (W32Time) is responsible for time synchronization. First, ensure that this service is running on a Windows client computer:
UDP port 123 is used for time synchronization on Windows. If this port is not available on the DC, the client computer won’t be able to synchronize the time.
You may get an error when you try to synchronize the time with the w32tm /resync command:
Sending resync command to local computer The computer did not resync because no time data was available.
Check that the w32time service is running on the DC and listening on UDP port 123:
netstat -an | find "UDP" | find ":123"
Then check that the UDP inbound rule named Active Directory Domain Controller – W32Time (NTP-UDP-In) is enabled in Windows Defender Firewall (Control Panel > Windows Firewall > Advanced settings > Inbound rules).
You can check Windows Defender Firewall rule status with PowerShell:
It is also possible to force a client to manually synchronize its time with another domain controller.
net time \\ny-dc01 /set /y
Configuring the NTP Client Time Sync on Windows Using GPO
In most cases, time sync with a domain on Windows client doesn’t require administrator intervention. However, if you find that time synchronization is not working properly on clients in your domain, you can centrally configure client NTP settings on Windows devices using Group Policy.
Use the gpedit.msc console if you want to change Group Policy settings on a single computer (this is the best solution if you need to solve synchronization problems on a single computer or test new NTP client settings). To set up a GPO for multiple domain computers, use the Group Policy Management Console (gpmc.msc);
Expand the following node in GPO editor: Computer Configuration > Administrative Templates > System > Windows Time Service;
Enable the Enable Windows NTP Client policy;
Then enable the Configure NTP Client policy and set the following settings in the Options panel: NTPServer: your domain name (preferred) or FQDN name of the domain controller with the PDC Emulator role (you can find it with the command: netdom.exe query fsmo) Type: NT5DS CrossSiteSyncFlags: 2 ResolvePeerBackoffMinutes: 15 ResolvePeerBackoffMaxTimes: 7 SpecialPollInterval: 64 EventLogFlags: 0
Restart your computer to apply the new GPO client time settings.
By: Shannon Murphy, Greg Young March 20, 2024 Read time: 2 min (589 words)
On February 26, 2024, the National Institute of Standards and Technology (NIST) released the official 2.0 version of the Cyber Security Framework (CSF).
What is the NIST CSF?
The NIST CSF is a series of guidelines and best practices to reduce cyber risk and improve security posture. The framework is divided into pillars or “functions” and each function is subdivided into “categories” which outline specific outcomes.
As titled, it is a framework. Although it was published by a standards body, it is not a technical standard.
https://www.nist.gov/cyberframework
What Is the CSF Really Used For?
Unlike some very prescriptive NIST standards (for example, crypto standards like FIPS-140-2), the CSF framework is similar to the ISO 27001 certification guidance. It aims to set out general requirements to inventory security risk, design and implement compensating controls, and adopt an overarching process to ensure continuous improvement to meet shifting security needs.
It’s a high-level map for security leaders to identify categories of protection that are not being serviced well. Think of the CSF as a series of buckets with labels. You metaphorically put all the actions, technology deployments, and processes you do in cybersecurity into these buckets, and then look for buckets with too little activity in them or have too much activity — or repetitive activity — and not enough of other requirements in them.
The CSF hierarchy is that Functions contain many Categories — or in other words, there are big buckets that contain smaller buckets.
What Is New in CSF 2.0?
The most noteworthy change is the introduction of Governance as a sixth pillar in the CSF Framework. This shift sees governance being given significantly more importance from just a mention within the previous five Categories to now being its owna separate Function.
According to NIST the Govern function refers to how an organization’s, “cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.” This is a positive and needed evolution, as when governance is weak, it often isn’t restricted to a single function (e.g. IAM) and can be systemic.
Governance aligns to a broader paradigm shift where we see cybersecurity becoming highly relevant within the business context as an operational risk. The Govern expectation is cybersecurity is integrated into the broader enterprise risk management strategy and requires dedicated accountability and oversight.
There are some other reassignments and minor changes in the remaining five Categories. CSF version 1.0 was published in 2014, and 1.1 in 2018. A lot has changed in security since then. The 2.0 update acknowledges that a review has been conducted.
As a framework, the CISO domain has not radically changed. Yes, the technology has radically evolved, but the greatest evolution in the CISO role really has been around governance: greater interaction with C-suite and board, while some activities have been handed off to operations.
So How Will This Impact Me in the Short Term?
The update to the NIST CSF provides a fresh opportunity to security leaders to start or reopen conversations with business leaders on evolving needs.
The greatest impact will be to auditors and consultants who will need to make formatting changes to their templates and work products to align with version 2.0.
CISOs and security leaders will have to make some similar changes to how they track and report compliance.
But overall, the greatest impact (aside from some extra billable cybersecurity consulting fees) will be a boost of relevance to the CSF that could attract new adherents both through security leaders choosing to look at themselves through the CSF lens and management asking the same of CISOs.
MARCH 28, 2024 15 MIN. READ WRITTEN BY Manuel Sabban
This article was originally published on 30 April 2021 in the Linux Journal.
Updated: 14 March 2024
With the launch of Security Engine 1.0.x, we enabled the Security Engine to function as an HTTP REST API, allowing it to gather signals from other Security Engines.
In this guide, I will guide you through the steps to set up the CrowdSec Security Engine across multiple servers, where one server will serve as the parent and two additional machines will forward alerts to it.
Sharing cybersecurity incidents across machines using the CrowdSec Security Engine is a highly effective strategy to enhance collective security defenses. By leveraging CrowdSec’s capability to distribute remediations among connected machines, each machine benefits from real-time updates about new threats detected elsewhere in the network.
Architecture
In the diagram above, the parent Security Engine, designated as server-1, will be set up as the HTTP REST API, commonly known as the LAPI (Local API). This engine will be in charge of storing and distributing the gathered signals. Remediation is managed through the Remediation Components, which depend on the LAPI offered by server-1. It’s crucial to understand that mitigation can occur independently from detection.
Server-2 and server-3 are designated as internet-facing machines that will host services available to the public and will be known as the child Log Processors. On these servers, we will install CrowdSec Security Engine and Remediation Components, which will interact with the server-1 LAPI.
Note: The phrase “child Log Processors” refers to a CrowdSec Security Engine that operates with its LAPI turned off. For more information on this, consult our Taxonomy Update Article.
We strongly encourage you to explore the CrowdSec Hub to learn about the extensive range of services the Security Engine can protect. This platform showcases the diverse capabilities of the Engine in securing everything from web applications to databases against cyber threats.
Architecture Decisions
I chose a postgresql backend for the server-1 LAPI to achieve greater stability in database read and write operations. Nevertheless, depending on your operational scale, you might discover that the default SQLite with WAL (Write-Ahead Logging) enabled meets your needs, if so you can skip section 1b.
Prerequisites
To follow this tutorial, you will need the following:
Two internet-facing Ubuntu 22.04 machines hosting services.
One Ubuntu 22.04 machine.
A local network connection between the Parent and Child machines.
Step 1b (Optional): Using postgresql on Parent server-1
Install the PostgreSQL package using the apt package manager.
sudo apt install postgresql
Next, transition to the postgres Linux user and then connect by executing the psql command.
sudo -i -u postgres
psql
You can set up the database and create an authorized user using the commands below. Replace with a password you select, you must keep it within the single quotes.
postgres=# CREATE DATABASE crowdsec;
CREATE DATABASE
postgres=# CREATE USER crowdsec WITH PASSWORD ‘[PASSWORD]’; CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE crowdsec TO crowdsec;
GRANT
Now, we’ll set up the Security Engine to utilize this newly created database as its backend. This requires updating the db_config section in the /etc/crowdsec/config.yaml file.
During the installation of the Security Engine, the local machine was configured to use the SQLite database. To switch to the newly set up postgres database, you will need to regenerate the credentials and then proceed to restart the Security Engine.
sudo cscli machines add -a –force
sudo systemctl restart crowdsec
Step 1c: Expose LAPI port
To enable communication between the LAPI and the child Log Processors/Remediation Components, it is necessary to adjust the LAPI’s settings to accept connections from external sources, since its default configuration binds it to the machine’s loopback address (127.0.0.1). This adjustment can be made by editing the /etc/crowdsec/config.yaml configuration file and changing the specified settings.
api:
server:
listen_uri: 10.0.0.1:8080
In the mentioned setup, we adjust the settings to listen on the 10.0.0.1 interface on port 8080. Should you wish to listen on several interfaces, you can change this to 0.0.0.0 and implement firewall rules to permit specific connections.
First, lets register the Log Processor to the LAPI server using the following command
sudo cscli lapi register -u http://10.0.0.1:8080
Ensure you adjust the -u flag to suit your network. Utilize the IP address if it’s static, or opt for the hostname if your network allows it.
Next, we’ll turn off the local API on the Security Engine, turning it into a Log Processor. This action is taken because the API won’t be utilized, which will conserve system resources and avoid occupying a TCP port unnecessarily.
To achieve this, we can disable the API in the configuration with:
api:
server:
enable: false
Step 2c: Validate the registration request on LAPI
Since we used the cscli lapi register on the child Log Processor we must validate the request on server-1 via the following commands:
sudo cscli machines list
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
NAME IP ADDRESS LAST UPDATE STATUS VERSION
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
dc6f34b3a4994700a2e333df43728701D0iARTSQ6dxiwyMR 10.0.0.1 2021-04-13T12:16:11Z ✔️ v1.0.9-4-debian-pragmatic-a8b16a66b110ebe03bb330cda2600226a3a862d7
9f3602d1c9244f02b0d6fd2e92933e75zLVg8zSRkyANxHbC 10.0.0.3 2021-04-13T12:24:12Z 🚫
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
From this output, it’s evident there’s a new machine that hasn’t been validated yet by the 🚫 within the status column. We need to manually validate this machine to ensure the LAPI recognizes which machines are authorized to transmit signals.
Note: If you don’t see a new machine marked with a 🚫 in the status column, make sure you are executing the command on the LAPI server.
Make sure to change the argument following validate to correspond with the new machine name displayed in the list output.
Step 2d: Restart the child Log Processor service
On the child Log Processor machine you can run the following command to restart the service:
sudo systemctl restart crowdsec
Then, for each machine you wish to connect, repeat step 2. In our case, we will perform this action twice, once for each Ubuntu machine.
Step 3: Setting up Remediation
Now, it’s important to configure remediation measures for your internet-facing servers since merely running the Log Processor does not implement enforcement actions. In this article, we’ll focus on setting up the Linux firewall Remediation Component. For additional remediation options, be sure to explore the extensive list available in the CrowdSec Documentation.
Step 3a: Generating API key on LAPI
First, we’ll create API token on the LAPI server by executing the following command:
sudo cscli bouncers add server-2-firewall
Api key for 'server-2-firewall':
02954e85c72cf442a4dee357f0ca5a7c
Please keep this key since you will not be able to retrieve it!
I used server-2-firewall as the name for the key, but you can choose any name you prefer. It’s crucial to select a descriptive name for the key to facilitate future management, especially if you need to revoke a key due to a token compromise.
Step 3b: Install the Remediation Component
IPtables firewall is among the most commonly used on Linux, so we’ll proceed to install the Component that interacts with it, using the apt package manager.
sudo apt install cs-firewall-bouncer-iptables
Once the Component is installed, we will edit the configuration under /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml to point towards the LAPI
Ensure you modify the api_url to align with your LAPI address and update the api_key to the one generated by the previous command. Remember, you can use either the IP address or the hostname.
Once you have altered the configuration, let’s restart the firewall Remediation Component.
sudo systemctl restart crowdsec-firewall-bouncer
Then, for each Remediation Component you wish to connect, repeat step 3. In our case, we will perform this action twice, once for each firewall on the Ubuntu machines. Make sure to alter the naming scheme of the API key.
A few closing thoughts
This guide illustrated the process for establishing a multi-server Security Engine setup. While this example utilized three servers, the architecture allows for easy expansion. The resource consumption on server-2 and server-3 remains minimal since the majority of operations are directed towards server-1, facilitating straightforward scalability of the system:
Register and validate additional Security Engines on the LAPI server
Add any additional Remediation Components
As previously stated, there’s no requirement for the Remediation Components and Security Engines to be installed on the same server. This implies that the Security Engine should be installed at the location where logs are produced, whereas the Remediation Component can be deployed at any desired location.
It’s important to note that this configuration comes with certain limitations:
The communication between Security Engines occurs via unencrypted HTTP, which is suitable for a local network but not secure for internet use. However, the CrowdSec Security Engine supports the use of HTTPS for these interactions.
This article does not delve into monitoring or alerting. Nonetheless, the Security Engine supports comprehensive monitoring capabilities via Prometheus, and you can find more detailed information about it in this article.
Having both the CrowdSec LAPI and PostgreSQL on server-1 creates a single point of failure, potentially leading to delays in threat response should any issues arise with the server.
Now you may be wondering — how do I build a highly available multi-server CrowdSec setup? We will have a dedicated article on that in the coming weeks, so stay tuned!
We are always more than happy to receive your feedback! Don’t hesitate to reach out to us on our community platforms on Discord and Discourse.
MARCH 28, 2024 10 MIN. READ WRITTEN BY Manuel Sabban
This article was originally published on 31 August 2021 in the Linux Journal.
Updated: 14 March 2024
Welcome to the second part of our tutorial on how to set up and secure a multi-server CrowdSec Security Engine installation. In the first part, I walked you through the setup of CrowdSec Security Engines across multiple servers, with one server serving as the parent and two additional machines forwarding alerts to it.
In this part, I will address security issues posed by clear HTTP communication in the previous multi-server Security Engine installation. To solve this, I propose establishing the communication between Security Engines over encrypted channels. This solution allows server-2 or server-3 to trust the server-1 identity and avoid man-in-the-middle attacks.
Using self-signed certificates
Create the certificate
First, you need to create a certificate. This can be achieved with the following one-liner.
For now, the Security Engine is not able to ask for the passphrase of the private key when starting. So, you have the choice to decipher the private key by hand each time you start or reload the Security Engine or store the key unencrypted. In any way, to strip the passphrase, you can use the following:
openssl rsa -in encrypted-key.pem -out key.pem
Then, the unencrypted key file can be safely deleted after the Security Engine is started.
Configure the Security Engine to use a self-signed certificate
On server-1 you need to configure the Security Engine to use the generated certificate. As seen below, the tls.cert_file and tls.key_file option in the api.server section of the following /etc/crowdec/config.yaml excerpt is set to the generated certificate file.
api:
server:
log_level: info
listen_uri: 10.0.0.1:8080
profiles_path: /etc/crowdsec/profiles.yaml
online_client: # Crowdsec API credentials (to push signals and receive bad
tls:
cert_file: /etc/crowdsec/ssl/cert.pem
key_file: /etc/crowdsec/ssl/key.pem
On the client side, configuration changes happen in two files. First, modify /etc/crowdec/config.yaml to accept self-signed certificates by setting the insecure_skip_verify to true.
You also need to change HTTP for HTTPS in the /etc/crowdsec/local_api_credentials.yaml file in order to reflect the changes. This small change has to be done on all three servers (server-1, server-2 andserver-3).
Note: Please keep in mind that this LAPI configuration has to be done on server-1 as well if it’s used as a log processor too.
Side note: Obviously using self-signed certificates doesn’t provide any confidence over ownership on the LAPI server. Servers using the service (server-2 or server-3 in this setup) are still vulnerable to man-in-the-middle attacks, but at least this setup provides encrypted communications. That’s the reason why the InsecureSkipVerify option is needed.
Using a Certificate Authority-issued certificate
Let’s Encrypt, or services like Amazon ACM, can be leveraged to workaround the InsecureSkipVerify, by issuing a certificate for a fully qualified domain name that can be added to /etc/hosts or to a local DNS server. /etc/crowdsec/local_api_credentials.yaml can then be filled with this specified fully qualified domain name.
This indeed works and prevents the InsecureSkipVerify option from being set. This ensures that communication between client and server can’t be tampered with as long as the DNS configuration can be trusted, but should still be considered as a workaround.
Using a PKI
The process of configuring and managing an SSL Public Key Infrastructure (PKI) falls outside the scope of this tutorial, but I highly recommend you take a look at the official OpenSSL documentation. The simple PKI scenario is enough for this Security Engine setup.
Following the OpenSSL documentation, there are a few things worth mentioning.
To be usable in our CrowdSec TLS scenario, the certificate requests have to be issued with a subject alternative name corresponding to the IP of the Crowdsec LAPI server. This can be done by positioning the SAN environment variable when invoking OpenSSL for the certificate request (see step 3.3 in the OpenSSL simple PKI scenario).
The public part of the root and the signing certificates (bundle file created at step 4.5 in the OpenSSL simple PKI scenario) have to be added to the local certificate store before starting the CrowdSec Security Engine. In this setup, this is required to connect to the LAPI server. There’re many ways to do so, golang sources specify where certificates are expected, or you can use the SSL_CERT_FILE environment variable in the systemd service file to specify where to find the certificate when launching the Security Engine.
Updated note on CrowdSec and TLS authentication
After the first publication of this article, we added a new feature to the Security Engine you are now able not only to secure communication over TLS but also ensure authentication with certificate. In the official documentation you can find a great example that shows how TLS authentication can be done using certificates between Security Engines or between Security Engine and Remediation Component.
Conclusion
This article gives some highlights on how to secure communications between different CrowdSec Security Engine installations. The considered use case is Security Engine installations in a private network, but this can also be deployed on a public network with communication over the internet. In such a case, a third-party certificate would easily do the trick.
Depending on the needs, I proposed three different ways to achieve secure TLS communications between your Security Engines — using self-signed certificates, using certificates issued by a Certificate Authority, and using an SSL Public Key Infrastructure.
The first scenario, with self-signed certificates, only applies if you want to ensure encrypted communication with no need for authentication. The second scenario proposed may only be considered as a workaround when you have the possibility to modify local DNS resolutions. The third proposed scenario is the most complicated but would fit in most use cases and may be the way to go when security concerns are high.
I hope this tutorial comes in handy. Thanks for reading and stay tuned!
If you have any questions or feedback, don’t hesitate to reach out to us on our community platforms on Discord and Discourse.
MARCH 19, 2024 10 MIN. READ WRITTEN BY Emanuel Seemann
Among the 29,000 vulnerabilities published as a CVE in 2022, CVE-2022-22954 is one of the more dangerous vulnerabilities, with a CVSS base score of 9.8. Recently there has been a significant uptick in exploitation attempts detected by the CrowdSec Network from bad actors located in China. To swiftly remediate this issue, we added the exploit as a rule for The CrowdSec AppSec Component.
This article serves as a reminder for security professionals to patch your VMware workspaces. Here I will also share some insights into the new attackers using this vulnerability.
The exploit
Since its introduction in 1999 there have been over 200,000 vulnerabilities published in the Common Vulnerabilities and Exposures (CVE) framework. As the number of vulnerabilities published each day grows, cyber security professionals are overwhelmed with figuring out whether a given vulnerability is actually at risk of being exploited. By leveraging CrowdSec’s large threat intelligence network, we know that most of these vulnerabilities very rarely lead to widespread adoption by threat actors. We suspect that this is mostly because proof-of-concept attacks are rarely published, which means that attackers don’t know a priori how difficult it will be to exploit the vulnerability in practice.
In the case of CVE-2022-22954, however, the exploit, as explained very succinctly by the Rapid7 team back in 2022, is simple and small enough to fit into a tweet. The Rapid7 team also showed that this vulnerability could be chained with other vulnerabilities of VMware products to gain a root shell for remote code execution. This showed that the exploit was both easy to use and significantly powerful in practice, which gave it a very high CVSS score.
The exploit itself is a classic case of Server-Side Template Injection (SSTI). Templating engines are systems used to insert user data into static HTML websites. For example, the web developer can write the template:
And for the user John Doe, it will then show up as:
In an SSTI, the user is able to get the server to render a user-submitted template. The templating engine used by VMware, Apache FreeMarker, allows a developer to execute system commands within the template using the freemarker.template.utility.Execute function. This function call is, therefore, often used in template injection attacks. In the specific case of CVE-2022-22954, templates could be injected into the deviceUdid parameter of the /catalog-portal/ui/oauth/verify endpoint.
To detect this, the CrowdSec Security Engine looks for calls to the utility.Execute function at this endpoint. Note that modern versions of FreeMarker allow sandboxing of the Execute function to prevent template injections from being easily exploitable.
A new surge in exploit attempts of the CVE-2022-22954
Usually, high CVSS scores cause defenders to patch their systems quickly and attacks to fall off as the attack surface rapidly decreases. This has been the case with log4shell as well. After a while, the real attacks drop away and, in turn, are replaced by a vast number of security scanners. This means that it’s not unusual to still see signals for old outdated vulnerabilities. To avoid such scanners polluting our threat intelligence, we maintain curated filters for the addresses of most scanner companies.
The following chart depicts the number of unique IPs reported for CVE-2022-22954 each day over the past 3 months:
Unique IPs Reported for CVE-2022-22954
The chart is split into two phases. A stable phase for 2 months, followed by a growth phase starting on the 19th of February 2024. The first phase is the baseline noise generated by vulnerability scanners. The second phase is the new surge in attacks. The same trend can be seen in the number of signals and the number of unique Security Engines reporting attacks.
Signals and Security Engines Reporting CVE-2022-22954
Most of the attackers participating in this new attack wave have previously not been seen by the CrowdSec network. A good 40% of them come from Chinese IP addresses. Overlap analysis also reveals that the attackers attempt multiple similar attacks. Of note here should be the http-probing scenario which detects attackers that get served a significant number of 404/403 responses in a short time span.
Combined with the fact that most of these IPs were previously unseen, we suspect that this might be an attempt to build a new botnet using very common vulnerabilities, not all of which we currently have detection scenarios for.
Scenario Overlap
We provide the following top 3 Indicators of Compromise (IoC) for this new wave of attacks:
In response to this new wave of attacks, we have added detection for this exploit to our Web Application Firewall (WAF) using a rule in the CrowdSec AppSec Component. CrowdSec WAF users are now protected against future attempts by these attackers. If you are not using the CrowdSec WAF solution yet, make sure to activate the AppSec Component in your Security Engine. You can find more information in the CrowdSec documentation.
In addition to the new AppSec Component rule, about 30% of the malicious IPs performing CVE-2022-22954 exploitation attempts are by now part of the CrowdSec Intelligence Blocklist, and considering the ramping intensity of these attackers, more will be added in the coming days.
Want to stay ahead of the curve? Proactively block these IPs and don’t take any chances with the IPs massively exploiting the CVE-2022-22954 vulnerability potentially reaching your systems.
MARCH 7, 2024 15 MIN. READ WRITTEN BY Emanuel Seemann
One of the big lessons we learned from collecting and analyzing huge amounts of data at CrowdSec is that cyberattacks are not distributed equally over the internet.
There are Autonomous Systems (AS) — think internet service providers or hosters — and IP ranges that harbor significantly more criminal activity than others. This insight prompted us to aggregate the signals we receive not only by IP address but also by IP range and Autonomous System.
In this article we provide an example of what this looks like in practice and how these new aggregations are used by us internally to improve our blocklist offerings. However, we first need to explore a crime scene to understand these insights.
Capturing petty criminals
The following table presents a sample of IPs that recently participated in http-path-traversal-probing attacks. These attacks are quite simplistic. They aim to get a web server to reveal files outside of the sitemap by trying to escape paths and walking backward along the file tree using ../.
While most modern web servers are not vulnerable to such attacks, the attackers show up directly in the log even on failed attempts which makes this a good Indicator of Compromise (IoC) for the Crowdsec Security Engine to investigate.
Now, good detectives will have already noticed something afoot here. But in case you didn’t notice, the table below draws your attention to certain IPs.
While some IPs in this table seem to come from all over the internet, the IPs highlighted all share the first 3 sections of their IP address. What this means is that these IP addresses originate from the same neighborhood or IP range of the internet. To further explore this strange coincidence, we need to learn a little bit about how the internet works.
IP ranges — The neighborhoods of the internet
At the core, an IP address is a representation of a 32-digit binary number. Wikipedia has a nice graphic to show how each of the 4 numbers of the dot-decimal notation corresponds to an 8-digit binary part of the IP address.
Usually, these IP addresses are not owned by individuals but by internet service providers and big technology companies, which then assign them to their customers and servers. To simplify the who-owns-what question, the service providers are not given lists of single IPs but so-called IP ranges.
IP ranges are blocks of consecutive IP addresses. They are specified by the number of digits of the binary address that they have in common. So, a /31 range for a given address includes all IPs that have the same 31 first bits as this address. As an IP address is only 32 bits long that means that a `/31` range contains exactly two IPs.
Generally, the lower the number on the range, the higher the number of IPs in it. At CrowdSec, we mainly consider range /24 neighborhoods, which are all the IPs that share the same 24 first bits. This is a convenient range size as it is still fairly small at 256 IPs per range, but also because the boundary falls right on one of the decimals in dot-decimal notation. So, the range 172.16.254.0/24 contains all the IPs from 172.16.254.0 to 172.16.254.256. This makes /24 an extremely useful range to look at.
Fighting organized crime
With the crash course in internet protocol and IP ranges finished, let’s turn our attention back to the matter at hand and recall the table of petty criminals seen earlier.
With your newly gained knowledge of the internet protocol, you can now identify that some of the criminals seen in the table operate from the same neighborhood of the internet.
So, it’s not difficult to realize that we might not be dealing with petty criminals who do some path traversal on the side here, but we are facing an organized crime network operating from the XXX.234.140.0/24 neighborhood of the internet.
Properly detecting such bad neighborhoods and taking the appropriate measures against these perpetrators is vital to our goal of always providing our users with blocklists that contain verified malicious IPs to help them proactively protect their systems from cyberattacks.
Block Mass Exploitation Attempts
Get immediate protection against active malicious IPs with CrowdSec’s actionable and real-time Blocklists.Get started
To generate the CrowdSec Intelligence Blocklist, we have built a fairly sophisticated system of rules that evaluate an IP on a diverse set of metrics to ultimately decide whether it gets added to the blocklist. This system is called the Expert System. The best way to understand the functionality of the Expert System is to imagine a judge ruling in a court.
Every IP is put to a trial with evidence supporting the case. The judge (Expert System) has a code of law (CrowdSec ruleset) within which it has to decide whether to convict the suspect. For validation, we have a lawmakers’ convention (internal meeting) every week where we inspect the rulings and change the laws if needed.
Staying within this law analogy, we face similar issues as real courts when fighting organized crime. Each individual IP in this range might not be criminal enough on its own to get convicted for a big sentence, but as an organization, it is clear that there is significant abuse coming from this range. Similar to real courts, we can keep playing whack-a-mole and jail abusers who cross the line for petty crimes, but to put a real dent into the criminal organization, we need a bigger mallet. In the real world, this big mallet is called the RICO Act — in the CrowdSec cybersecurity court, it is the Range Reputation System.
Introducing the IP Range Reputation System
The IP Range Reputation System is an aggregation of stats on individual IPs at the level of their /24 range. That means that for every /24 range, we track the following:
The number of IPs from this range we have seen in reports from Security Engines
The number of IPs from this range that landed in the CrowdSec Intelligence Blocklist
The average duration of any given IP remaining in our data lake
The trust score of the Security Engines reporting this IP
The behaviors identified for IPs in this range
The CrowdSec Data
Explore CrowdSec’s fail-proof approach to tactical intelligence and learn how CrowdSec guarantees unmatched data curation.Learn more
We then use this information to build an organized crime case. The case is built on two components.
Neighborhood reputation: This is based on how many other IPs have already been reported and how many of them have landed in the CrowdSec Intelligence Blocklist.
Attacker behavior: How the behavior of this specific attacker compares to the other IPs in its range. The analogy for this is that while a pickpocket and a bike thief might operate in the same neighborhood, as long as they do their separate things, there is no reason to suspect that they are part of the same organized crime unit.
These two components are then weighted, scored, and fed to the Expert System as additional evidence. If an IP is convicted of operating within a criminal network, it gets into the CrowdSec Intelligence Blocklist significantly faster, turning this simple system into an effective large mallet to bleed cybercriminals of their most valuable resource — fresh IP addresses.
The Range Reputation System we built alongside this feature powers our insights in the Majority Report and allows us to act on emerging threats with confidence even when there is little primary information to go on.
Get your hands on the IP Range Reputation feature
The IP Range Reputation feature is now available in our CTI API to help incident response teams and threat researchers gain improved visibility in low-information environments and act fast and decisively against threats, even in situations where the defenders are outnumbered.
To use the IP Range Reputation feature today, simply sign in to your CrowdSec Console account or sign up for free if you don’t have an account yet. Then navigate to the Settings page to generate a CTI API key.
Equipped with your API key, you can get started by querying the API using curl or any other tool. If you don’t have any interesting IP addresses at hand, you can always find an interesting selection under https://app.crowdsec.net/cti.
Similar to our ratings of individual IPs, the range reputation comes as both a score ranging from 0 to 5 and as a single label of either malicious, suspicious, or known. For further information on our CTI API, including exhaustive documentation and a swagger portal, check out our CTI API documentation.
The CrowdSec team is working on expanding and improving the capabilities of the IP Range Reputation feature, so stay tuned as we’ll be sharing more updates on this soon!
Running a WooCommerce store demands more than just listing your products and waiting for sales to happen. It requires a proactive approach to maintenance, optimization, and engagement to ensure that every aspect of your store functions smoothly and efficiently. From the careful crafting of product attributes to secure checkout processes, each element plays a critical role in the overall success of your online business.
With a plethora of tools at your disposal, it can be overwhelming to navigate the options and identify what will best support your store’s unique needs. As we dive into the various tools and strategies to keep your WooCommerce store running smoothly, remember that the goal is not just to maintain but to excel.
Enhancing store performance
A well-performing WooCommerce store is the cornerstone of a successful eCommerce business. As your store grows, so does the complexity of managing its performance. Here, we’ll explore key tools and practices to enhance your store’s speed, efficiency, and overall performance, ensuring a seamless experience for your customers.
Database optimization
One of the most critical yet overlooked aspects of maintaining a high-performing WooCommerce store is database optimization. Over time, your store’s database can become cluttered with old product revisions, outdated orders, and unnecessary data, leading to slower loading times and a sluggish site experience. Tools like WP-Optimize provide an easy-to-use solution for database cleanup and optimization. By regularly clearing out this digital detritus, you can ensure your store operates at peak efficiency, maintaining swift navigation and quick access to product information for your customers.
Image optimization tools
Visuals play a crucial role in eCommerce, but high-quality images often come at the cost of file size, which can significantly slow down your site. Leveraging tools to optimize WordPress images is essential for balancing quality and performance. Plugins like Smush or SEO Image Optimizer automatically optimize product images without degrading quality, ensuring your site remains fast and visually appealing. This not only enhances the user experience but also positively impacts your store’s SEO, as page load speed is a key ranking factor for search engines.
Streamlining order processing and delivery
Efficient order processing and timely delivery are pivotal in ensuring customer satisfaction and loyalty in eCommerce. This section delves into tools and plugins that can significantly streamline these aspects of your WooCommerce store, from the moment an order is placed to when it reaches the customer’s doorstep.
Automated order printing
In the bustling environment of an eCommerce business, automating mundane tasks can save valuable time and reduce the risk of errors. For WooCommerce store owners, automatically printing orders as they come in can be a game-changer, ensuring that every order is promptly prepared for shipping and enhancing operational efficiency and customer satisfaction. This automation allows store managers to focus on more strategic tasks rather than getting bogged down with manual order processing.
Delivery date plugins
Giving customers the power to choose their preferred delivery date not only enhances the shopping experience but also helps in managing logistics more effectively. Delivery date plugins for WooCommerce enable customers to select dates that work best for them at checkout. This level of customization improves the likelihood of successful first-time delivery, thereby reducing the costs and hassles associated with missed deliveries. Moreover, it allows businesses to plan their dispatch schedules better, ensuring that peak times are managed more efficiently and resources are allocated appropriately.
Boosting conversions and sales
Improving your WooCommerce store’s conversion rate can be achieved through various means, from simplifying the checkout process to using upselling and cross-selling techniques. Tools like Checkout Field Editor allow you to customize the checkout experience, removing unnecessary fields to streamline the process and make it as quick and painless as possible for customers. Additionally, integrating plugins that suggest related products or offer last-minute deals can tempt customers to add more to their carts, increasing the average order value.
An effective email marketing strategy can also boost conversions. For example, when promoting a webinar with an email sequence, crafting a well-timed sequence of emails can nurture leads and gently guide them toward registration. Starting with an announcement email, followed by reminder emails that add value and build anticipation, can increase engagement and conversion rates. Tools like Mailchimp integrate seamlessly with WooCommerce, enabling you to automate these sequences and tailor your messaging based on customer behavior and preferences, thereby enhancing the chances of conversion.
Enhancing user experience
The success of an eCommerce store largely hinges on the user experience (UX) it provides. A seamless, engaging, and intuitive UX can significantly boost customer satisfaction, repeat business, and word-of-mouth recommendations. In this section, we’ll cover tools and practices that can enhance the UX of your WooCommerce store, from collaborative content creation to managing contact form inquiries efficiently.
Content collaboration
High-quality, compelling content is crucial for attracting and retaining customers. Tools like MultiCollab offer a WordPress plugin that facilitates content collaboration directly within the Gutenberg editor, allowing teams to work together more efficiently on product descriptions, blog posts, and other content. This not only improves the quality of your store’s content but also ensures it’s consistently updated and relevant, enhancing the overall user experience by providing valuable information and engaging narratives that guide customers through your store.
Managing spam
Effective communication channels are vital for customer service and feedback, but spam can significantly hinder these processes. Implementing robust spam filters and captchas for your contact forms can streamline customer inquiries, ensuring that genuine messages are promptly addressed while keeping the nuisance of spam at bay.
Improving searchability
A critical aspect of optimizing user experience in your WooCommerce store is making it easy for customers to find exactly what they’re looking for. Clear navigation and efficient product search mechanisms can significantly reduce bounce rates and increase conversions. Carefully defined product attributes play a vital role in enhancing product discoverability. Attributes such as size, color, brand, and material not only help in organizing your inventory but also improve the shopping experience for customers. By using a plugin to implement filters based on these attributes, you enable customers to quickly narrow down their search to find their desired products effortlessly.
Security and maintenance
Maintaining the security and proper functioning of your WooCommerce store is not just about protecting your data and assets; it’s about safeguarding your customers’ trust. A secure and smoothly running store enhances user confidence and encourages repeat business. This section will cover essential practices and tools for ensuring your WooCommerce store remains secure and operates without hitches, focusing on malware removal and the importance of regular maintenance.
Malware removal tools
The threat of malware and cyber-attacks is a constant concern for online businesses. Malware can compromise customer information, disrupt transactions, and tarnish your store’s reputation. Utilizing robust malware removal tools is critical for detecting and eliminating threats before they cause harm. Plugins can provide comprehensive security solutions, offering firewall protection, malware scan, and threat removal features specifically designed for WordPress sites. Regularly scanning your WooCommerce store for vulnerabilities and ensuring all security patches are up-to-date can prevent potential breaches and keep your business and customers safe.
Regular maintenance checks
An ounce of prevention is worth a pound of cure, especially when it comes to eCommerce. Regular maintenance checks are essential for identifying and addressing issues before they escalate into serious problems. This includes updating WordPress and WooCommerce to the latest versions, ensuring all plugins are compatible and current, and checking for broken links or outdated content. Establishing a routine maintenance schedule helps in preempting issues that could disrupt your store’s operations, ensuring a smooth and reliable shopping experience for your customers.
Conclusion
Overall, the journey to a well-maintained WooCommerce store is multifaceted, involving everything from database optimization and image compression to malware protection and content collaboration. By leveraging the tools and strategies discussed, store owners can address the myriad challenges that come with running an online business.
Remember, the goal is not just to maintain your store but to continuously improve it. The eCommerce landscape is ever-evolving, and staying ahead requires an adaptable approach and a willingness to embrace new technologies and methodologies. Engaging with your customers, understanding their needs, and providing them with a seamless shopping experience will set your WooCommerce store apart in a crowded marketplace.
As you implement these tools and strategies, monitor their impact on your store’s performance and customer satisfaction closely. This data-driven approach will help you refine your tactics, ensuring your store not only runs smoothly but thrives. With dedication and the right tools at your disposal, your WooCommerce store can achieve remarkable success, grow its customer base, and secure a prominent place in the digital marketplace.
Are you concerned about the security of your WordPress website? Do you want to restrict login access to only trusted IP addresses? Whitelisting IP addresses is an effective way to enhance the security of your WordPress login page. In this article, we’ll be taking a closer look at whitelisting within Shield Security PRO, exploring its dual applications:
Whitelisting your entire site to ensure exclusive access for approved users.
Whitelisting users from Shield Security Pro’s Bad Bot detection system to ensure that specific IP addresses are recognized as legitimate, reducing false positives and preventing these users from being blocked from the site.
While shielding against bad bots protects site access for legitimate users, full-site whitelisting takes security even further. Full-site whitelisting, set up through Shield Security PRO’s full-site lockdown feature, ensures that your site won’t load at all for non-whitelisted users. This is an intense security measure that may serve a vital role for businesses with strict security and access requirements.
We’ll walk you through the pros and cons of both whitelisting approaches and how to set them up, while helping you decide whether they’re necessary and practical for your business.
Let’s get started!
Understanding full-site IP whitelisting and its importance in WordPress security
Although it is too restrictive for public-facing platforms, full-site IP whitelisting is great for contexts where stringent access control is vital. Industries like finance, government, and healthcare, dealing with Sensitive Personal Information (SPI) or Private Personal Information (PPI), benefit from this heightened security. However, these are far from the only sites that can benefit from full-site whitelisting
For instance, although an eCommerce site catering to the public will find full-site IP whitelisting impractical, it could make sense for a wholesale retailer that only works with pre-approved buyers. It can also be useful for corporate intranets, which are limited to employee access only, or websites used to manage private security systems.
The decision to implement a full-site whitelist shouldn’t be taken lightly. Site owners must carefully weigh the pros and cons and remember that the extreme nature of IP whitelisting makes it fully incompatible for general public facing businesses and platforms.
Benefits and drawbacks of full-site whitelisting in WordPress
There are many benefits and drawbacks to full-site whitelisting that users should consider before setting this up on their site. For example, some benefits include that this gives you strict access control, ensuring that only approved users can interact with the site. It’s a highly effective security measure that can easily safeguard sensitive and confidential information.
It’s a great tool for building a secure environment that provides a safe and secure place for authorised individuals to access sensitive data. It’s a good way to balance security and accessibility when working with highly sensitive information, such as for financial transactions or healthcare.
One major drawback to consider, however, is that it’s time-consuming and resource-intensive to get a full-site whitelist set up. It also needs continuous attention and maintenance. It can be inconvenient for users, since it restricts them to a specific computer and location. There are workarounds like virtual machines, but they introduce additional complexities as well.
Lastly, no single measure, even whitelisting your whole site, is a foolproof solution against cyber attacks, as it does not provide complete protection. For example, you still have basic cybersecurity measures to keep in mind, such as the risks associated with remote workers logging in on shared family devices. However, the whitelisting itself can lull users into a false sense of security, which may lead to lapses in other vital security practices.
Step-by-Step guide to implementing full-site lockdown in WordPress
Shield Security PRO provides an advanced Site Lockdown feature that transforms your website into a whitelist-only accessible domain. When activated, this setting renders your site inaccessible to everyone except those IP addresses listed on your site’s bypass/whitelist list.
🚨Warning! Before enabling this feature, it’s crucial to add your own IP address to the bypass list to prevent locking yourself out.
Understanding the Site Lockdown Feature
In Shield Security PRO, the Site Lockdown feature simplifies the process of creating a whitelist-only site. It is also a useful solution to deploy during attacks, helping to limit access t the site until the situation can be fully assessed.
Shield Security Pro streamlines the process by doing all the heavy lifting for you, leaving little room for error. To enable the Site Lockdown feature, you need to:
Access your WordPress dashboard.
Navigate to ShieldPRO from the left-hand menu.
Go to Tools → SiteLockdown.
Check the box to whitelist your own IP address, if you haven’t already done so. Do not skip this – otherwise you will be locked out of your own site.
Review and confirm you understand the warnings and risks associated with this process.
Select “Lockdown The Site”
With this setting turned on, your site will only be accessible to users you have whitelisted using Shield Security PRO IP bypass rules, referenced earlier in the article.
Although the Shield Security PRO Site Lockdown feature makes full-site whitelisting a breeze, you can alternatively restrict access to your website by supplying access rules within your .htaccess file (for Apache servers). This method is totally different from Shield Security PRO’s Lockdown capability and requires technical expertise. So, if you’re in any doubt, we recommend hiring a developer to help with the manual approach.
Here is how to manually restrict access to your WordPress site:
Use a plugin like UpdraftPlus or your hosting control panel to back up files and databases.
Accessing the .htaccess file:
Connect to the server using an FTP client (like FileZilla) or through the hosting control panel.
Navigate to the root directory (usually public_html, www, htdocs, etc.).
Modify the.htaccessfile:
Locate and download the.htaccessfile.
Open it in a text editor.
Add the following lines at the top to restrict access to specific IP addresses:
Order deny,allow Deny from all # whitelist Your First IP address Allow from xxx.xxx.xxx.xxx # whitelist Your Second IP address (if any) Allow from xxx.xxx.xxx.xxx
📝Note on code: Replace xxx.xxx.xxx.xxx with the actual IP addresses.
If you are using Apache 2.4 or newer, it’s recommended to use the new Require directive for access control, which is more flexible and straightforward.
# whitelist Your First IP address Require ip xxx.xxx.xxx.xxx # whitelist Your Second IP address Require ip xxx.xxx.xxx.xxx
📝Note on code: Replace xxx.xxx.xxx.xxx with the actual IP addresses. The Require directive is part of Apache’s authorisation features, allowing you to specify which users or systems can access your site.
Once you have done this, the changes should be saved and uploaded again to the server (replacing the old .htaccessfile).
Whitelisting IP addresses in the Shield Security PRO plugin
When using Shield Security PRO, safeguarding your website involves understanding and managing the ADE, which detects bad bot signals, defending your site from malicious entities.
However, this system, while effective, can occasionally result in false positives – legitimate users being mistakenly flagged as bots.
To prevent the accidental blocking of known users, you can whitelist IP addresses with Shield Security PRO. By adding these trusted users to the IP Bypass list, you ensure uninterrupted access while maintaining a robust defence against malicious bots. Here’s how to do this:
Identify the IP address of the user you want to whitelist. Online tools, like Shield Security PRO’s IP address finder, can help users find this information.
Go to your WordPress dashboard and select ShieldPRO from the left-hand menu to open the Shield Security PRO dashboard.
Within Shield Security Pro’s dashboard, go to IP Rules and select the gear icon in the top right-hand corner.
Choose Create new IP rule to initiate the whitelisting process.
Enter the IP address or range you want to whitelist.
Provide a clear and memorable label, such as “Whitelist”, for easy identification.
Select Add to bypass list to confirm the whitelisting.
Once an IP address is whitelisted, the ADE will bypass it completely. However, exercising caution is important as this practice may pose security risks, particularly if the whitelisted IP address becomes compromised. It’s wise to periodically review your IP whitelists and remove any entries that are no longer required.
Maintaining your whitelist: Regular reviews and updates
One of the most important things to remember is that whitelisted addresses, once approved, are never blocked, regardless of their onsite activity.
Unlike Shield’s Automatic IP Blocking system which keeps your IP rules list lean for performance purposes, there is no automated pruning of whitelisted IP addresses.
The potential risks associated with outdated whitelist entries shouldn’t be overlooked.
Unauthorised access through excessive permissions could pose significant security threats. That’s why due diligence in the form of regular security audits are crucial to ensure authorised users retain the necessary access and unauthorised entities are promptly removed.
Here is our recommended approach to whitelist maintenance:
Review: Periodically review the existing whitelist to identify any outdated or unnecessary entries. Always verify the legitimacy of each whitelisted IP address.
Periodic checks: Conduct periodic checks, aligning with your usual website security audit schedule. Ensure that the whitelist aligns with the current needs of your website.
Secure your WordPress site with Site Lockdown today
While Site Lockdown may not suit every website, it’s invaluable for security sensitive industries like finance, government, and healthcare, where stringent cybersecurity measures are vital.
IP whitelisting helps streamline access for some users, and it can be complex without a plugin to manage it for you, but Shield Security PRO simplifies the process.
This article explains about how to integrate Content Filtering Service with LDAP (With Single Sign On) by using SonicOS 7.0.1 or older.
Restricted user group on the active directory is imported to SonicWall and give restricted web access to those users in that group.
Where in the Full Access User group has full access or partial access to websites.
Resolution
Enable Content Filtering Service from Policy | Security Services | Content Filter
Navigate to Profile Objects| Content Filter and access the Profile Objects tab. Create the new Content Filter Profile and Allow/Block for each category according with your need.
Make sure to Enable HTTPS content Filtering. This option is disabled by default.
4. Create another Content Filter Profile as Restricted Access CFS Policy for Restricted User Group.Click on Add, Add a Policy for Restricted Group with most of the categories enabled (Depends on what should be Blocked)
5. Creating a Full Access CFS Policy for Full Access User Group.Add second Policy for the Full Access Group with certain category enabled or all categories enabled (Depends on what should be allowed).
Configuring LDAP on SonicWall
For more information about how to enable LDAP on Sonicwall, please reach below link.
Navigate to Users | Settings page, in the Authentication method for login drop-down list, select LDAP + Local Users and click Configure.
On the Settings tab of the LDAP Configuration window, configure the following fields.
Name or IP address: IP address of the LDAP serverPort Number: 389 (Default LDAP Port)Server timeout (seconds): 10 Seconds (Default)Overall operation timeout (minutes): 5(Default)Select Give login name/location in tree
On the Login/Bind, Give login name/loction in three. Set the admin user and password to access on your LDAP server.
On the Schema tab, configure the following fields: LDAP Schema:Microsoft Active Directory.
On the Directory tab, configure the following fields.
Primary domain:The user domain used by your LDAP implementation.
User tree for login to server:The location of where the tree is that the user specified in the settings tab.
Click Auto-configure. (This will populate the Trees containing users and Trees containing user groups fields by scanning through the directories in search of all trees that contain user objects.)
On the LDAP Test tab, Test LDAP connectivity to make sure that the communication is successful.
Importing Groups from LDAP to the SonicWall unit
Navigate to Users | Local Groups.
Click Import from LDAP
Click Configure for the Group that is imported from LDAP.
Go to CFS Policy tab , Select the appropriate CFS Policy from the drop down and Click OK.
Configuring Single Sign-On Method on SonicWall
For more information about how to enable SSO Agent and Enable SSO on Sonicwall, please reach below link.
In the Single-sign-on method , select SonicWall SSO Agent and Configure
Click Configure button. The SSO configuration page is displayed.
Under the Settings tab, Click Add button to add the IP address of the work station that has SSO agent running.
Click on the ADD button: settings window is displayed
In the HostName or IP Address field, enter the name or IP Address of the workstation on which SonicWall SSO Agent is installed
In Port Number, enter the port number of the workstation on which SonicWall SSO Agent is installed. The default port is 2258
In the Shared Key field, enter the shared key that you created or generated in the SonicWall SSO Agent. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field. Click Apply.
Once the SSO Agent is successfully added, under the Authentication Agent Settings a green light is shown for status.
Click Test tab. The Test Authentication Agent Settings page displays.
Select the Check agent connectivity radio button then click the Test button. This will test communication with the authentication agent. If the SonicWall security appliance can connect to the agent, you will see the message Agent is ready.
Select the Check user radio button, enter the IP address of a workstation in the Workstation IP address field, then click Test. This will test if the agent is property configured to identify the user logged into a workstation.
NOTE: Performing tests on this page applies any changes that have been made. TIP: If you receive the messages Agent is not responding or Configuration error, check your settings and perform these tests again.
When you are finished, click OK.
Enabling CFS for the LAN Zone and applying Imported LDAP Group
CAUTION: It is not recommended to do this change on a Production Environment because this changes are instant and can affect all the computers on the LAN. So it is best to schedule a downtime before proceeding further.
Navigate to Network | Zones, click Configure Button for LAN Zone.
Check the box Enforce Content Filtering Service, select the Default CFS Policy from the drop down.
How to TEST
Log out from the windows domain computer and log in back with a user from either the full access or restricted access groups and check whether the policy is getting enforced correctly for the user.
WRITTEN ON FEBRUARY 14, 2024 BY NOLEN JOHNSON (NPJOHNSON)
21 – Finally old enough to drink (at least in the US)!
Hey y’all! Welcome back!
We’re a bit ahead of schedule this year, we know normally you don’t expect to hear from us until April-ish.
This was largely thanks to some new faces around the scene, some old faces stepping up to the plate, and several newly appointed Project Directors!
With all that said, we have been working extremely hard since Android 14’s release last October to port our features to this new version of Android. Thanks to our hard work adapting to Google’s largely UI-based changes in Android 12/13, and Android 14’s dead-simple device bring-up requirements, we were able to rebase our changes onto Android 14 much more efficiently.
This lets us spend some much overdue time on our apps suite! Applications such as Aperture had their features and UX improved significantly, while many of our aging apps such as Jelly, Dialer, Contacts, Messaging, LatinIME (Keyboard), and Calculator got near full redesigns that bring them into the Material You era!
…and last but not least, yet another new app landed in our apps suite! Don’t get used to it though, or maybe do, we’re not sure yet.
Now, let’s remind everyone about versioning conventions – To match AOSP’s versioning conventions, and due to the fact it added no notable value to the end-user, we dropped our subversion from a branding perspective.
As Android has moved onto the quarterly maintenance release model, this release will be “LineageOS 21”, not 21.0 or 21.1 – though worry not – we are based on the latest and greatest Android 14 version, QPR1.
Additionally, to you developers out there – any repository that is not core-platform, or isn’t expected to change in quarterly maintenance releases will use branches without subversions – e.g., lineage-21 instead of lineage-21.0.
New Features!
Security patches from January 2023 to February 2024 have been merged to LineageOS 18.1 through 21.
Glimpse of Us: We now have a shining new app, Glimpse! It will become the default gallery app starting from LineageOS 21
An extensive list of applications were heavily improved or redesigned:
Aperture: A touch of Material You, new video features, and more!
Calculator: Complete Material You redesign
Contacts: Design adjustments for Material You
Dialer: Large cleanups and code updates, Material You and bugfixes
Eleven: Some Material You design updates
Jelly: Refreshed interface, Material You and per-website location permissions
LatinIME: Material You enhancements, spacebar trackpad, fixed number row
Messaging: Design adjustments for Material You
A brand new boot animation by our awesome designer Vazguard!
SeedVault and Etar have both been updated to their newest respective upstream version.
WebView has been updated to Chromium 120.0.6099.144.
We have further developed our side pop-out expanding volume panel.
Our Updater app should now install A/B updates much faster (thank Google!)
We have contributed even more changes and improvements back upstream to the FOSS Etar calendar app we integrated some time back!
We have contributed even more changes and improvements back upstream to the Seedvault backup app.
Android TV builds still ship with an ad-free Android TV launcher, unlike Google’s ad-enabled launcher – most Android TV Google Apps packages now have options to use the Google ad-enabled launcher or our ad-restricted version.
Our merge scripts have been largely overhauled, greatly simplifying the Android Security Bulletin merge process, as well as making supporting devices like Pixel devices that have full source releases much more streamlined.
Our extract utilities can now extract from OTA images and factory images directly, further simplifying monthly security updates for maintainers on devices that receive security patches regularly.
LLVM has been fully embraced, with builds now defaulting to using LLVM bin-utils and optionally, the LLVM integrated assembler. For those of you with older kernels, worry not, you can always opt-out.
A global Quick Settings light mode has been developed so that this UI element matches the device’s theme.
Our Setup Wizard has seen adaptation for Android 14, with improved styling, more seamless transitions, and significant amounts of legacy code being stripped out.
The developer-kit (e.g. Radxa 0, Banana Pi B5, ODROID C4, Jetson X1) experience has been heavily improved, with UI elements and settings that aren’t related to their more restricted hardware feature-set being hidden or tailored!
Amazing Applications!
Calculator
Our Calculator app has received a UI refresh, bringing it in sync with the rest of our app suite, as well as a few new features:
Code cleanup
Reworked UI components to look more modern
Added support for Material You
Fixed some bugs
Glimpse
We’ve been working on a new gallery app, called Glimpse, which will replace Gallery2, the AOSP default gallery app.
Thanks to developers SebaUbuntu, luca020400 and LuK1337 who started the development, together with the help of designer Vazguard.
We focused on a clean, simple and modern-looking UI, designed around Material You’s guidelines, making sure all the features that you would expect from a gallery app are there.
It’ll be available on all devices starting from LineageOS 21.
Aperture
This has been the first year for this new application and we feel it has been received well by the community. As promised, we have continued to improve it and add new features, while keeping up with Google’s changes to the CameraX library (even helping them fix some bugs found on some of our maintained devices). We’d like to also thank the community for their work on translations, especially since Aperture strings changed quite often this year.
Here’s a quick list of some of the new features and improvements since the last update:
Added a better dialog UI to ask the user for location permissions when needed
UI will now rotate to follow the device orientation
Added Material You support
Improved QR code scanner, now with support for Wi-Fi and Wi-Fi Easy Connect™ QR codes
Added support for Google Assistant voice actions
Added photo and video mirroring (flipping) options
Audio can be muted while recording a video
Better error handling, including when no camera is available
Added configurable volume button gestures
The app will now warn you if the device overheats and is now able to automatically stop recording if the device temperature is too high
Added an information chip on top of the viewfinder to show some useful information, like low battery or disabled microphone
Added some advanced video processing settings (noise reduction, sharpening, etc.)
You can now set the flash to torch mode in photo mode by long-pressing the flash button
Added support for HDR video recording
Jelly
Our browser app has received a UI refresh, bringing it in sync with the rest of our app suite, as well as a few new features:
Code cleanup
Reworked UI components to look more modern
Added support for Material You
Fixed some bugs regarding downloading files
Added Brave as a search engine and suggestions provider
Dropped Google encrypted search engine, as Google defaults to HSTS now
Baidu suggestion provider now uses HTTPS
Implemented per-website location permissions
Dialer, Messaging, and Contacts
Since AOSP abandoneddeprecated the Dialer, we have taken over the code base and did heavy cleanups, updating to newer standards (AndroidX) and redesigning:
Code cleanup
Changed to using Material You design
Proper dark and light themes
Several bugfixes, specifically with number lookups and the contact list
While Messaging was also deprecated by AOSP, at least the Contacts app was not. Nonetheless we gave both of them an overhaul and made them also follow the system colors and look more integrated.
Careful Commonization
Several of our developers have worked hard on SoC-specific common kernels to base on that can be merged on a somewhat regular basis to pull in the latest features/security patches to save maintainers additional effort.
Go check them out and consider basing your device kernels on them!
Additionally, many legacy devices require interpolating libraries that we colloquially refer to as “shims” – these have long been device and maintainer managed, but this cycle we have decided to commonize them to make the effort easier on everyone and not duplicate effort!
You can check it out here and contribute shims that you think other devices may need or add additional components to additional shims and compatibility layers provided via Gerrit!
Deprecations
Overall, we feel that the 21 branch has reached feature and stability parity with 20 and is ready for initial release.
For the first time in many cycles, all devices that shipped LineageOS 19.1 were either promoted or dropped by the maintainer by the time of this blog post, so LineageOS 19.1 was retired naturally. As such, no new device submissions targeting the 19.1 branch will be able to ship builds (you can still apply and fork your work to the organization, though!).
LineageOS 18.1 builds were still not deprecated this year, as Google’s somewhat harsh requirements of BPF support in all Android 12+ device’s kernels meant that a significant amount of our legacy devices on the build-roster would have died.
LineageOS 18.1, is still on a feature freeze, and building each device monthly, shortly after the Android Security Bulletin is merged for that month.
We will allow new LineageOS 18.1 submissions to be forked to the organization, but we no longer will allow newly submitted LineageOS 18.1 devices to ship.
LineageOS 21 will launch building for a decent selection of devices, with additional devices to come as they are marked as both Charter compliant and ready for builds by their maintainer.
Upgrading to LineageOS 21
To upgrade, please follow the upgrade guide for your device by clicking on it here and then on “Upgrade to a higher version of LineageOS”.
If you’re coming from an unofficial build, you need to follow the good ole’ install guide for your device, just like anyone else looking to install LineageOS for the first time. These can be found at the same place here by clicking on your device and then on “Installation”.
Please note that if you’re currently on an official build, you DO NOT need to wipe your device, unless your device’s wiki page specifically dictates otherwise, as is needed for some devices with massive changes, such as a repartition.
Download portal
While it has been in the making for quite a while and already released a year ago, it’s still news in regards to this blog post. Our download portal has been redesigned and also gained a few functional improvements:
Dark mode
Downloads of additional images (shown for all devices but not used on all of them, read the instructions to know which ones you need for your device’s installation!)
Verifying downloaded files (see here) – if you go with any download not obtained from us, you can still verify it was originally signed by us and thus untampered with
Wiki
The LineageOS Wiki has also been expanded throughout the year and now offers, in addition to the known and tested instructions for all supported devices, some improvements:
The device overview allows filtering for various attributes you might be interested in a device (please note: choosing a device only based on that list still does not guarantee any device support beyond the point of when you chose it)
The device overview now lists variants of a device and other known marketing names in a more visible way, also allowing for different device information and instructions per variant to be shown
The installation instructions have been paginated, giving users less chance to skip a section involuntarily
In addition to that we’d like to take this time to remind users to follow instructions on their device’s respective Wiki Page given the complexity introduced by AOSP changes like System-As-Root, A/B Partition Scheme, Dynamic Partitions, and most recently Virtual A/B found on the Pixel 5 and other devices launching with Android 11, the instructions many of you are used to following from memory are either no longer valid or are missing very critical steps. As of 16.0, maintainers have been expected to run through the full instructions and verify they work on their devices. The LineageOS Wiki was recently further extended, and maintainers were given significantly more options to customize their device’s specific installation, update, and upgrade instructions.
Developers, Developers, Developers
Or, in this case, maintainers, maintainers, maintainers. We want your device submissions!
If you’re a developer and would like to submit your device for officials, it’s easier than ever. Just follow the instructions here.
The above also applies to people looking to bring back devices that were at one point official but are no longer supported – seriously – even if it’s not yet completely compliant, submit it! Maybe we can help you complete it.
After you submit, within generally a few weeks, but in most cases a week, you’ll receive some feedback on your device submission; and if it’s up to par, you’ll be invited to our communications instances and your device will be forked to LineageOS’s official repositories.
Don’t have the knowledge to maintain a device, but want to contribute to the platform? We have lots of other things you can contribute to. For instance, our apps suite is always looking for new people to help improve them, or you can contribute to the wiki by adding more useful information & documentation. Gerrit is always open for submissions! Once you’ve contributed a few things, send an email to devrel(at)lineageos.org detailing them, and we’ll get you in the loop.
Also, if you sent a submission via Gmail over the last few months, due to infrastructural issues, some of them didn’t make it to us, so please resend them!
Generic Targets
We’ve talked about these before, but these are important, so we will cover them again.
Though we’ve had buildable generic targets since 2019, to make LineageOS more accessible to developers, and really anyone interested in giving LineageOS a try, we’ve documented how to use them in conjunction with the Android Emulator/Android Studio!
Additionally, similar targets can now be used to build GSI in mobile, Android TV configurations, and Android Automotive (we’ll talk more about this later) making LineageOS more accessible than ever to devices using Google’s Project Treble. We won’t be providing official builds for these targets, due to the fact the user experience varies entirely based on how well the device manufacturer complied with Treble’s requirements, but feel free to go build them yourself and give it a shot!
Please note that Android 12 (and by proxy Android 13/14) diverged GSI and Emulator targets. Emulator targets reside in lineage_sdk_$arch, while GSI targets reside in lineage_gsi_$arch.
Translations
Bilingual? Trilingual? Anything-lingual?
If you think you can help translate LineageOS to a different language, jump over to our wiki and have a go! If your language is not supported natively in Android, reach out to us on Crowdin and we’ll take the necessary steps to include your language. For instance, LineageOS is the first Android custom distribution that has complete support for the Welsh (Cymraeg) language thanks to its community of translators.
Please, contribute to translations only if you are reasonably literate in the target language; poor translations waste both our time and yours.
On the Settings tab of the LDAP Configuration window, configure the following fields. 
NOTE: Performing tests on this page applies any changes that have been made.
CAUTION: It is not recommended to do this change on a Production Environment because this changes are instant and can affect all the computers on the LAN. So it is best to schedule a downtime before proceeding further.
