Welcome to Invision Community 4.3!

This release brings numerous improvements and several new features, so be sure to read our announcement for everything new!

Version 4.3.1 is a small maintenance update to fix issues reported since 4.3.0.

**IMPORTANT UPGRADE NOTICE**
Please note that not all third party applications and themes are yet compatible with Invision Community 4.3. If you utilize third party resources, including custom themes, please ensure they have been declared compatible by their respective authors or your site may be non-functional after upgrade. There is a new compatibility field on all marketplace resource listings. If this field is missing or does not specifically list 4.3, it is likely not yet compatible.

Also included: 4.3.0

Welcome to Invision Community 4.3.0!

This release brings numerous improvements and several new features, so be sure to read our announcement for everything new!

**IMPORTANT UPGRADE NOTICE**
Please note that not all third party applications and themes are yet compatible with Invision Community 4.3. If you utilize third party resources, including custom themes, please ensure they have been declared compatible by their respective authors or your site may be non-functional after upgrade. There is a new compatibility field on all marketplace resource listings. If this field is missing or does not specifically list 4.3, it is likely not yet compatible.

noticed this today

[Mon Apr 23 14:43:17.269029 2018] [ssl:error] [pid 26654:tid 140572910118656] AH01941: stapling_renew_response: responder error
[Mon Apr 23 14:43:32.308002 2018] [ssl:error] [pid 26035:tid 140572815709952] (70007)The timeout specified has expired: [client 94.66.43.86:39010] AH01974: could not connect to OCSP responder 'ocsp.comodoca.com'
[Mon Apr 23 14:43:32.308091 2018] [ssl:error] [pid 26035:tid 140572815709952] AH01941: stapling_renew_response: responder error
[Mon Apr 23 14:43:35.311210 2018] [ssl:error] [pid 27055:tid 140572773750528] (70007)The timeout specified has expired: [client 85.76.98.195:27343] AH01974: could not connect to OCSP responder 'ocsp.comodoca.com'

and decided to look around

https://forums.cpanel.net/threads/any-problem-with-ocsp-comodoca-com-ssl.625667/

We are aware of the issue with Comodo as well and we're currently tracking it as part of an internal case CPANEL-19612. We'll update this thread with more information as soon as it becomes available

You can work around this issue by temporarily disabling SSL Stapling in Apache. This will cause client browsers to perform the OCSP check instead of waiting on your server to perform the check. The quickest way to do this is to:

1) Navigate to WHM -> Service Configuration -> Apache Configuration -> Include Editor.
2) Under "Pre Virtualhost Includes" set the drop-down to "All Versions"
3) In the text box, enter the following:

SSLUseStapling off

4) Click "Update" to save the changes, and then restart Apache.

=====

Alternatively, if you wish to do this via the command line, the following can be run:

For EA4:
== == == == == == == ==
echo "SSLUseStapling off" >> /etc/apache2/conf.d/includes/pre_virtualhost_global.conf; /scripts/restartsrv_httpd
== == == == == == == ==

For EA3:
== == == == == == == ==
echo "SSLUseStapling off" >> /usr/local/apache/conf/includes/pre_virtualhost_global.conf; /scripts/restartsrv_httpd
== == == == == == == ==

Once this issue has been resolved, we recommend removing this workaround.

Thank you,

still looking for more resources

https://support.comodo.com/index.php?/comodo/Knowledgebase/Article/View/1016/0/enable-ocsp-stapling-on-apache

Invision Community 4.3

κάτι ήξερα ισως και εκοβα ακομη και την 8083 by default. μεχρι τώρα δεν εχω βρει κάτι κάπου

εχω δεί τόσα vesta να σπάνε on update που να δείς οτι ίσως λύσει το θέμα και δημιουργήσει άλλα

alarming, to say the least

31^st of March is World Backup Day, a global initiative that aims to get organisations and individuals to pledge to back up their data on that day. As a web host, it’s something we fully support and we’ve written this article to explain why you should join in. To give you a little more incentive, we’ve also got a couple of superb backup deals on offer which we’ll tell you about at the end of the post.

If you’re one of our regular readers, you’ll know that this is not the first post we’ve written about backups – and it’s unlikely to be the last. Backing up is one of the things that people need to be constantly reminded to do. Most of us know why we should but, for some reason, we don’t always see it as a priority. Data loss is what happens to others – isn’t it?

If you aren’t overly concerned about the need to backup your data, here are a few points to get you thinking.

Malware vulnerability                                          

According to Sophos, over 300 million new pieces of malware are created to infect websites and computers every year. This results in 10% of all computers being infected every month and 30,000 websites being infected every single day. When viruses infect, data is lost and software is corrupted.

