SaaS vs PaaS vs IaaS: What’s the Difference & How to Choose

Companies are increasingly using Cloud services to support their business processes. But which types of Cloud services are there, and what is the difference? Which kind of Cloud service is most suitable for you? Do you want to be unburdened or completely in control? Do you opt for maximum cost savings, or do you want the entire arsenal of possibilities and top performance? Can you still see the forest for the trees? In this article and in the next, I describe several different Cloud services, what the differences and features are and what exactly you need to pay attention to.

Let’s start with the definition of Cloud computing. This is the provision of services using the internet (Cloud). Think of storage, software, servers, databases etc. Depending on the type of service and the service that is offered (think of license management or data storage), you can divide these services into categories. Examples are IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service), etc. These services are provided by a cloud provider. Whether this is Microsoft (Azure), Amazon (AWS), or another vendor (Google, Alibaba, Oracle, etc.), each vendor offers Cloud services that fall under one of the categories of Cloud services that we are about to discuss.

One feature of Cloud computing is that you pay according to the usage and the service you purchase. For example, for SaaS, you pay for the software’s license and support. This also means that if you buy a SaaS service (e.g., Office 365) and don’t use it, you will still be charged. At the same time, if you purchase storage with IaaS, for example, you only pay for the amount of storage you use, possibly supplemented with additional services such as backup, etc.

Sometimes Cloud services complement each other; think, for example, of DaaS (Database as a Service), where a database is offered via the Cloud. Often you need an application server and other infrastructure to read data from this database. These usually run in a Landing Zone, purchased from an IaaS service. But some services can also be standalone, for example, SaaS (Office 365).

Each Cloud service has specific characteristics. Sometimes it requires little or no (technical) knowledge, but it can also be challenging to manage and use the services according to best practices. This often depends on the degree to which you want to see yourself in control. If you want an application from the Cloud where you are completely relieved of all worries, this requires little technical knowledge from the user or the administrator. But if you want maximum control, then IaaS gives you an enormous range of possibilities. In this article, you can read what you need to consider.

It is advisable to think beforehand about what your requirements and wishes are precisely and whether this fits in with the service you want to purchase. If you wish to use an application in the Cloud but use many custom settings, this is often not possible. If you don’t want to be responsible for updating and backing up an application and use little or no customization, a SaaS can be very interesting. Also, look at how a service fits into your business process. Does it offer possibilities for automation, reporting, or disaster recovery? Are there possibilities to temporarily allocate extra resources in case of peak demand (horizontal or vertical scaling up), and what guarantees does the supplier offer with this service? Think of RPO / RTO and accessibility of the service desk in case of a calamity.

Let’s get started quickly!

IaaS (Infrastructure as a Service)

One of the best-known Cloud services is undoubtedly IaaS. For many companies, this is often their first introduction to a Cloud service. You rent the infrastructure from a cloud provider. For example, the network infrastructure, virtual servers (including operations system), and storage. A feature of IaaS is that you have complete control – Both on the management side and how you can deploy resources (requests). This can be done in various automated ways (Powershell, IaC, DevOps pipelines, etc.) and via the classic management interface that all providers offer. Things that are often not possible with a PaaS service are possible with an IaaS service. You have complete control. In principle, you can set up a complete server environment (all services are available for this), but you do have the benefits of the Cloud, such as scalability and pay per use or per resource.

IaaS therefore, most resembles an on-premise implementation. You often see this used in combination with the use of virtual servers. Critical here is a good investigation into the possible limitations, for example, I/O, so that the performance can be different in practice than in a traditional local environment. You are responsible for arranging security and backup. The advantage is that you have an influence on the choice of technology used. You can customize the setup according to your needs and wishes. You can standardize the configuration to your organization. Deployment can be complex, and you are forced to make your own choices, so some expertise is needed.

PaaS (Platform as a Service)

PaaS stands for Platform as a service and goes further than IaaS. You get a platform where you can do the configuration yourself. When you use a PaaS service, the vendor takes care of the sub-layer (IaaS) and the operating system and middleware. So you sacrifice something in terms of control and capabilities. PaaS services are ideal for developers, web and application builders. After all, you can quickly make an environment available. Using it means you no longer have to worry about the infrastructure, operating system, and middleware. This is taken care of by the supplier based on best practices. This also offers security advantages, as you do not have to think about patching and upgrading these things that are now done by the vendor.

Another advantage is that you can entirely focus on what you want to do and not on managing the environment. You can also easily purchase additional services and quickly scale them up or down. When you are finished, you can remove and stop the resources, so you have no more costs.

However, do take into account the use of existing software. Not all existing software is suitable to function in a PaaS environment; for example, in a PaaS environment, you do not have full access (after all, the vendor is responsible). Also, not all CPU power and memory are allocated to the Cloud application. This is because it is often hosted on a shared platform, so other applications (and databases) may use the same resources. As for the database, you have the same advantages and disadvantages as with DBaaS.

SaaS (Software as a Service)

This is probably a service you’ve been using for a while. In short, you take applications through the Cloud on a subscription basis. The provider is responsible for managing the infrastructure, patches, and updates. A SaaS solution is ready for use immediately, and you directly benefit from the added value, such as fast scaling up and down and paying per use. Examples are Office365, Sharepoint online, SalesForce, Exact Online, Dropbox, etc.

