Sup sla.ckers,

I joined this board to check on the latest hacks etc for better protection for my websites.But it's only advanced stuff.

Maybe u want to point out some basic's, i searched on google:

Now i found a basic strategy guide, http://blogs.techrepublic.com.com/security/?p=424

Do you think this is enough to setup the basic needs for securing a webpage these days?

"Date: March 13th, 2008" It might be outdated? Let me know, thank's in advance.

Solf.

1. Login pages should be encrypted
2. Data validation should be done server-side
3. Manage your Web site via encrypted connections: (hmm?)
4. Use strong, cross-platform compatible encryption
5. Connect from a secured network
6. Don’t share login credentials
7. Prefer key-based authentication over password authentication
8. Maintain a secure workstation
9. Use redundancy to protect the Web site
10. ? any more ?

Looks pretty good to me.

Although I miss a few things, or some things I would add.

Like:

- make clever use of iptables, and it's protection it can give you.
- use at least 1 IDS, like SNORT or AIDE.
- run a cron that backs up your logs to another disk (preferably encrypted)
- disable "features" stuff that you will never use on a server, lowers the chance that you might run outdated software.
- basic server security should be knowledge about: routers, chroot jails, chmod, protocols like ARP, ICMP and other hazards it can pose.
- drop the use of FTP and use sFTP or even better SCP
-

edit: typo's



Edited 1 time(s). Last edit at 08/03/2009 04:29PM by rvdh.

Those are all fine things to say, but everything is in the implementation.


1. Login pages should be encrypted.

Maybe...too generic of a statement.
- Who is logging in and why do they need to be protected?
- If the login is just for administration purposes you may be better off with another form of security such as port forwarding ssh to the host itself and only making those pages available to the local forward.

2. Data validation should be done server-side

3. Manage your Web site via encrypted connections: (hmm?)
- ssh (as mentioned above), vpn connection, or ssl.

4. Use strong, cross-platform compatible encryption
- Maybe...once again, who is the audience, should you make sure that encryption works on a commador 64 too?

5. Connect from a secured network
- This may not be practical at all times depending on a variety of things
- Most of the Internet is not a secured network, often times your home network isn't secured (siblings/spouse/co-workers/etc that are insecure themselves).

6. Don’t share login credentials
- duh

7. Prefer key-based authentication over password authentication
- totally depends on where you store the the keys and how well you can secure that.

8. Maintain a secure workstation
- duh

9. Use redundancy to protect the Web site
- huh? Have backups I guess is what they are saying, of course...can be a bit more involved if you have a DB or 2,but of course.

10. ? any more ?
- yes, tons :)

-id

Quote


7. Prefer key-based authentication over password authentication
- totally depends on where you store the the keys and how well you can secure that.

Yeah 2nd that, I hear many preaching keys for SSH but the problem is storage, if they get to your less well secured box (workstation) they could obtain that key. Trade-off I guess? I memorize it and run SSH local so no need for a key :)

Maybe another gem: try to get the box under your control if you are serious about security. A virtual account (e.g. sit next to 300 other rackshackers) (e.g. cheap account) out of your control means basically pwnage most of the time, see my case from last year on a virtual account I had, where I could hack myself and others on the same box, and later on another moron actually did it, well my fault for being so naive.

Spelling police detected the following:

Quote

- Maybe...once again, who is the audience, should you make sure that encryption works on a commador 64 too?

<Sniglet>
Commador; noun

It, is, a, machine, that, inserts, commas, automatically, after, each, and, every, word.
</Sniglet>

I think id meant a commodore

I'm writing that one off to too many beer @ defcon.

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Ignoring thrill...

Ronald makes good points, just some clarifications:

- make clever use of iptables, and it's protection it can give you.
* Block all in, etc...block all out is the one overlooked.

- use at least 1 IDS, like SNORT or AIDE.
* I have to disagree, unless you're really into huge time sinks or have staff, this is the least bang for your buck (time)

- run a cron that backs up your logs to another disk (preferably encrypted)
* Syslog your stuff off host, use encryption, make sure the remote server has nothing in common with the web server...including passwords.

- disable "features" stuff that you will never use on a server, lowers the chance that you might run outdated software.
* Yup, even modules in Apache, or whatever server you are running.

- basic server security should be knowledge about: routers, chroot jails, chmod, protocols like ARP, ICMP and other hazards it can pose.

..Routers...odds are you won't control the one directly in front of you, but you can put a firewall/router behind it.
* Firewalling shouldn't be hard, but it isn't always easy understanding the concepts without doing some serious studying.

- chroot
* understand what chroot is and can do for you, it is not in itself security in any way, don't rely on it as such. FreeBSD jails offer other protections, Openbsd as well.

chmod
* chmod is a huge friend of yours
* more importantly, chmod is your friend when you run your server as a different user than your files are chownd...

ARP, ICMP, Whatever protocol
* These belong in the firewall/router section
* ICMP actually does things, don't just turn it off.
* ARP is pretty damn important too, but odds are it is unimportant to your security unless you are on a very hostile local segment...

- drop the use of FTP and use sFTP or even better SCP
* FTP sucks in every way known to man
* scp though has no advantage securitywise over sftp.

-id

Offline backups.

Thank's for all the reply's! I'm going to check them out!

Cheers.

Login pages should be encrypted:
How does forum software like phpbb or vbulletin stop a malicious hacker crafting their own login form if phpbb/vbulletin don't use SSL?

Data validation should be done server-side:
Is there anyway to make javascript forms server-side? If there isn't, what are some server side data validation programming languages to use?

For Solf :

If you want you can look for 3rd party authentication systems as well.
They will save all the hassle. Specially in ASP.NET you can find one comes in the framework itsself. It is called " Membership And Roles API ".