And these infections can spread beyond just computers and websites. Viruses can be transmitted to phones, tablets, pen drives, camera cards and other storage devices – and done so unwittingly by employees and customers.

Whilst antivirus software can usually protect you, the companies that make the software have to detect the malware first and then discover a way to eradicate it. Unfortunately, you can’t detect malware until it is already out there doing damage in the first place.

Having a clean backup means your data isn’t lost and your business recovers far quicker and with significantly less expense.

Hacking

Surprisingly, most website owners think hacking is a conscious undertaking done by an individual who chooses a company to target. This leaves them to believe that no-one would be interested in hacking their organisation and so they have little to fear.  “We’re a plumbers’ merchant in Hampstead Heath, nobody would want to hack us.”

It doesn’t quite work like that.

Hacking is very much an automated process where computer programs, not too dissimilar to Google’s search bots, scour the entire internet looking for sites which have vulnerabilities.  It is these sites which are then targeted; and the actual break in is much more likely to be done using highly sophisticated software rather than by some hooded character, wearing a Salvador Dali mask, beavering away at a keyboard.

Anyone who has any kind of hacking detection software, such as the WordPress Wordfence plugin, will know that even small websites have multiple attempted break-ins on a daily basis. Indeed, 66% of all attacks are on SME’s and in 2016 there is expected to be a 37% increase in the number of attacks.

Whilst one of the biggest threats of hacking is that data will be stolen, there is also the risk of data being lost. Once an intruder has access to your admin panel, there is nothing they cannot do. If they wish, they can delete everything and take down your entire system.

I put it somewhere….

Human error is one of the most significant causes of data loss for businesses. Hundreds of thousands of computers and phones go missing every year.  Even back in 2008, a study found that 12,000 laptops were lost every week, just in US airports. If you are a small business and you keep your entire business records on your laptop, losing it can have enormous consequences: invoices, clients’ work, contact details, emails, website content, account details, logins, portfolios… all of it important information. It’s not just a matter of it potentially being stolen or accessed, if it is not backed up, it’s gone.

It’s not just misplacing hardware where human error causes problems; we erroneously delete data and carelessly break our devices.

There are 84,900,000 results on Google for the term ‘phone down the toilet’ and over 25 million for ‘spill water on computer’ which indicates how many people have put their data in jeopardy just by accident. And, of course, devices are prone to breaking down and hard drives to failing.

A regular backup would ensure that when your device dies, the data will live on and your organisation can make a full recovery.

Make your World Backup Day pledge

We’d like to think that we’ve done our bit here to remind you just how important backing up your data can be and hopefully this will encourage you to support World Backup Day on 31^st March by pledging to backup on that day.  You can find out more about World Backup Day by watching the video below.

Need an incentive? Here are our offers

Hopefully, we’ve convinced you that regularly backing up your data is absolutely essential. To make things easier we have got two offers which you might be interested in.

Firstly, if you buy any of our VPS, Cloud or Dedicated server packages on World Backup Day, 31^st March, well give you a 25GB of backup storage, FREE for 12 months. If you don’t need a VPS, Cloud or Dedicated server package but still want a backup facility, we’re offering 25% off any backup purchased on 29th, 30th, 31^st March.

I am using rsync to recursively sync a remote folder tree that looks something like the following:

/folderA/a1/cache
/folderA/a1/cache/A1
/folderA/a1/cache/A2
/folderA/a1/somefolder
/folderA/a1/someotherfolder
/folderA/a2/somefolder/cache
/folderB/cache/
/folderB/b1/somefolder/cache
/folderB/b1/somefolder/yetanotherfolder/cache
/folderB/b1/somefolder/yetanotherfolder/cache/B1
/folderB/b1/somefolder/yetanotherfolder/cache/B2

I don't know what the folder tree will look like and it will change over time. So what I want to be able to do is recursively rsync the above but exclude the folder "cache" and any sub folders it contains so that I ultimately end up syncing:

/folderA/a1
/folderA/a1/somefolder
/folderA/a1/someotherfolder
/folderA/a2/somefolder
/folderB/
/folderB/b1/somefolder
/folderB/b1/somefolder/yetanotherfolder/

Any suggestions?

>>

You want the --exclude flag. For example, a local rsync:

rsync -a --exclude cache/ src_folder/ target_folder/

https://unix.stackexchange.com/questions/5774/rsync-excluding-a-particular-subdirectory-and-its-children-where-the-subdirect

many many solutions !

https://stackoverflow.com/questions/42385099/1273-unknown-collation-utf8mb4-unicode-520-ci

https://krikienoid.github.io/flagwaver/

It is very easy. The solution is on nixCraft, but on the comments.