Unlike IaaS and PaaS, where there is still a lot of freedom, and you have to set everything up yourself, with SaaS however, it is immediately clear what you are buying and what you will get. With this service, you are relieved of most of your worries. The vendor is responsible for all updates, patches, development, and more. You cannot make any updates or changes to the software with this service.

Many companies use one or more SaaS services often even within companies, there is a distinction. For example, each department within a company has its specific applications and associated SaaS services. With this service, you only pay for what you need, including the licenses. These licenses can easily be scaled up or down.

It is interesting for many companies to work with SAAS solutions. It is particularly interesting for start-ups, small companies and freelancers because you only purchase what you use, you don’t have unnecessarily high start-up costs, and you don’t have to worry about the maintenance of the software.

But SAAS can also be a perfect solution for larger companies. For example, if you hire extra staff for specific periods, you can quickly get these people working with the software they need. You buy several additional licenses, and you can stop this when the temporary staff leaves.

How can Vembu help you?

BDRSuite, is a comprehensive Backup & DR solution designed to protect your business-critical data across Virtual (VMware, Hyper-V), Physical Servers (Windows, Linux), SaaS (Microsoft 365, Google Workspace), AWS EC2 Instances, Endpoints (Windows, Mac) and Applications & Databases (MS Active Directory, MS Exchange, MS Outlook, SharePoint, MS SQL, MySQL).

To protect your workloads running on SaaS (Microsoft 365Google Workspace), try out a full-featured 30-days Free Trial of the latest version of BDRSuite.

Source :
https://www.vembu.com/blog/saas-vs-paas-vs-iaas-whats-the-difference-how-to-choose/

Differences between availability modes for an Always On availability group

Applies to:  SQL Server (all supported versions)

In Always On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary’s session-timeout period).

 Note

If primary’s session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Supported Availability Modes

Always On availability groups supports three availability modes-asynchronous-commit mode, synchronous-commit mode, and configuration only mode as follows:

  • Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.For more information, see Asynchronous-Commit Availability Mode, later in this topic.
  • Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.For more information, see Synchronous-Commit Availability Mode, later in this topic.
  • Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. A replica in configuration only mode does not contain user data. In configuration only mode, the replica master database stores availability group configuration metadata. For more information see Availability group with configuration only replica.

The following illustration shows an availability group with five availability replicas. The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

Availability and failover modes of replicas

The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

Current Primary ReplicaAutomatic Failover TargetsSynchronous-Commit Mode Behavior WithAsynchronous-Commit Mode Behavior WithAutomatic failover possible
010202 and 0304Yes
020101 and 0304Yes
0301 and 0204No
0401, 02, and 03No

Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability Mode

Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in situations where performance is more important than synchronized data protection. Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. The failover target transitions to the primary role, and its copies of the databases become the primary database. Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. This means that some or all of the new primary databases might be lacking recently committed transactions. For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability Mode

Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. The secondary database remains SYNCHRONIZED as long as data synchronization continues. This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

In This Section:

Factors That Disrupt Data Synchronization

Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. The synchronized secondary replica will remain healthy unless one of the following occurs:

  • A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout. NoteFor information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).
  • You suspend a secondary database on the secondary replica. The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. The secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.
  • You add a primary database the availability group. Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.
  • You change the primary replica or the secondary replica to asynchronous-commit availability mode. After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.
  • You change any secondary replica to synchronous-commit availability mode. This causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state until all of its databases are in the SYNCHRONIZED synchronization state.

 Tip

To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_statessys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

How Synchronization Works on a Secondary Replica

Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

Synchronous operation is maintained in the following manner:

  1. On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.
  2. Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. The primary replica waits for confirmation from the synchronous-commit secondary replica.
  3. The secondary replica hardens the log and returns an acknowledgement to the primary replica.
  4. On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client. NoteIf a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

Synchronous-Commit Mode with Only Manual Failover

When these replicas are connected and the database is synchronized, manual failover is supported. If the secondary replica goes down, the primary replica is unaffected. The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). For more information, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Mode with Automatic Failover

Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. You can have up to three automatic failover replicas.

Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. If the primary replica becomes unavailable under these conditions, automatic failover occurs. The secondary replica switches to the role of primary, and it offers its database as the primary database. For more information, see the “Automatic Failover ” section of the Failover and Failover Modes (Always On Availability Groups) topic.

 Note

For information about WSFC quorum and Always On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Data latency on secondary replica

Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

The primary replica sends log records of changes on primary database to the secondary replicas. On each secondary database, a dedicated redo thread applies the log records. On a read-access secondary database, a given data change does not appear in query results until the log record that contains the change has been applied to the secondary database and the transaction has been committed on primary database.

This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. In unusual cases, however, for example if network issues reduce throughput, latency can become significant. Latency increases when I/O bottlenecks occur and when data movement is suspended. To monitor suspended data movement, you can use the Always On Dashboard or the sys.dm_hadr_database_replica_states dynamic management view.

For more information on investigating redo latency on the secondary replica, please see Troubleshoot primary changes not reflected on secondary replica.

Related Tasks

To change the availability mode and failover mode

To adjust quorum votes

To perform a manual failover

To view availability group, availability replica, and database states

Related Content

See Also

Overview of Always On Availability Groups (SQL Server)
Failover and Failover Modes (Always On Availability Groups)
Windows Server Failover Clustering (WSFC) with SQL Server

Source :
https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver16

PSA: Zero-Day Vulnerability in WPGateway Actively Exploited in the Wild

