# Top security tools and tricks

## corley

Ok I thought about it recently and am curious to know what everyones opinion of 'must have' security tools' or tricks used to make and/or keep a system secure against break-ins/hacks/etc. Might make an interesting thread.  :Smile: 

Personally I use a variety scripts along with the standard iptables to secure my boxes as well as doing some commonly know and some not so commonly known (at least to some) to help.

1. Make sure to edit your /etc/ssh/sshd_config and at a miminum change the following

     a. Make the port > 2000  (If you leave this as 22 you are open to brute force script attacks)

     b. Make the Protocol line = Protocol 2 only.

     c. PermitRootLogin = no (make sure your users have to login with a standard account then su - to gain root if you want)

     d. Optionally use ssh forwarding to prevent having to type passwords each time.

2. Edit your /root/.bash_profile and add a line similar to:

    echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" your_name@yourisp.com

    This is useful for notifying you via email if someone logins in or su's to root.

3. If you are script savy you can write up some scripts to watch various ports for attacks and automatically firewall users after so many negative tries. There's alot of scripts out there like this even if you can't write them. DAVBlack is an excellent one for starters.

4. Disable telnet

5. Use ssh encryption for pop3, smtp, webmail and the like. Plain passwords to your server is not good. If anyone can use those same plain text passwords to say .. log in.. then you might as well not use encryption anywhere else. Encyrption is only as strong as it's weakest link. That goes for security in general too.

6. Use SFTP instead of ftp.

7. Use tripwire from the moment you get your server up and running.

8. Copy binaries of a few of the files you will definately need incase you are hacked and put them somewhere you can access them later. Perferably encrypted.

9. Install LSOF in you haven't. Most rootkits don't mess with it and it's great not only for tracking down open connections and rootkits but it's an envaluable SA tool.

10. Don't forget the simple things which are in actuality most important. Update daily if you can (emerge) but weekly on the very least. Monitor the forums here and watch for exploits and patch them immediately. If you run things like phpBB, gallery, or anything php related, then you will have to watch that like a hawk and keep it patched. If you will notice most of the stuff that is hackable right now are those php type scripts.

11. Install chkrootkit and rkhunter

12. Install ClamAV and SpamAssassin

These things are a bare minimum of what I do with all of my servers but is by no means a end all in security. Which.. is the reason I started this thread. I hope someone makes it sticky and alot of security people and others can get together and post their input. I'd love to hear what everyone else is doing along these lines.  :Smile: 

----------

## SinoTech

I've also done the following:

1. Changed ssh to use public key authentication only

2. Installed iptables to make sure no programs are allowed to go out (Except a hand full which are specified with full path)

(For the case someone hacked my box and want to use it to send spammail, trade files, ...)

Mfg

Sino

----------

## segedunum

 *Quote:*   

> 
> 
> Ok I thought about it recently and am curious to know what everyones opinion of 'must have' security tools' or tricks used to make and/or keep a system secure against break-ins/hacks/etc. Might make an interesting thread.
> 
> 

 

Forget about knee-jerk reactions to security and trying to jump on every mole hill in a field. Do not run a SSH server, or any admin tools, publicly. If you wish to admin your server from the outside on the internet then set up a VPN and pipe all your network communication through it, including SSH.

The only thing you should be running publicly is your VPN server, and possibly something like a website should you want to run something publicly for anonymous people to use.

Of course, this is complicated slightly if you don't have access to the server physically (what happens if the VPN goes down?) In that case, in terms of publicly running SSH servers, I would create some public and private keys and only allow logins that way. Disallow password logins. But, if you do have physical access to your server(s), don't run anything like that publically.

----------

## tumbak

I wrote scripts that extract values such as the number of currently logged in users and I store those numbers in an RRD database, I check the graphs everyday and after about 2 weeks of observation I can easily pinpoint an anamoly and investigate the issue.

some values I watch for:

1 - apache busy and idle processes.

2 - system load, those (1 min, 5 min, 15 min) values.

3 - Disk Space.

4 - currently logged in users.

5 - qmail queue size and simulatnous SMTP connections.

I always use a DROP policy for all iptables chains and I explicitly allow certain ports.

----------

## nielchiano

Nice list!

However, I'm wondering if anyone could help me with:

 *corley wrote:*   

> 7. Use tripwire from the moment you get your server up and running.

 

I'm still trying to find a descent policy which doesn't look for dozens of non-existing RedHat files... and I'm worried that I might strip out too much.

