Erudite Relics of Loc Huu Ho

ORIGINAL SOURCE HERE

26th March 2009

I was reading a polemic if entrepreneurs should, or not, get an MBA and I would like to put forth my idea about the matter.

We are always learning and will continue until dead. There is always something that could be improved and, to figure out, knowledge will facilitate the process.

I agree that many entrepreneurs develop their business skills with blood, sweat and tears, as I did. I co-founded two high tech start-ups and, after 25 years of

Original Document Here

How to install and configure Linux as a Web server? What are the main steps to go? This article should cover the main configuration steps for LAMP – Linux Apache MySQL PHP server.

1. Which Linux distribution to install?
2. Before installation
3. Partitioning
4. Package selection
5. Set runlevel to 3
6. Turn off needless services
7. Firewall
8. Forbid ssh access for root

1. Which Linux distribution to install?
List of Linux distributions are huge, please see Linux distribution list (after page load, click on Go button). Among that list, there exists several main Linux distributions (streams): RedHat, Debian, Suse, Ubuntu

Original Document Here

WHM

Step one was to login to Web Host Manager (the server management front-end for cPanel), and run their configuration wizard. The only things that required non-default action were:

• setting the hostname
• added a resolver (DNS) server ip

After the wizard was complete, these additional settings were performed manually:

• Server Contact E-Mail
• Turned on awstats web stats reporting tool
• Changed hostname. (Even though the wizard set it, this was an additional, different place.)
• Changed system mail preferences to send root email to an admin alias.
• Changed root password.
• Set Nameservers

Also ran Update Server Software and Update System Software within WHM to update as many components as reasonable.

Linux Kernel

The original configuration as delivered by the server farm:

WHM 10.1.0 cPanel 10.2.0-R82
RedHat Enterprise 3 i686 – WHM X v3.1.0
Linux kernel version: 2.4.21-27.ELsmp

Since that’s not the latest kernel at the time of delivery, and cPanel will not update the kernel automatically, I was advised to update. I upgraded the kernel to 2.4.21-32.0.1.ELsmp, which went smoothly.

Remote Access

One of the areas for almost immediate security tweaking is remote access. If you’ve ever examined a server’s logs, you know that they’re regularly probed with various types of attacks. There are several modifications to render those attacks pointless, as well as secure remote access in general.

SSH

SSH, or secure shell, is the remote command-line access mechanism of choice. It’s single biggest claim to fame is simply that everything is encrypted, though it includes many more features as well.

I first created a couple of non-root login accounts, and installed RSA public keys for eventual RSA/public key-only logins. (Also created end-user instructions for creating, and using, SSH key pairs.)

I then made the following changes to /etc/ssh/sshd_config:

• Protocol 2 – this disables protocol version 1, which is known to have security issues.
• PermitRootLogin without-password – this disables root login, unless a public key is used.
• PasswordAuthentication set to no – this disables the ability to login with just a username and password. A username and public key are required.

Telnet

I disabled telnet, as it allows passwords to be transmitted in the clear, and is a known security risk.

FTP

Normally at this point I would also disable the FTP service for the same reasons as Telnet – it’s a known security risk. For reasons I didn’t bother to investigate further, cPanel either complained repeatedly via email if the service was stopped, or it would restart it, depending on the technique I was attempting to use. I gave up on this and left the FTP service running, but blocked at the firewall, discussed below.

TMP

The /tmp directory is an interesting and apparently common place for hackers to exploit to breech a system. One approach to securing it without breaking its functionality is to create it as a new partition that disallows program execution. Where in the past a hacker could use an exploit to place a file in /tmp and then execute it, the ability to execute is now removed by creating a secure /tmp partition.

Firewall

Installed APF which is, essentially, an intelligent front end to the built in Linux firewall, iptables. I found a good how-to, though I did not yet configure the antidos (denial of service) component. The one change that I did make to the default configuration is that I disabled or blocked all ports that we know are not explicitly used for something specific. For example, this is where I blocked all FTP access. I also whitelisted my own static IP address, and that of the client.

Logging

Logwatch is a server log summary tool that emails a report to the server admins nightly. An older version was installed. I updated to latest, and increased the reporting level to “medium”.

Rootkit Checks

Installed nightly backup script, which includes nightly reporting of both rkhunter and chkrootkit runs.

Apache

Installed mod_security, which guards against exploits via the Apache web server, using a basic ruleset. This how to was helpful in setting that up.

General

A few additional tweaks and settings …