On September 8, 2022, the Wordfence Threat Intelligence team became aware of an actively exploited zero-day vulnerability being used to add a malicious administrator user to sites running the WPGateway plugin. We released a firewall rule to Wordfence PremiumWordfence Care, and Wordfence Response customers to block the exploit on the same day, September 8, 2022.

Sites still running the free version of Wordfence will receive the same protection 30 days later, on October 8, 2022. The Wordfence firewall has successfully blocked over 4.6 million attacks targeting this vulnerability against more than 280,000 sites in the past 30 days.

Vulnerability Details

Description: Unauthenticated Privilege Escalation
Affected Plugin: WPGateway
Plugin Slug: wpgateway
Plugin Developer: Jack Hopman/WPGateway
Affected Versions: <= 3.5
CVE ID: CVE-2022-3180
CVSS Score: 9.8 (Critical)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: N/A

The WPGateway plugin is a premium plugin tied to the WPGateway cloud service, which offers its users a way to setup and manage WordPress sites from a single dashboard. Part of the plugin functionality exposes a vulnerability that allows unauthenticated attackers to insert a malicious administrator.

We obtained a current copy of the plugin on September 9, 2022, and determined that it is vulnerable, at which time we contacted the plugin vendor with our initial disclosure. We have reserved vulnerability identifier CVE-2022-3180 for this issue.

As this is an actively exploited zero-day vulnerability, and attackers are already aware of the mechanism required to exploit it, we are releasing this public service announcement (PSA) to all of our users. We are intentionally withholding certain details to prevent further exploitation. As a reminder, an attacker with administrator privileges has effectively achieved a complete site takeover.

Indicators of compromise

If you are working to determine whether a site has been compromised using this vulnerability, the most common indicator of compromise is a malicious administrator with the username of rangex.

If you see this user added to your dashboard, it means that your site has been compromised.

Additionally, you can check your site’s access logs for requests to //wp-content/plugins/wpgateway/wpgateway-webservice-new.php?wp_new_credentials=1

If these requests are present in your logs, they indicate that your site has been attacked using an exploit targeting this vulnerability, but do not necessarily indicate that it has been successfully compromised.

Conclusion

In today’s post, we detailed a zero-day vulnerability being actively exploited in the WPGateway plugin.

Wordfence PremiumWordfence Care, and Wordfence Response customers received a firewall rule on September 8, 2022, protecting against this vulnerability, while sites still using the free version of Wordfence will receive the same protection 30 days later, on October 8, 2022.

If you have the WPGateway plugin installed, we urge you to remove it immediately until a patch is made available and to check for malicious administrator users in your WordPress dashboard.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that is actively being exploited in the wild. Please help make the WordPress community aware of this issue.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

Our investigation is ongoing, and we will provide more information in an additional blog post when it becomes available.

Special thanks to Threat Intelligence Lead Chloe Chamberland for spotting this exploit in the wild.

Source :
https://www.wordfence.com/blog/2022/09/psa-zero-day-vulnerability-in-wpgateway-actively-exploited-in-the-wild/

WP Shield Security PRO – Release 16.1

It’s been a few months in the making, but it’s finally here – our most exciting release (yet again!) of Shield Security for WordPress.

This release is absolutely packed with goodies and our headline feature – integration with CrowdSec – deserves an article all to itself.

Here you’ll discover all the exciting things we’ve packed into ShieldPRO v16 and why you should be upgrading as soon as it’s out.

Let’s dig into all the new goodies…

#1 Partnership with CrowdSec for Crowd-Sourced IP Intelligence

This is, to our mind, one of the most exciting developments for WordPress security for a very long time.

We’ve wanted to achieve this level of protection against bots for years, as we firmly believe that good WordPress security starts with intelligent blocking malicious IP addresses.

Shield does an effective job of this already with its automatic block list system, but we’ve now achieved group intelligence so all WordPress sites running on Shield will benefit from the experiences of all the other websites running Shield.

This is a big topic so we’ve dedicated a whole article to it – learn about the new partnership here.

#2 Brand New IP Rules and Blocking Engine

IP Blocking has been a part of ShieldPRO, practically from the outset. It’s core to our WordPress security philosophy.

With such a long-standing feature, you can imagine that the knowledge and experience used to create that original system isn’t as thorough as it is today. We’ve come a long way, I can promise you.

This release, spurred on by the new CrowdSec integration, sees the much-needed overhaul of our IP management system. It’s smarter and more versatile, and altogether much faster!

Shield must lookup a visitor’s IP address on every single request to a WordPress site. If we can improve the speed of that lookup, we improve Shield performance overall.

#3 Improved UI

Shield has a number of different subsystems, many of which are related. The scan results page is linked to the scanner configuration page, for example.

To-date when you wanted to view any section of the plugin, it would reload the entire page. We’ve done some work to reduce full page reloads so that you can stay “where you are” while viewing the contents of another page.

In particular we’re referring to “Configuration” pages. Links to such areas will now open in an overlay, letting you keep your current page active while you review and adjust settings.

Another UI enhancement is a new title bar across every page of the plugin, letting you see more clearly where you are, along with important links to help resources.

This title bar also includes our brand new “super search box”…

#4 Shield’s Super Search Box

We mentioned UI improvements already, but this deserves a section all to itself.

To say Shield is a large plugin is understating it. There are many options pages, as well tools, tables, data, and charts etc.

Finding your way around can be a bit tricky. Since we built it, we know it inside out. But for everyone that uses it as a tool to protect their sites, it’s not always obvious where to go to find the “thing” you need.

No longer!

