I know that a website can have some vulnerabilities that hackers could use even though the admin tries his/her best to make their website very secure. I want to make my website secure and by doing that I need to try my best to do so. First way to make it secure is to ask questions and below are the specific questions I want to ask.
These are my specific questions:
1. Can a hacker access my website's .htaccess file? And if so, can they edit it?
2. Can a hacker get my SSH root password even if the SSH password is 18+ characters long?
3. Can a hacker get my FTP username and password even if the FTP password is 18+ characters long?
4. Is SSH more secure than FTP?
NOTE: The below is just a general information which probably doesn't cover half of the subject, there are tons of things you need to make sure of but the below should give you a rough idea.
Can a hacker access my website's .htaccess file?
Yes, some scenarios this could happen:
If you configure wrong your httpd.conf allowing people to visite .ht* pages which is by default forbidden on the httpd.conf
If your server is meant for hosting and you or your users don't properly apply permission to their files so they are accessible within other accounts.
If your webserver don't deploy user and group protection to accounts
If accounts are not rooted to their folders.
And if so, can they edit it?
Yes and no, just accessing the file from a browser will not grant them access to edit it, however in some cases it may be possible for instance:
If one of your codes PHP, perl, etc have vulnerabilities then yes it may be possible
As mentioned early if your websever does not deploy per account user and group then others account will have access to the files from another account
If the permission set on the .htaccess file is for instance 777 which allows ANYONE to manipulate that file it will be editable and readable from others account.
Can a hacker get my SSH root password even if the SSH password is 18+ characters long?
Brute force is not the only way to grab someone's password, if your computer has been compromised, if your services are not up to date with the newest exploits and more, it's also possible to get your password.
The most common way to protect against this would be to make your SSH password-less, basically you will deny direct access to root, block any access using password and will only grant access to authorized keys that are generated from a pair of keys.
This key would allow you access to a pre-defined account that have that key allowed to be logged as.
From that account you've logged as, you can either use sudo to run commands as root or su - to switch the current account to root.
Change the SSH port to some other port.
Use your firewall to prevent and catch brute force attempts on certain ports and block it.
Use your firewall to allow only your IP to access the server if your IP is static.
Use your firewall to block access to unused ports of service that do not require external access for example if you do not offer MySQL remote access you can block access to the port 3306 as well as configuring your MySQL server to bind on the localhost only.
Can a hacker get my FTP username and password even if the FTP password is 18+ characters long?
Brute force is not the only way to grab someone's password, if your computer has been compromised, if your services are not up to date with the newest exploits and more, it's also possible to get your password.
Is SSH more secure than FTP?
They are different protocols and serve to different purpose and they can be equality insecure or equality secure it all depends on the System Administrator to keep it up to date and secure.
About a year ago I have installed mod_pagespeed on my VPS server, set it up and left it running. Recently I was exploring files on my server, went to pagespeed cache folder and discovered some strange folders.
All folders usually named this way ,2Fwww.mydomain.com or ,2F111.111.111.111 for IP addresses. I was surprised to see some domains that does not belong to me, like:
24x7-allrequestsallowed.com
allrequestsallowed.com
m.odnoklassniki.ru
www.fbi.gov
www.securitylab.ru
It looks like something dodgy is going on, was my server compromised, is there any reasonable explanation?
That does look peculiar. Everything in the cache folder should be files that mod_pagespeed tried to rewrite. There are two ways that I know of that this can happen:
1) You reference some third-party resource (say an image from another domain, or google analytics script) and you have explicitly enabled rewriting of that domain with ModPagespeedDomain www.example.com or ModPagespeedDomain *.
2) If your server accepts HTTP requests with invalid Host headers. Try (for example) wget --header="Host: www.fbi.gov" www.yourdomain.com/foo/bar.html. If your server accepts requests like that it may be providing mod_pagespeed with an incorrect base domain, and then subresources would be fetched from the same domain (so if www.yourdomain.com/foo/bar.html references some.jpeg, and your server accepts invalid host headers, we could fetch www.fbi.gov/foo/some.jpeg as the resource). There was a recent security release that makes sure all of these subrequests are done against localhost (not arbitrary third-party websites). Please see: https://developers.google.com/speed/docs/mod_pagespeed/CVE-2012-4001
You might want to look through these folders and see what specific resources are in there. I think that the biggest concern you should have is that someone might be trying to perform an XSS attack on your users or maybe a DDoS attack against another website (like www.fbi.gov), using your server as one vector. I do not think that these folders are indicative that your server itself is compromised.
If you would like to discuss this more, https://groups.google.com/forum/?fromgroups#!forum/mod-pagespeed-discuss is a good list to join and email.
Assuming a small (pages < 5) site, what is the proper usage of .htaccess and .htpassword? I recently watched a tutorial from Nettuts+ where this sample code was given:
.htaccess
AuthName "Login title"
AuthType Basic
AuthUserFile /path/to/.htpasswd
require valid-user
.htpasswd (created using htpasswd -c <file> <username> command)
username:encrypted-version-of-password
I am also curious as to the actual level of security this provides: can it be bypassed easily? If Apache by default does not allow users to access either of the two files directly, do they need to be outside the public directory? Are there any speed implications?
What level of security does this provide?
.htpasswd does not provide much security by itself. That is, it provides a login mechanism, and Apache will not respond without the proper credentials, but unless separately configured, nothing about the exchange is encrypted (or even obfuscated). For example, listening to the GET request with Wireshark gives you a nice view of all the headers being sent by the client, including:
Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==
"d3BhbG1lcjp0ZXN0dGVzdA==" being just the base64 encoded form of "wpalmer:testtest". These days, a hacker (or more likely, a virus) can sit on a public WiFi connection and log any requests containing the Authorization: for later perusal. In general, sending any authentication information over an unencrypted HTTP connection is considered a bad idea, even if you're over a wire or secure WiFi end-to-end. It would not, for example, meet the requirements of PCI Compliance if you were storing customer data, payment information, etc behind the .htpasswd lock.
Add https to the mix, and you completely eliminate that particular problem, however...
.htpasswd authentication as implemented by Apache httpd does not provide any form of rate-limiting or brute-force protection. You can make as many simultaneous attempts at a password guess as Apache is willing to serve simultaneous pages, and Apache will respond with success/failure as soon as it possibly can. You can use something like Fail2Ban to limit the number of failed attempts can be made before the client is blocked from talking to the server, but that will not necessarily provide any useful protection against a botnet, which may automatically target your server from thousands of unique addresses. This can lead to the decision of "do I leave myself vulnerable to password attempts from botnets, or do I leave myself vulnerable to denial-of-service attacks, when the entire account is locked-down due to failures from multiple clients?"
These angles of attack can be limited by adding IP-based restrictions to your .htaccess file, allowing connections only from certain addresses. Depending on how you operate, this may be inconvenient, but it also severely limits the types of threats which you would be vulnerable to. You would still be at risk from someone specifically targeting your site, or an infection on part of the network infrastructure itself. Depending on the type of content you are protecting, this may be "good enough". An example of this type of restriction is:
Order deny,allow
Deny from all
Allow from 127.0.0.1
This means, in short, "only allow connections from the local host". Line-by-line, it means:
Order deny,allow defines the order in which rules are processed, with the last match taking precedence.
Deny from all begin by assuming that all clients are denied
Allow from 127.0.0.1 if the client has the IP 127.0.0.1, then it is allowed
To some extent, IP-based restrictions will also protect you to the point where HTTPS may be considered optional. Attackers / viruses can still see your credentials, but it is harder for them to use those credentials on the page itself. Again, this would not be PCI compliant, and it would not be suitable for "important" information, but there are some situations for which this may be considered "good enough". Be aware that many people re-use credentials across multiple sites, so failing to protect login details is generally considered to be very dangerous to the user, even if the site itself is protected.
Finally, the .htaccess file itself is a bit of a liability. See the response to "do they need to be outside the public directory?" for more details on that.
Can it be bypassed easily?
No. There is no reason to expect that the server, when properly configured, would ever fail to require login details to access the protected content. While HTTP Basic authentication has its flaws, Apache httpd is very robust and is one of the most thoroughly tested pieces of software in the world. If you tell Apache that HTTP Basic authentication is required to access certain content, it will be required.
If Apache by default does not allow users to access either of the two files directly, do they need to be outside the public directory?
There are a couple of points to this. First, Apache does not default to preventing access to either of these files. Many distributions of Apache httpd include initial configuration which prevents access (using "Deny from all" rules) to, depending on the distribution, .htaccess/.htpasswd files, .ht* files, or .* files. It is very common, but there are plenty of reasons why this may not be the case. You can add a rule yourself to block these files, if they are not already blocked:
<FilesMatch "^.(htaccess|htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
Secondly, it should be pointed out that the way .htaccess files work, they are processed when the directory they are in is matched. That is to say: .htpasswd may be elsewhere, but .htaccess needs to be in the same directory. That said, see the "speed implications" section for a bit more detail.
So, as they can be blocked so easily, why keep .htpasswd outside of the public directory? Because mistakes happen, and the .htpasswd file is a big liability. Even if you're using HTTPS, exposure of your .htpasswd file means that your passwords can be easily cracked via brute-force attacks. These days, consumer-grade GPUs can make millions of password guesses per second. This can make even "strong" passwords fall in comparatively little time. Again, this argument generally only applies to a targeted attack, but the fact remains that if an attacker has your .htpasswd file and wants access to your system, these days, they may be able to do so easily. See Speed Hashing on Coding Horror for a relatively-recent (April 2012) overview of the state of things.
With that in mind, the possibility of accidentally (temporarily) exposing your .htaccess file is worth moving it somewhere that should never be even looked at when httpd is looking for content to serve. Yes, there are still configuration changes which could expose it if it's "one level up" instead of "in the public directory", but those changes are much less likely to happen accidentally.
Are there any speed implications?
Some.
First off, the use of .htaccess files does slow down things somewhat. More specifically, the AllowOverride all directive causes a lot of potential slow-down. This causes Apache to look for .htaccess files in every directory, and every parent of a directory, that is accessed (up to and including the DocumentRoot). This means querying the filesystem for a file (or updates to the file), for every request. Compared to the alternative of potentially never hitting the filesystem, this is quite a difference.
So, why does .htaccess exist at all? There are many reasons which might make it "worth it":
depending on your server load, you may never notice the difference. Does your server really need to squeeze every last millisecond out of every request? If not, then don't worry about it. As always, don't worry about estimates and projections. Profile your real-world situations and see if it makes a difference.
.htaccess can be modified without restarting the server. In fact, this is what makes it so slow- Apache checks for changes or the presence of an .htaccess file on every request, so changes are applied immediately.
An error in .htaccess will take down the directory, not the server. This makes it much less of a liability than changing the httpd.conf file.
.htaccess can be modified even if you only have write-access to a single directory. This makes it ideal for shared hosting environments. No need to have access to httpd.conf at all, or access to restart the server.
.htaccess can keep the rules for access next to the files they are meant to effect. This can make them a lot easier to find, and just keeps things more-organised.
Don't want to use .htaccess, even considering all of the above? Any rule that applies to .htaccess can be added directly to httpd.conf or an included file.
What about .htpasswd? That depends on how many users you have. It is file-based, and the bare minimum in terms of implementation. From The docs for httpd 2.2:
Because of the way that Basic authentication is specified, your
username and password must be verified every time you request a
document from the server. This is even if you're reloading the same
page, and for every image on the page (if they come from a protected
directory). As you can imagine, this slows things down a little. The
amount that it slows things down is proportional to the size of the
password file, because it has to open up that file, and go down the
list of users until it gets to your name. And it has to do this every
time a page is loaded.
A consequence of this is that there's a practical limit to how many
users you can put in one password file. This limit will vary depending
on the performance of your particular server machine, but you can
expect to see slowdowns once you get above a few hundred entries, and
may wish to consider a different authentication method at that time.
In short, .htpasswd is slow. If you only have a handful of users who need to authenticate, you'll never notice, but it is yet another consideration.
Summary
Securing an admin section with .htpasswd is not ideal for all situations. Given its simplicity, it may be worth the risks and problems where security and performance are not the highest of priorities. For many situations, with a little bit of tweaking, it can be considered to be "good enough". What constitutes "good enough" is a judgement call for you to make.
I'm using this for one of my applications:
Options +FollowSymLinks -SymLinksIfOwnerMatch
And I worry about the security problems this may bring. Any idea what measures I can take to make this approach as secure as possible?
There's nothing specific you can do to make using those options as secure as possible. The risk in using them is that a user, or a process running under a user, can disclose information or even hijack content by creating symlinks. For example, if an unpriviliged user (who may have been compromised) wants to read a file that they normally can't, they can sort of escalate it by creating a symlink from their public_html directory to it, and if apache can read it, they can then just access their webpage and read the file. There's nothing specific you can do to prevent something like that from happening except to make sure you're system is properly patched and configured.
Note that this threat isn't just from users on your system. If you are running a webapp in, say php, and it got compromised somehow, an attacker can upload a php file browser and create symlinks to content outside of your document root (like to /etc/passwd or some other file you don't want exposed to the web).
If you're worried about stuff like that, it's better not to use these options.
Hey guys, i've been googling ambitiously but my searches seem to be somewhat ambiguous so I thought i'd ask here.
My company has asked me to look into a web portal system that allows clients to log in via their browser and view/download their specific invoices / reports (the web server would be inhouse).
These (initially at least) would be static documents, pdf's, maybe excel spreadsheets and the like.
What I want to happen is a customer heads to our website (hosted elsewhere), clicks a link that takes them to a secure login for our webserver, they then enter their login details and are taken to their respective 'folder' on our webserver. Here they can download pdf's - that we keep up to date.
The main considerations are for it to be secure such that users can't access other users' folders and for users not to have to install anything to be view download their documents.
I'm setting up a pc to be a LAMP server right now, i've read WebDAV would be a good way to go but i'm not sure about how to get that working in a browser? Any advice or resources you guys can point me to give me a bit more direction would be greatly appreciated.
Thanks, Rob
If you've only got a handful of accounts to manage, apache's built-in HTTP Auth password stuff works pretty well; you write usernames and hashed passwords into an .htpasswd file with the htpasswd utility.
Then you use <Location> directives to specify the URL and directories to find the data, and inside the <Location> directives, use the Require directive to either list specific usernames or valid-user.
Just make sure your .htpasswd file isn't stored in the web root. You don't want people to get a hold of the thing and start brute-forcing your passwords (or see your other allowed users, in case client privacy is a priority).
But it is pretty heavy maintenance -- password changes pretty much have to go through a human. I imagine someone has scripts to automate that, but I wouldn't trust them very far. :)
If you want something that scales larger, I think you might be better off building such a tool yourself.