I run a Wordpress site for my company, and lately we've been getting comment spam to the point of triggering a lockout for 20+ hours at a time. I can't log in, nor can any of my coworkers. We whitelisted our IP address, but still keep getting locked out.
Is this a common occurrence? I can't imagine I'm the only person to run into this specific issue, but Google has as of yet been unhelpful...
I took it up with my managed hosting provider - WPEngine - who told me that I needed to whitelist our office IP (done, didn't help) and, if we get locked out, run a SQL query on our production database:
SELECT option_value AS row_count
FROM wp_options
WHERE option_name = "limit_login_lockouts"
Which, y'know, doesn't actually do anything, just tells me that, if I'm reading this right, we've gotten something like 1.4 billion attempts to log in from an IP address that coincides with the Linode datacenter WPEngine has us sitting in.
Long-winded, sorry, but my question is twofold: what should I do to clear this up temporarily to let me log in, and what do you do/have you done to avoid this issue?
Thanks.
Have you tried using another IP (another location) rather than your offices? If you have cPanel access you might wanna check your access logs and look for any fishy IPs. Also check to see if your IP is on IP "Deny list".
Hope this helps
Related
I would like to host my webapp on Firebase, since I'm using their services and functionalities since a long time (before Firebase was inside Google and since its static hosting service was named Divshot... ).
But I've got a demo domain from Freenom (.tk domain) and I was wondering how to connect this with firebase:
I can set only this paramater relative to TXT record:
dns management
so where should I define the parameters needed
google-site-verification=...
?
Thank You to all!
PS: I've already seen
Firebase hosting custom domain error
and related
firebase-talk Dqmz9Iuio54
and
and the question: how-can-i-verify-my-custom-domain-using-domains-google-com/39020649#39020649
but none of them seems to respond to my problem...
PS: I've come here from firebase support page where StackOverflow is the first choice.
Thank you!
Leave the "Name" field blank and fill "Target" with the google-site-verification=... value. Once you've done so, things should go through. One way to check is to run:
dig yourdomain.tk TXT
If you've done it correctly, you should receive back the google-site-verification=... value. It may take some time to propagate before it starts showing up.
DNS registrar / records host: delete TXT records pointing to
firebase.
firebase console: delete the custom domain.
firebase console: add custom domain.
copy the two TXT records from firebase to DNS host
DNS record host should include two entries with one yourdomain.tk and www.yourdomain.tk
Once the yourdomain.tk is added it'll show as empty and other entry will be shown as www.
The copy the two given A records to Freenom DNS records.
There will be 4 A records two for yourdomain.tk and two for www.yourdomain.tk.
Wait 24-48 hours to see if the changes work.
If it doesn't work, contact firebase support from the console; be sure to take screen shots of the DNS records and the firebase console. These will help the firebase support team to troubleshoot the problem.
Mean while you can check for the dns propagation by using below tutorial
The Firebase Hosting servers run what is essentially this command for verifying the TXT records for your domain:
dig -t txt +noall +answer yourdomain.tk
If you immediately run this command right now, you might not get results. If the Firebase servers are seeing the same in their DNS query, they will not be able to continue.
That means that either you didn't save/apply your changes yet, or they haven't propagated everywhere yet. The longer it takes for the changes to show up, the more likely it becomes that you still need to take some action at your DNS provider
About 12 days ago a friend was messing around with the nameserver record for his domain, trying to change between his old agency to a new Squarespace account. He was able to make the changes to the ns records see it work, revert, and then make the changes one more time all in the same day and saw the changes within a few hours each time.
About 10 days ago I had him set his NameServer record back to the default provided for his domain registrar, GoDaddy, and just point the CNAME and MX records as needed.
So, after all that here's the fun part. Using https://www.whatsmydns.net/#NS I can see that the nameserver changes have taken place everywhere but when I run traceroute I still see the old nameserver. I'm guessing that the local IP is just not releasing the cached record - maybe because he made so many changes to the ns record in one day?
Any idea what's going on or where I should look next?
Appreciate the help in advance.
You should look for a records which contains mentioned server in /etc/hosts or Windows system partition:\Windows\system32\drivers\etc\hosts and delete them.
I've gotten pretty far into a deployment of my Meteor application on Distelli. Like, almost there. I've done everything as far as setting up the EC2 box, creating a user group [which didn't even seem necessary as I was able to SSH into the box with full rights without specifying my machine's IP], creating an elastic IP, successful build, and deployment to that box. But, I can't seem to check if Meteor is actually running (note: when I ssh in, there are active instances of Mongo and Node, so SOMETHING is running).
The problem has something to do with associating the elastic IP with my ROOT_URL and domain. I'm just not sure what to do at this step and can't seem to find any directions that are Meteor specific. Been using these guides:
https://www.distelli.com/docs/tutorials/how-to-set-up-aws-ec2
https://www.distelli.com/docs/tutorials/deploying-meteor-applications
http://gregblogs.com/tlt-associate-a-namecheap-domain-with-an-amazon-ec2-instance/
Recap: Distelli deployment is a success, but I get the follow error just before finishing:
Error: $ROOT_URL, if specified, must be an URL
I've set my ROOT_URL to my domain, and associated according to the previous guide. I can run traceroute on the IP, but like port 3000, so my inclination is the Meteor build is silently failing.
My manifest: https://gist.github.com/newswim/c642bd9a1cf136da73c3
I've noticed that when I point the CNAME record to my ec2 public DNS, NameCheap (aptly named) adds a . to the end of the record. Beyond that, I'm pretty much stumped.
I have "You do not have sufficient permissions to access this page." issue when trying to access Wordpress wp-admin login as an administrator. The login page appears, but when the user details are entered the "You do not have sufficient permissions to access this page." appears.
The strange part is that I have another administrator account that accesses with no error.
I tried to create a new administrator account, but that also cannot access giving the above error message.
I have looked into the database and the users that don't work have wp_capabilities of a:1:{s:13:"administrator";b:1;}
The user that does work has: a:2:{s:13:"administrator";b:1;s:13:"bbp_keymaster";b:1;}
I am also running S2 Member plugin.
The only difference I can see between the account is this beginning section of a:1 and a:2. All of the sites I see say the account should be a:1
I don't think it is a plugin issue, as I assume then I would not be able to access either. I think perhaps something to do with s" Member plugin, but I'm now at a bi of a loss.
All plugins are updated and running Wordpress 4.0 (however this was an issue even before upgrade to 4.0)
All help gratefully received!
The only difference I can see between the account is this beginning section of a:1 and a:2.
Look more carefully. The working example has a whole extra section: s:13:"bbp_keymaster";b:1;
To understand why that matters, it helps to know that that is the format produced by by PHP's serialize() function.
If you unserialize each of those strings, you will find that the first is an array with 1 entry (hence a:1), with the key 'administrator' and a value of true. The longer string is an array with that entry plus another one, with the key 'bbp_keymaster', also set to true.
From this, it's easy to surmise that 'administrator' and 'bbp_keymaster' are the internal names for permissions which can be granted to a user, and the page in question is only available to users with the 'bbp_keymaster' permission.
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.