With Shield’s “Super Search Box”, you can find almost anything you need, and jump directly to it. Currently you can search for:

  • Specific configuration options
  • Tools such as Import/Export, Admin Notes, Debug
  • Logs such as Activity Logs and Traffic Logs
  • IP Rules
  • IP addresses – it’ll open a popup to review the data Shield holds on any particular IP
  • External links such as Shield’s homepage, Facebook page, helpdesk, crowdsec etc.

We’ll develop this a bit more over time as we get feedback from you on what you’d like to see in there.

#5 Lighter, Faster Scan Results Display

Shield’s scans can turn up a lot of results and some customers have reported trouble on some servers with limited resources.

We’ve redesigned how the scan results are built, so it’s faster and lighter on both your browser and the WordPress server.

#6 Improved Human SPAM Detection

After working with a customer on some issues she faced with Human SPAM, we’ve developed enhancements to how Shield will detect repeated human spam comments.

For example, a SPAMer may post a comment and trigger our human SPAM scanner. But then they’ll fire off more comments which might bypass the same scanner. We’ll now use previous SPAM detections by Shield to inform future comments, too.

We also squashed a bug where Shield wasn’t properly honouring the “disallowed keywords” option built into WordPress itself.

#7 Custom Activity Logs and Events

Shield covers a lot of areas when it comes to monitoring events that happen on a WordPress site. But we typically don’t cover 3rd party plugins.

So, based on the feedback from a number of interested customers, we’ve added the ability for any PHP developer to add custom events to Shield’s Activity Logs.

When might you find that useful?

You could, for example, track WooCommerce orders, or you could be facing a particularly menacing visitor that repeats an undesireable action on your site that’s not covered by Shield, and decide to block their IP.

You can do whatever you want with this, though you should always take care when allocating offenses to actions as you may inadvertently block legitimate users.

#8 All-New Guided Setup Wizard

When first installing a platform like Shield Security for WordPress, it can be a little overwhelming. Shield is a large plugin, with many features, tools and options.

We’ve had a “Welcome Wizard” in Shield for a while, but it was a little rough around the edges. For this release we decided to revamp it and provide a new guided setup wizard, helping newcomers get up-to-speed more quickly.

Anyone can access the Guided Setup from the Super Search Box (search: “Wizard”), or from the Shield > Tools menu.

A Change To Minimum Supported WordPress Version

We try to make Shield Security as backward-compatible as possible, while it makes sense to do so.

However, this means that our code development and testing must reflect this and means that the burden of support increases the farther back we support older versions.

Our Telemetry data suggests that there are no WordPress sites below version 4.7 running the Shield plugin. Of course, we can only go on what data has been sent to us. But we have to draw the line somewhere, and with Shield v16, we’re drawing the line at WordPress 4.7.

As more data comes through and time marches on, we’ll gradually increase our minimum requirements so we strongly suggest you keep your WordPress sites, and hosting platforms as up-to-date as possible.

Comments, Feedback and Suggestions

A lot of work has gone into this release that will, we hope, improve security for all users by making it much easier to see what’s going on and what areas need improved. The Security Rules Engine is one of our most exciting developments to-date and we can hardly wait to get the first iteration into your hands and start further development on it.

As always, we welcome your thoughts and feedback so please do feel free to leave your comments and suggestions below.

Source :
https://getshieldsecurity.com/blog/wp-shield-security-pro-release-16-1/

ShieldPRO 16.1.0 Upgrade Guide

ShieldPRO 16.1.0 for WordPress is a major release packed with many changes and improvements, including UI enhancement, adding integration with CrowdSec and the ability to permanently block IP any much more.

This guide outlines what have been added/removed, changed, or improved and what fixes we’ve made.

Firstly, we’re going to explain what major changes are made and which options you’d need to review.

New Added Features

For 16.1.0 release we added

With the CrowdSec integration, your WordPress sites will have access to intelligence about malicious IP addresses before they’ve ever accessed your website. (This intelligence will have already been gathered for you by other websites.)

This reduces that “window” available to malicious bots to zero.

The settings can be found under the IP Blocking section:

There are 2 options available

  1. CrowdSec IP Blocking – how Shield should block requests from IP addresses found on CrowdSec’s list of malicious IP addresses.
  2. CrowdSec Enroll ID – link site to your CrowdSec console by providing your Enroll ID.

There is now the option to log custom events to Shield’s Activity Log. It’s impossible that Shield can log every possibly event for every plugin and scenario, so you can now add logging for all your desired site events. This is an advanced option and will require professional software development experience to implement. 

  • Logging: App Password Creation

Shield now captures creation of new Application Passwords in the Activity Log.

  • Shield’s Super Search Box

This search box will look for almost anything you need and provide you with links directly to the item in question. 

Currently you can search for:

  • Specific configuration options
  • Tools such as Import/Export, Admin Notes, Debug
  • Logs such as Activity Logs and Traffic Logs
  • IP Rules
  • IP addresses – it’ll open a popup in-situ to review the data Shield holds on any particular IP
  • External links such as Shield’s homepage, Facebook page, helpdesk, CrowdSec etc.

The Super Search Box is accessible and visible from every page inside the plugin.

Enabling the Shield Beta Access option allows you to gain access to beta versions of the Shield Security plugin.

  • All-New Guided Setup Wizard

For this release we revamped it and provide a new guided setup wizard, helping newcomers get up-to-speed more quickly.