----------

## MrUlterior

Stuff I do to my boxes in no particular order ... it's by no means exhaustive, but these are the most important ones IMO.

YMMV UAYOR  :Smile: 

Run SSHDfilter to dynamically create iptables DROP rules for people bruteforcing your SSHD http://www.csc.liv.ac.uk/~greg/sshdfilter/

 Install AIDE instead of tripwire (if it ain't OSS, it ain't usable ... )

 As mentioned, move your SSHD off port 22, install portsentry and monitor 22, 137, 139, 445 and dynamically DROP packets from the trojan infested zombies that scan for abusable windows/samba shares ...

 Run logcheck daily, to recieve emailed reports on logged events on your boxes

 Use iptables's owner module to restrict outbound traffic by user _AND_ command. 

 Use SSH public key authentication & keep your keys on a USB removable device

 Enable process accounting & limit the ammount of process per untrusted user to prevent thread forking attacks by malicious local users or compromised accounts.

 Where possible, mount file systems as noexec or readonly

 Log to a remote machine with the highest verbosity possible

 Where possible when you install 3rd party PHP stuff, do not use default naming conventions (eg. don't install phpmyadmin at /phpmyadmin/ on your server) 

 Don't install abusable services like POP3 & IMAP on your internet facing NIC, rather install openvpn and use these services over that; it's less hassle than SSH tunnels and there's even a Windows client

 Run the following script frequently to remind yourself what listens on what port & check that nothing has been added.

```
netstat -nap| egrep "(0\.0\.0\.0).*(0\.0\.0\.0).*LISTEN" | \

        gawk '{print $4 "\t" $7}' | egrep -o ":(.*)" | cut -c 2-
```

 Use generated passwords, typically I install APG & run the following to generate passwords

```
apg -m 30
```

 - if your password is memorable, its probably too short.

 Ensure that if you have multiple unix boxes on the same network, root & privileged user accounts are NOT synced between them

 Check frequently for setuid binaries/shell scripts

 Perform differential backups frequently so that in the event of a compromise you are able to undo just the modifications made by the hacker & fix the hole(s) rather than re-installing the entire box (I use rdiff-backup via SSH backup to a remote host)

 Users by nature are untrustworthy, log everything they do! Recompile BASH with logging so that even rm -f ~/.bash_history will not cover the trail ... 

 Alter the OS fingerprint of your boxes so they're identified by nmap etc as Win 98 or a C64 or something.

 Turn off apache signature's -- why tell any hackers what version you're running? Let 'em find out the hard way.

 Disable inbound UDP and ICMP traffic from the internet

 Enforce a minimum 2048 bit keylength on SSH

 Ensure that your /var/log/ partition is sufficiently sized so that an attacker can not just fill the disk by flooding the logs before doing malicious stuff 

 chroot services where possible

 Set users shell to /bin/false whereever possible

 Disable kernel support for broadcasts

 Disable kernel module support & internalise all components to prevent the LKM type trojans

 Run snort

 Graph traffic in/out -- spikes will help you pinpoint suspicious stuff

 Check for promiscuous mode NIC's on your network, this could be the first indication that someone has compromised something on your LAN -- your box(es) could be next!

 do NOT use wireless junk unless using something secure over it, like openvpn

 never use wireless keyboards and move your keyboard port to the front of your PC so that you can quickly check for the presence of a physical keylogger

 enable chassis intrusion detection

 encrypt local partitions

 Use a switch not a hub on your LAN

 Use portsentry to block wankers port-scanning you, investigate use of the MIRROR target  :Smile: 

 do NOT install BIND

 do NOT install Sendmail

 do NOT install Wuftpd

 do NOT install Samba

 do NOT install NFS

 do NOT install non-essential apps

 be paranoid!

----------

## UberLord

 *MrUlterior wrote:*   

> [*] be paranoid!

 

Based on that list I'd say that you need locking up   :Razz: 

----------

## MrUlterior

 *UberLord wrote:*   

>  *MrUlterior wrote:*   [*] be paranoid! 
> 
> Based on that list I'd say that you need locking up  

 

I'd agree that some of the things I suggested are not neccesary for everyone; but to me that looks like a sensible list of precautions. I mean heck, security is only as good as the weakest link in the chain, so any attempt to secure a box has to be serious or else is pointless.

----------

## MrUlterior

Can't believe I forgot this  :Sad: 

 Make sure your ARP cache is static

----------

## nielchiano

 *MrUlterior wrote:*   

> 
> 
> Disable inbound UDP and ICMP traffic from the internet
> 
> 

 

I hope you don't mean this to the letter?

you probabely need DNS for most things to work

second: just blocking ICMP is a BAD IDEA. at the very least, allow iptables to decide what ICMP's are related to other connections before dropping the rest. I had serious problems with this. I'm behind ADSL, PPPoE, which basicaly has a MTU of 1492 instead of the usual 1500. This isn't a problem, when a too large packet arrives, you just send back a ICMP Fragmentation Needed.

If this gets dropped by a firewall, the connection seems to set up, small amounts of data work, but it "suddenly" doesn't work anymore...

----------

## UberLord

 *MrUlterior wrote:*   

> I'd agree that some of the things I suggested are not neccesary for everyone; but to me that looks like a sensible list of precautions. I mean heck, security is only as good as the weakest link in the chain, so any attempt to secure a box has to be serious or else is pointless.

 

One of the weaklist links is a human. Especially memory.

Now, did I put my ssh on port 3529 on server foo, or was it 3525? Or was for that server bar?

Hang on, I know I wrote it on a post it under my keyboard!

You get the idea.

Alternatively you can say ssh is always on port 22 as I keep forgetting my random ports, BUT every client that connects needs to present a valid SSL cert allowed by an account as the only means of authentication.

You can even go one better by having a port-knock script (which you mention) that opens and closes port22 to a certain IP based on knocks.

----------

## kamikaze04

If you are using apache + php, ensure them:

apache: - Disable showing the version

            - Use mod_security with the rules in www.gotroot.com

            - Use mod_evasive if you could suffer a DOS attack

            - Use mod_ssl if your users write passwords etc...

            - Use mod_bandwith if you want to limit the bandwith depending on the ip/range

php     : 

Register globals off

Safe mode on

allow_url_fopen = Off

disable_functions like dl phpinfo system mail exec passthru

open_basedir

file_uploads = Off 

max_execution_time 

expose_php = Off 

display_errors = Off

If find this thread highly important, everybody should keep writing ther litte tips,tricks and configs  :Very Happy: 

Have a nice day!

----------

## krolden

 *UberLord wrote:*   

> 
> 
> You can even go one better by having a port-knock script (which you mention) that opens and closes port22 to a certain IP based on knocks.

 

Alternatively you could allow connections based on IP.  Can be done through (x)inetd or even through iptables.

My box at university has a static IP, so unless I'm connecting from that IP to my home box, all packets get dropped.

----------

## adelante

 *Quote:*   

> 
> 
> #  Enable process accounting & limit the ammount of process per untrusted user to prevent thread forking attacks by malicious local users or compromised accounts.
> 
> 

 

Is there any GOOD doc's on how to do this, i run php on my box, and i would like to know the best way to prevent someone from running a script which could use up all the system resources.

----------

## slycordinator

 *UberLord wrote:*   

> Alternatively you can say ssh is always on port 22 as I keep forgetting my random ports, BUT every client that connects needs to present a valid SSL cert allowed by an account as the only means of authentication.
> 
> You can even go one better by having a port-knock script (which you mention) that opens and closes port22 to a certain IP based on knocks.

 

First you say that certs are better than passwords. Then you say that using port-knocks is even better. But isn't the combination of ports in port knocking just a password?

----------

## nielchiano

 *slycordinator wrote:*   

> But isn't the combination of ports in port knocking just a password?

 

yes and no. It is a kind of password, but without a password prompt.

So it's combined with obscurity (while not a good security thing on it's own, it's nice when combined)

----------

## slycordinator

 *nielchiano wrote:*   

> 
> 
> yes and no. It is a kind of password, but without a password prompt.
> 
> So it's combined with obscurity (while not a good security thing on it's own, it's nice when combined)

 

1) leaving out a password prompt doesn't make the knock not be a password

