I keep hearing keys only ssh ... I'll add that too. But I do have a question. If the students are not allowed to bring in outside laptops (to store their private keys on), this would seem like a bad idea. Public and Private keys would both be installed on the servers.
I've attached the latest version. Thanks again for all of your input. Keep the advice coming! -- Joseph Kern On Tue, Feb 2, 2010 at 2:06 PM, Chuong Dao <c...@sentrilock.com> wrote: > From a quick look through the responses, it seems like we've been focusing > mostly on remote attacks. Looks like you're allowing SSH (w/o root access). > Watch for local vulnerabilities. > > > -----Original Message----- > From: discuss-boun...@lopsa.org [mailto:discuss-boun...@lopsa.org] On Behalf > Of Joseph Kern > Sent: Tuesday, February 02, 2010 12:14 PM > To: LOPSA Discuss List > Subject: Re: [lopsa-discuss] If you only had 5 minutes to secure a server ... > > Here's what I got so far ... suggestions? > > On Tue, Feb 2, 2010 at 8:21 AM, Edward Ned Harvey <lop...@nedharvey.com> > wrote: >>> 3b) ssh key only authentication >> >> And generate new keys too, just incase anyone ever got them before. >> >> >Title: CTF-Cutsheet
CTF-Cutsheet
Table of Contents
1 CTF Cutsheet - Defenders v0.1
Last updated:
Written by: Joseph Kern
Lots (and lots) of Help From: Chuong Dao, Edward Harvey, David Lang, Tom Limoncelli, Atom Powers, Matt Simmons, and Nick Whalen
Want to add something? Email Additions to joseph.a.kern (AT) gmail (DOT) com
2 DO THIS FIRST
2.1 Accounts
2.1.1 [ ] Create sudo enabled accounts for all defenders
# adduser <username>
2.1.2 [ ] Add accounts to the sudoer file
# visudo
Where it says 'root ALL=(ALL) ALL' add the line (for each <username>):
<username> ALL=(ALL)
2.1.3 [ ] Change all root passwords
# passwd root
2.2 SSH
After every configuration change restart ssh.
/etc/(somewhere.d)/ssh(d) resart
2.2.1 [ ] Disable root login via ssh
vi /etc/ssh/(config) "PermitRootLogin" to "no"
Note: The ssh config file may be named differently.
2.2.2 [ ] Also note any other groups or users in this file
If they are not used for scoring or for scoring services, disable them
2.2.3 [ ] Disable SSH Password Logins
NOTE This is a great idea IF you have no-play laptops that you'll be using for CTF. BUT if the only systems you have are the in-play servers this may very well be a bad idea. IMHO.
This is highly recommended, brute force password attempts become usless.
The following guide was stolen from sial.org
client$ mkdir ~/.ssh client$ chmod 700 ~/.ssh client$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa Enter passphrase (empty for no passphrase): ... Enter same passphrase again: ...
Do not use an empty passphrase!
# first, upload public key from client to server client$ scp ~/.ssh/id_rsa.pub <username>@server.example.org:~/
# next, setup the public key on server server$ mkdir ~/.ssh server$ chmod 700 ~/.ssh server$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys server$ chmod 600 ~/.ssh/authorized_keys server$ rm ~/id_rsa.pub
Set the following parameters in your ssh config
RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no
3 Configuration Management
3.1 [ ] Backup important config files
cp -r /etc/* ~/mnt/(usb-or-whatever)/
There is an issue here. If the attacker corrupt this local backup you're hosed. Keep these backups off the server. Then unplug the drive! Yes this is a pain. But it will pay off. Create new backup directories each time you change any of the files.
3.2 [ ] Hash all config files
sha1sum /etc/* > ~/tmp/hashes.sum
This file needs to be backed up as well, once local once remote, remember you must rerun this every-time you make a change to the configs.
3.3 [ ] Check configs for changes
sha1sum -c hashes | grep FAILED
This will NOT work if you don't keep your config backups and hash files current inform your team members of this.
3.4 [ ] Replace configs as needed
3.5 [ ] Look for currently logged in users
users
4 Network and Services Management
4.1 [ ] List all listening services
# netstat -lp # service list
service is zenwalk specific, YMMV.
4.2 [ ] Disable all unscored services
4.3 [ ] Use nmap on all servers periodically
# nmap <local ip block or system>
You can set up a script to run nmap against all systems, store the results, and then run a diff across the two versions. This will alert you to any changes.
5 LAMP Stack
LAMP (Linux Apache MySQL PHP|Perl|Python)This is a large topic, and could lead to reams of documentation. Here's some things to look for.
5.1 [ ] root should not be running any of the services
There is NO reason root should be running any of these services. If you change the user or group, make sure you change the file permissions as well.
5.2 [ ] Change all admin passwords within the applications
5.3 [ ] Change default URLs to web pages that enable administration
These will be in application specific files
5.4 [ ] Monitor resource usage
This may give you an early warning. I like using htop.
6 Firewall
iptables is complex (if you've never used it), if you don't have a ruleset start with this:
6.1 [ ] Listing all current iptables (firewall rules)
iptables -nL
6.2 [ ] Creating a basic ruleset
What I suggest is stopping all traffic, and then allowing on scored traffic through.
This is a basic firewall built with iptables. This needs to be modified to allow incoming connections to services.
Firewall template stolen from pzion.org and modified, this has not been tested yet …
#!/bin/bash # This assumes your external NIC is eth0 EXT-NIC=eth0 iptables --flush iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP iptables --append INPUT -i lo -j ACCEPT iptables --append OUTPUT -o lo -j ACCEPT iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# from here you need to add site specific info: # example for ssh on port 22 and http on port 80 # iptables -A INPUT -p tcp -i $EXT-NIC --dport 22 --sport 1024:65535 -m state \ --state NEW -j ACCEPT # iptables -A INPUT -p tcp -i $EXT-NIC --dport 80 --sport 1024:65535 -m state \ --state NEW -j ACCEPT
iptables -A INPUT -j DROP # Here's your implicit DROP/DENY NOTE: You will NOT be able to ping after this is set.
6.3 iptables kung-fu
6.3.1 SYN Flood
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT
6.3.2 ICMP Denial of Service
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -i eth0\ -j ACCEPT
This rule may conflict with the last rule of the script template.
6.3.3 The Nuclear Option
If you find yourself in an impossible situation and need to cut off all access issue this command.
iptables -I INPUT 1 -j DROP
This will insert a rule at the top of the chain, dropping all connections. If you are using ssh, you will be dropped as well. The only way to regain access is to use a physical terminal.
- Removing this option
This will delete the 1st rule of the chain.iptables -D INPUT 1
7 References
7.1 IPtables Resources
- Linux Firewalls Using iptables
- Ubuntu IPtables Community Wiki (Includes logging examples)
7.2 SSH
Date: 2010-02-02 15:51:54 EST
HTML generated by org-mode 6.34 in emacs 23
_______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