You can access the Guided Setup from the Super Search Box (search: “Wizard”), or from the Shield > Tools menu.

For whitelisted IP addresses, there are no restrictions for the user related with that IP whatsoever –  none of the setting will apply to that IP, including the hiding login URL. 

We added a special notice for a user with a whitelisted IP:

Changes

Change 1: Improved UI

We’ve done some work to reduce full page reloads so that you can stay “where you are” while viewing the contents of another page.

In particular we’re referring to “Options/Configuration” pages. Links to such areas will now open in an overlay, letting you keep your current page active while you review and adjust settings.

Example

Also, IP analysis dialog now opens in an overlay, for example:

Another UI enhancement is a new top title bar across every page of the plugin, letting you see more clearly where you are and with some important links to help and other resources.

Example

Change 2: Completely New IP Rules and Blocking Engine

This release, spurred on by our CrowdSec integration, sees the much-needed overhaul of our IP management system. It’s smarter and more versatile and altogether much faster.

We also made some UI enhancements on the Management & Analysis section:

  • “Manage IP” section is renamed to “IP Rules”
  • IP blocking and bypass list are merged and a new table is used now
  • IP Analysis dialog is now separated and can be loaded for each IP directly from within IP Rules, Activity Log, and Traffic Log. Example, loading from within IP Rules:

  • “Reset” option added into the IP analysis dialog

  • Manual adding IP to the block or bypass list is merged now and can be accessed from within “Add New IP” option:
  • Manually or auto blocked IP can be now permanently blocked

    You can do this by manually adding IP to the block list or directly from within IP analysis dialog

Change 3: Improved Build Custom Charts option

The Shield event(s) are now displayed in a form of list. Selecting desired events is much easier now.



Improvements

For 16.1.0 release we’ve made the following improvements

  • Improved and Faster Scan Results Display

    We’ve redesigned how the scan results are built so it’s faster and lighter on your browser and on the server itself.

    Eliminated errors and slow processing when displaying scan results pages for large datasets. Shield now uses highly optimised queries to request only the records required to display the current table page.
  • Improved Human SPAM Detection
    We’ve added some enhancements on how Shield will detect repeated human spam comments.

    We also squashed a bug where Shield wasn’t properly honouring the “disallowed keywords” option built into WordPress itself.
  • A change to minimum supported WordPress version: 4.7
    Based on Shield telemetry data, we’re pushing our minimum supported WordPress version up to 4.7. We’ll continue to push this upwards as usage data suggests it make sense to do so.
  • Protection Against Unauthorised Deactivation
    The Security Admin feature that protects against unauthorised deactivation has been further strengthened with offenses.
  • Shield Navigation Bar
    Shield offer a much better navbar on the dashboard with built-in search, helpdesk links and updates.

Removed Options

For 16.1.0 release we removed the following options

  • Auto Block Expiration (under Config > IP Blocking section) we removed “1 minute” option.
  • Leading Schema Firewall Rule
    This rules flags too many false positives for members.

Fixes

For 16.1.0 release we’ve made various fixes

  • Mitigate a fatal error caused by the latest wpForo plugin passing NULL to locale filters.
  • Bug when specifying a particular list when adding/removing an IP address using WP-CLI.
  • Shield no longer attempts to solve the issue of invalid ‘from’ email addresses on a WordPress site.

For more information on Shield 16.1.0 release, read this blog article here.

Source :
https://help.getshieldsecurity.com/article/476-shieldpro-1610-upgrade-guide

How to set up the Surveillance Station of QNAP NAS?

Introduction

To satisfy the increasing demand for embedded network surveillance solutions on NAS, QNAP unveiled a value-added application ‘Surveillance Station’ on its All-in-One Turbo NAS Series. The Surveillance Station enables users to configure and connect many IP cameras at the same time and manage functions including live audio & video monitoring, recording, and playback. Installation and configuration can be easily carried out remotely in a web browser in a few steps. Various recording modes are provided: continuous recording, motion-detection recording, and scheduled recording. Users can flexibly define the recording settings according their security plans.
The Surveillance Station supports a large number of IP camera brands. You can find a list of supported cameras at: https://www.qnap.com/compatibility.

Contents

  • Plan your home/office network topology
  • Set up the IP Cameras
  • Configure the Surveillance Station on the QNAP NAS
  • Configure Alarm Recording on the QNAP NAS
  • Play Video Files from the Surveillance Station

Plan Your Home/Office Network Topology

Write down your plan of the home/office network before starting to set up the surveillance system. Consider the following when doing so:

  • The IP address of the NAS
  • The IP address of the cameras
  • The IP address of your router and the wireless SSID

Your computer, the NAS, and the IP cameras should be installed to the same router in LAN. Assign fixed IP addresses for the NAS and the IP cameras.
For example:

  • The LAN IP of the router: 192.168.1.100
  • Camera 1 IP: 192.168.1.10 (fixed IP)
  • Camera 2 IP: 192.168.1.20 (fixed IP)
  • NAS IP: 192.168.1.60 (fixed IP)

Set up the IP Cameras

Configure the IP address for both IP cameras using the following steps.
You can download a camera IP Finder from official website of your camera’s vendor.
The name of the IP finder may differ between vendors. IP Finder is a utility that helps you search for the IP address of the camera.
CONNECT the IP camera to your home/office network with a network cable and run the IP Finder. Set the IP address of the cameras so that they are on the same LAN as the computer. You will then be able to login to the configuration page of the camera with a web browser. Enter the IP address of the first camera as 192.168.1.10. The default gateway should be set as the LAN IP of the router (192.168.1.100 in our example).

