Yes, a can of worms... But general direction would be nice...

Scott Morris scottmorris at suseblog.com
Tue Jul 14 19:49:05 MDT 2009


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][user at 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 user at desktop
[0218][user at 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][user at desktop:~]$ ssh user at webserver.com
Last login: Tue Jul 14 10:06:41 2009 from 10.245.106.32
[1054][user at 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



More information about the PLUG mailing list