How do I test the security of my box?

moisespedro · 09-02-2014, 09:57 PM

In my search to secure my computer I found a few things and then I edited a few files.

/etc/hosts.allow:

Code:

ALL: ALL: DENY

/etc/hosts.deny:

Code:

ALL: ALL

my iptables (got it from BLFS book):

Code:

#!/bin/sh

# Begin rc.iptables

# Insert connection-tracking modules
# (not needed if built into the kernel)
modprobe nf_conntrack
modprobe xt_LOG

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects

# Do not send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface, where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians

# be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# disable Explicit Congestion Notification
# too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local-only connections
iptables -A INPUT  -i lo -j ACCEPT

# Free output on any interface to any ip for any service
# (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT

# Permit answers on already established connections
# and permit new connections related to established ones
# (e.g. port mode ftp)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Log everything else. What's Windows' latest exploitable vulnerability?
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

# End $rc_base/rc.iptables

I have services I don't need disabled, including SSH. It is fully patched with all security patches, and some other patches I grab from mancha's thread.

What else can I do? And how can I test it?

ReaperX7 · 09-02-2014, 09:59 PM

Get another machine and attack the hell out of it.

moisespedro · 09-02-2014, 10:02 PM

Quote:

Originally Posted by ReaperX7

Get another machine and attack the hell out of it.

I don't even know how to attack a machine

Yes, I am a noob

ReaperX7 · 09-02-2014, 10:45 PM

Not sure how old this info is but here's a site you can check for tools to attack your system with (some scan internally):

http://www.yolinux.com/TUTORIALS/Lin...rityTools.html

moisespedro · 09-03-2014, 12:16 AM

Thanks, I am gonna give it a try. To be honest, the machine don't have anything on it, if someone hacked it I wouldn't lose much. I just want to get knowledge on Linux security (and OS security in general)

Mark Pettit · 09-03-2014, 12:44 AM

Actually, this is a VERY good question. It's one that I've thought about, but never managed to properly answer. A few years back I setup an internet-facing FTP server server for a company I contract at, and we employed a so-called 'white-hat' hacker to test it out. Took 2 days and he declared it safe (enough). Even so, it would be nice to know of a fairly simple tool which could answer such a question, to some reasonable level. Could 'snort' be such a tool - altho' I suspect it fails on the 'simple' specification ?

moisespedro · 09-03-2014, 01:21 AM

Quote:

Originally Posted by Mark Pettit

Actually, this is a VERY good question. It's one that I've thought about, but never managed to properly answer. A few years back I setup an internet-facing FTP server server for a company I contract at, and we employed a so-called 'white-hat' hacker to test it out. Took 2 days and he declared it safe (enough). Even so, it would be nice to know of a fairly simple tool which could answer such a question, to some reasonable level. Could 'snort' be such a tool - altho' I suspect it fails on the 'simple' specification ?

Something like a script that would try to hack it using all sort of exploits possible. I guess that is something that can be done?
Plus some common stuff like DDoS (but that should be pretty easy to do)

unSpawn · 09-03-2014, 01:30 AM

Quote:

Originally Posted by moisespedro

What else can I do?

- Be clear about the purpose(s) of the machine(s), location(s) and risks (so you have a good picture of what you secure against / for).
- Make a list of what you found and changed ("I found a few things and then I edited a few files" just doesn't cut it and you're bound to forget some).
- Remind yourself security not a one-off but a continuous process of auditing and adjusting. (Also see commonly used CERT, Cisecurity, OWASP and other check lists.)

Quote:

Originally Posted by moisespedro

And how can I test it?