Note: The default IP and ID of administrator may differ based on what camera model is used.

ENTER the web configuration page of the IP camera.
You will then be able to view the monitoring image.

GO to ‘Network/ Network’ and check the IP settings of the camera.

NEXT, if you are using a Wireless IP CAM, please go to “Network/Wireless” and configure the wireless setting of your camera. Please ensure the camera’s settings are completed.

Repeat the above steps to set up the second camera.
To summarize, so far you have finished the following settings:

  • Camera 1 IP: 192.168.1.10
  • Camera 2 IP: 192.168.1.20

Note:
If you forget the camera settings, please press the reset button at the back of the camera for 5-10 seconds. The camera will be restored to default settings. You can then set the IP address and login to the camera’s configuration page with using the default login name and password. The reset function may differ by the brand of the camera. Please refer to the camera’s user manual in advance.

Configure the Surveillance Station on the QNAP NAS

Go to “Control Panel” > “System Settings” >”Network” > “TCP/IP” and press the “Edit” button to specify a fixed IP to the NAS: 192.168.1.60. The default gateway should be the same as the LAN IP of your router, which is 192.168.1.100 in our example.

Install Surveillance Station

  • Auto installation: Go to “App Center” > “Surveillance” > “Surveillance Station” and click “Add to QTS” to start installation.
  • Manual installation: Download the Surveillance Station QPKG from the App Center on the QNAP website. Then you can install it by clicking the “Install Manually” button and by selecting the location of the Surveillance Station QPKG to start installing.

Please note: To ensure proper operations of Surveillance Station, we recommend rebooting the Turbo NAS after its installation is completed.

In the Surveillance Station, please go to “Settings” and select “Camera 1” then click “” to add the camera configuration, e.g. name, model, IP address, recording setting and recording schedule.

In our demonstration we will assign the following IPs to each camera:
Camera 1 IP: 192.168.1.10
Camera 2 IP: 192.168.1.20

Note:
Before applying the settings, you may click “Test” on the right to ensure the connection to the IP camera is successful.

You can enable or change the recording option of the camera in next page. Click “next” to move to the next page.

On this page, you will see the “Schedule Settings.” In the table, 0~23 represents the time period. For example, 0 means 00:00~01:00, 1 means 01:00~02:00. You can set a continuous recording in any period that you want.

Then you will see the “Confirm Settings” on the next page.

After you have added the network cameras to the NAS, go to the “Monitor” page. The first time you access this page by browser, you have to install the ActiveX control (QMon.cab) in order to view the images of Camera 1 and Camera 2.

Note:
You can use the Surveillance Station in Chrome, Firefox or IE. The browser will prompt you to install the “ActiveX control” (QMon.cab) before using Monitor or Playback functions. Please follow the on-screen instructions to complete the installation.

Note:
When you click on the monitoring screen of a camera, the frame will become orange. You can use the s configuration page.
In Surveillance Station 5, there is a new feature called “Instant Playback”. You can click the floating button to play recording and find recent event.

Configure Alarm Recording on the QNAP NAS

The Surveillance Station supports alarm recording by schedule. To use this function, go to “Camera Settings” > “Alarm Settings” in the Surveillance Station. You could select ‘Traditional Mode’ to do basic configurations or ‘Advanced Mode’ to define advanced alarm events.

  • Traditional Mode :
    You may define criteria enabling alarm recording then click ‘Apply’ to save the changes.
  • Advanced Mode :
    You may select the event on the left side and add an action on the right side by clicking “Add”.

Then you may choose the action type you need for this event.

The event “Motion Detection” has a corresponding action “Recording”.

Play Video Files from the Surveillance Station

You have to click or to enter the playback page and follow the steps below to play the video files on the remote Surveillance Station.

1. Drag and drop camera(s) from the server/camera tree to the respective playback window(s) to select the channel(s) for playback.

2. Select playback date from.You can examine each channel to know the time range when the files were recorded for each IP camera. The blue cells indicate regular recording files and the red cells indicate alarm recording files. If it is blank, it means no files are recorded at that time.

3. Clickto start the playback. You can control the speed and playback direction by dragging the button to right or left on the shuttle bar.

4. Specify the time to play back the recording files at that moment. You can view the preview image on the timeline bar to search the moment you want to play.

5. Clickto control all the playback windows to play back the recording files. When this function is enabled, the playback options (play, pause, stop, previous/next frame, previous/next file, speed adjustment) will be applied to all the playback windows.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-the-surveillance-station-of-qnap-nas

How to set up myQNAPcloud to remotely access a QNAP NAS

Requirements

Register your NAS with myQNAPcloud

  1. Log in to your QNAP NAS.
  2. Open myQNAPcloud.
  3. Click Get Started.

    The Welcome to myQNAPcloud! window appears.
  4. Follow the steps to register your NAS. Click Next to move to the next step.
    1. Enter your QNAP ID and Password.
    2. Enter a Device name for your NAS.
      Note: This name is used to identify your NAS on myQNAPcloud and must be unique across all users.
    3. Choose what NAS services will be enabled and the Access Control setting.

      Your device is registered on myQNAPcloud.

      A summary page displays all the registration details and services guidelines of your NAS.

