Scott Morris here. Hello everyone. :) For all of the expert Linux wizards in the land, I hail from n00btown. It would be of much help to myself, my job, and my employer if I were a little (read "much") more enlightened as to hardening a network, specifically the Linux part of the network. Thus, it seemed somewhat of a good idea to throw together a short list of measures of which I am already aware to lock down machines.
Following my yammering is a list of things that 'seem' to be at least logical to do to lock down a box or at least increase the likelihood that you can get back into it if it is compromised. I am seeking helpful, explanatory comments and suggestions as to why these thoughts would work, would not be a good idea, or that there is something better that accomplishes the same thing more efficiently. </chatter> -------------------------- When you have been hacked: -------------------------- Determine how they compromised your system. Copy /var/log/messages off the system Copy 'last' output off the system Copy the webserver logs off the system Determine, if you can, what files they modified. This cmd may help: find . -ctime -7 // find all files created in the past 7 days That command helped me find all sorts of code hackers put into the website I was fixing. ---------- HOSTS.DENY ---------- Check the /var/log/messages file for anything looking like this: Jul 14 09:48:25 nmm-webserver01 sshd[14192]: Invalid user ident from 125.71.214.15 Add the ip address to /etc/hosts.deny Disallows the host to connect to the ssh daemon DenyHosts also automatically takes care of this for you. ------------------------------------------------------ DROP ALL PACKETS FROM HOST RANGE - FIREWALL - IPTABLES ------------------------------------------------------ If a specific host is known to be hostile, block it and all hosts in its block: iptables -I INPUT -s 125.71.214.0/24 -j DROP This adds a rule to the firewall that simply drops the packets. This is more annoying to the other end because they never get a response. If you explicitly reject the packets, they get a message to the effect instantaneously. You want them to have to wait. To list rules in the INPUT chain: iptables --line-numbers -L INPUT (add -v for verbosity) To delete a rule from the INPUT chain: iptables -D INPUT <line number> ex. iptables -D INPUT 1 Would delete the first rule in the INPUT chain. Cool subnet calculator at : http://www.subnet-calculator.com/ ------------------------ ADD ADDITIONAL ROOT USER ------------------------ Add a line to your /etc/passwd file, as such: sysrt:*:0:0:System Routes:/var/lib/sysrt:/bin/bash Change the /etc/group file by adding 'sysrt' to the 'root' group, as follows: root:x:0:sysrt Add a line to the /etc/shadow file: sysrt:!:14377:::::: Then, change the sysrt user's password: passwd sysrt Then, create public/private keys for your root user and your sysrt user -------------------------- CREATE PUBLIC/PRIVATE KEYS -------------------------- Generate the two keys: [0218][u...@desktop:~]$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): [JUST PRESS ENTER HERE] Enter passphrase (empty for no passphrase): [JUST PRESS ENTER HERE] Enter same passphrase again: [JUST PRESS ENTER HERE] Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: a5:25:c0:aa:fe:f3:9f:46:7a:23:e3:6e:10:ec:6f:d3 u...@desktop [0218][u...@desktop:~]$ Copy the contents of /home/user/.ssh/id_dsa.pub to /home/user/authorized_keys2 on the remote machine where 'user' is the remote account which you wish to access. Test the setup by attempting to ssh into the remote machine: [1040][u...@desktop:~]$ ssh u...@webserver.com Last login: Tue Jul 14 10:06:41 2009 from 10.245.106.32 [1054][u...@webserver.com:~]$ ---------------------------------- RESET MYSQL ROOT PASSWORD IN LINUX ---------------------------------- First things first. Log in as root and stop the mysql daemon. Now lets start up the mysql daemon and skip the grant tables which store the passwords. mysqld_safe –skip-grant-tables You should see mysqld start up successfully. If not, well you have bigger issues. Now you should be able to connect to mysql without a password. mysql –user=root mysql update user set Password=PASSWORD(’new-password’) where user=’root’; flush privileges; exit; Now kill your running mysqld, then restart it normally. You should be good to go. Try not to forget your password again. --------------- ALLOW_URL_FOPEN --------------- This should be set to 'off' in the php.ini file. It allows for file operations on urls. Someone can pull in any file they want. Keep this off. ---------- FTP SERVER ---------- Never ever use an FTP server. If you do, make sure it is the only thing running on that box. Make sure that it does not have access to any other machine in your network (i.e., that it is outside your network). Make sure it is jailed. Make sure it is in India. Anyone have some sources that I could consult that give some generally good ideas of security measures, and then how to clean up once you've been pwnd? Or comments on the above suggestions? Thanks for your collective wisdom, expertise, and valuable input. Except for Steve or Jason. :) Scott /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
