Buying a hard disk used to be quite easy. Now we have stuff like CMR vs SMR drives, manufacturers not being completely clear in their product showcase pages, and so on.
TLDR: To keep things short, you should strive to buy a CMR drive because SMR drives, while they work just fine, are usually slower in every typical individual test carried by a lot of people out there. SMR drives are slower as their method of writing data aims for storage density, and one of the drawbacks of this goal is speed.
And before we continue, yes, even if manufacturers have developed firwmare that optimize the read and write performance for SMR drives, they are still not that great as a CMR drive.
Tip: some great benchmarks for hard disk drives are: Crystal Disk Mark, ATTO Disk Benchmark, HD Tune, and even PCMark has some storage benchmarks.
CMR or PMR drives – how they work
CMR comes from Conventional Magnetic Recording. It is also known as PMR that comes from Perpendicular Magnetic Recording.
The way CMR works is by aligning the poles of the magnetic elements, which represent bits of data perpendicularly to the surface of the disk. The magnetic tracks are written side-by-side without overlapping.
And because the write head is usually quite large in comparison to the read head, HDD manufacturers aim to shrinking the size of the write head – or do it as much as possible.
SMR – how do these drives work?
Shingled Magnetic Recording, or SMR, is an extension to PMR. It basically offers improved density. And this happens because rather than writing each magnetic track without overlapping, SMR overlaps each new track with part of the previous track. One way to think about it is by comparing it to the shingles on a roof.
By overalapping the tracks, write heads become a lot thinner, and we get a bigger areal density.
CMR vs SMR drives – why does it actually matter?
In short, because you want the best performance for your dollar.
But to get a little bit more technical, regardless of whether an HDD uses CMR or SMR when some new data is written on the drive, the tracks are fully readable without performance impact.
So we have a pretty good read speed, right? No matter what we choose? Right? Kind of. Not really. Well, it depends on how you use the drive.
But! On an SMR drive, when any data is edited or overwritten, the write head will not overwrite data on the existing magnetic track. It will write the new data on an empty area of the disk. While the original track with the old data will temporarily sit put. Then, when the SMR HDD becomes idle, it will enter a ‘reorganization mode’, where the old bits of data on the original track are being erased and made available for future use.
This reorganization procedure must occur and makes idle time essential on an SMR drive. If you hit the respective SMR drive hard with write and read operations, it won’t get to do this in a fast way, and the drive will have to write new data and reorganize stuff at the same time. This causes an impact on the overall read and write performance of the drive.
How can I tell if the HDD I want to buy is SMR or CMR?
Some manufacturers make it easy, some not so much. But basically, searching with something like ‘product code SMR or CMR’ on Google will lead you to a good result most of the time.
Now, Western Digital, on their homepage in the shop section, actually lists CMR or SMR for their drives in the ‘Full Specifications’ area, at the Recording Technology specification. Neat!
For Seagate, however, you have to go to the product page, and download the PDF datasheet. Oh well, I guess it works.
Here’s a breakdown of what is what usually, at least for the common models. Please, search online or on the manufacturer’s website in case the below data becomes outdated.It was last looked up in 29.01.2022, on the manufacturers’ websites, just so you know.
But if you get an amazing price, and you know that hard drive will not get a lot of writes, edits, and deletions… well, it might make sense since the actual heavy usage of erasing,editing and writing data is causing the ‘slowness’. Like if you were to just fill it up with movies and that’s it. Those movies will not get edited, deleted or anything – they will just be read when you watch them. I guess – thinking about selfhosting something like Plex or Nextcloud… or a DIY NAS. I’d still opt for a CMR drive – what kind of discount are we talking about, to be fair? 10% is not worth it in my opinion.
Closing thoughts
Basically, aim for a CMR drive. And if you are new to the whole computer parts upgrade or stuff… don’t stress if you are buying a NAS drive for your desktop PC. It does not matter, it will work the same – maybe even last longer!
Hard disk buying is now as tedious as buying another component, I guess – one more thing to look for besides the usual specifications. I do hope that testing, developing, and working with diverse methods and technologies of storing data will eventually lead to manufacturers developing more performant and higher density hard disks. Just imagine a 100 TB HDD! That would be insane.
I hope this article helped you figure out what you need – an SMR or a CMR drive and why it matters.
Learn how to Defer Parsing of JavaScript to improve pagespeed score. And how you can fix ‘Eliminate render-blocking of JavaScript’ warning in Google PageSpeed Insights by deferring non-critical JavaScript(s). The newer version of Google PageSpeed Insight refers to this issue as ‘Eliminate render-blocking resources’; these render-blocking resources may include JavaScripts and CSS.
In this article, I will cover what is defer parsing of JavaScript, how to defer parsing of JavaScript properly, why you should defer parsing JavaScript, how to find render-blocking JavaScript(s) which are to be deferred, how to defer multiple JavaScripts in one go, how you can defer parsing of JavaScript in WordPress with or without plugin and how does deferred loading of JavaScript help to speed up your website?
In a nutshell, we’ll eliminate render-blocking JavaScript(s) not by actually removing (deleting) them from the website code but by defer loading them. So that they stop blocking the loading (rendering) of meaningful content (the first paint) of the website.
These terms (the above terminology) might be overwhelming for you at first, especially if you’re not a tech guy.
But, don’t worry about that!
I am going to explain everything step by step in simple words. So that you can proceed at your pace and implement the methods to fix ‘Eliminate render-blocking resources’ on your website/blog.
A web page is made of up several components which include HTML, CSS/Stylesheets, JavaScript, and graphical (images & icons) components etc. These components are stacked one over another in the code structure of the web page.
When a user types your website URL in the web browser’s address bar and hit enter. The browser first establishes the connection with the server on which your website is hosted.
Once the connection is established, the browser starts rendering the components of the webpage to display the web page.
The browser renders the components serially from the top towards the bottom of the webpage. That means what comes first rendered first and so on.
When the browser encounters JavaScript on a web page, it downloads the JavaScript, executes it, and then proceeds to render the next component. So during this time browser stop rendering the rest of the web page.
Every time the browser encounters JavaScript, it stops rendering the rest of the webpage until it renders and executes the encountered JavaScript.
That’s how JavaScript blocks the critical rendering path.
To avoid this situation, Google Engineers recommend deferring non-critical JavaScript.
The question still remains the same, What is Defer Parsing of JavaScript?
Defer Parsing of JavaScript can be defined as the process of using defer or async attribute with JavaScript to avoid render blocking of the first paint of a web page. These attributes tell the web browser to parse and execute the JavaScript in parallel (asynchronously) or after (defer) the parsing of HTML of a web page. Thus, the visitors need not wait longer to see the meaningful content of the web page.
Difference between defer or async
Now you know that there are two attributes – defer or async; that can be used to defer javascript loading.
Before we talk about the difference between defer and async, let’s see how does <script> tag works.
Legend
<script>
When we use <script> tag to add script in our code, the HTML is keep parsing till the script file is reached, then onwards parsing will be paused until the script file is downloaded and executed.
Suitability: Not recommended in most cases.
<script defer>
When defer attribute is appended with script tag, the script file is downloaded alongside the HTML parsing but the downloaded script executes only after the completion of HTML parsing.
Suitability: For non-critical script files.
<script async>
When async attributed is used with script tag, the script file downloads during HTML parsing, then HTML parsing pauses just to execute the downloaded-script file.
Suitability: For critical script files that cannot be inline.
Defer loading of JS & PageSpeed Insights recommendation
Let’s try to put this in a perspective with Google PageSpeed Insights warning and recommendation.
When you test, a website using Google Pagespeed Insights Tool, you get some warnings and recommendations to fix those warnings/errors.
The PageSpeed Insights (PSI) text for render-blocking resourcessays,
Eliminate render-blocking resources.
Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.
This warning triggers for two different elements i.e. JavaScript (JS) and CSS when any of them block the critical rendering path 1 during the website loading. Here in this article, we are discussing the JavaScript part.
(In the previous version of PageSpeed Insights Tool, the same warning (for the JavaScript) used to be called ‘Eliminate render-blocking of JavaScript’.)
In simple words, this warning triggers when there are some JavaScript(s) loading on your website which blocks the loading of the content that matters most to your visitors.
This means your visitors have to wait longer to see the meaningful content of your website because JavaScript(s) are blocking the rendering of content.
Clearly, Pagespeed Insights or other site speed testing tools (GTMetrix, etc.) show this warning/error, if your site loads some JavaScript(s) that block the loading of meaningful content (the first paint) of your site.
And this needs to be fixed.
Critical vs Non-critical JavaScript: Explained
As Google PageSpeed Insights (PSI) recommendation says you should deliver critical JSinline and defer all non-critical JS.
What does this mean?
Let’s break that down by terminology.
Critical JavaScripts: JavaScripts that are necessary to load during optimized critical rendering.
Non-critical JavaScripts: Those JS that can wait to load until the first meaningful content (the first paint) of the webpage has loaded.
Inline Delivery: Inline delivery refers to loading a resource (in this case JS) within the HTML code instead of calling/importing that separately.
Curious? Why does JavaScript block the critical rendering path in the first place?
We’ll discuss that in the next section with other reasons why you should Defer JavaScript Parsing.
First of all, JavaScript(s) is one of the major culprits to make your website slow.
Wondering, why is that?
Because when the web browser comes across a script, it executes the script firstbefore continuing to load HTML that includes the content users are looking for.
For a browser, executingJavaScript is a heavier task (depending on the size of the script) and takes more time as compared to rendering the meaningful content (the first paint) of the webpage.
Hence JavaScript affects the critical rendering path and slows down pagespeed of your website.
Why not defer this heavier task of JS execution so that the critical rendering path remains uninterrupted, right?
Pagespeed: is now a Ranking Factor
Site speed has already become a ranking signal.
About a decade ago Google announced 2 in an official blog post on Google Webmaster Central Blog that site speed has become a ranking signal.
In another blog post published on the Official Webmaster Central Blog in 2018, they revealed 3 that Google started using page speed as a ranking factor in mobile search ranking.
Since Google had declared pagespeed a factor in search result rankings for desktop and mobile. Therefore, site speed optimization has become a significant aspect of technical SEO.
For the same reason, Google PageSpeed Insights Tool recommends deferred parsing of JavaScript as one of the solutions 4 to remove render-blocking JavaScript in above-the-fold content.
User Experience: decides Your Site’s Success
How does JavaScript affect user experience (UX)?
We have already discussed that JavaScript(s) slow down the pagespeed by blocking the rendering of first paint (the meaningful content). That led to more loading time and a longer wait for users to see the content; bad user experience, right.
Speed matters a lot, the truth is users do not like slow-loading websites. In fact, studies show that the users leave a slow loading site early and move on.
On the contrary, you want your website audience to engage with your site and eventually turn into a customer, subscriber, or ad-viewer. In order to make that happen, you need to improve your pagespeed by deferring non-critical JavaScript(s).
Reasons to Defer Loading of JavaScript: Summing it up
As I mentioned above, however, the parser (browser) starts downloading and executing the script over parsing the rest of HTML, whenever it encounters the script.
But the fact is, most of the JavaScript(s) come into use when the complete web page is loaded. For example, in some animation, effect, or functionality, etc.
Therefore, it is a good idea to load JavaScript(s) only after the content has loaded.
This way deferred loading of JavaScript does not affect the critical render path and consequently helps to speed up your website. And hence, a better user experience for your readers.
And by making your site load faster, you also improve your search ranking on desktop as well as mobile.
Do you know, good web hosting is a must for better pagespeed? If you are already using good web hosting? Awesome, let’s skip to defer parsing of JavaScript. Not sure? whether your hosting is as good as your website deserves, don’t worry. We recommend Cloudways and Kinsta Hosting for better sitespeed. Read our Kinsta Review.
Now, since you have an understanding of what is defer parsing of JavaScript and why you should defer loading of JavaScript(s).
It is a good time to figure outwhich JavaScript(s) (on your website) are the culprits and need to be deferred.
If you already know which JavaScript(s) on your website are blocking the critical rendering path, you may skip the following section and jump to the implementation part. Otherwise, keep on reading…
How to Find Render-blocking JavaScript(s)
JavaScript(s) which block the rendering of meaningful content are called ‘Render Blocking JavaScript(s)’ and need to be deferred.
You can find render-blocking JavaScript(s) by analyzing your website using site speed testing tools.
There are several pagespeed testing tools available to analyze a website for site speed and loading time. I am sharing with you the most reliable and trusted tools for pagespeed testing.
Test your site using these tools and note the results of these tools so that you can compare the results before and after implementing defer parsing of JavaScript(s).
1. PageSpeed Insights by Google
Google PageSpeed Insights (PSI) is an exclusive pagespeed testing tool by Google. Test your website using Google PSI Tool to find out render-blocking JavaScript(s). PageSpeed Insights Tool results give information about warnings and their solutions/fixes.
2. GTmetrix
This one (GTmetrix) is another good free tool to test site speed. You can test your site with GTmetrix to know which JavaScripts need to be deferred.
3. Pingdom Tools
Solarwinds’ Pingdom Tools are also very popular when it comes to site speed testing tools. You can test your site using Pingdom Tools to check the number of JS requests on your site and how much they contribute to the total number of requests.
Now you know which JavaScript(s) are making your site slow and need to be deferred. So, let’s see how to fix this issue by deferring non-critical JavaScript(JS).
Test Results: Before Defer Parsing of JavaScript
I have tested a website beforeimplementing defer parsing of JavaScript. Consider these a baseline and compare these results after deferred loading of JavaScripts.
How to Defer Parsing of JavaScript [Step by step]
You need to use the following code to defer parsing JavaScript. Insert this code in HTML file just before the </body> tag. Read the instructions given below to use this script.
< script type="text/javascript">
function parseJSAtOnload() {
var element = document.createElement("script");
element.src = "script_to_be_deferred.js";
document.body.appendChild(element);
}
if (window.addEventListener)
window.addEventListener("load", parseJSAtOnload, false);
else if (window.attachEvent)
window.attachEvent("onload", parseJSAtOnload);
else window.onload = parseJSAtOnload;
</script >
Instructions for Defer Parsing JavaScript using the script
Don’t forget to take a complete backup before making any changes in the code. If something went wrong, you can use that backup to go back.
Copy the code and paste it in HTML file just before the </body> tag (near the bottom of HTML file).
Replace script_to_be_deferred.js with the link of the JavaScript which is to be deferred. You can copy the link of JavaScript(s) (which Google PageSpeed tool suggests to defer) from Google PageSpeed Insights tool results for your website.
Save changes. And you are done.
Finally, test your website again to see the effect.
Code to Defer Multiple JavaScripts in One-go
If you want to defer multiple scripts in one go. You can use the same script with little modification. In the following code replace defer1.js, defer3.js, and defer3.js, etc. with the link of scripts that you want to defer.
< script type="text/javascript">
function parseJSAtOnload() {
var links = ["defer1.js", "defer2.js", "defer3.js"],
headElement = document.getElementsByTagName("head")[0],
linkElement, i;
for (i = 0; i < links.length; i++) {
linkElement = document.createElement("script");
linkElement.src = links[i];
headElement.appendChild(linkElement);
}
}
if (window.addEventListener)
window.addEventListener("load", parseJSAtOnload, false);
else if (window.attachEvent)
window.attachEvent("onload", parseJSAtOnload);
else window.onload = parseJSAtOnload;
</script >
How to Defer Parsing of JavaScript in WordPress
You can defer parsing of JavaScript in WordPress by following methods:
Using WordPress Plugins (with a plugin) – suitable for all plugin lovers.
Adding a Code Snippet to function.php file – suitable for those who are used to playing with code and editing files in WordPress. – without plugin method #1
Using the Script mentioned above – suitable for geeks who don’t want to use a plugin. – without plugin method #2
1. Defer Parsing of JavaScript using WordPress Plugin
There are several WordPress plugins available to defer parsing of JavaScript in WordPress, I am listing the best plugins that stand out in the crowd because of their performance and reliability.
Obviously, the process of installing and activating any of the following plugins remains the same.
If you’re not sure about the process of installing a WordPress plugin, you can refer this beginner’s guide to learn different methods of installing a plugin in WordPress.
#1.1 Async JavaScript Plugin
If you want a standalone plugin to defer parsing of JavaScript, Async JavaScript should be your pick.
This tiny plugin offers all necessary settings to tweak deferred loading of JS in WordPress.
HOW TO USE ASYNC JAVASCRIPT PLUGIN: SETTINGS & USAGE GUIDE
Steps to defer parsing of javascript in WordPress using a plugin:
Navigate to WordPress Dashboard > Plugins > Add New.
Search Async JavaScript Plugin in the plugin repository.
Go over WP Dashboard > Performance (W3 Total Cache Settings) > Minify.
Scroll down to JS minify settings. You will see settings like shown in the image below.
Check/select options as shown in the image below. Click Save all settings and you are done.
Test your site using pagespeed test to see the results.
#1.4 Defer Loading of JavaScript in LiteSpeed Cache Plugin
LiteSpeed Cache is an amazing optimization plugin for LiteSpeed server hosting. But the general features of this plugin can be utilized on any server like LiteSpeed, Apache, NGINX, etc.
Steps to defer parsing of javascript in LiteSpeed Cache plugin:
Go to Dashboard > Settings > Autoptimize > JS, CSS & HTML.
Under JavaScript Options enable Optimize JavaScript Code and,
Then enable Do not aggregate but defer option and save changes.
Now Empty Cache and test your site using speed test tool to see the result.
#1.8 WP Fastest Cache to Defer Parsing of JavaScript
You can eliminate render-blocking JavaScript resources using WP Fastest Cache plugin. But this feature is available with the premium version only.
2. Defer JavaScript Parsing in WordPress via functions.php file
Yes, you can defer parsing of JavaScript in WordPress by adding a code snippet to function.php file.
This is one of the methods that you can use to Defer Parsing of JavaScript in WordPress without using a plugin.
As I have mentioned above this method is suitable for people who are comfortable with code editing in WordPress.
You might be thinking, but why?
First of all, functions.php is an important theme file. That means you might end up breaking your site easily if anything went wrong with the editing of functions.php file.
Also, there are different versions of the code snippet on the web to fix defer parsing of JavaScript in WordPress via functions file. Unfortunately, not all the code snippets work fine.
So you should be careful while using a code snippet to defer loading of JavaScript.
How to Edit functions.php File Safely
I always recommend using a child theme in WordPress in order to avoid code editing mess.
Because while editing the code, even if you miss a single comma (,) semicolon (;) or any other symbol/syntax, your website will break completely or partially. And you have to make extra efforts to recover the site.
For any reason, if you don’t want to implement a child theme now, you can use this plugin to add code to functions.php file of your theme without editing the original file.
Step by step process to Defer Parsing JavaScript in WordPress via functions.php
Take a complete backup before making any changes to the code.
I assume that you’re using a child theme. If you’re not, first create and activate a child theme to any trouble because of theme file editing.
Go to your WordPress Dashboard > Appearance > Theme Editor
Select/open functions.php file (of child theme) from theme files.
Paste the code snippet given below at the end of functions.php file.
You can specify JS files to exclude from defer in the array (‘jquery.js’).
Finally, click Update File to save changes. That’s all.
The code snippet is to be pasted in functions.php file.
// Defer Parsing of JavaScript in WordPress via functions.php file
// Learn more at https://technumero.com/defer-parsing-of-javascript/
function defer_parsing_js($url) {
//Add the files to exclude from defer. Add jquery.js by default
$exclude_files = array('jquery.js');
//Bypass JS defer for logged in users
if (!is_user_logged_in()) {
if (false === strpos($url, '.js')) {
return $url;
}
foreach ($exclude_files as $file) {
if (strpos($url, $file)) {
return $url;
}
}
} else {
return $url;
}
return "$url' defer='defer";
}
add_filter('clean_url', 'defer_parsing_js', 11, 1);
The above code snippet is using defer attribute to defer parsing of JavaScripts. You can replace the defer attribute with async attribute to parse JavaScript asynchronously. You can read more about async attribute and other methods to fix render-blocking JavaScript.
3. Defer Parsing of JavaScript without WordPress Plugin – Script Method
The script method explained above can be used in WordPress to defer loading of javascript. In WordPress, the above-mentioned code can be placed in HTML file just before the </body> tag using hook content option.
Most of the popular WordPress themes come with hook content provision. If you are not using the hook content option or it is not available in your theme. Then, either you can use a WordPress plugin to add the script to WordPress footer before </body> tag or you can place the script in the footer file just before the </body> tag manually.
Steps to defer load javascript in WordPress without using a plugin:
Copy the code and paste that before the </body> tag (using a plugin or built-in theme hook) .
Now replace script_to_be_deferred.js with the JavaScript to be deferred.
Save changes and you’re done.
Clear the cache, if there is any.
Test your website again to see the result.
Test Results: After Defer Parsing of JavaScript
The following are the test results after defer loading of JavaScript.
Wrapping it up
Other than defer parsing of JavaScript, you can also use async attribute or inline JavaScript to remove render-blocking JavaScript. I have covered async attribute or inline JavaScript in another blog post, read that article here. In that article, I have also mentioned a few useful WordPress plugins to defer parsing JavaScript.
Although WordPress plugins are available to defer parsing of JavaScript. The above-explained script method is considered more appropriate by several experts and webmasters. But the people who use WordPress know that using a WordPress plugin is like bliss.
I hope this guide will help you to defer parsing of JavaScript. Let me know, which technique you use to defer parsing of JavaScript. If you are facing any problem implementing the above methods or have a question. Let me know via the comment section. I will be happy to answer.
Looking for the best way to extend your firewall protection to the cloud? Independent testing recently found that SonicWall NSv series is more than up to the challenge.
More than 90% of enterprises use the cloud in some way, with 69% of those considered hybrid cloud users (utilizing both private and public clouds). Along with widespread remote work adoption, this shift is driving the need for scaled-out, distributed infrastructure.
Within this new cloud landscape, security has become more complex as the number of perimeters and integrations grow, and cybercriminals increasingly focus on security gaps and vulnerabilities in cloud implementations. It’s often easier for threat actors to exploit these vulnerabilities than it is to breach hardened components of the cloud deployment.
A next-generation firewall deployed in the cloud can protect critical data stored in the cloud. But it’s important to make sure this firewall provides the same level of security and performance as an on-premises firewall.
Recently, Tolly Group used Keysight Technologies’ brand-new native cloud testing solution — CyPerf — to measure the performance of SonicWall NSv 470 virtual firewall in Amazon Web Services (AWS). AWS is the major public cloud vendor, with a projected 49% market share in enterprise cloud adoption for 2022. AWS recommends a shared responsibility model, meaning AWS is responsible for the security of the cloud, and the customer is responsible for security in the cloud.
What is SonicWall NSv virtual firewall?
SonicWall’s NSv Series virtual firewalls provide all the security advantages of a physical firewall, plus all the operational and economic benefits of the cloud — including system scalability and agility, speed of system provisioning, simple management and cost reduction. NSv delivers full-featured security tools including VPN, IPS, application control and URL filtering. These capabilities shield all critical components of the private/public cloud environments from resource misuse attacks, cross-virtual-machine attacks, side-channel attacks, and common network-based exploits and threats.
What is Keysight Technologies CyPerf?
Keysight CyPerf is the industry’s first cloud-native software solution that recreates every aspect of a realistic workload across a variety of physical and cloud environments. CyPerf deployed across a variety of heterogeneous cloud environments realistically models dynamic application traffic, user behavior and threat vectors at scale. It validates hybrid cloud networks, security devices and services for more confident rollouts.
Putting SonicWall NSv to the Test
Keysight Technologies and Tolly Group engineers tested a SonicWall NSv 470 virtual firewall running SonicOSX version 7. The AWS instance for the NSv 470 under test was AWS C5.2xlarge. The engineers deployed CyPerf agents on AWS C5.n2xlarge instances to be certain that the agents would have sufficient resources to stress the firewall under test. Each of two agent instances was provisioned with 8 vCPUs, 21GB memory and 25GbE network interfaces.
Test methodology and results
The engineers used three different traffic profiles to collect results — unencrypted HTTP traffic, encrypted (HTTPS/TLS) traffic, and Tolly’s productivity traffic mix, which includes five applications: JIRA, Office 365, Skype, AWS S3 and Salesforce. Engineers used CyPerf application mix tests to create the Tolly productivity mix and generate stateful, simulated application traffic.
The tests were run against three different security profiles:
1) Firewall: Basic firewall functions with no policy set
2) IPS: Firewall with the intrusion prevention system feature enabled
3) Threat Prevention: Firewall with IPS, antivirus, anti-spyware and application control features enabled
The results observed in the AWS public cloud environment are similar to the results observed in virtual environment.
Test
Unencrypted HTTP Traffic
Encrypted HTTPS/TLS Traffic
Firewall Throughput
7.70 Gbps
3.10 Gbps
IPS Throughput
7.60 Gbps
3.05 Gbps
Threat Prevention
7.40 Gbps
3.04 Gbps
Table 1: Test measurements for NSv 470 in AWS Cloud
Note: The table above highlights just a few of the test results. For complete results and test parameters, please download the report.
Conclusion
Most enterprises are moving their datacenters away from traditional on-premises deployments and to the cloud. It is imperative that security teams provide the same level of security for cloud server instances as they have been doing for on-premises physical servers. A next-generation firewall with advanced security services like IPS and application control is the first step to securing cloud instances against cyber threats.
In addition to security features, it also important to choose a firewall that provides the right level of performance needed for a given cloud workload. SonicWall NSv series offers a variety of models with performance levels suited to any size of cloud deployment, with all the necessary security features enabled. To learn more about how SonicWall NSv Series excels in AWS environments, click here.
Our lastest ShieldPRO 14.1 security plugin for WordPress brings a huge WordPress REST API integration along with some much-needed tweaks and enhancements.
Read on to discover everything we’ve included in your newest and favourite WordPress Securty Plugin.
Consider the work that’s involved with managing just 1 WordPress site and all its plugins, themes, updates, backups and, of course, security.
Now multiply that by the number of WordPress sites you run.
It’s a huge amount of work.
This is why we built iControlWP many years back and why we also integrated Shield Security into it to allow WordPress admins to manage their WordPress sites at scale, and also their WordPress security.
But not everyone wants to use iControlWP and that’s totally cool! But we still want to open up management of Shield to folk that need to scale their WordPress security.
This is where our new WordPress REST API integration comes in. It leverages the very thorough platform that the WordPress Core provides, letting us build a REST API that is powerful, secure and easy to maintain.
Many clients won’t have a need for our REST API directly, but you may use tools and services that could take advantage of if you asked them to.
This involved a major revamp of the UI and the tables that display the logs.
As you can imagine, these tables and data set can grow very large, particularly for busy websites.
Since we were loading a large dataset all at once, browsing these log tables became tedious and slow. For high traffic sites, it would unusable in some cases resulting in loading errors!
So we went back to our core implementation (again) and made the entire thing dynamic. Instead of loading all the records, we only load precisely what we need. This makes the initial loading near-instant.
The pagination will be a bit slower than what you’re used to – but this is because we’re loading just the log records you need, when you need them.
We’ve also adjusted the traffic log database table structure to help us speed all this along and provide more useful information right where you need it.
This is a major reworking and we hope you’ll love it!
#3 Run Shield As A “Must-Use” (MU) Plugin
If you’ve never heard of a must-use WordPress plugin, don’t worry, you’re not alone.
They’re installed in a different directory (/wp-content/mu-plugins/) instead of the default (/wp-content/plugins/).
So why would you want to switch Shield to be an MU plugin?
In much the same way as Shield offers the Security Admin module to protect against tampering, you could set Shield to be an MU plugin to prevent the plugin from being disabled accidentally, maliciously.
It’ll also ensure Shield executes before other plugins. While this won’t offer an advantage currently, we’ll soon adjust some Shield’s code to block malicious requests much earlier in the WordPress load.
What actually happens when you enable MU Mode?
The core of the Shield plugin will remain in the normal installation directory- /wp-content/plugins/.
Shield will then create a new file in the MU directory that loads the normal Shield plugin. When this happens you’ll see 2x Shield plugins installed on your site as shown below:
How can you disable Shield after enabling MU Mode?
Once MU mode is enabled, you can’t disable the normal Shield plugin from the WordPress dashboard. This is normal WordPress behviour.
However, you can simple revert the option within Shield’s settings to disable MU Mode, and then return the plugins screen and disable Shield like any other plugin.
The setting for MU Mode is found within the Security Admin module and doesn’t require a Security Admin PIN to be set.
#4 Better Detection Of Incorrect Application Passwords
Until now Shield wasn’t correctly spotting when these application password login attempts were failing. We’ve added some new events and logging and we’ll even increase the offense counter for an IP address when the event is triggered.
We spotted these new events being triggered almost immediately after we put them live for testing.
#5 More Quick Access Data In Admin Bar
Some time ago we add a top menu to the WordPress admin bar to help indicate when Shield found some scan items that warrant further investigation.
After prompting for some extra information by a client, we’ve made some new helpful additions to the menu (see image below).
Each of these additions provide helpful links to the item in question, for example:
Recently Blocked IPs and Offenses link to the IP Analyse Tool for the specific IP in-question.
Recent Sessions links to the Shield Sessions table and the individual session item in the menu links to the profile of the given user.
On March 10, 2022 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in “SiteGround Security”, a WordPress plugin that is installed on over 400,000 sites. This flaw makes it possible for attackers to gain administrative user access on vulnerable sites when two-factor authentication (2FA) is enabled but not yet configured for an administrator.
Wordfence Premium, Wordfence Care, and Wordfence Response received a set of firewall rules on March 10, 2022 to provide protection against any attackers trying to exploit this vulnerability. Wordfence Free users will receive this same protection 30 days later on April 9, 2022
After sending the full disclosure details to the SiteGround security team on March 10, 2022 a patch was released the next day on March 11, 2022. While the plugin was partially patched immediately, it wasn’t optimally patched until April 7, 2022.
Sites hosted on the SiteGround platform have automatically been updated to the patched version while those hosted elsewhere will require a manual update, if auto-updates are not enabled for the plugin. We strongly recommend ensuring that your site has been updated to the latest patched version of “SiteGround Security”, which is version 1.2.6 at the time of this publication.
SiteGround Security is a plugin designed to enhance the security of WordPress installations via several features like login security including 2FA, general WordPress hardening, activity monitoring, and more. It’s also worth noting that it comes pre-installed on all SiteGround hosted WordPress sites. Unfortunately, the 2FA functionality of the plugin was insecurely implemented making it possible for unauthenticated attackers to gain access to privileged accounts.
When two-factor authentication is enabled, it requires all administrative and editor users to set-up two factor authentication. This requirement is triggered when the site’s administrative and editor users log into the site for the first time after 2FA has been enabled at which time they are prompted to configure 2FA for their account. This means that there will be a period of time between 2FA being enabled on a site and each user configuring it for the account.
During this interim period, attackers could hijack the 2FA set-up process. The plugin had a flaw that made it so that attackers could completely bypass the first step of authentication, which requires a username and password, and access the 2FA set-up page for users that had not configured 2FA yet.
It was as simple as supplying the user ID they would like to compromise via the sg-user-id parameter, along with a few other parameters to indicate that they would like to trigger the initial 2FA configuration process.
The following validate_2fa_login() function shows the process by which a user-supplied ID is validated. If the results from the check_authentication_code() function and the sg_security_2fa_configured user meta retuned false, which indicated that 2FA hasn’t yet been configured for that user, then the plugin would load the 2fa-initial-setup-form.php template which displays the QR code and 2FA secret needed to configure the authenticator app for the user supplied ID.
</pre><pre>publicfunctionvalidate_2fa_login( $user) {// Bail if there is no valid user authentication.if( ! isset( $_POST['sg-user-id'] ) ) { // phpcs:ignorereturn;}$result= $this->check_authentication_code( wp_unslash( $_POST['sgc2facode'] ), wp_unslash( $_POST['sg-user-id'] ) ); // phpcs:ignore// Check the result of the authtication.if( false === $result) {if( 0 == get_user_meta( $_POST['sg-user-id'], 'sg_security_2fa_configured', true ) ) { // phpcs:ignore// Arguments for initial 2fa setup.$args= array('template'=> '2fa-initial-setup-form.php','qr'=> get_user_meta( $_POST['sg-user-id'], 'sg_security_2fa_qr', true ), // phpcs:ignore'secret'=> get_user_meta( $_POST['sg-user-id'], 'sg_security_2fa_secret', true ), // phpcs:ignore'error'=> esc_html__( 'Invalid verification code!', 'sg-security'),'action'=> esc_url( add_query_arg( 'action', 'sgs2fa', wp_login_url() ) ),);} else{// Arguments for 2fa login.$args= array('template'=> '2fa-login.php','error'=> esc_html__( 'Invalid verification code!', 'sg-security'),'action'=> esc_url( add_query_arg( 'action', 'sgs2fa', wp_login_url() ) ),);}$this->load_form( wp_unslash( $_POST['sg-user-id'] ), $args); // phpcs:ignore}// Set the auth cookie.wp_set_auth_cookie( wp_unslash( $_POST['sg-user-id'] ), intval( wp_unslash( $_POST['rememberme'] ) ) ); // phpcs:ignore</pre><pre>
The authentication QR code and secret key displayed that would be displayed to potentially unauthorized users.
The returned QR code and secret key are the only things needed to connect the user account with an authentication mechanism, such as Google Authenticator. Attackers were able to use this to connect their authentication app with the account and successfully use a code to pass the “second factor of authentication.” This function would then set the user authentication cookies via the wp_set_auth_cookie() function using the user supplied ID from the sg-user-id parameter which effectively logs the attacker in as that user. Due to the default configuration of the plugin, this account would most likely be a privileged user like an administrator or editor. It’s also worth noting that the function returns the back-up codes which could be used via the weakness outlined in the next section.
To sum it up, there was no validation on the validate_2fa_login() function that the identity a user was claiming was in fact legitimate. As such attackers could bypass the first authentication mechanism, a username/password pair, which is meant to prove identity and successfully log in, due to a weakness in the second authentication mechanism, the 2FA process. When successful, an attacker could completely infect a site by exploiting this vulnerability.
In addition to the above outlined vulnerability, the method in which 2FA back-up code authentication was handled made it possible for attackers to log in if they were able to brute force a back-up code for a user or compromise it via other means such as SQL Injection.
Diving deeper, the plugin registered the validate_2fabc_login() function which validated the supplied backup code through the validate_backup_login() function using the user supplied user ID from the sg-user-id parameter along with the back-up code supplied via the sgc2fabackupcode parameter. If the back-up code was found in the array of stored back-up codes for that user, then the function would use the wp_set_auth_cookie() function to set the authentication cookies for the supplied user ID. If that user ID belonged to an administrator, the attacker would effectively be logged in as an administrator.
</pre><pre>publicfunctionvalidate_2fabc_login() {$result= $this->validate_backup_login( wp_unslash( $_POST['sgc2fabackupcode'] ), wp_unslash( $_POST['sg-user-id'] ) ); // phpcs:ignore// Check the result of the authtication.if( false === $result) {$this->load_form(wp_unslash( $_POST['sg-user-id'] ), // phpcs:ignorearray('template'=> '2fa-login-backup-code.php','action'=> esc_url( add_query_arg( 'action', 'sgs2fabc', wp_login_url() ) ),'error'=> esc_html__( 'Invalid backup code!', 'sg-security'),));}// Set the auth cookie.wp_set_auth_cookie( wp_unslash( $_POST['sg-user-id'] ), intval( wp_unslash( $_POST['rememberme'] ) ) ); // phpcs:ignore
Similarly to the previous vulnerability, the issue here is that there was no true identity validation for the authentication, which indicates an authorization weakness. The function performed no checks to verify that a user had previously authenticated prior to entering the 2FA back-up code, and as such they did not need to legitimately log in prior to being logged in while using a back-up code. This meant that there were no checks to validate that a user was authorized to use a back-up code to perform the second factor of authentication that would log them in.
Though the risk in this case is lower, the backup codes were 8 digits long and entirely numeric, so an attacker could potentially brute force one of the 8 back-up codes and automatically be logged in without knowing a username and password combination for an administrative user.
While this might not be practical to attempt on most servers, a patient adversary attacking a well-provisioned server capable of processing a large number of requests at once would have a high chance of eventually gaining access unless the brute force attempts were stopped by another mechanism, such as the Wordfence plugin’s built-in brute force protection or rate limiting rules.
Further, this vulnerability could be used in conjunction with another vulnerability, such as SQL injection, where an attacker would be able to compromise the 2FA back-up codes that are stored in the database and then subsequently use them to log in without needing to crack the password of an administrative user which would likely be significantly stronger. In both cases, the impact would be significant as an attacker could gain administrative access to the compromised WordPress site which could be used for complete site infection.
An Important Security Reminder: Audit Your WordPress Site’s User Accounts
This vulnerability serves as an important reminder to audit your WordPress site’s user accounts. This means identifying any old and unused user accounts that have been inactive for an extended period of time and/or are likely to never be used again and removing them or completely stripping the user’s capabilities. This vulnerability could easily be exploited on sites where the site owner enabled 2FA, which is required for all administrative and editor users, and had old inactive administrative/editor user accounts on the site that an attacker could target. Considering accounts that are no longer active are unlikely to log in after the 2FA setting has been enabled, the 2FA for those accounts would not be configured leaving the site ripe for exploitation by any attackers exploiting the vulnerability.
A situation involving a similar security issue involving insecure 2FA was reported by the CISA in conjunction with the FBI a few weeks ago, around the same time we discovered this vulnerability. In the Cybersecurity Advisory (CSA) by the CISA, it was disclosed that a threat actor was able to successfully brute force a dormant user’s account credentials, and due to a default 2FA setting that would allow dormant users to re-enroll a new device for 2FA during the next active log in, the threat actor was able to connect the 2FA secret to their own account and retrieve the code needed to pass the second factor of authentication. Once the threat actor gained initial access to the system they were able to escalate their privileges by exploiting the “PrintNightmare” vulnerability, which you can read more about here, and steal sensitive information from across the organization’s network. This goes to show that attackers are definitely looking for flaws like the one disclosed today to exploit and any site can be a target. As such, it’s important to actively maintain and validate the security of your site through regularly performed professional or self-conducted security audits and penetration tests, which is a service Wordfence provides. Security is an active and continuous process.
Timeline
March 10, 2022 – Conclusion of the plugin analysis that led to the discovery of two Authentication Bypass Vulnerabilities in the “SiteGround Security” WordPress plugin. We deploy firewall rules to protect Wordfence Premium, Wordfence Care, and Wordfence Response users. We send the full disclosure details to SiteGround in accordance with their responsible disclosure policy. March 11, 2022 – The CTO of SiteGround responds indicating that a patch has been released. We review the patch and inform them that it is insufficient. They release an additional patch. March 11, 2022 – A patched version of the plugin is released as version 1.2.3. We suggest further security enhancements to the functionality. March 16, 2022 – An update is made that reduces the security of the 2FA functionality, we follow-up again to suggest better security enhancements to the functionality. The CTO assures us that they are working on it. April 6, 2022 – A fully and optimally patched version of the plugin is released as version 1.2.6. April 9, 2022 – Wordfence Free users receive the firewall rules.
Conclusion
In today’s post, we detailed a flaw in the “SiteGround Security” plugin that made it possible for unauthenticated attackers to gain access to administrative user accounts in instances where 2-Factor Authentication was enabled, though not yet fully set up, and in cases where an attacker could successfully brute force a back-up code. This could easily be used by an attacker to completely compromise a site. This flaw has been fully patched in version 1.2.6.
We strongly recommend ensuring that your site has been updated to the latest patched version of “SiteGround Security”, which is version 1.2.6 at the time of this publication.
Wordfence Premium, Wordfence Care, and Wordfence Response received a set of firewall rules on March 10, 2022 to provide protection against attempts by attackers to exploit this vulnerability. Wordfence Free users will receive this same protection 30 days later on April 9, 2022
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 Wordfence Care and Wordfence Response include hands-on security support that provide you with ongoing assistance from our incident response team, should you need it.
Special thanks to the team at SiteGround, for responding swiftly and working quickly to get a patch out to protect their customers and working to further secure the 2FA component.
On April 18, 2022, the Wordfence Threat Intelligence team initiated the responsible disclosure process for an Object Injection vulnerability in the Booking Calendar plugin for WordPress, which has over 60,000 installations.
We received a response the same day and sent over our full disclosure early the next day, on April 19, 2022. A patched version of the plugin, 9.1.1, was released on April 21, 2022.
We released a firewall rule to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers on April 18, 2022. Sites still running the free version of Wordfence will receive the same protection on May 18, 2022. We recommend that all Wordfence users update to the patched version, 9.1.1, as soon as possible as this will entirely eliminate the vulnerability.
The Booking Calendar plugin allows site owners to add a booking system to their site, which includes the ability to publish a flexible timeline showing existing bookings and openings using a shortcode, [bookingflextimeline].
The flexible timeline includes the ability to configure viewing preferences and options when viewing the published timeline. Some of these options were passed in PHP’s serialized data format, and unserialized by the define_request_view_params_from_params function in core/timeline/v2/wpbc-class-timeline_v2.php.
An attacker could control the serialized data via several methods:
If a timeline was published, an unauthenticated attacker could obtain the nonce required to send an AJAX request with the action set to WPBC_FLEXTIMELINE_NAV and a timeline_obj[options] parameter set to a serialized PHP object.
Any authenticated attacker could use the built-in parse-media-shortcode AJAX action to execute the [bookingflextimeline] shortcode, adding an options attribute in the shortcode set to a serialized PHP object. This would work even on sites without a published timeline.
An attacker with contributor-level privileges or above could also embed the [bookingflextimeline] shortcode containing a malicious options attribute into a post and execute it by previewing it, or obtain the WPBC_FLEXTIMELINE_NAV nonce by previewing the [bookingflextimeline] shortcode and then using method #1.
Any time an attacker can control data that is unserialized by PHP, they can inject a PHP object with properties of their choice. If a “POP Chain” is also present, it can allow an attacker to execute arbitrary code, delete files, or otherwise destroy or gain control of a vulnerable website. Fortunately, no POP chain was present in the Booking plugin, so an attacker would require some luck as well as additional research in order to exploit this vulnerability. Nonetheless, POP chains appear in a number of popular software libraries, so many sites could still be exploited if another plugin using one of these libraries is installed.
Despite the lack of a POP chain and the complexity involved in exploitation, the potential consequences of a successful attack are so severe that object injection vulnerabilities still warrant a “High” CVSS score. We’ve written about Object Injection vulnerabilities in the past if you’d like to find out more about how they work.
Timeline
April 18, 2022 – We release a firewall rule to protect Wordfence Premium, Care, and Response customers. We initiate the disclosure process. The plugin developer verifies the contact method. April 19, 2022 – We send the full disclosure to the plugin developer. April 21, 2022 – A patched version of the Booking Calendar plugin, 9.1.1, is released. May 18, 2022 – The firewall rule becomes available to free Wordfence users.
Conclusion
In today’s post, we covered an Object Injection vulnerability in the Booking Calendar plugin. Wordfence Premium, Wordfence Care, and Wordfence Response customers are fully protected from this vulnerability. Sites running the free version of Wordfence will receive the same protection on May 18, 2022, but have the option of updating the Booking calendar plugin to the patched version 9.1.1 to eliminate the risk immediately.
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.
Picking just 10 Linux open source security tools isn’t easy, especially when network professionals and security experts have dozens if not several hundred tools available to them.
There are different sets of tools for just about every task—network tunneling, sniffing, scanning, mapping. And for every environment—Wi-Fi networks, Web applications, database servers.
We consulted a group of experts (Vincent Danen, vice president of product security, RedHat; Casey Bisson, head of product growth, BluBracket; Andrew Schmitt, a member of the BluBracket Security Advisory Panel; and John Hammond, senior security researcher, Huntress) to develop this list of must-have Linux security tools.Linux security: Cmd provides visibility, control over user activity
Most of them listed here are free and open source. The two that cost money are Burp Suite Pro and Metasploit Pro. Both are considered indispensible in any enterprise program of vulnerability assessment and penetration testing.
1. Aircrack-ng for Wi-Fi network security
Aircrack-ng is a suite of tools for security testing wireless networks and Wi-Fi protocols. Security pros use this wireless scanner for network administration, hacking, and penetration testing. It focuses on:
Monitoring: Packet capture and export of data to text files for further processing by third-party tools.
Attacking: Replay attacks, deauthentication, fake access points via packet injection.
Testing: Checking Wi-Fi cards and driver capabilities.
Cracking: WEP and WPA PSK (WPA 1 and 2).
According to the Aircrack-ng website, all tools are command line, which allows for heavy scripting. The tool works primarily on Linux, but also Windows, macOS, FreeBSD, OpenBSD, NetBSD, as well as Solaris and even eComStation 2.
Burp Suite Professional is a web application testing suite used for assessing online website security. Burp Suite operates as a local proxy solution that lets security pros decrypt, observe, manipulate, and repeat web requests (HTTP/websockets) and responses between a web server and a browser.
The tool comes with a passive scanner that lets security pros map out the site and check for potential vulnerabilities as they manually crawl the site. The Pro version also offers a very useful active web vulnerability scanner that allows for further vulnerability detection. Burp Suite is extensible via plugins, so security pros can develop their own enhancements. The Pro version has the most robust plugins, making Burp a multi-tool suite of very useful web attack tools.
Cost: The professional version costs $399. There’s also an enterprise version that enables multiple concurrent scans that can be used by application development teams.
3. Impacket for pen testing network protocols
This collection of tools is essential for pen testing network protocols and services. Developed by SecureAuth, Impacket operates as a collection of Python classes for working with network protocols. Impacket focuses on providing low-level access to packets, and for some protocols such as SMB1-3 and MSRPC, the protocol implementation itself. Security pros can construct packets from scratch, as well as parsed from raw data. The object-oriented API makes it fairly easy to work with deep hierarchies of protocols. Impacket supports the following protocols:
ethernet, Linux;
IP, TCP, UDP, ICMP, IGMP, ARP;
IPv4 and IPv6;
NMB and SMB1, SMB2 and SMB3;
MSRPC Version 5, over different transports: TCP, SMB/TCP, SMB/NetBIOS and HTTP;
Plain, NTLM and Kerberos authentications, using password/hashes/tickets/keys;
Portions of TDS (MSSQL) and LDAP protocol implementation
Cost: Free as long as the user gives SecureAuth credit. Impacket is provided under a slightly modified version of the Apache Software License. Security pros can review it here and compare it to the official Apache Software License.
4. Metasploit: A super-tool for detecting exploits
An exploitation framework from Rapid7 that is used for general penetration testing and vulnerability assessments, security pros consider it a “super tool” that contains working versions of nearly every known exploit in existence.
Metasploit enables security pros to scan networks and endpoints (or import NMAP scan results) for vulnerabilities and then perform any possible exploitation automatically to takeover systems.
According to a recent Rapid7 blog post, capturing credentials has been a critical and early phase in the playbook of many security testers. Metasploit has facilitated this for years with protocol-specific modules, all under the auxiliary/server/capture function. Security pros can start and configure each of these modules individually, but now there’s a capture plug-in that streamlines the process.
Cost: Metasploit Pro, which comes with commercial support from Rapid7, starts at $12,000 per year, but there is also a free version.
5. NCAT probes network connectivity
From the makers of NMAP, NCAT is a successor to the popular NETCAT. It facilitates reading and writing data over a network from the command line, but adds features such as SSL encryption. Security experts say NCAT has become crucial for hosting TCP/UDP clients and servers to send/receive arbitrary data from victim and attacking systems. It’s also a popular tool for establishing a reverse shell or exfiltrating data. NCAT was written for the NMAP Project and stands as the culmination of the currently splintered family of NETCAT incarnations. It’s designed as a reliable back-end tool to execute network connectivity to other apps and users. NCAT works with IPv4 and IPv6 and offers the ability to chain NCATs together, redirect TCP, UDP, and SCTP ports to other sites, as well as SSL support.
Cost: Free open source tool.
6. NMAP scans and maps networks
NMAP is a command-line network scanning tool that uncovers accessible ports on remote devices. Many security pros consider NMAP the most important and effective tool on our list— the tool is so powerful it’s become obligatory for pen testers. NMAP’s flagship feature is scanning network ranges for active servers, and then all of its ports for operating system, service and version discovery. Via NMAP’s scripting engine, it then performs further automated vulnerability detection and exploitation against any service it finds. NMAP supports dozens of advanced techniques for mapping out networks filled with IP filters, firewalls, routers, and other obstacles. This includes many TCP and UDP port scanning mechanism, OS detection, version detection, and ping sweeps. Security pros have used NMAP to scan large networks of hundreds of thousands of machines.
Cost: Free open source tool.
7. ProxyChains for network tunneling
The de facto standard for network tunneling, ProxyChains lets security pros issue proxy commands from their attacking Linux machine through various compromised machines to traverse network boundaries and firewalls, while evading detection. They use it when they want to use the Linux operating system to hide their identity on a network. ProxyChains routes the TCP traffic of pen testers through the following proxies: TOR, SOCKS, and HTTP. TCP reconnaissance tools such as NMAP are compatible – and the TOR network is used by default. Security pros also use ProxyChains to evade firewalls and in IDS/IPS detecting.
Cost: Free open source tool.
8. Responder simulates attacks on DNS systems
Responder is an NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) and mDNS (multicast DNS) poisoner that is used by penetration testers to simulate an attack aimed at stealing credentials and other data during the name resolution process when no record is found by the DNS server.
The latest version of Responder (v. 3.1.1.0) comes with full IPv6 support by default, which lets security pros perform more attacks on IPv4 and IPv6 networks. This is important because Responder had lacked IPv6 support and therefore missed several attack paths. This was especially true on IPv6-only networks or even mixed IPv4/IPv6 networks, particularly when you take into consideration that IPv6 has become the preferred network stack on Windows.
Cost: Free open source software.
9. sqlmap looks for SQL injection flaws in database servers
sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws that could be used to take over database servers. The tool comes with a powerful detection engine, and boasts many features for penetration testing including database fingerprinting, accessing the underlying file system and executing commands on the operating system via out-of-band connections.
Security pros say it helps them automate SQL discovery and injection attacks against all major SQL back-ends. It supports a wide range of database servers, including MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB and HSQLDB. It also supports various kinds of SQL injection attacks, including boolean-based blind, time-based blind, error-based, stacked queries, and out-of-band.
Cost: Free open source software.
10. Wireshark: Popular network protocol analyzer
Wireshark, which has been around since 1998, is a network protocol analyzer, commonly called a network interface sniffer. The latest update is Version 3.6.3.
Wireshark lets security pros observe a device’s network behavior to see which other devices it is communicating with (IP addresses) and why. In some older network topologies, network requests from other devices pass through the network interface of a security pro’s device, allowing them to observe the entire network’s traffic, not just their own. Security experts say it’s a great tool to figure out where the DNS servers and other services are for further exploitation of the network. Wireshark runs on most computing platforms, including Windows, MacOs, Linux, and Unix.
Cost: Free open source software.Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.