IDS don't take away the fact that you can learn what you are doing they just look at each packet and see if there is anything suspect about it.

Please read below:

===============================================

(1) What makes a good password?

A good password will consist of numbers, letters (upper and lower case), and shift characters. Additionally, it will be of a good length, at LEAST eight characters. Further, a good password will not contain any easily-guessable information, like names (human or pet), anniversaries, birthdays, or the like. While a password should be difficult to guess, it should not require that the user write it down. To increase ease in recall of passwords, may use mnemonics ("3g8Ah!wRT?" becomes "Three goats ate all hay! Where are they?") or practice their "leet-speak" ("barnyard forever" becomes "64Rn|\|y4RD |=0r3ver").

2) Lockdown 101 or HOW-TO be secure

This is, of course, not an all-inclusive list, but rather a simple guide to creating a fairly secure system.

A) ifconfig $INTERFACE down

Turn off the your connection to the outside. You just installed your distribution, and there are criminals out there (who, by the way, are most likely *not* hackers) that would just love to root your juicy little box.

B) Kill ALL services to the outside world. This is one of the most crucial steps. By default, many distributions enable the oft-exploited fingerd, RPC, and wu_ftp. Turn them all off. Turning some services off (like sshd) will be as easy as killall -9 sshd (or, for the Sys V minded, /etc/rc.d/init.d/sshd stop). However, the services implemented by inetd (or xinetd) will require an editing of configuration files and the 'killall -HUP xinetd' call.

C) When there are NO services running, you can ifconfig $interface up. However, it is still the best practice to retrieve the necessary files from another computer and install them from a medium (such as cdrom) rather than download them off the internet.

Short story: if you don't have to bring your network device up, don't.

D) Compile. Install. Tweak. Repeat. Install the latest versions of any services you will use (sshd and apache come to mind).

E) Edit init files. Using rename (From S* to K*), deleting symlinks, commenting out of BSD startup scripts, or chkconfig, disable the services that you don't want/need from starting. Note that you must disable the 'portmap' to keep RPC from loading.

F) Obtain and install nmap. Run it and repeat E until you have no unnecessary ports open.

G) Install an IDS. Snort is a very good program that is powerful, robust, and easy to tweak for personal needs. It comes highly recommended.

H) Reboot.

Tools such as Bastille Linux can tweak config files and scripts for the security-minded. A great tool to audit your netowork is Nessus. Nessus is a daemon that waits on a machine until the Nessus Client tells it to scan a machine. For security's sake, nessusd should only allow connections from localhost, and be restricted to scanning the local network. Nessus can perform a very nice security audit, checking for information-leaking banners, vulnerable services, and even vulnerable cgi scripts.

Finally, make sure to watch your logs. Using the command tail -f $LOGFILE from a desktop console that has had the border removed and made transparent, logs can be made to scroll across your desktop, not taking up much room at all. Using tail -f, one can easily and unobtrusively moniter Snort's alert log, /var/log/messages, /var/log/secure, and the httpd access and error logs.

Make sure to keep your daemons and other programs (especially those that suid!) updated to avoid being rooted.

(3) Lockdown 201 or HOW-TO be very secure

A) Security through obscurity. Install portsentry. Have it open a few ports that don't belong on your OS. This will foil port-based OS guesses (such as that used by nmap). Recompile daemons to report an incorrect version. Two famous OS fingerprinting culprits are sshd and apache. Either compile the sources, replacing the offending text (sed and grep are your friends) or open up your favorite hex editor and hack away at the binary (make sure to back it up first!). There are a few methods to porting false banners: the obvious way and the sly way. The obvious way involves replacing banner text with obviously false text (such as having a Unix/Apache server report Goat/Hayburner). The second way is a bit craftier, and a bit harder to pinpoint. This involves a complete mask of the operating system, for example configuring an Apache/Unix daemon to report IIS/Microsoft. This method, when coupled with opening Windows ports with portsentry, is quite effective in outwitting would-be vandals.

While security through obscurity is often the subject of ridicule, keep in mind that it, like any security system, is only part of the greater blanket of security.

It should be noted that the wonderful tool from Ofir Arkin, xprobe, will still be able to OS fingerprint, since it relies on differences in ICMP and UDP responses.

A wily sysadmin would disable ICMP messages and unsolicited UDP responses with their stateful firewall.

Security through obscurity is not, mind you, confined to the network.

Programs such as ps (especially when used with the switches 'aux') can reveal valuable information about running processes, and may include IP addresses that can give hints on network topology. Unless a user needs access to such programs, they should be disabled. Other information-giving programs include dmesg (which prints kernel messages), lsof (lists open files), netstat (lists network connections) and ifconfig (lists network interface information). Further, world-readable config files can provide information to a potential attacker. Some files, which should be owned by root and not world-readable, contain plaintext password files, as any reader would necessarily need root privelages anyway. Sometimes, however, mistakes happen and such a juicy file will be readable by everyone, Random J. User included.

B) Proper network setup

A good network setup will not allow access to or from the LAN, save through highly customized systems. A poor network setup would look like this:

{internet}---[hub]
|--- LAN box 1
|--- LAN box 2
|--- ...

