I have a WordPress blog on an AWS EC2 server. I followed this tutorial from AWS for configuring the web root /var/www/html permissions to directories 2775 and files 0664 with ownership apache:apache, and I was able to install my site and edit it through wordpress normally.
However, last week I noticed odd behavior on the site and upon looking at the web root, I found a new directory had been created that was full of spammy php files. The directory had a random name and ownership apache:apache
This is a webserver, so it has 0.0.0.0 access on ports 80 and 442 (I have SSL through LetsEncrypt and HSTS).
My question is: how was someone able to create a new directory on my server and how do I prevent it from happening in the future? My ec2-user uses an SSH key for login and I have not created any other users on the server. I know now that 775 is probably too open, but if apache does not have a login how could someone write to this directory?
You can set in-bound rules on your instance security group to access or allow SSH using your IP address to prevent other attack and make sure you can use a nulled or hack script on the website.
Related
I have a bitnami WordPress instance using AWS lightsail. I need to migrate the site to another identical AWS instance. I created a PHP installer from the first instance using the Wordpress Duplicator plugin.
I then uploaded the file onto the new server to a folder (opt/bitnami/apache2/htdocs/).The instructions I've seen online they say I just need to navigate to the location of the installer in a browser and it will run. However, when I attempt to access the PHP file from a browser I just get an error on the front-end saying:
OOPS! THAT PAGE CAN’T BE FOUND
I have seen suggestions online that the installer be placed into a public folder called html_public but my instance doesn't have a folder like that. I changed the access rights to the folder, and the installer, to be full rw access.
Any ideas how I can get this to work?
You must config the Security Groups firewall to open the HTTP port.
Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/]
On the Inbound Rules tab, choose Edit the port range 80, 443 - Source: Anywhere - IP Address: 0.0.0.0/0 and Save.
I just received a zip file containing the mydomain.crt and mydomain.ca-bundle files. I would like to know how to install the certificate for a WordPress website hosted in a Google Cloud Platform instance. I have the instance configured with the common Bitnami software ( Apache 2.4.25, MySQL 5.7.18, OpenSSL 1.0.2k, PHP 7.0.18, phpMyAdmin 4.7.0, SQLite 3.7.15.1, Varnish 4.1.0, WordPress 4.8). I found plugins available from WordPress such as Really Simple SSL or Cloudflare, but I would like to avoid the use of plugins. Thanks.
You want to follow apache instructions on installing SSL cert onto your website. Meaning, you will need to install the certificate by generating the keys and restarting your server. Being on the cloud or being on a hosted server that's not on the cloud shouldn't matter, it's a web server although you have to make sure port :443 is in your security firewall is allowed otherwise you're https request will change.
Once you've done that, and the installation is successful, you should see a lock next to the https request with the domain information you gave when you installed the ssl certificate. Let us know what kind of problems you ran into, otherwise you should be good to go. You may need to change all your referencing urls that is http to https with mysql search and replace query afterwards.
I found all the required information in this page Bitnami WordPress for Google Cloud Platform. Once you have your certificate generated (self-signed or from an official Certificate Authority), which usually contains 2 files (yourdomian.crt and yourdomian.ca-bundle), the simplest procedure is:
Upload those two files to /opt/bitnami/apache2/conf
If it is a fresh install, in that folder you should have the server.key, server.crt and server-ca.crt original files. Make a backup of them and delete them, or just rename them like server_b.key, server_b.crt and server-ca_b.crt
Rename yourdomian.crt to server.crt and yourdomian.ca-bundle to server-ca.crt
In the same folder /opt/bitnami/apache2/conf place a copy of the key used to generate the certificate signing request (CSR), and rename the key to server.key
Open the configuration file with sudo nano/opt/bitnami/apache2/conf/bitnami/bitnami.conf if you are not root.
To the section add SSLCACertificateFile "/opt/bitnami/apache2/conf/server-ca.crt" if using Apache v2.4.8+, or SSLCertificateChainFile "/opt/bitnami/apache2/conf/server-ca.crt" if using Apache < v2.4.8 and save the changes
Make your files only readable by root with sudo chown root:root /opt/bitnami/apache2/conf/server* and sudo chmod 600 /opt/bitnami/apache2/conf/server*
Restart apache with sudo /opt/bitnami/ctlscript.sh restart apache
That worked for me to have a Certificate Authority (CA) produced SSL certificate working for my WordPress site, hosted in a Google Cloud VM without installing any third party plugins. As #unixmiah pointed out, do not forget to open port 443 in the server firewall.
I cannot locate a account from WHM (list accounts). I can access cpanel for that domain (mysite.com/cpanel).It just disappeared from whm. So now I cant directly go to mysite.com. I don't have a backup but all the files and db exist for that domain. Any solution to this problem because I cant find such a thing.
How do i find the option via WHM Control Panel?
If you have root SSH access of our server then check /etc/trueuserdomains and /etc/userdomains file because you without root access you can not check these files. if you have only cPanel access then you need to contact your hosting provider to check your mission domain logs.
Was there any cPanel upgrade performed on server recently?
If you have root access then login to your server via SSH and run the following command:
$ /scripts/rebuildcpusers
It should rebuild files for each domain under /var/cpanel/users from source databases.
If you has a root acces to server
Access SSH to server
Check /etc/userdomains – this file should contain the the domain and username that’s missing.
Check /etc/trueuserdomains domain.com: username
Check /var/cpanel/users/USERNAME
/var/cpanel/users/USERNAME
DNS=domain.com
IP=ipaddress
USER=username
OWNER=root (This will be set to ‘root’ unless the account was created under a reseller).
Check the Apache configuration file /etc/httpd/conf/httpd.conf and make sure that a virtual host exists for your domain. Try to rebuild apache /scripts/rebuildhttpdconf
Finally run /scripts/updateuserdomains
I have XAMPP running fine on one machine and I have 2 WordPress installs running fine on that machine. I would like to be able to access and work on those WordPress installs on other machines on my network.
Right now, I have it set so that if I try to access those directories from another computer on the network, all I get is either the XAMPP splash screen, or a 404 error if I try to access specific folders.
I've researched this and researched this and I have found numerous posts about how to do this.... but only in bits and pieces.
Does anyone know of a step by step, start to finish, guide of how to do this? In layman's terms?
Remote (from another network) would be great too. But I'll cross that bridge once I figure this out.
Any help would be appreciated.
Thanks!
I would suggest rather than shared folders you use an FTP client / server - I use Filezilla server and client for my local sandbox testing server. This will give you additional info like file and folder groups and permissions.
Got to ask the question what OS? have you opened port 80 on the server machine?
Things like this can also occur on Linux if the folders and files do not have the correct groups for access and or permissions.
chown -R apache:apache /var/www/html
the above if on linux will assign all the folders and files to be accessed by the apache process. not having the correct groups assigned can give you 404 when you know the files are actually there.
also check the file and folder permissions,
different files and directories have permissions that specify who and what can read, write, modify and access them - this wordpress page gives a good overview of permissions
http://codex.wordpress.org/Changing_File_Permissions
edit p.s. to access then from other networks all you will have to do is forward ports from your router to your internal server then your ftp and www services will be accessable from the outside world. I would suggest using a .htpass htaccess password to protect your services at this point.
I built a WP site on a particular server. I did not set or change any folder permissions and everything worked perfectly. Mainly, I could upload files and images.
I then moved the install to a different server and domain. Suddenly I could not upload to the media library.
On checking the permissions of the wp-content folder and its sub-folders the permissions were set to 755. I only assume this is what they were set to on the previous server.
By setting them to 777 I could then upload files but understand this is a big security risk. I then set it back to 755 and cannot upload again.
Can anyone explain why 755 is ok on one server but not on another please? and what I could do on the new server to make 755 acceptable?
The file permissions are correct 755, you'll have to check the file owner also.
Do not assume the file permision and owner on the development server will be correct on other servers (different os's can give issues as the one you have, different webservers from different os's can give again issues as above).
It also depends on the way you upload your files:
-you can do it throw ftp then you'll have to check the ftp settings (how it saves the files, under which user).
-if you use ssh to upload then it depends on the user that you used to connect to the server
and so on... (I saw the ftp tag but wanted to describe this also )
At this point you'll have to make sure that the website files have as owner the webserver (different server setups require different websrevers - www-data vs apache vs ... )
In the end it depends on the control (options you can change) on the server, do you have ssh access? Do you have to contact your host for this corrections?
If you are not administrating this new domain server then contact it's administrator it is a setting issue(of the ftp ) or a bug/error that he should handle.