2) also, there's the problem that this moves the security of the server out of the server and onto client boxes. If the attacker broke through any one of your client boxes your server is screwed.

3) What about man-in-the-middle or replay attacks? It fails with those as well.

----------

## nielchiano

 *UberLord wrote:*   

> You can even go one better by having a port-knock script (which you mention) that opens and closes port22 to a certain IP based on knocks.

 

I understand that the knocking is only to OPEN the port; you'd still have to SSH-login either with another passwd or with keys

----------

## MrUlterior

Port-knocking is only useful in one aspect IMO:

It conceals any services you may run. This means a cursory scan of your box will show very little of interest perhaps making it less of a target (certainly to most automated rootkits that I've encountered). After all, it's difficult to exploit something you can't prove is there. So effectively, this is just another method of "security via obscurity". Heck you could hack up your SSHD and remove the login & password prompts if you really want to go down this road ...

Personally I think it's useless, I work frequently from behind extremely fascist firewalls which limit my outbound to TCP ports 80 & 443 -- So I've not much use for port-knocking ..

 *Quote:*   

> I hope you don't mean this to the letter?
> 
> you probabely need DNS for most things to work
> 
> second: just blocking ICMP is a BAD IDEA.

 

Actually I do, I tunnel my DNS out via VPN to a remote server, I have no interest at all in using my ISP's nameservers. This is just more information your ISP, Govt, etc have about you -- what FQDNs you resolve. 

Regarding ICMP, I've had ADSL & Cable for the past 6 or 7 years running on my setup; my  MTU has always been 1500 -- no problems at all; as with all the "tips" -- your mileage may vary  :Smile: 

----------

## UberLord

 *slycordinator wrote:*   

>  *UberLord wrote:*   Alternatively you can say ssh is always on port 22 as I keep forgetting my random ports, BUT every client that connects needs to present a valid SSL cert allowed by an account as the only means of authentication.
> 
> You can even go one better by having a port-knock script (which you mention) that opens and closes port22 to a certain IP based on knocks. 
> 
> First you say that certs are better than passwords. Then you say that using port-knocks is even better. But isn't the combination of ports in port knocking just a password?

 

How about a passworded cert + a port knock? By "one better" I meant an extra layer of "security" - I didn't mean to imply that port knocks are > certs > passwords.

The point I was trying to make is that while security through obscurity does give you a nice tingly feeling, it can be a false tingly feeling as someone just has to see through it.

----------

## krolden

 *adelante wrote:*   

>  *Quote:*   
> 
> #  Enable process accounting & limit the ammount of process per untrusted user to prevent thread forking attacks by malicious local users or compromised accounts.
> 
>  
> ...

 

http://gentoo-wiki.com/SECURITY_Limit_User_Processes

----------

## kamikaze04

Also,

- Mount /tmp with noexec,nosuid,nodev (really usefull for apache)

- Use quotas for users (if you have them)

----------

## UberLord

my servers fstab bit

```

none                    /dev/shm        tmpfs           noexec,nosuid,nodev     0 0

none                    /tmp            tmpfs           noexec,nosuid   0 0

```

iirc, there was an issue with mounting /tmp with nodev and I cannot remember what it was....

----------

## MrUlterior

 *UberLord wrote:*   

> my servers fstab bit
> 
> ```
> 
> none                    /dev/shm        tmpfs           noexec,nosuid,nodev     0 0
> ...

 

/tmp/mysql.sock or some other socket perhaps?

----------

## slycordinator

 *UberLord wrote:*   

> 
> 
> How about a passworded cert + a port knock? By "one better" I meant an extra layer of "security" - I didn't mean to imply that port knocks are > certs > passwords.

 

It wasn't clear that that's what you meant. From what you wrote originally it seemed that you were saying that a port knock IS "one better" than using passworded certs.

----------

## humbletech99

somebody forgot to say unplug the network cable and bury the computer in a locked room, itself buried in a nuclear bunkar, itself completely sealed underground and concreted over. Then nobody will be able to break in (least of all you!).

Thanks for the tips, that was a very long list MrUlterior, thanks for that, the only thing is, we've got to actually make our boxes do something useful as well in order to justify their existence as well as our own! 

The static arp thing strikes me as a step too far maybe, since you'd have to really distrust your local network... Oh, and I second UberLord, you do need locking up! That's the profile of a dangerously paranoid person!

I do however, agree with most of what you said, especially the minimalist attitude to apps, but then what would you expect from a gentoo user? Samba seems pretty critical though these days, I think that firewalling it is probably all that can be done there...

Uberlord, I'd love to know that the problem with the nodev setting on /tmp is. I've done this on 2 production web servers and it doesn't seem to have had any adverse side effects, maybe I'm just not running anything that would complain, but I'm a fan of the nosuid and especially noexec bits though...

I haven't experimented with port knocking yet, does anyone know a really good howto?

----------

## MrUlterior

 *humbletech99 wrote:*   

> The static arp thing strikes me as a step too far maybe, since you'd have to really distrust your local network... Oh, and I second UberLord, you do need locking up! That's the profile of a dangerously paranoid person!

 

Actually it's standard practice on many large scale LANs where people are only supposed to use the "authorized" equipment. Essentially it ensures that a DHCP server will never acknowledge an unknown host. Handily it also minimises the effects of MitM attacks on infrastructure (servers) though not so much against workstations and other appliances. I work on such a system daily, and these sort of measures vastly reduce the impact of Joe Average who decides to plug in their virus/trojan ridden PC to the corporate LAN to print something. Likewise, these same measures make things like the 802.11 X experience (which I don't advocate to begin with, but that's another story) that extra bit safer ...

If any of that qualifies me for locking up, then I know a heck of a lot of people in that category too: they're called sys admins  :Razz: 

----------

## humbletech99

I don't see how this would help with the DHCP server as you said, since the arp is ip to Mac mapping and a client has no ip (hence it's requesting one from the DHCP server), although it is supposed to prevent mitm attacks. You could tell the DHCP server to give addresses to only certain macs but this defeats the purpose of the DHCP server in my opinion since you may as well just statically assign. I believe M$ are making strives in security so that you have to authenticate and have a proven known safe state before you can even get an ip (dunno how yet, it may still be development - I got this from some of their top security guys I met)

Well, most "sysadmins" don't know all that much about security, you're one of the more clued up ones (maybe I've just known too many talentless monkeys...). I appreciate the list, I guess it also depends on the place you work, if security is a massive security consideration or not. Where I'm working now, it's fairly open internally and it will take a long time to change that, since everybody's so busy and the priority is for everything to work and for things to get done for the business...

I actually like most of your list but sometimes there isn't time to do everything (especially not in the huge variety  of stuff I gotta do at my new place...).

Having local firewalls on every machine also helps if you can, and also, not running a DHCP server or a Wireless Lan is definitely a plus. What I did in my last place was to have both but keep them switched off, if they then needed to be used temporarily, I double clicked an icon and entered my password to switch on my DHCP server an another machine (and later another to switch it off) to tightly control what  happened on the lan so that somebody couldn't just come along and jack in etc...

----------

## mikegpitt

I'm suprised there was only one quick mention of snort on this thread.  I'd say if you want to ensure the safety of your network/machine snort is mandatory.  

Things like snort work better when installed on another invisible machine though (ie. a dedicated snort server that is only physically accessible), so if anyone does break in you can guarantee an untainted log of what happened.

----------

## cynric

Interesting. Picked up some new ideas. Wanted to toss out Gentoo's own security handbook.

----------

## jamapii

I think many of these tips are good, but many add only little security.

If you intend to use a password, always use a good one. WPA is insecure with a weak password. The current ssh attacks you're seeing is only looking for weak passwords only, and I consider the attention it gets here vastly overrated. Real brute-force attacks need to know the user (which is likely no secret) but not the ssh port (scanning all ports is no big deal), and then they must try millions of passwords (if they are enabled at all). How long does one attempt take? -> look into /etc/ssh/sshd_config

After using good passwords, the most dangerous situation occurs if you type it into an untrusted machine. There might be a keylogger. 

The risk with public/private keys is that if the private key is on a device that is lost or stolen, you must be quick to remove the line from ~/.ssh/authorized_keys

Of all possible servers, I consider openssh the most secure. Its history is longer than openvpn and others, it's probably well tested, all communications are encrypted, and the last serious problem was years ago. If I can only have one server, I choose openssh, not openvpn.

Never rely on WEP for security! This problem is vastly underrated! You could just as well leave the WLAN open and should then secure the computers individually.

spamassassin and clamav decrease security. If they are vulnerable, someone can send you an evil mail and you're compromised without running a server at all. But I couldn't read my mail without them.

Most iptables scripts I've ever seen seem to contain subtle bugs - if someone connects from port 80 to your filtered X server, will it still be filtered? Watch out for this.

Some methods make access more inconvenient but add only little security, this includes portknocking if you access ssh from a smartphone. Also, running both openvpn and ssh is more insecure, but if one of them crashes/fails for some reason, you can use the other to gain access and correct it.

I don't disable ping, it only makes testing harder.

Subscribe to the security announcements! Clients can be vulnerable, too, even a .png can carry a virus.

----------

## jamapii

 *nielchiano wrote:*   

>  *slycordinator wrote:*   But isn't the combination of ports in port knocking just a password? 
> 
> yes and no. It is a kind of password, but without a password prompt.
> 
> So it's combined with obscurity (while not a good security thing on it's own, it's nice when combined)

 

I'd say on its own, portknocking is as good as telnet. For those attackers who can eavesdrop on your traffic, it's easy to get through, but they should still have a hard time getting into openssh or openvpn. For everyone else, it basically locks them out.

----------

## jamapii

 *MrUlterior wrote:*   

> 
> 
>  Use iptables's owner module to restrict outbound traffic by user _AND_ command. 

 

but only --gid-owner can still be used for that, see https://forums.gentoo.org/viewtopic-t-417517.html

 *Quote:*   

> 
> 
>  Use generated passwords, typically I install APG & run the following to generate passwords
> 
> ```
> ...

 

good idea!

 *Quote:*   

> 
> 
>  Use a switch not a hub on your LAN
> 
> 

 

In what ways can this improve security?

----------

## think4urs11

 *jamapii wrote:*   

>  *Quote:*   
> 
>  Use a switch not a hub on your LAN
> 
>  
> ...

 

(quite minimal) additional hurdle - you first need to flood the arp table in the switch before you can sniff the complete segment traffic.

But you are right, to believe switching adds security is as effective as believing VLans add more real security - in other words 'snake oil security'  :Wink: 

----------

## cynric

Think4UrS11 answered it, but if anyone wanted to read more on it, the main thing to look at is what's called a "collision domain". A hub does not create another collision domain and re-broadcasts all data to all ports; except the original of course. This allows anyone on any of the other ports to easily listen to all traffic. A switch (and router) creates a collision domain for each port. This lowers overall bandwidth consumption from having to re-broadcast by giving each port it's own, dedicated path to the switch. That is what creates the byproduct of security in that it's difficult to listen to those other dedicated ports. There are other differences between switches and hubs, but you can read up on that on your own.

----------

## Esel Theo

corley,

I think there are a number of interesting ideas in your list. However, you have to think about who suffers most from you security enhancment ideas, you or the one who wants to get into your machine.

 *corley wrote:*   

> 
> 
> 1. Make sure to edit your /etc/ssh/sshd_config and at a miminum change the following
> 
>      a. Make the port > 2000  (If you leave this as 22 you are open to brute force script attacks)
> ...

 

I guess this only eliminates those numerous entries in /var/log/messages, when some automated script is trying to brute-force your machine. In the first place, however, you are annoying legal users of your system who will always have to remember your SSH port. If you use hard passwords (or better key based authentication), these script kiddies won't hack your machine anyway. And if someone is really up to your machine, he will find you SSH port easily. (A quick port scan suffices. Have you ever looked at how much information your SSH server exposes to connecting clients by the way? Try telnet localhost ssh.)

 *Quote:*   

> 
> 
> 2. Edit your /root/.bash_profile and add a line similar to:
> 
>     echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" your_name@yourisp.com
> ...

 

If somebody hacks your machine, he/she certainly doesn't by logging in or su'ing to root. So this IMHO nonsense and only blows up your mailbox.

 *Quote:*   

> 
> 
> 8. Copy binaries of a few of the files you will definately need incase you are hacked and put them somewhere you can access them later. Perferably encrypted.
> 
> 

 

...but don't forget to use statically linked binaries...

----------

## MrUlterior

 *Esel Theo wrote:*   

> 
> 
>  *Quote:*   
> 
> 8. Copy binaries of a few of the files you will definately need incase you are hacked and put them somewhere you can access them later. Perferably encrypted.
> ...

 

Personally I don't bother with this anymore, I use Knoppix CD for forensics on x86 and a custom Gentoo livecd for amd64. Is there any concievable version to bother retaining your own static bins anymore?

----------

## humbletech99

what tools do you use for forensics?

----------

## MrUlterior

 *humbletech99 wrote:*   

> what tools do you use for forensics?

 

 *Quote:*   

> *  app-forensics/rkhunter
> 
>       Latest version available: 1.2.7-r1
> 
>       Latest version installed: 1.2.7-r1
> ...

 

Are the obvious candidates for cold forensics, though I suspect there're others in /usr/portage/app-forensics/ that I've yet to use.

Beyond that, common tools like "strings" (search binaries for suspicious strings), and a comprehensive database of sha1sum hashs of every single file on a server (these are auto-generated once a week and written to WORM media). I also maintain a listing of "static" directories like /dev etc which is auto compared against current contents generating an immediate warning if anything appears in there. A useful addition I've found is simple script to search for setuid & executable stuff.

For live forensics, in addition to the above (as I will never trust binaries on a running system): Tcpdump/ethereal are very useful, in addition to lsof, netstat, ps, top, iftop.

----------

## steveb

Moving SSH to a differend port then 22 is not helping very much. A simple:

```
nmap -sS -sV <target> | sed -n "s:^\([0-9]*\)/.*ssh.*:\1:gIp"
```

can easy spot the correct SSH port.

If I would spot a system runing SSH on a differend port then 22, then I would be very much suspicious and start hacking the hell out of that system.

cheers

SteveB

----------

## Esel Theo

 *MrUlterior wrote:*   

>  *Esel Theo wrote:*   
> 
>  *Quote:*   
> 
> 8. Copy binaries of a few of the files you will definately need incase you are hacked and put them somewhere you can access them later. Perferably encrypted.
> ...

 

It may be wise to produce dedicated binaries of important system tools and use them also for every day administration. Rootkits usually only modify a bunch of predefined binaries (/bin/ps, /bin/ls, etc.). If root instead uses /roots/own/ps, he/she has a good chance that they are left untouched by rootkits. This gives a higher chance that he/she finds out that a machine was hacked after all.

----------

## humbletech99

you may want to change the name to something other than ps though cos I'm sure rootkits can be coded to just search out all references of 'ps' binary and replace them, for example.

----------

## MrUlterior

 *Esel Theo wrote:*   

> 
> 
> It may be wise to produce dedicated binaries of important system tools and use them also for every day administration. Rootkits usually only modify a bunch of predefined binaries (/bin/ps, /bin/ls, etc.). If root instead uses /roots/own/ps, he/she has a good chance that they are left untouched by rootkits. This gives a higher chance that he/she finds out that a machine was hacked after all.

 

Think about this:

1. If they're for day-to-day stuff, they have to be accessible (eg. in root's PATH to start with)

