I run Slackware 13.0 and I have an apache server 2.2.13 with a postgresql 8.4.1 database attached to it via php 5.3.0. Both the apache server and the postgresql database are on the same machine.

I have the apache server port 80 exposed to the WAN. It is not a fqdm, it's just a simple IP address. On my index page, a user can login with a user/password that encrypts to md5 via postgresql and takes them into the database.

Here is the vulnerability. Can't a hacker just scan port 80 and find my ip address running apache. Go to my index page, see that I accept user/password for authentication into my postgresql database. Then they could setup a script to simply inject html GET requests of random users and passwords and use those values on the php page(the one where the action link is pointing to in the form tag) that contains user login/password in php to login to my postgresql database. There's nothing stopping that. It would be a simple dictionary attack.

I checked out postgresql documentation and it suggested using ldap, kerberos, or md5 and not trust. I'm using md5 already. I currently use fail2ban for proftpd and sshd and it works great. After 6 failed user/pass attempts on either of these services, the IP gets banned via iptables for 24 hours. I love it. I was wondering if I could use that. Of course postgresql port is not exposed to the WAN which is a good thing. I know that when I put in a wrong user/pass from my index page, I get sent to a default postgresql pg_connect warning page. Perhaps I can increase the verbosity of postgresql's logger, find the phrase that it spits out when there's been a bad login and create a filter using that.

Any ideas on how to go about this? I understand that the way it is currently setup, my server is pretty secure, but where there's a will there's a way. I just feel that my postgresql database is unprotected even tho the postgresql port is not exposed to the WAN. They could just bruteforce from the apache server.

Any ideas? I was also thinking about snort. I'd like to learn how to use that awesome piece of software someday. But if I dont' have to, I'd rather wait hehe.

I'd use https and have apache require a client certificate for connections to your database app.

At very least, this needs to be going over https. As is, it sounds like you're sending authentication credentials in clear text across the 'net.

At the DB level, you should at least look at locking/deleting unnecessary accounts, requiring strong passwords, and enabling proper auditing and logging.

Good idea on implementing SSL. I have done that. A few questions.

1. Is there any downside to running every page in SSL? even the ones with no authentication?
2. apachectl startssl is deprecated. I made the changes to use ssl in the /etc/httpd/httpd.conf file. So I start apache with apachectl start.
When I run lsof -i it shows several httpd instances in both http and https. What do I change in httpd.conf to only run the https instances?

On the DB level, user priveleges are pretty good. I don't have postgres or any other DBowner on the list to where they can login remotely, those two have to authenticate locally. I do have a few users(friends) which only have the right to select on the database. So I figure I should be good.

So I guess my server is overall secure. I might end up writing that fail2ban filter for postgresql. I just hate cluttered logs. I'm just wondering if the postgresql logger on verbose mode prints the user logins. I'm gonna look into it this afternoon. Thanks for info.

there's a cost associated with each ssl connection, in terms of cpu. This matters if you're running hundreds of simultaneous connections, but I doubt you'll even notice it unless your machine is getting hammered.

In your case though, https alone is not enough. If you're worried about a client making dictionary attacks against your login page, he can just connect via https and do the same thing.

What you need to do is to create yourself a simple CA, then generate a pair of certs that you sign with your own CA. One will be the server certificate that replaces the snake oil self signed cert for apache, the other will be for the client browser(s) that you attach to your app with.

You'll import your CA's root cert into your browser, then configure apache to require a client certificate signed by your CA. Then, only a browser with a valid ssl cert (i.e., signed by your CA) will be able to connect to your application at all. The combination of a client cert and a second factor (the password) should get you in a pretty good state.

So then I should just use SSL on the pages where you enter user/pass or on the next page which actually does the logging into database part? Which link needs to have https? The way I have it setup is, the index page forwards users to the main page, query.html. Then enter user/pass and a query, then next page query.php takes in user/pass to database and executes query.

Also, to implement SSL, aside from configuring the httpd.conf I just change the links in my html to https?

I ended up generating my own CA and key. I removed the passphrase as well. So I now have server.crt and server.key in my /etc/httpd directory.

So then how would I make the browsers of my friends have a valid ssl cert that is signed by my CA? Is that what you mean? Setting it up to where only my friends can view my website? Cause yea as of now, when they go to my site they see an untrusted cert.

I'd enable ssl for anything on your site that isn't public.

Without looking at your httpd.conf, I'm not sure what you'll need to change, but I'm assuming your https virtual server has the same configuration as the default instance, which means you'd just replace http: with https:. To require ssl, most people will create a rewrite rule that translates http urls to https and redirects the user.

To allow your friends access, you create a CSR (cert signing request) then sign it with your CA. You can either generate a single cert and give a copy to each friend, or you can create and sign a CSR for each of them individually. It's better to generate a cert per user, since then you can revoke the cert for one person without screwing up access for everybody else.


Here are the guides I like for making a home CA and using it to create and sign CSRs

http://sial.org/howto/openssl/ca/
http://sial.org/howto/openssl/csr/

Remove the Listen 80 directive.

To be extra safe, in each Directory container where SSL must be enabled, use the directive SSLRequireSSL. This denies access to requests that are not over SSL.

Thing is though, don't I need at least 1 instance of httpd with http? For example, when users view my webpage they enter my ip address. The first thing their browsers will try to connect to is an index.html on port 80, so on that index I have it auto forward to my main https page. So in this case, I would have to run all of those instances of both http and https? I guess I could just kill the separate http instances and leave only 1 running. I also noticed that with all those http and https instances running, I had a huge memory leak. I had never had this problem before but after a day of running both of those instances my mem free went down to 200MB. I usually have 1.6GB free.

Can you provide them with the https URL instead? That would be a simple solution. If not (e.g. because you want their http requests to be redirected to https), then you'll need to keep listening on tcp 80.

I would leave port 80 listening, but just have a mod_rewrite rule that rewrites everything to the same url but with https: as the schema.

Yea I'm going to leave both https and http running because I don't want to have to notify all of my users to use port 443. Also, I found out that the memory leak was due to running a ventrilo server hehe. Switching over to teamspeak, hehe.

So the problem of somebody possibly sniffing the network and stealing the user/pass in clear text is now solved with SSL support. However, I still need to resolve the potential issue of a dictionary attack. I will take a closer look at increasing the verbosity of my postgresql logger to show user logins and then make a fail2ban filter. I will post on this later this week.

client certs will protect you- it's a little work to set up, but its really cool once you get it figured out.