Remotely access your QNAP NAS with myQNAPcloud

  1. Go to https://www.myqnapcloud.com/.
  2. Sign in using your QNAP Account.
    Note: If you are already signed in you are automatically redirected to My Devices .
  3. Go to My Devices.
    The devices registered to your QNAP Account are displayed.
  4. Click the ”  ” button next to the device to display the device IP and SmartURL.
  5. Click SmartURL.

    A login page for your NAS appears.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-myqnapcloud-to-remotely-access-a-qnap-nas

How to back up your Mac to QNAP NAS using Time Machine

Requirements:

  • QNAP NAS with QTS 4.3.0 (or later).

There are two ways to back up your Mac to a QNAP NAS: using QTS or HBS 3.

QTS: Go to “Perform Time Machine Backup to your QNAP NAS”.
HBS 3: Go to “Back up Mac with the shared Time Machine account in HBS 3”

  • Perform Time Machine Backup to your QNAP NAS
    • (Optional) Create a designated Time Machine backup user and shared folder
    • Configure Time Machine to use QNAP NAS for backups
  • Back up Mac with the shared Time Machine account in HBS 3
    • Set up shared Time Machine account
    • Configure Time Machine to use QNAP NAS for backups

Perform Time Machine Backup to your QNAP NAS

  • (Optional) Create a designated Time Machine backup user and shared folder
    1. Create a Time Machine backup user.
      Tip: A dedicated Time Machine user account can be created to provide additional security and the ability to set storage quotas for each Mac.
      • Open Control Panel.
      • Go to Privilege > Users.
      • Click Create.
      • Select Create a User.
      • Click Create.
    2. Create a Time Machine backup shared folder.
      • Open Control Panel.
      • Go to Privilege > Shared Folders.
      • Click Create.
      • Select Shared Folder.
      • Enter a Folder Name.
      • Click Next.
      • Give the Time Machine backup user RW access privileges.
      • Click Next.
      • Check Set this folder as the Time Machine backup folder (macOS).
      • Click Finish.
    3. Configure QTS to use SMB 3
      1. Open Control Panel.
      2. Go to Network & File Services > Win/Mac/NFS > Microsoft Networking.
      3. Click Advanced Options.
      4. Under Highest SMB version select SMB 3.
      5. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>.
      • Enter the username and password of the backup user account.

        Note:
        If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
      • This can be your NAS account or the dedicated Time Machine user account.
      • Select the NAS shared backup folder.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared backup folder.
    5. Click Use Disk.
    6. Enter the username and password of the backup user account.
      Tip: This can be your NAS account or a dedicated Time Machine user account.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

Back up Mac with a shared Time Machine account in HBS 3

  • Set up the shared Time Machine account
    1. Open HBS 3.
    2. Go to Services > Time Machine.
    3. Check Use shared Time Machine account.
    4. Enter a password for the Time Machine account.
    5. (Optional) Set a storage quota.
    6. Select Maximum
    7. Enter the total capacity in GB.
      Important: If the backup data size is greater than the quota, the Time Machine backup will fail.
    8. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>/TMBackup.
      • Enter the username TimeMachine and the password you created earlier.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared folder TMBackup.
    5. Click Use Disk.
    6. Enter the username TimeMachine and the password you created earlier.

      Note:
      If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

      Tip: Backups can be located under the shared folder TMbackup.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-back-up-your-mac-to-qnap-nas-using-time-machine

Moving the Mission Forward: Mandiant Joins Google Cloud

Google’s acquisition of Mandiant is now complete, marking a great moment for our team and for the security community we serve.

As part of Google Cloud, Mandiant now has a far greater capability to close the security gap created by a growing number of adversaries. In my 29 years on the front lines of securing networks, I have seen criminals, nation states, and plain bad actors bring harm to good people. By combining our expertise and intelligence with the scale and resources of Google Cloud, we can make a far greater difference in preventing and countering cyber attacks, while pinpointing new ways to hold adversaries accountable.  

When I founded Mandiant Corporation in 2004, we set out to change how businesses protected themselves from cyber threats. We felt the technologies people depended on to defend ultimately failed to innovate at the pace of the attackers. In order to deliver cyber defenses as dynamic as the threats, we believed you had to have your finger on the pulse of adversaries around the world. To address this need, we set out to respond to as many cyber security breaches as possible. We wanted to learn first-hand how adversaries were circumventing common safeguards with new and novel attacks; monitor the development and deployment of attacker tools, their infrastructure, and their underground economies; and study the attacker’s targeting trends.

Armed with this knowledge and experience, we felt we were best positioned to close the gap between the offense and the defense in the security arms race.  

As we investigated thousands of security incidents over the years, we honed the deep expertise required to find the proverbial needle in the haystack: the trace evidence that something unlawful, unauthorized, or simply unacceptable had occurred. We believed this skill was the foundation to automating security operations through software, so that organizations and governments around the world could easily implement effective security capabilities. 

By joining forces with Google Cloud, we can accelerate this vision. I am very excited that Mandiant and Google Cloud can now work together to leverage our frontline intelligence and security expertise to address a common goal: to relentlessly protect organizations against cyber attacks and provide solutions that allow defenders to operate with confidence in their cyber security posture. More specifically, we can leverage our intelligence differentiator to automate security operations and validate security effectiveness.

Mandiant Remains Relentless

While we are now part of Google Cloud, Mandiant is not going away—in fact, it’s getting stronger. We will maintain our focus on knowing the most about threat actors and extend our reputation for delivering world-class threat intelligence, consulting services, and security solutions. 

Automating Security Operations