2. A rootkit in the process of installing backdoors into your bins already has root

3. Trojans are fairly cross-distro (even OS independant in some cases ... ) therefore /usr/local/bin/blah on one system is /usr/bin/blah on another, /opt/something/bin/blah on yet another. Therefore the trojan searches for "blah" to find its target

Given all the above, to prevent corruption of the bins you intend to use to detect corruption, the ONLY way this works is if there is not physical method by which the attacker can subvert your binaries.  Some people mount RO an NFS share and put this in root's PATH before everything else, others burn them to CDROM.

This still leaves several huge problems:

1. In a large environment with differing servers it is not practical to maintain the set of bins for many architectures & versions on WORM media.

2. A RO NFS mount could be compromised

3. Even known good binaries rely on the running kernel to produce any info, given that LKM trojans exist and are commonplace, even this info can't be trusted. For example ps relies on the kernel for a process list, now if the info the kernel returns has been maliciously altered to hide process "bb", you're not going to see that process whether you run the trojanned version of ps or your known good version of ps.

So, I repeat my question:

Why bother? Concentrate on IDS and at the slightest hint of a compromise, physically disconnect the machine from the inet perform preliminary forensics, then shutdown & perform autospy prior to a complete rebuild. It might give you the perception that you have a better chance of detecting compromise, but it definitely also gives you a false sense of security.[/list]

----------

## nitroburn

I agree that moving ssh to a different port helps keep the trolls off your logs, but doesn't help against a directed attacks.

Now that I admin several boxes I only have one open to the net...all the other servers are wide open to the net, except I use /etc/hosts.deny SSHD:ALL and only allow my open machine's ip in /etc/hosts.allow   I watch my main machine's logs all the time and have an extensive /etc/hosts.deny with all the updated trolls in them. 

I currenty run without a firefwall and only have apache open to the net on our production servers...mysql only listens to localhost(speed too:)

The primary thing is to evaluate what is open and how to protect those services. If they are a private service try to make it where only your machines can connect. 

I have found overtime that a lot security "tools" just open you to more vulnerabilities, most people just need to get back in the rl and see what services they need open to the world and keep those up to date.

----------

