Randy Calvert

Moving to cloud would remove any infected files because they don’t use the original raw files provided by you. They want the source files to get to the uploads folder and the folder with third party resources in it. The main IPB core files with source code are not used. So in a majority of the cases it should fix it. But for example if your theme was edited, that might be carried over too. It depends on exactly what is injecting the bad code. That’s why it’s hard to give you a simple yes/no answer. It depends on what is actually the root cause of your problem. But if it’s on the cloud and having issues still, they should be able to help isolate where it’s happening. (For example having you switch to a default theme to see if it fixes problem.)

It's always good to be safe! 😄

Yes via FTP and overwrite anything. All the current images and data would be safe. The data is in the database and user uploaded images would not be in the files downloaded from the client area. You're replacing IPB core system files, not the user generated ones.

Are you using a proxy, firewall, or a cdn or something else in front of the server?

If you maintain control of DNS, the biggest problem will be dealing with the domain apex. domain.com (the apex) cannot be a CNAME according to RFC standards. www.domain.com (or any subdomain) can be. If you control DNS, it’s not easy to point the apex to IPS as they use load balancers to distribute load to multiple servers. You could create a redirect on your current VPS to take domain.com and issue a redirect to www.domain.com or use cloudflare simply to have a rule to direct domain.com to www.domain.com. For most people, this is too much work and headache so it’s easier to have IPS manage DNS so they can handle all of the changes themselves. They can map the apex through AWS since they also manage the load balancer. I have both cloud and self hosted like you are proposing and it works just fine!

One thing to consider/investigate… any chance are you using sql replication or sharding, or anything were multiple database instances are involved?

4.6 to 4.7 does not change the database for post content. So it’s not like upgrading from version 3 to version 4 where there was db conversations and content conversions. But there may be some components that might need to rebuild such as the search index or achievement recounts etc. Those activities may be done in the background and take a long time. The biggest change from 4.6 to 4.7 was the move to php8. You will need to move to php8, make sure it’s compatible with the latest version of IPB and then upload fresh files from the client area and manually upgrade (domain.com/admin/upgrade). You would also have to make sure any third party resources/applications have php8 compatible versions. That honestly is your biggest chance of downtime.

If they were added via the recommended way (from the integrations section of ACP for GTM for example), it’s preserved. If you manually stuck it in your theme, you might have to manually update your theme.

He most likely has old GA tag (UA) and needs to replace it with GA 4 tag. Google is ending support for UA in July and requiring people to move to new GA4 tag. If you did the initial integration of the UA tag the recommended way, it would be in ACP - System - Site Features - Integrations. Choose Google Analytics and update the code. If you manually edited your theme, you would have to do that again there.

Run a diff between the suspected file and the same file from the client area. That will tell you if the file was actually modified. If there is no difference between the two, it’s a false positive issue with the scanner. If you for some reason can’t do an auto update, download a set of files from the client area, upload them, and run domain.com/admin/upgrade.

Are you hosted in the IPS cloud or are you hosted elsewhere? If you are hosted elsewhere, this is something your host will have to help with. It's not a software issue.

It's a pretty reliable/safe operation. I've done it multiple times personally. (I had a few sites that came all the way back from 1.x!) As a best practice, it's recommended you take a backup of the database before any changes just to be 100% safe. I would PERSONALLY recommend using SSH to do the change instead of phpMyAdmin so that you don't run into any timeout issues. If the table is small enough though, phpMyAdmin might work.

The feedback you’re getting is that this is a server level setting. You should be setting it in your MySQL my.cnf. The server sets the default engine type, not the software.

Looks like it does for me.

It's a problem with the language pack itself. You might need to work with the author for it.

If you have not updated in that long, you will most likely need to upgrade PHP and make sure your server meets the requirements. Once on PHP8, run the following script: Again, only do it after you switch to PHP8. It will tell you if it is ready for the latest version of IPB. Temporarily disable any third party plugins/applications. Once everything is good, download a set of files from the client area and upload them to your site. (Replacing everything already there.). Then run domain.com/admin/upgrade. Let it walk you through upgrading. Once done, login to ACP, make sure any resources are updated and turn them back on. Test things to make sure they're good! You might need to update your theme or switch to a new default as well if your theme is super old.

Anything uploaded by the users would be located in the /uploads/ folder typically in a subfolder like monthly_XX_XX like: /uploads/monthly_2023_04