Today’s announcement should be welcome news to organizations facing cyber security challenges that have accelerated in frequency, severity, and diversity. I have always believed that organizations can remain resilient in the fight against cyber threats if they have the right combination of expertise, intelligence, and adaptive technology. 

This is why I am a proponent of Google Cloud’s shared fate model. By taking an active stake in the security posture of customers, we can help organizations find and validate potential security issues before they become an incident. Google Cloud and Mandiant have the knowledge and skills to provide an incredibly efficient and effective security operations platform. We are building a “security brain” that scales our team to address the expertise shortage.

Validating Security Effectiveness

Google Cloud’s reach, resources, and focus will accelerate another Mandiant imperative: validating security effectiveness. Organizations today lack the tools needed to validate the effectiveness of security, quantify risk, and exhibit operational competency. Mandiant is working to provide visibility and evidence on the status of how effective security controls are against adversary threats. With this data, organizations have a clear line of sight into optimizing their individual environment against relevant threats.

Advancing Our Mission

Google Cloud has made security the cornerstone of its commitment to users around the world, and the Mandiant acquisition underscores that focus.

We are thrilled to continue moving our mission forward alongside the Google Cloud team. Together, I believe Mandiant and Google Cloud will help reinvent how organizations protect, detect, and respond to threats. This will benefit not only a growing base of customers and partners, but the security community at large.

You can learn more about this milestone moment and the exciting opportunities ahead in this blog post by Google Cloud CEO Thomas Kurian, “Google + Mandiant: Transforming Security Operations and Incident Response.”

Source :
https://www.mandiant.com/resources/blog/mandiant-joins-google-cloud

Cisco SD-WAN vManage Software Unauthenticated Access to Messaging Services Vulnerability

  • A vulnerability in the binding configuration of Cisco SD-WAN vManage Software containers could allow an unauthenticated, adjacent attacker who has access to the VPN0 logical network to also access the messaging service ports on an affected system.This vulnerability exists because the messaging server container ports on an affected system lack sufficient protection mechanisms. An attacker could exploit this vulnerability by connecting to the messaging service ports of the affected system. To exploit this vulnerability, the attacker must be able to send network traffic to interfaces within the VPN0 logical network. This network may be restricted to protect logical or physical adjacent networks, depending on device deployment configuration. A successful exploit could allow the attacker to view and inject messages into the messaging service, which can cause configuration changes or cause the system to reload.Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.This advisory is available at the following link:
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-msg-serv-AqTup7vs

Affected Products

  • Vulnerable ProductsThis vulnerability affects Cisco devices if they are running a vulnerable release of Cisco SD-WAN vManage Software.For information about which Cisco software releases are vulnerable, see the Fixed Software section of this advisory.Products Confirmed Not VulnerableOnly products listed in the Vulnerable Products section of this advisory are known to be affected by this vulnerability.Cisco has confirmed that this vulnerability does not affect the following Cisco products:
    • IOS XE SD-WAN Software
    • SD-WAN vBond Orchestrator Software
    • SD-WAN vEdge Cloud Routers
    • SD-WAN vEdge Routers
    • SD-WAN vSmart Controller Software

Workarounds

  • There is a workaround that addresses this vulnerability.Administrators can use access control lists (ACLs) to block ports 4222, 6222, and 8222, which are used by Cisco SD-WAN vManage Software messaging services. They may be configured in the following ways depending on deployment:
    • Configure ACLs on Cisco IOS devices. For information about preventing exploitation of Cisco IOS devices, see Protecting Your Core: Infrastructure Protection Access Control Lists.
    • Configure ACLs at the firewall that protects Cisco SD-WAN vManage Software. For information about Cisco Adaptive Security Appliance (ASA) and Cisco Firepower Threat Defense (FTD) ACL configuration, see Cisco ASA Series Firewall CLI Configuration Guide: Access Control Lists.
    • Cisco Cloud Controllers ACLs (Inbound Rules allowed list) are managed through the Self-Service Portal. Customers will have to review their ACL configurations on the Self-Service Portal to ensure that they are correct. This does not involve updating the controller version. By default, Cisco-hosted devices are protected against the issue described in the advisory unless the customer has explicitly allowed access. For more information, see Cisco SD-WAN Cloud Hosted Controllers Provisioning.
    While these workarounds have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.

Fixed Software

  • Cisco has released free software updates that address the vulnerability described in this advisory. Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license:
    https://www.cisco.com/c/en/us/products/end-user-license-agreement.htmlAdditionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.When considering software upgrades, customers are advised to regularly consult the advisories for Cisco products, which are available from the Cisco Security Advisories page, to determine exposure and a complete upgrade solution.In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.Customers Without Service ContractsCustomers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco TAC: https://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.htmlCustomers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.Fixed ReleasesCustomers are advised to upgrade to an appropriate fixed software release as indicated in the following table(s):Cisco SD-WAN vManage Software ReleaseFirst Fixed ReleaseEarlier than 20.3Migrate to a fixed release.20.3Migrate to a fixed release.20.620.6.420.7Migrate to a fixed release.20.8Migrate to a fixed release.20.920.9.1Note: It is the customer’s responsibility to upgrade their cloud controllers to the latest version in which this vulnerability is fixed.The Cisco Product Security Incident Response Team (PSIRT) validates only the affected and fixed release information that is documented in this advisory.

Exploitation and Public Announcements

  • The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.

Source

  • Cisco would like to thank Orange Business for reporting this vulnerability.

URL

Revision History