With this setup, ALL boxes are open and potentially vulnerable to the outside internet. A different, though not recommended, setup is the following:

In this setup, the network is isolated on the subnet, but is still vulnerable.

Since the server is on the same subnet, an attacker would have access to the entire network if they rooted it [the server]. A better setup would be to isolate the servers on their own subnet.

{internet}---[router]
------|-----
| |
| |
{Servers} {LAN}

This is a good setup, with only one major drawback: it allows possibly malicious traffic to talk to the router. With a single exploit (remote kernel, say) an attacker could have access to the LAN. However, an attack against the servers would leave the LAN relatively uneffected, since the two are separated. The best configuration will include a stateful firewall, be it a purchased solution or a simple *nix box running iptables:

{internet}---[firewall]-+-[router]
|D |
|M |
|Z |
{Servers} {LAN}

As you can see, this network uses a DMZ to completely isolate servers from the LAN. This way, even if a server is exploited, the LAN would remain secure. Further, the firewall itself could be rooted, and the LAN would still have a fair degree of security. Note that it is also smart to turn the router above into a firewall by simply installing and running iptables.

A final step to building a secure network is the installation of an IDS(Intrusion Detection System). One of the most common IDS, Snort, is actually a Network IDS (NIDS).

Basically, it looks at each and every packet that crosses its NIC and makes a note if the traffic is suspicious. A NIDS is usually run from a box within the DMZ, as opposed to the firewall or router itself, to minimize the chances of it being compromised.

C) Chroot

Chroot is a method of "locking down" a program, isolating it. Basically, it makes the chrooted program believe that a specified directory is /. Of course, it can take some work setting up a chroot jail, as all libraries and conf files will need to be copied. However, if a chrooted daemon is rooted, it will still be locked in it's chroot jail, unable to wreak havoc. This method has transformed countless security disasters into a short cleanup job. An important part of chrooting is to make the filesystem appear to be non-chrooted. This way, the would-be vandal would have no way of knowinng that he was, in fact, absolutely no threat to the rest of the system.

Many admins, however, use too much (or, more accurately, poorly-implemented) security. For example, some systems will permanently block an IP address after three failed loging attempts. By spoofing their IP address, an attacker could arbitrarily lock a user (or subnet, or router)out of a system.

C) Priveledge seperation

Often used in conjuntion with chroot, privelage separation is the act of separating the core of a deamon from its children. While the daemon, hat needs to be root, sits at uid 0, its children (who actually serve the data) can be made to run at a lower (user-equivalent) privelage level. This way, if an attack on the daemon is successful the attacker only gains the separated privelage (user) rather than full root access. This becomes very powerful when coupled with chroot, as it is impossible for a non-root user to break from a chroot jail.

(4) Lockdown 202 or Physical security

An oft-overlooked aspect of *nix security is physical security. Aside from post-it notes containing passwords, many don't know how vulnerable most systems are when accessed through the terminal. Of course, one can never realistically stop a user from pulling the plug.

Although it's fairly obscure, physical security is quite easy to implement on it's base levels. Simply putting a password file on the boot loader and booting into the OS immediately provide a very good level of security.