The server itself may be up, but something like a firewall (like cloudflare) or mod_security or anything else might be disrupting the path. Unfortunately this is not a solution in the software.

If you have not already looked into it... there is a 3rd party company called CleanTalk that has been a big help in reducing spam on my site as well. It's 12 bucks a year, and there are lots of ways of getting additional free time. It's not perfect, but it catches a lot. When combined with IPS anti-spam and hCaptcha, I only have 1-2 that get through a week with more than 400 attempts weekly.

It's happening across the board. It's targeting all sorts of sites. Not just IPB, but anything online where users can submit content.

There is no capability to do that (yet). That sort of request is great for the feedback forum.

The cheapest solution is typically not really a good solution. It means you gotta deal with the crap like bad and unoptimized configurations. In my experience the equation is GOOD, FAST, and CHEAP. But you can only pick TWO.

No. There is not a separate change log posted other than the description shown at the time you patch.

What happens when you try to run the following command from the server via SSH? curl -svo /dev/null https://remoteservices.invisionpower.com If the above command does not work, it's a firewall issue. The output SHOULD look something like: curl -svo /dev/null https://remoteservices.invisionpower.com * Trying [2600:9000:2508:ec00:16:1470:7d40:93a1]:443... * Connected to remoteservices.invisionpower.com (2600:9000:2508:ec00:16:1470:7d40:93a1) port 443 (#0) * ALPN: offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): } [337 bytes data] * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): { [122 bytes data] * (304) (IN), TLS handshake, Unknown (8): { [19 bytes data] * (304) (IN), TLS handshake, Certificate (11): { [5030 bytes data] * (304) (IN), TLS handshake, CERT verify (15): { [264 bytes data] * (304) (IN), TLS handshake, Finished (20): { [36 bytes data] * (304) (OUT), TLS handshake, Finished (20): } [36 bytes data] * SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 * ALPN: server accepted h2 * Server certificate: * subject: CN=remoteservices.invisioncommunity.com * start date: Feb 24 00:00:00 2023 GMT * expire date: Feb 8 23:59:59 2024 GMT * subjectAltName: host "remoteservices.invisionpower.com" matched cert's "remoteservices.invisionpower.com" * issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02 * SSL certificate verify ok. * using HTTP/2 * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: https] * h2h3 [:authority: remoteservices.invisionpower.com] * h2h3 [user-agent: curl/7.71.1-DEV] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x7f8ae000f400) > GET / HTTP/2 > Host: remoteservices.invisionpower.com > user-agent: curl/7.71.1-DEV > accept: */* > < HTTP/2 500 < content-type: text/html; charset=UTF-8 < content-length: 0 < date: Sat, 17 Jun 2023 15:09:46 GMT < set-cookie: AWSALB=NcKhSYLwWLgh7aoGLNLNvun4SZ2jppFOAQ7+R4MXstAJutTYeHbMBytHjYTjQl7deYakTzjIZtpFQhOrH+heaCsP0G+Ezlz/wZEu/AGSPf36y2umJMkaYAazjQgW; Expires=Sat, 24 Jun 2023 15:09:46 GMT; Path=/ < set-cookie: AWSALBCORS=NcKhSYLwWLgh7aoGLNLNvun4SZ2jppFOAQ7+R4MXstAJutTYeHbMBytHjYTjQl7deYakTzjIZtpFQhOrH+heaCsP0G+Ezlz/wZEu/AGSPf36y2umJMkaYAazjQgW; Expires=Sat, 24 Jun 2023 15:09:46 GMT; Path=/; SameSite=None < server: Apache < x-cache: Error from cloudfront < via: 1.1 c625b1bdde545acdeb26c9f6ad3a8c6e.cloudfront.net (CloudFront) < x-amz-cf-pop: IAD12-P1 < x-amz-cf-id: FL5WuKYD_sg0GW2jdobrQeVb2B6Iusx0DUKg7ymsCEcRDlZZtia1qw== < { [0 bytes data] * Connection #0 to host remoteservices.invisionpower.com left intact If you don't have the above, it means the firewall never allowed the outbound request. Firewalls have two network paths. Inbound (meaning from the internet to your server) and outbound (from your server to the internet). Your firewall sounds like it is blocking OUTBOUND while allowing INBOUND. If you are not sure how to fix this, you would need to work with your hosting provider.

Those are all inbound services. You don’t want your firewall restricting outbound connections.