• Installed LES – “LES is intended as a facility to quickly & easily secure Redhat/RPM based environments (i.e: turbo Linux, open Linux). It does such by enforcing root-only permissions on system binaries (binaries that have no place being executed by normal users), enforcing root-only path traversal on system paths, enforcing immutable bit on essential rpm package contents (i.e: coreutils), and enforcing immutable bit on shell profile scripts.”
• Added a mail line to /etc/rc.d/rc.local, to automatically notify on reboots.
• Removed the cpbackup cron job, since we don’t use cPanel’s backup approach.
• Modified reverse-DNS to be correct.

Ongoing Maintenance

Even with all the tools and updates in place, there’s still on-going work and vigilance required.

• Monitor the nightly logs and reports generated for anomalies.
• Manually install updates as reported available by up2date.
• Monitor Redhat for kernel updates, and install as appropriate.
• Monitor chkrootkit for updates, and install as appropriate.

Still More Options

I haven’t implemented these, but they’ve been recommended, and they’re on the list to evaluate at some point.

• mod_doevasive. “mod_dosevasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. It is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera. mod_dosevasive presently reports abuses via email and syslog facilities.” How To
• Evaluate BFD. “BFD is a modular shell script for parsing applicable logs and checking for authentication failures.”

This saved me a couple of hours trying to figure out it myself.

Original Document Here

So you’re trying to set up ssh keys on your windows box with putty and you keep getting “Server refused our key”. Read on, I’ve got your solution… but first lets take a look at what you’ve done so far.

Chances are you have done some/none/all of the following:

• opened up puttygen.exe
• generated a key after wiggling your mouse
• entered a strong passphrase
• saved the public key to something like

  pubkey

• saved the private key to something like

  privatekey.ppk

• moved your public key up to the server
• (maybe even) converted the format of the key from putty to openssh with something like

  ssh-keygen -if pubkey > pubkey_openssh_format

• changed some permissions like

  chmod 700 .ssh

• added your pubkey to the authorized_keys file with something like

  cat pubkey >> .ssh/authorized_keys

• changed some more permissions like

  chmod 600 authorized_keys

• changed your putty settings under “connection > SSH > auth” to use

  privatekey.ppk

• tried to connect and…

“Server refused our key”

Well – from what I have read that’s supposed to work… but it didn’t work for you did it?

Your problem has nothing to do with how well you followed these well documented procedures for getting ssh keys to work.
The solution to the problem is…
(brace yourself, its really simple) to try generating the keys on the server (unix, linix, bsd etc.) instead of the client (i.e. in windows).

Try the following:

• ssh to your server using good old user name and password
• do check permissions on your ~/.ssh folder and make sure to

  chmod 700 .ssh

  if they are wrong

• do check permissions on your ~/.ssh/authorized_keys file and make sure to

  chmod 600 authorized_keys

  if they are wrong

• generate the keys on the server with something like

  ssh-keygen -t dsa

  (or rsa – read the man pages if your don’t know how to use ssh-keygen

• accept the file names it wants to use
• enter a strong passphrase
• add the pub key to the authorized_keys file with something like

  cat id_dsa.pub >> .ssh/authorized_keys

• copy the private key (id_dsa) to your local windows machine (use winscp or sftp or some such tool)
• NOW open puttygen.exe
• under actions select “load” and load the id_dsa file
• enter the passphrase you set when you generated the key on the server. Puttygen will now convert the key to something that putty will understand
• save that file to something like

  pivatekey.ppk

• NOW change your putty settings under “connection > SSH > auth” to use

  privatekey.ppk

• NOW try and connect
• enter the passphrase when prompted
• pat yourself on the back. You’re connected to the server (I hope)

Now all you have to do is figure out a way to not have to always enter that passphrase. Well that will require setting up puttyagent. But, I’ll let you figure that out for yourself.

I really hope this helped you out. I wasted too much of my life figuring this out this evening and I hope I saved you hours of aggravation.

Original Document Here

SSH (Secure Shell) and SFTP (Secure FTP) support a very strong security model that can be used instead of the normal username and password authentication scheme we’ve all come to know and love. It uses public key cryptography to create a different, and more secure approach to authenticating your identity and rights to access a server or resource.

In a nutshell, you will generate a public and private key pair. The public key will be placed on the server by your system administrator, giving you access. You will keep the file containing the private key in a safe place. You’ll login by simply by providing that private key file to your SSH or SFTP supporting client.

It really is that simple.