Further, disabling floppy and cd booting and adding a BIOS password can make a quite secure box. Of course, if the box is easily accessible, the harddrive can still be stolen. This is where harddrive encryption comes in. Using the PPDD driver (http://linux01.gwdg.de/~alatham/ppdd.html), one can transparently encrypt an entire partition or harddisk. This allows seamless reading of data, but prevents a thief from gaining access to sensitive data. One could go a step further and install various locks and light-detecting sensors inside the case itself, but such measures are often quite costly. Finally, one should remember not to leave terminals unattended. Programs such as xlock (for X) and vlock (for terminals) can keep unauthorized users from accessing the computer directly. Note that a quick ctrl+alt+backspace will kill the X server, dropping the user into a terminal. However, this can be disabled.

It should be noted that security is not a one-step process. A great firewall, up-to-date binaries and the best available physical security are but parts of the security process. Just blocking connections won't be great security; neither will chrooting everything or running a single IDS/NIDS. Security is not an either/or situation; it is thoroughly and-based.

Some Added Info:

Firewalls

Firewalls come in two basic flavors: hardware and software. A hardware firewall is a dedicated machine (be it a small, commercially available box or a *nix box running iptables or ipchains) placed between a LAN and the outside network. A software firewall, however, is not a true firewall at all. It is simply a piece of software that monitors port usage and blocks or denies access. As such, it is no more a true firewall than MS Outlook.

Hardware firewalls can be broken down into three main categories:

Packet filter

(stateless), packet inspection (stateful), and proxies.

Packet filtering (IPCHAINS)

Packet filtering firewalls are simple and rule-based. The administrator simply tells the firewall which packets to relay and which to drop. A breeze to set up, packet filtering firewalls are the most common (and cheapest) firewalls available. Unfortunately, rulesets are based on addresses and ports only, and data payload is not inspected.

The oft-misnamed Windows port-monitoring applications usually use packet filtering, but are not firewalls due to the fact that they reside on the connecting machine.

An analogy for stateless firewalls would be a post office worker examining envelopes on a conveyor, tossing out those that have certain source or destination addresses.

Packet inspection (IPTABLES)

Packet inspection firewalls take packet filtering to the next level. They look at each and every packet, determining the state of the connection. For example, ACK floods have little effect on stateful firewalls because they immediately drop ACKs that have no SYN. Further, stateful firewalls examine the data of each packet, making the logs of stateful firewalls much more informative.

An analogy would be the factory worker watching as items whiz by on a conveyor, kicking out those that are unfit.

Proxy

The proxy is hardly a firewall at all. It is simply a machine that intercepts all data between two computers and decides whether or not to allow the connection. Where stateful and stateless firewalls act on a packet-by-packet basis, proxies act on a connection-by-connection basis, simply refusing to relay connections as appropriate.

Since proxies are basically a server piping into a client, they clog fairly easily (although are easy to set up and maintain). Further, UDP is often not supported well (or at all) by proxies.

To better understand proxies, one can imagine a conveyor belt bringing widgets to a man who inspects them and places them on a separate conveyor to be carried away.

Just like to mention the very first thing you should do to secure linux is shutdown the services you don't know, in mdk I believe you can use mcc to disable what you don't want. Personally I use slackware. You might want to read up on iptables and build a decent firewall as well.

Can someone suggest what I should be looking for to secure my mandrake machine to a reasonable standard:
<snip!>
Im more concerned with where I should be looking for possibly security breaches and general administration.
<snip!>
Also where do I put IP restrictions on incoming SSH. I know this can be done through a firewall but im sure it can be done via configuration files or similar to /etc/hosts.allow

Securing a Linux box can be fairly complicated; in lieu of a course or tutorial in this regard I would highly recommend the book "HackNotes Linux and Unix Security Portable Reference". This book touches on a lot of security concerns and how to address them.

Now IRT your query about how to place IP restrictions on incoming SSH - off the top of my head (and I'm sure someone will correct me if I'm wrong), I believe you should be able to do this by removing the "sshd: ALL" entry from the /etc/hosts.allow file if it is there and adding the appropriate information, e.g. "sshd: x.x.x.x", where x.x.x.x is the IP address of the host you wish to allow.

If you're really security-conscious, then you might want to have a look at LIDS, the Linux Intrusion Detection System. I came across it today. Here's some basic information about it:

Code:

"The Linux Intrusion Detection System (LIDS) is a patch which enhances the kernel's security by implementing a reference monitor and Mandatory Access Control (MAC). When it is in effect, chosen file access, all system/network administration operations, any capability use, raw device, memory, and I/O access can be made impossible even for root. You can define which programs can access specific files. It uses and extends the system capabilities bounding set to control the whole system and adds some network and filesystem security features to the kernel to enhance the security. You can finely tune the security protections online, hide sensitive processes, receive security alerts through the network, and more."

I believe you should be able to do this by removing the "sshd: ALL" entry from the /etc/hosts.allow file if it is there and adding the appropriate information, e.g. "sshd: x.x.x.x", where x.x.x.x is the IP address of the host you wish to allow.

I usually check my servers a couple of times per day, and my carrier changes (I am using the SSH client from http://mobish.com on my mobile) the IP adress from time to time. I mean not just a /24 mask but like a 16-mask... Can I put that C-mask in hosts.allow? What happens if I go abroad? Will I get an entirely new IP?? Or do I get routed (NAT/ed) so I get the same IP-range?

I'm not familiar with vanish or other log cleaners, but consider this: suppose the cracker didn't erase an entire day's worth of logs, but only the entries relevant to his intrusion. You might not miss a few deleted lines from your logs. One potential way around this is to have your syslogger write to a log file and *also* e-mail directly to a logging server (on another subnet with only console access). It's bandwidth intensive, but if you are really paranoid...

Still, by all means *DO* check your log files daily. Unless your system is really insecure or the cracker is either exceptionally good or exceptionally lucky,there will probably be a period of hack attempt, failure, repeat... before he/she gets in. These failed attempts should show in your log files (you are running iptables, right?) That gives you a chance to detect what's happening and take action to counter the attacks.

Case in point: I recently detected a number of brute-force ssh attempts against one of my Slack boxes. Because I found the evidence in the logs, I was able to set iptables to deny all incoming ssh from other than a handful of IP addresses that I know I use regularly. Without scanning the logs, I never would have found the attempts...until I was hosting an 0wn3d server

You should check almost all (if not all) of your log files regularly, but especially these: messages, syslog, apache's error_log, apache's access_log, sulog. Depending upon what services you are running and how your logging is configured, there might be other files that are just as important, too.

One other note: make sure you are using some kind of integrity checking software! At work we use Tripwire, and it is a really good, full featured program--I highly recommend it. You can download the open source linux version at http://www.tripwire.org/downloads/index.php

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forum

Featured Links*

Looking for more Windows Networking info?

Sign up to the WindowsNetworking.com Monthly Newsletter, written by Enterprise Security MVP Deb Shinder, containing news, the hottest tips, Networking links of the month and much more. Subscribe today and don't miss a thing!View a sample newsletter.