Not strictly security but more a mix of CIA and security in no particular order:
- Have somebody alter 5 files at random. Now find out which files were altered (without using shell or application history, mind you ;-p).
- Move your /home. Restore from backup and compare. (You do make backups, right? ;-p) What data is missing still?
- Or, if you use a laptop: zero out the first 2 mb of your main hard disk or kill power hard (remove power, then battery) then follow the previous point.
- Run a local test with GNU/Tiger (or Lynis) and review for "must haves",
- Run a remote test from the same network segment with OpenVAS followed by a remote nmap scan,
- Check swap for legible data,
- Esp. if running from laptop: can anyone alter BIOS?
- Esp. if running from laptop: boot a Live CD, USB stick, PCMCIA card, firewire or whatever else on offer. Which data is still readable?
- Esp. if running from laptop: place in different environment. Does it broadcast data you think it shouldn't?
- Create a runaway process and try to log in from remote,
- Try to log in from remote over SSH without using pubkey auth,
- Log in and become root. Trace back exactly when this happened and what was changed using solely whatever /var/log offers,
- Verify where an installed package originates from,
- Verify installed package contents,
- Determine how you'll be alerted of package updates,
- Load a kernel module you would never use,
- if your SOHO router allows this run a packet trace and inspect what traffic isn't encrypted and determine if it should be.

And that's just a few random things.

zhjim · 09-03-2014, 03:51 AM

Maybe checkout some of the pentesting distros out there and attack your server your self: http://www.concise-courses.com/secur...p-ten-distros/

Also recheck your iptables settings. Specially the order/place of your DROP policy settings.

tronayne · 09-03-2014, 08:33 AM

A default installation of Slackware is, by default, pretty much secure as is: if you watched the installation, when it gets down close the end, keys are generated specific to your machine and installation (ssh keys for example).

Insecurities, generally, are created by humans. Just the simple stuff: dictionary passwords, guessable passwords, revealing passwords to others, writing them down on a Postit and leaving it somewhere that it can be easily found, leaving the machine logged in, other silly stuff that people do.

My experience with Internet-facing machines has been that attacks come to port 22, the SSH port, and are, typically, attempts to log in to root, wheel, and other administrative accounts or, if there is a web page, through Apache.

You do not, under any circumstances, put passwords on any administrative account with the sole exception of root. None of them will ever be used for anything and they are locked out by default. You put a "good" password on root (lower and upper case letters, numbers, punctuation, minimum eight characters, more is better, not your dog's name, not your kids names, not your birth date, nothing guessable.

You do not create an open guest account, period.

You do not, under any circumstances, modify the permissions of /etc/passwd or /etc/shadow (and you never, ever edit /etc/shadow).

Understand that if your server is facing the Internet, you're going to get hit. A lot. The hits are going to be log in attempts and they are recorded in /var/log/secure. You cannot, as an ordinary user, read that file (neither can anybody else), you must be root to look at the "important" log files in /var/log, and you don't mess with that for "convenience").

You may want to install something like DenyHosts, a daemon that monitors /var/log/secure for failed log in attempts and records the IP address of the intruder in /etc/hosts.deny. The next time that IP address attempts to connect it is simply denied immediately (before log in) and that's that. DenyHosts can share your experience with other users around the world -- and their experiences with you -- and update your /etc/host.deny file with the IP addresses of the bad guys, effectively locking out any attempts. I've used it for years, never have had a break in and I don't have to fiddle with it. See http://denyhosts.sourceforge.net/.

If you're going to a LAMP model, be sure that you do not have an open data base connection. After you initialize MariaDB/MySQL, be sure to run /usr/bin/mysql_secure_installation to lock it down. Be sure to use passwords on every MariaDB/MySQL data base -- and make sure that each user has their own password for data base access. Do the same for PostgreSQL or any other data base management system you may install (such as Oracle). Read and heed the security sections of the software manual pages.

If you have a user who goes away, immediately change every password that user had.

