I have a website with a loose security admin area. Instead of fixing the many security holes that /admin page has, I kinda kept the hackers away by using htaccess:
deny from all
It didn't allow anyone to access /admin area. But I had to remove this condition any time I wanted to access the page. So, I used htaccess white list of IP's.
Now it looks like this:
<Limit GET POST>
order deny,allow
deny from all
allow from 1xx.2xx.xxx.xxx
allow from 1xx.2xx.xxx.xxx
</Limit>
So, this way, my home and office IP's are whitelisted and other people (incl. hackers) will get a 403 error accessing /admin.
But now, I wonder if they can hack my computer and use my IP to access this forbidden page. Do you think hacker have this ability, or is my website totally safe now?
or is my website totally safe now
No, not a single website is totally safe, hackers are always one step in front of the defenders.
But it's a good start making it harder for the hackers to break into your site
A) please don't think that the only way in is through your PC
B) please don't think you are safe because no-one would do that
Both are incorrect. B) especially is a false sense of security. What you will find is that attackers who may gain access to your PC will have a look at what you do with it, and that will likely include accessing your web administration area. This doesn't even require much effort.
You should always use a decent authentication mechanism, and add IP whitelisting as an extra.
Related
Somebody tried to get access to my TYPO3 backend. I already have the IP adress of the attacker and want to block it from the backend.
I already tried to block ip with .htaccess but this doensn't work. I think the rules are overwritten by something else in the .htaccess file which I couldn't figure out yet.
Captcha is at the moment not a suitable solution.
Are there any good extensions for blocking IP adresses or is there another way to avoid these brute-force attacks?
If you are really concerned about somebody to be able to successfully get access to the system I suggest to go the "white list" path instead of blacklisting single IPs.
TYPO3 has a built in feature to block backand access for ALL IPs except some white listed ones.
To do this just add the following into AdditionalConfiguration.php putting your own IP and the IPs (or subnets) of other users too.
$GLOBALS["TYPO3_CONF_VARS"]['BE']['IPmaskList'] = 'x.x.x.x,y.y.y.*,z.z.*.*';
Other than that, just make sure you take the basic steps to make your backend more secure:
1) Force SSL for the backend:
$GLOBALS['TYPO3_CONF_VARS']['BE']['lockSSL'] = 2;
2) Implement a secure password policy for the backend users by using e.g. EXT:be_secure_pw
3) Secure session cookies to have ssl_only and http_only attributes:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieHttpOnly']=1;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieSecure']=1;
4) And last but not least: make sure you are using the most recent version of your TYPO3 version line, ideally a maintained LTS version.
You should block requests before PHP/MySql is in use in the best case. So .htaccess is the correct way in my eyes. If it does not work, you should ask your hoster.
It sounds like you want to block the IP of the attacker and put measures in place to block known bad ip's. One of the main issues with blocking the IP of the attacker is that it's fairly easy for an attacker to setup a new IP address and launch a new attack.
There are services that provide lists of known bad ip's if you wanted to implement your own firewall.
Alternatively you can look to place your URL behind a solution such as Cloudflare that have the ability to block IP's or countries. I know of business's that block traffic from China and Russia since they identified that most of their attacks came from these countries.
I have seen the updates requesting that we install these updates on Magento and seen questions here on how to do so and some difficulty in doing so.
However I'm still unclear as to why I should do so and what will happen if I don't.
Also (I'm quite new to Magento) these updates take a couple of hours to implement, how often do they come along?
Many thanks
Ed
The 5344 security patch fills a hole that allows for total bypass of authentication to get into your Magento website Admin backend.
http://magento.com/security-patch
At the top of the page is a fill-out form ShopLift detector.
At the bottom of the page is instructions on how to use their check api to test. It basically connects to your website and uses the same hole the hackers will be exploiting soon.
Check your server access logs for the following requests:
POST /index.php/admin/Cms_Wysiwyg/directive/index/
Also, change your admin url.
And it is a good thing to add a Watchlog module and block some IP's in .httaccess:
############################################
## By default allow all access
Order allow,deny
Deny from 93.115.83.243
Deny from 95.110.207.164
Deny from 104.219.248.145
Deny from 108.61.122.9
Deny from 108.61.123.80
Allow from all
Those IP's are the IP's currently brute-forcing my store...
Watchlog extention: http://www.magentocommerce.com/magento-connect/watchlog.html
I am realy wonder why in .htaccess has those code bellow, can tell me what is this code?
<Files 403.shtml>
order allow, deny
allow from all
</Files>
deny from 212.92.53.18
It is not definitely malware.
At least, not in the sense it's intended for malicious reasons...
In the case you are using cpanel and you have used its IP Deny Manager to block access to 212.92.53.18 then this will automatically be written to your .htaccess file with the intended purpose of blocking that IP (and any others you may wish to enter):
<Files 403.shtml>
order allow, deny
allow from all
</Files>
deny from 212.92.53.18
Do you use cpanel and if so, do you remember doing that?
Allowing the 403 to All simply prevents a loop. If you block an IP using the 'deny from' method, then serving of the 403 to that IP would also get blocked, creating a loop. Allowing the specific 403 file to ALL, will override the block -- of serving the 403 to that specific IP -- that otherwise would have occurred. That prevents a loop.
<Files 403.shtml>
order allow, deny
allow from all
</Files>
I used it myself on an old domain. It simply says "allow anyone to access the file named 403.shtml"; which is the forbidden access error. Of course, you would use this usually if you created a custom 403.shtml page.
The denied IP in this case would not see the custom 403.shtml and instead would get a White-screen-of-death.
So this is not, in any way shape or form, malware related.
UPDATE: This answer was based on speculation using the facts provided when it was originally posted. The overall consensus seems to be this modification of the .htaccess file is most likely the result of using server management software such as CPanel so it’s not—on its own—an indication of malware infection.
The contents of that .htaccess are a bit odd.
<Files 403.shtml>
order allow, deny
allow from all
</Files>
deny from 212.92.53.18
The <Files 403.shtml> part refers to the 403.shtml file and it seems to be allowing a custom 403: Forbidden response (assumption based on file naming) .shtml file to be sent. The order allow, deny and related allow from all explain it to me. It seems like the site is blocking all traffic in some way but wants that 403.shtml to come through?
But the deny from 212.92.53.18 is quite specific & odd as a result. That is basically blocking any/all access from 212.92.53.18.
Now typing that out it seems like the .htaccess is set to explicitly deny access from address 212.92.53.18 which would send a 403 response code, and the <Files 403.shtml> allows the actual 403: Forbidden htaccess page to be sent?
But still, it seems odd for a directive to block traffic from one single IP address would be in an .htaccess file like that.
EDIT: Did a Google search for <Files 403.shtml>—because if you know Apache configs, that is a highly odd directive—and it seems like this might be part of some malware? Look at this page as well as this page and this other page.
Seems like this is part of a definite XSS backdoor? Perhaps the .htaccess is in a malware directory, and the deny from 212.92.53.18 is denying the infected server from accessing itself?
ANOTHER EDIT: Okay, putting on my thinking cap—as well as personal experience with web malware—and looking at the specificity of the deny from 212.92.53.18 I think I know what the deal is. This is part of a malware infection. But I bet that 212.92.53.18 is a node on a bonnet because you can curl -I it & visit it in a browser & it seems to be an active server. Most client IP addresses just won’t do that; who has a web server exposed on a basic ISP connection, right? Unless the machine is infected. So the 403.shtml is not actually a real 403: Forbidden page but actually part of the malware. Meaning, a connection being made FROM 212.92.53.18 would trigger 403.shtml—which is a server side include HTML file—that could be used for unauthorized access. I mean, when has anyone in 2014 last seen active .shtml files on legit servers, right? It’s all PHP, Python, Java or Ruby nowadays.
This?
<Files 403.shtml>
order allow,deny
allow from all
</Files>
deny from xx.xx.xx.xx
Hacker? Backdoor? Malware? Ukraninian DOS attack?
Of course it IS NOT. It's nothing of the sort.
It is automatically generated by cPanel, when the "IP Blocker" is used.
cPanel writes it to your .htaccess file
The 'deny from' is simply the IP specified when using the cPanel IP Blocker tool. cPanel is clever enough to know a little more is needed than just a simple 'deny' IP4 entry.
Probably it's terrorific hack and malware. Ukraine/Russian/Indonesian hackers. On july 2016 they have attacked a lot of sites with Prestashop with a vulnerability on image file uploads. They upload that 403.shtml to the root and then they destroy the server and files. I have checked that my web is on their web page that inform hacked websites. They block some nights your access to the web with a DDOS attack to get the pass of mysql and ftp. In prestashop you have to upload urgent to 1.6.1.16 or upload some protection files. Unfortunately, I have do that, but they don't stop and try again blocking my webshop.
The only another option is that you put block ip on cpanel, but the trick is what Giacomo1968 says in their answer. Congratulations.
So this is a somewhat broad question, I know, but I'm hoping someone who is wiser than I can provide a summary answer that can help wrap up all of the ins and outs of SSL for me.
Recently I watched a video of Moxie Marlinspike giving a presentation at BlackHat, and after the hour was up, I thought to myself, "It doesn't really matter what I do. There's always a way in for a determined hacker." I recall his final example, in which he demonstrated how even using a redirect when the user typed in an HTTP address to go directly to HTTPS, there is still an opportunity in that transition for an attacker to insert himself via MITM.
So if browsers always default to HTTP, and users very rarely enter an HTTPS address directly in the address bar, then an attacker who is listening for accesses to Bank X's website will always have an opportunity during the HTTP -> HTTPS redirect to gain control. I think they have to be on the same network, but that's little consolation. Seems like Marlinspike's point was that until we go straight HTTPS as a standard rather than an alternative, this will always be a problem.
Am I understanding this correctly? What is the point in redirecting to HTTPS if an attacker can use MITM during the transition to gain control? Does anyone have any clue as to preventative measures one might take to protect himself? Would redirecting via javascript that obfuscates the HTTPS links (so they can't be stripped out in transit) be of any help? Any thoughts would be appreciated!
You can use HSTS to tell the browser that your site must always be accessed using HTTPS.
As long as the browser's first HTTP connection is not attacked, all future connections will go directly over HTTPS, even if the user doesn't type HTTPS in the address bar.
There are no actually any information leak in HTTP/HTTPS redirect if implemented properly on server side (i. e. if all dangerous cookies are marked as "HTTPS only" and inaccessible for JavaScript).
Of course, if end user doesn't know anything about security, it can be hacked, but from the other hand, if you user doesn't know even basic security rules and there are not system administrator who will explain it to user, it is possible to hack such user in so many ways that HTTP to HTTPS redirect problems is not really trouble.
I saw many users who downloaded and run unknown EXE files from server just for promise to "win 1000000 dollars", which is also a good way to hack them (even better than to exploit redirection, if you run as EXE in user computer, you are already king here and can steal any user cookies under default security settings).
So, if user collaborates with hacker and helps hacker to hack his own computer, yes, such user will succeed to be hacked, but security is about professionals who ready to protect himself and not about user who may be publishes his PayPal cookies somewhere on Blogpost and after that surprized that he is hacked.
I am developing a website with CakePHP.
I have an AdminsController for admins to authenticate. However I want create extra security by adding .htaccess password protection.
I tried to do it by adding .htaccess and a .htpasswd files in my Admins view directory since I want the other pages of my site to work normally, but it doesn't work.
So how to add .htaccess and .htpasswd for only a specific view?
In my AdminsControllers's beforeFilter method I've added :
if(env('HTTP_HOST') == 888.888.888.888 || ......),
The list of IP addresses that should be allowed. Can I say that it is safe now?
I think you might want to investigate the other authentication components that CakePHP has to offer. BasicAuthenticate should be of particular interest.
If you go down this route, the authentication will still happen against a userModel rather than a .htpasswd file.
As for the IP restriction, that should be relatively safe. IP spoofing is possible but hard.