## 64 bit linux ##
wget https://www.rarlab.com/rar/rarlinux-x64-5.5.0.tar.gz
tar -zxvf rarlinux-x64-5.5.0.tar.gz
cd rar
sudo cp -v rar unrar /usr/local/bin/

There’s no need to compile or anything. The binary on the tar file works out of the box. On the above example, we copy it on /usr/local/bin so it is found by default after login on our system. Other “exotic” solutions are possible, but I don’t want to make suggestions.

https://bitsanddragons.wordpress.com/2018/01/09/install-rar-unrar-on-centos-7/

Rest In Peace, Professor

always useful

https://github.com/rezasp/joomscan

this one is ready

Your Invision Community 4 is ready

The upgrade process is now complete and your Invision Community is now ready!

underway, i have to also cover a glitch with their system while trying to pay for license

"Sorry, there is a problem

Changing the Postfix maximum email size

I've recently had some of my customers emailing me large image attachments and my Postfix mail server has been rejecting them. A quick look at the postfix configuration showed the message size limit was the default so I needed to increase it. This post looks at how to see what the current email message size limit is with Postfix and how to change it.

The configuration option is "message_size_limit" and by default is set to 10240000 bytes which is roughly 10MB. You can see what setting your postfix install is currently using by issuing the following command:

postconf | grep message_size_limit

Just doing "postconf" on its own will show all the options so using grep on "message_size_limit" filters the output to just the setting we want. For the default setting, you'll see this:

message_size_limit = 10240000

To change the setting to some other value, open the main.cf file in your favourite text editor (it's often at a location like /etc/postfix/main.cf) and either edit or add the following line, depending if it's already in the file or not.

message_size_limit = 20480000

In the above example I've changed it to ~20MB.

Then reload postfix like so:

service postfix reload

and your setting will take effect. You can query postconf again if you want to check all is as expected.

https://www.electrictoolbox.com/postfix-email-size-limit/

$ echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u 127.0.0.1 11211

If you see non-empty response, your server is vulnerable.

The Israeli security researcher Barak Tawily a vulnerability tracked as CVE-2018-6389 that could be exploited to trigger DoS condition of WordPress websites.

The expert explained that the CVE-2018-6389 flaw is an application-level DoS issued that affects the WordPress CMS and that could be exploited by an attacker even without a massive amount of malicious traffic.

“In this article I am going to explain how Denial of Service can easily be caused to almost any WordPress website online, and how you can patch your WordPress website in order to avoid this vulnerability being exploited.” reads the analysis of the expert.

Tawily reported this DoS vulnerability to the WordPress team through HackerOne platform, but the company refused to acknowledge the flaw.

“After going back and forth about it a few times and my trying to explain and provide a PoC, they refused to acknowledge it and claimed that:
“This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.“” Tawily wrote.

The expert has implemented the mitigation against this vulnerability in a forked version of WordPress, he has also released a bash script that addresses the issue.

https://securityaffairs.co/wordpress/68709/hacking/cve-2018-6389-wordpress-dos-flaw.html

Yesterday (Monday, February 5, 2018), a zero-day vulnerability in WordPress core was disclosed, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks.

WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit.

The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive.

Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesn’t retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com. Hence, appending these JS files to the requested list is useless from an attacker’s perspective.

Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isn’t recommended and a simple authentication-based whitelist will not work either because it may break the login page.

WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall / web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions.

Until today (February 6, 2018), we have only seen a few dozen exploit attempts using this vulnerability, but we might see a steep rise in attacks using this exploit due to the popularity of the platform, unless a mitigation will be applied in the near future.

It is advised to set access restrictions to the “load-styles.php” and “load-scripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources.

Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”. In a testing environment in our lab we didn’t encounter any such errors and thus we assume that altering the “noop.php” is not obligatory for all WordPress users.

We did not extensively test this patch in our lab, and as of today, it wasn’t integrated into the main WordPress repository. Thus, we cannot recommend this solution, as it deviates from the WordPress core source and may cause compatibility issues.

After analyzing the data on our CDN, we have deployed mitigations against this vulnerability, which are enabled by default for all Incapsula sites with protection against “Illegal Resource Access”.

https://www.incapsula.com/blog/cve-2018-6389-wordpress-parameter-resource-consumption-remote-dos.html?mkt_tok=eyJpIjoiWkdVNE5UUXhaalUxTUdZMSIsInQiOiJzSEl2RzJvaDZXM0FuWWJ6R1Z2SlNzdUU4OEh0Q0JZcXlhcTYzc0FUbW9hOUFwaFwvMmlmN0Y0bitEREtNUzlwYjk3SWdsOEVtZ2pkQlZ2TFZYTWlwUG1ndWhnaW42K1N6ODdSRFdMZ0YzSzI2eWpEbkhZaVYreWdxMUhKZ0NTakwifQ%3D%3D