If your installation is new, download and upgrade every patch, including the kernel patches for 64-bit (there aren't any kernel patches for 32-bit). The so-called Heartbleed problem in OpenSSL has been dealt with, but you need to apply the patches.

Security is mostly good sense and good practice -- don't take shortcuts and circumvent permissions and the like for the sake of convenience (that will come back and bite you in the hiney),

Hope this helps some.

hitest · 09-03-2014, 08:50 AM

Have a hardware and a software firewall, keep your box fully patched. Install root kit hunter from slackbuilds.org. Scan your box to see if you have a root kit installed.

rkhunter

enine · 09-03-2014, 09:26 AM

Quote:

Originally Posted by moisespedro

Thanks, I am gonna give it a try. To be honest, the machine don't have anything on it, if someone hacked it I wouldn't lose much. I just want to get knowledge on Linux security (and OS security in general)

Typically no one is after whats on your machine, they want the machine its self. They can install a spam relay, bot net client, etc.

First determine your attack vectors, i.e. how would someone attack your system. are you exposing it to the outside works, i.e. have you told your router to allow any incoming traffic because your running a web server or game hosting. If not they the attacks are going to be at a higher level, probably browser or e-mail based.

moisespedro · 09-03-2014, 09:39 AM

@UnSpawn I should have said "I edited these files" instead of what I said, they are the only files I've edited. Other than that and keeping the box patched I disabled any kind of remote connection to it since I don't use it. And of all the items in your list with my current Linux knowledge I wouldn't be able to do most of it

But I will catch up. What I want to achieve is a way to keep my data secure and prevent people from getting control over my box (this is the most aggravating one since my data is not very interesting lol), stealing data, spying it, etc. ("normal" hackers, I am not trying to go against NSA or something, I am not going that way, it is too beyond me).

@zhjim What do you mean by the order?

@tronayne Although it might be considered relative secure (if you compare to some other Linux distro or Windows) I don't believe Slackware is that secure by default. In the end, it is just a vanilla Linux distro put together by Patrick (not picking on him or anything).

"You do not, under any circumstances, put passwords on any administrative account with the sole exception of root."

Why would I let the account password-less?

DenyHosts looks great, thanks for the tip

Oh and by the way guys I am not running a server, it is a desktop machine.

brianL · 09-03-2014, 09:54 AM

Try Alien Bob's Slackware version of the Easy Firewall Generator.

http://www.slackware.com/~alien/efg/

enine · 09-03-2014, 10:44 AM

Quote:

Originally Posted by moisespedro

@UnSpawn I should have said "I edited these files" instead of what I said, they are the only files I've edited. Other than that and keeping the box patched I disabled any kind of remote connection to it since I don't use it. And of all the items in your list with my current Linux knowledge I wouldn't be able to do most of it

But I will catch up. What I want to achieve is a way to keep my data secure and prevent people from getting control over my box (this is the most aggravating one since my data is not very interesting lol), stealing data, spying it, etc. ("normal" hackers, I am not trying to go against NSA or something, I am not going that way, it is too beyond me).

@zhjim What do you mean by the order?

@tronayne Although it might be considered relative secure (if you compare to some other Linux distro or Windows) I don't believe Slackware is that secure by default. In the end, it is just a vanilla Linux distro put together by Patrick (not picking on him or anything).

"You do not, under any circumstances, put passwords on any administrative account with the sole exception of root."

Why would I let the account password-less?

DenyHosts looks great, thanks for the tip

Oh and by the way guys I am not running a server, it is a desktop machine.

Most "normal hackers" don't care about your data, they just need boxes to control. They might delete it if they need the disk space but most will leave the data so your not alerted to their intrusion.

So if your just using the system as a desktop and not a server then one basic security principle is to not run any 'server' services (apache, samba, mysql/mariadb). Slackware is generally more secure than average because these various servers are not enabled by default.

So you want to look at attack vectors from a desktop user perspective then. usually these are done via scripts in e-mail or browsers. Either by exploiting vulnerabilities in those or other desktop programs or javascript or such in ads. So maintain your (desktop) software such as keeping up to date the browsers programs you use. Use add-ons such as ad block, don't install flash, etc.