Recently I started a new WordPress blog and didn't add any forms for user registrations. But I got a email from my site saying that new users was registered. Still I haven't written any post or didn't advertise anything. still Im building it. When I check the site users it was as below.
Now my questions are,
1) What kind of attack is this. How did a attacker find my site while im just building it?
2)They are registered as subscribers, am I safe to just delete them?
any guideline from an expert will be highly appreciated. please advice me what should I do? Thanks.
Is it on WordPress.com or self-hosted? And yes, it's ok to delete them.
It may not be an 'attack'. If you are on WordPress.com (or even self-hosted) it may just be other users that came across the site. There are a lot of possibilities of who they are.
You can turn off allowing registrations in your Admin Settings and put up a landing page to show no content to unauthorized users while you're working on it.
If you're self-hosting it you can use your .htaccess to allow only your own IP address access while you're working on it.
.htaccess
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^YOUR_IP_ADDRESS$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>
Also, just to make sure no one has tried an attack, you can use a plugin like WordFence to do a security audit.
You can use the Wordfence plugin to secure your WordPress installation. The Wordfence plugin protects against brute force attacks and allows blocking ips.
Related
I have a wordpress site on SiteGround and have hundreds of attempts entering looking for http://example.com/?option=com_k2&view=itemlist&task=user&id=93265
The old site used Joomla and it appears that bots still have the site on their list.
Please let me know if there is a way to prevent these requests from causing an "execution" of index.php as this has a 20,000 execution daily limit on Siteground shared host. Passing the limit causes the site to be disabled.
Thanks in advance for any suggestions.
Found this on http://botcrawl.com/how-to-block-incoming-traffic-backlinks-attempted-site-hijacks-and-multiple-urls-in-the-htaccess-file/
RewriteCond %{QUERY_STRING} option=com_k2
RewriteRule ^ - [F]
It appears to working. I'll write back if not.
This problem started yesterday.
When the public visitor view my website, the Wordpress navigation bar will appear on top of the page as if they are a login user. They can even see the greeting message on top right corner, "Howdy, John(My name)"
The good news is, these public visitors will not be able to access the wordpress configuration page. They can only thee the top navigation bar when they view the page.
My question is, what is going on?
Could it be a plugin?
Could it be CDN (Cloudflare) problem?
Could it be the hosting site problem?
or could it be a hacker's deed?
Please help, I have no idea where to begin with.
You're probably serving fully cached pages (which includes the logged-in user content) for all visitors. This means that a new visitor will get served the exact same HTML and other assets that have been served earlier for a logged-in user.
I would start by checking the Cloudflare settings and see whether there are any options for disabling the cache for certain types of visitors (e.g. validated by cookies).
Problem solved.
Apparently, the culprit is the wrong configuration in Apache Server.
One of our engineer added the snippet below into the .htaccess as a recommendation from LiteSpeed module for Wordpress. This little devil makes Apache server to do full-page caching.
<IfModule LiteSpeed>
CacheEnable public /
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET)$
RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-login.php|wp-cron.php)
RewriteRule .* - [E=Cache-Control:max-age=120]
</IfModule>
Thank you #ojrask for pointing out the possibility of full-page caching in Apache Server.
I've searched this site without finding the answer to my specific query. Many apologies if I have overlooked the answer.
I'm looking to block direct access to the files in a folder - which I have learned I can do with "deny from all" in .htaccess - AND allow WordPress access to these files. The idea is not to let anyone access the images directly, but still have them show up in blog posts. When I use "deny from all", WordPress does not have access. How do I fix that?
When you say "allow WordPress access to these files", I'm guessing what you really mean is "allow people who are on a WordPress page to have direct access to these files", because it's not wordpress that is accessing the files, it's still the client/browser accessing them directly. That's why when you use Deny from all, they can't see images linked in a word press page.
You can deny by referer, though there's easily ways to get around that. Something like this in the htaccess file in your document root for example (preferably before any wordpress rules):
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^https?://your.wordpress-site.com/ [NC]
RewriteRule \.(jpe?g|gif|png)$ - [NC,L,F]
would deny access to images if the images aren't linked from your wordpress site (replace your.wordpress-site.com with the hostname of your site).
I'm planning on using Wordpress on an upcoming project and the biggest question for me is security.
I will be having several users who will be able to update the site and I've given myself several options. I can build a static web page and then have a 'blog' page that is using a WordPress install for that page only. This seems a bit excessive just for a blog feature, but it's an option.
The other option I'm looking at is a full WordPress install to power the whole site. My big issue is blocking the /wp-admin from everyone but the people at a static IP that won't be changing. I'm thinking if I go this route I can use my .htaccess to check the IP and if it returns false, redirect it to the homepage. If it is true, then continue on to the wp-admin login page.
If I go with my second option, how do I use .htaccess to check the IP and if it returns false, redirect back to the homepage. And if it's true, continue to the WordPress login page.
Is this best starting point?
<Location /wp-admin/>
order allow,deny
allow from 1.1.1.1
deny from all
</Location>
I appreciate any input ahead of time!
You cannot use Location in a .htaccess file. As you can see from the Context it is only allowed in the main server configuration file or in a virtual host section.
Furthermore, you shouldn't use it for security, if wp-admin is a real directory in the file system
<Location> Directive
<Location> sections operate completely outside the filesystem. This has several consequences. Most importantly, <Location> directives should not be used to control access to filesystem locations. Since several different URLs may map to the same filesystem location, such access controls may by circumvented.
If you use Access control by host, the order should be
Order deny,allow
Deny from all
Allow from 1.1.1.1
This ensures, that anybody is prohibited to access /wp-admin/, except the given IP addresses or domains.
I think this is documented here: http://httpd.apache.org/docs/trunk/howto/auth.html
You may need to couple it with this: http://httpd.apache.org/docs/2.2/howto/htaccess.html, and this: http://httpd.apache.org/docs/trunk/mod/mod_authz_core.html#require
But, it appears that something like this could work:
<Directory /wp-admin/>
Require ip 192.168.1.104 192.168.1.205
</Directory>
Full disclosure: I'm guessing.
I was able to use what Olaf Dietsche wrote to lead me in the right direction. By putting the below code in my wp-admin folder instead of the root, I was able to control who had access to my url/wp-admin login and if they didn't match the allowed IP, then I redirect them back to the home page.
Options +FollowSymlinks
RewriteEngine on
#urls to exclude
RewriteCond %{REQUEST_URI} !/wp-admin$
RewriteCond %{REQUEST_URI} !^/images$
RewriteCond %{REQUEST_URI} !^/$
#ip to allow access
RewriteCond %{REMOTE_HOST} !^111\.111\.111\.111$
#send to root. If you want a specific URL, use /yourcustomurl.html
RewriteRule .? / [R=302,L]
I appreciate the input everyone. And thank you much!
I would like to know every solutions and keep only the best one to "close a website to every anonymous user". An anonymous user should only have the login form.
Existing ways:
using zope security (remove View permission to anonymous on root plonesite)
using workflows (changing security mapping of published state)
using apache in proxy with http auth
Is there other solutions ? What is the best one ?
Note: I had an issue when trying using zope security even the login form was not accessible, so please details a bit your way to achieve this.
I would use http://pypi.python.org/pypi/iw.rejectanonymous. It adds a custom traversal hook to the Plone site and only allows access to the login form and the resources used by it for anonymous users.
Keep in mind that in this scenario you cannot cache any pages or listings in a frontend cache, as that would be accessible without authentication. Caching CSS, JS and image resources in Varnish is still a good idea and you can cache things in the browser cache.
My approach with this use case has been (and still is) always to deal with workflows.
Start customizing "intranet workflow" and than remove all options to anonymous.
Then give to authenticated (or members) privileges you want.
No need extra code.
No need extra product.
No need external configuration.
Only the power of Plone.
I once secured a Plone site so that only authenticated users could see anything (login form
was accessible). It was a Plone 2.5 and I know I modified (checked/unchecked roles) these permissions in the Plone Site root's access ZMI page (manage_access):
Add portal member
Allow sendto
Change portal events
Modify portal content
Set own password
Set own properties
View
I know new permissions have been added in next Plone versions so you might need to tweek other ones.
I think that the easiest way to achieve what you need is by doing this, although I'd recommend using GenericSetup and not TTW customization, like I did:
It's easier than modifying Published state of workflows.
If you configure Apache you'll need a double log in (to access the login form and then to log in to Plone). Unless you set a special PAS plugin. This approach, in my opinion, is more difficult than mine.
But given that I didn't tried any of these two last options I can not say my way is the way. I can just say that it worked for me, and hopefully it'll work for you.
You can also use the WebServerAuth plugin so users are only allowed access via basic auth. http://plone.org/products/webserverauth
That way you can, just by default, protect everything on the site and not worrying about the plone login forms.
If you're already running a virtual host with Apache then I'd use mod_rewrite to enforce this. The following configuration will direct all unauthenticated users to the login form and also allow users to use the forgotten password process. I've tested this with Plone 4.1 already I imagine it will also work with Plone 4.0
RewriteCond %{HTTP_COOKIE} !__ac=.*
RewriteCond %{REQUEST_URI} !^/acl_users/credentials_cookie_auth/require_login$
RewriteCond %{REQUEST_URI} !/login_form$
RewriteCond %{REQUEST_URI} !/login$
RewriteCond %{REQUEST_URI} !/logged_out$
RewriteCond %{REQUEST_URI} !^/portal_css/
RewriteCond %{REQUEST_URI} !^/portal_javascripts/
RewriteCond %{REQUEST_URI} !^/login.js$
RewriteCond %{REQUEST_URI} !^/logo.png$
RewriteCond %{REQUEST_URI} !^/mail_password_form$
RewriteCond %{REQUEST_URI} !^/mail_password$
RewriteCond %{REQUEST_URI} !^/portal_registration/passwordreset/
RewriteCond %{REQUEST_URI} !^/pwreset_form$
RewriteCond %{REQUEST_URI} !^/pwreset_finish$
RewriteRule ^(.*) /acl_users/credentials_cookie_auth/require_login?came_from=%{REQUEST_URI} [last,redirect=temp]