Slashdot Mirror

That's exactly what tools like nessus are for.

1. Sure it could be a target. Obscurity is what keeps it from being a target.

[ horrified ] If it's a web site -- on the Internet or (to a lesser degree an intranet) -- there's no way that obscurity is any bit of protection. Secrets, such as passwords, can be helpful though obscurity itself is wishing nothing goes wrong not insurance against problems.

At a bare minimum, run Nessus or one of the other top-notch scanners from both the intranet and Internet and see what it finds; www.nessus.org

Check out Nessus. Nuff said.

It's the shit.

My company recently purchased an SSL cert from verisign and recently received an email from http://www.qualys.com (in conj. with our purchase) to perform a web based security scan of internet facing machines, such as web servers. The results and demo reports appeared a bit better than our usual Nesus vulneravility scan, however, Qualsys is not free. Try these tools out, for web servers, they have done quite well for my end.

I was thinking more along the lines of via remote access w/ a portscanner and whatnot. I guess I'm just used to seeing Nessus run and taking friggin forever to scan a host over my cable modem (no... I don't break into the systems, I just scan them and sell the results ;).

You should be running your server through the ringer every time you change something or new holes are found, every 2 weeks is a decent number.

This is just one of many steps to consider ;-)

It's a good idea to have a box local that is configured exactly like your live one for this, the tests can eat a lot of bandwidth and make a mess out of your logs. Of course if you are testing the box as a whole there is no substitute for testing the live box.

Not flaming here, but you may be comparing apples to oranges. You are complaining that /. reports every active Microsoft worm while it is out there, actively infecting multiple computers, but does not report every vulnerability affecting Linux machines. Slashdot doesn't tend to report new vulnerabilities affecting Windows, unless it comes as something spectacular, such as 6 high risk holes announced at once.

If you're reading security sites, then you're "doing it right", and that's what you need to focus on. You. I run Jay's IPTables Firewall. I occasionally check LinuxSecurity, but instead I usually visit their Packetstorm mirror and try out some of the latest exploits against my various machines just to see if I'm vulnerable. I also check CERT weekly, NIPC's Cybernotes biweekly, D-Shield and Incidents.org biweekly, and update Nessus and check my firewall biweekly. I don't have any open ports, so I rarely check for updated Snort rules. I do check my MRTG reports about once a day to see if an inordinately high amount of traffic is flowing through my firewall. There's so much that everyone should do all the time, that there's hardly enough time to complain about how much focus a web site places on reporting one OS'es actively exploited holes vs another OS'es potential vulnerabilities. In the time to read this, you could have been reviewing the Top 75 security tools and seeing where they fit in your environment, even if your environment is your house.

I introduced one of them to Nessus, not because it was a Unix program, but because it is a damn good (the best?) security auditing tool available.

His reaction to a security audit showing our primary app server had multiple potential holes just in the programs that support the app? "Well, we don't use that software much, we only use it to get into the program. All the work is being done using the other programs."

For the record, the system was an HPUX server running an older version of Apache 1.x. The app gateway is through Apache to Weblogic, though the main application program runs on the HP box, not elsewhere.

This is not simply an aversion to Unix or command lines. The lax security extends into all the Windows systems as well. For example; all drives readable/writable on the network by any user.

It's a lack of professionalism, not intellegence -- the guy is plenty smart. Adding a little fear to the mix (we print checks dammit!) doesn't raise his concern too much. I've not raised the possibility that he, personally, might be held to blaim for security issues and I doubt that it would work with him.

My only hope is that slowly, without forcing him, he will see that there is something behind my comments and tips. Maybe a light will go on, and he will decide to take a look.

For admins that'd like a way to check for rootkits I'd recommend looking at chkrootkit. While it's not a 100% reliable method (and there may be restrictions: for instance, compiling it on a compromised remote box from uploaded source isn't secure*), it's good as a quick 'n' dirty check. Worth a look at the links at the bottom of the above site too for more info on rootkits, there're some excellent articles listed.

Also of interest would be Nessus - a vulnerability scanner which uses NMAP and other tools that may identify potential points of ingress on a suspect box.

*In this case you'd be best off running pre-compiled trusted binaries off a read-only source such as a CD, or mounting the suspect drive on another machine - though this depends on whether you can get physical access to the box to do either, or if you have truly awesome datacenter techs that can help!

Being a system admin for a college, having this updated tool out for the world really doesn't bother me. Honestly, I'd rather have it in my hands to know what's running on my server, than to be ignorant and hope everything is ok. It also is a good tool to for testing things like if your firewall is configured properly. After all... all the script k1dd13z are going to have these programs too, so it's best to know what you've got exposed to the internet. Besides, in a lot of the programs out there, you can turn off the server identification so that when you connect, you don't know what the host is running for programs. Apache does this (I know because I turned it off myself). And you could probably even hack the source code to them if you really wanted. My FTP server at home just says "Go away!" when you connect so you don't even even see which program is running, much less what version.

Now for a *real* tool for making sure your sytems are up to date, try Nessus. It not only scans your system for what programs are running (using nmap no less), but it finds out what versions they are if they can, and it tries to run common exploits on them too! I use it perodically just to make sure that all the bases are covered so that none of the holes for common exploits on the internet are left open.

If you feel like running some other scans, get a friend to give you a good probing with nmap or nessus(which performs an nmap scan as well).

I was experimenting with nessus several months ago. I unchecked the "safe checks only" option and ran it against a series of internal Windows systems and crashed RPC. I thought "wow, this could be really dangerous if nessus'd a range of public IPs."

I honestly don't see the purpose in this site or the tool being developed to use it. I use Nessus on a daily basis and it seems to work just fine for this task.

I mean what more could you ask for... a client/server based vuln. scanner that will give you reports in xml, csv, txt, html, doc... Since the site and database has been created, maybe you should just write a program that exports the exploit tests as Nessus nasl scripts so we can do the tests and Snort rules so we can detect testing.

All very good for the beginner, for sure.

Don't forget tripwire, nmap and Nessus. I find Nessus particularly interesting, especially if you have more than a modicom of network experience under your belt.

I think security is the one area of the IT industry that's growing. Thanks, Microsoft!

Soko

• set up a network of very cheap boxes with old software you know to be vulnerable, and try using exploits against them.
• Try hardening and patching those boxes so the exploits don't work anymore. (You'll frequently be patching/protecting obsolete boxes in the real world, so this is actually realistic.)
• Try adding tripwire and snort to stop/detect attacks. Configure snort with database logging, with syslog/swatch, etc. Clients will want it done in a variety of ways, so it is good to be able to do it in different ways.
• Familiarize yourself with as many of the tools in Fyodor's list as possible. Using them will be the bread an butter of your work. That includes scanners like nessus.
• Read an ultra paranoid book that will give you an overall view of the field (e.g. John M. Caroll's "Computer Security, Third Edition").
• Practice security. As you install and register software, watch what is happening to the box.
• Pick an area of security that you want to specialize in...there are too many bugs and holes each week to know all of them...just the PHP code injection stuff will keep you swamped.
• Don't be afraid to ask more advanced people security questions, but do your homework first, and make sure that they know you have. They will take your more seriously if you say "I've already read the FAQ and the man page, but I'm not clear on...." than if you say, "Dude, how do I do...". This can make your learning experience far less painful

• set up a network of very cheap boxes with old software you know to be vulnerable, and try using exploits against them.
• Try hardening and patching those boxes so the exploits don't work anymore. (You'll frequently be patching/protecting obsolete boxes in the real world, so this is actually realistic.)
• Try adding tripwire and snort to stop/detect attacks. Configure snort with database logging, with syslog/swatch, etc. Clients will want it done in a variety of ways, so it is good to be able to do it in different ways.
• Familiarize yourself with as many of the tools in Fyodor's list as possible. Using them will be the bread an butter of your work. That includes scanners like nessus.
• Read an ultra paranoid book that will give you an overall view of the field (e.g. John M. Caroll's "Computer Security, Third Edition").
• Practice security. As you install and register software, watch what is happening to the box.
• Pick an area of security that you want to specialize in...there are too many bugs and holes each week to know all of them...just the PHP code injection stuff will keep you swamped.
• Don't be afraid to ask more advanced people security questions, but do your homework first, and make sure that they know you have. They will take your more seriously if you say "I've already read the FAQ and the man page, but I'm not clear on...." than if you say, "Dude, how do I do...". This can make your learning experience far less painful

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

The problem with the old TAMU version is that it was getting as out of date as SATAN was. It still is a good framework and has lots of room for improvement.

Also, it's the only tool of that time that is completely free. SATAN, COPS and ISS are either outdated or no longer free and new replacements have appeared for some of them (Nessus).

Why do people pay good money to ISS for their Internet Scanner tool? It seems that this tool is very popular, but don't most people involved at these levels of security work know about the Nessus project? I personally find the ability to customize the system to the Nth degree and build my own triggers blows away most commercial systems. I've used ISS's scanner, Cybercop, and a few others. Some of the reporting tools are good out of the box, but I always find myself returning to Nessus.

Why do people pay good money to ISS for their Internet Scanner tool? It seems that this tool is very popular, but don't most people involved at these levels of security work know about the Nessus project? I personally find the ability to customize the system to the Nth degree and build my own triggers blows away most commercial systems. I've used ISS's scanner, Cybercop, and a few others. Some of the reporting tools are good out of the box, but I always find myself returning to Nessus.

Better still would be a reverse honeypot - an app that catches outgoing requests, tests them against a database of known offending addresses and/or ports, and (optionally) tricks the offending application into thinking it has successfully phoned home.

For something like this you need not a firewall but an IDS, an Intrusion Detection System, with correct signatures of traffic you want to detect. I would suggest Snort (there's an MS Windows port), a great free software IDS released under the GPL 2+. It won't change the traffic, but it will detect it (you have to use signatures matching traffic patterns of known spyware or even something very general, but disable Web attacks rules and other which you don't need to look for).

To fool application you would need not only some firewall/router rules to redirect the traffic somewhere else, like to your own machine, but you would also need this machine to speak the right protocol, which may be much harder than useful, or even impossible without altering the spyware binaries. I would personally rather not use spyware at all instead of mounting such attacks against their communication. If I wanted to write spyware, I'd use valid HTTP on port 80 to call home, which wouldn't differ from normal WWW traffic, or ICMP ECHO_REQUEST/ECHO_RESPONSE, etc. The problem is that if you have any network connection at all, the covert channels will always be possible.

But if you really want to try intercepting and altering the spyware traffic, which may be fun after all, you may want to take a look at such tools as ngrep, tcpdump, netsed, netcat, etc. If you want to look for open ports on your machine, use nmap. Use Nessus if you want to test for many different vulnerabilities.

One installs and runs nessus, updates the plugins and scans one's servers weekly.

One also tends to sleep well at night afterwards.

If you haven't yet, you should definitely check out nessus.

It'll scan your machiens for known vulnerabilities and give you pointers on how to go about taking care of any that it finds. It's also got built-in updating to pull in the latest exploits.

The clients are even getting pretty spiffy these days, and the project has matured very rapidly.

he only way we have been able to verify that a Win2K box have been taken care of is when we do it ourselves.

select "vulnerable to Nimda" and "weak NT administrator password" from the nessus template list. scan your whole network. ban any IP address which fails at your firewall. tell people what they have to do to be compliant at your local FAQ.

to say that manual verification is the only way is to deny years of progress by the security community. don't insult us.

-s.

look. get nessus. select only the filter that checks for weak or nonexistent windows administrator passwords. scan your network. take the list of IP addresses that were vulnerable and ban them at your firewall. you can perform this single-filter nessus scan on a class B network in under 12 hours.

PROBLEM SOLVED

good god man, work for a living!

-s.

SMBdie attack NetBIOS over TCP [NetBT], not NetBIOS over IPX [NBX].

But, I guess the people from CORE have provided enough information in their advisory. Check this out: http://www.corest.com/common/showdoc.php?idx=262&i dxseccion=10

Also, there is a sample NASL script (Nessus) at this location: http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout ~/nessus-plugins/scripts/smb_null_params_dos.nasl

Last, [EMAIL ADDRESS WITHHELD] has wrote a Linux version of SMBdie. Open source. Please contact him for a copy.

I cary a 3.5" mini cd full of diagnostics programs for winblows, because god knows you need them when dealing with windows and windows users. Here is a list of what's on the disc. First of all it's a basic MS-DOS bootable disk with all the functionality of a regular MS-DOS boot CD (fdisk, format, edit, etc) and a few utilities such as
Fresh Diagnose
VNC server and viewer
NessusWX
Fresh Diagnose is an excellent benchmark/testing utility.
VNC is for accessing remote desktops (Great for lazy people such as myself)
NessusWX is a windows interface for Nessus security scanner. A must for checking default installations of any OS.
All the extra utilites are freeware. MS-DOS is of course copyrighted.

hth

If you're a Network or System Administrator, you should KNOW you're not safe.

You SHOULD be testing your systems constantly.
You SHOULD be installing new patches.
You SHOULD be subscribed to CERT style mailings.

You SHOULD NOT think you are safe because you're small. Security though obscurity is the biggest false sense if security I've seen. Former employees, especially the guy you replaced are a pretty large threat.

For beginners out there, here are some places to start... (Some of these are OLD links, but still contain some useful information and yes, they're Linux oriented.):
Beginners Guide to Armoring Linux
Linux Security Guide
Nessus
Traditional HOWTO

Using the free Nessus tool can be very, very valuable towards securing your external IP-addressable presence if you don't have thousands of dollars to blow on security.

Note this will only identify some potential holes in your firewall, and won't secure you against other vectors like email worms, malicious employees, nuclear weapons, hair gel, etc.

No NAT? So am I to understand that you are going live to the net with real IPs or is your debian firewall taking care of NAT for you? Either way, the situation you described is a network sniffer's wet dream. At this point I would assume that at least one if not more of the boxes on this net are compromised and actively capturing traffic. I suggest you learn a bit of Nessus trickery and thouroughly assess all of your systems. Steve Gibson is a joke, sorry to disappoint you but his service is flawed to the core. Try host based firewalls for *all* of your systems, mabe included a bit of Snort in there as well. But seriously, try Nessus from home one night on your network, the admin apparently will not notice and you will be horrified at the results more than likely.

The first step (really!) is to get a security policy in place. This really doesn't have to be anything special-- but it does need the buy-in of ALL groups affected (sysadmins, developers, marketing, sales, executives, etc.) That's really the only hard part.

Probably the quickest way to get started is to head to the SANS security policy project and adapt their sample policies to your company. This is one of those rare cases where it's more important to get something in than it is to get it right the first time. Policies can be changed fairly easily-- but you don't want to go to all the trouble to implement a secure environment only to have someone on the inside fighting you every step of the way.

Now the fun part-- actually securing your systems. Here are some pointers on places to start:

1) Review the SANS "top 10" security vulnerabilities and make sure they're covered.

2) Review Lance Spitz's excellent collection of host security information and make sure to follow his recommendations.

3) Make sure your firewall rules are set up with the security best practice of "minimum access to get the job done". Far too many firewalls allow traffic they shouldn't.

4) Get NMAP, a network mapper, port scanner, and OS identifier and run it from the Internet to your exposed (i.e. DMZ) hosts. Also run it from your exposed hosts to your internal network to validate that only the traffic that should get in can get in. (The traffic allowed back in from your DMZ should be very little, preferably none.) If you find anything that is inconsistent with what you think should be happening, check your firewall rules again.

5) Grab a copy of the Nessus security scanner and run it against your newly secured systems. If it finds anything, read the description of the problem and see if it's something you can fix. You can bet that everything you find here will also show up on your "security audit" since most "audits" are just someone running a tool like this and then feeding the output to the consultants to make it all pretty for management.

6) You should have most of the obvious, widespread holes plugged by now. This would be a good time to get some sysadmins out to some classes. Verisign has a number of excellent general Internet security classes. I'm sure there are lots of other good places, too. I was pleased with Verisign because of their Internet focus. Too many security classes only concentrate on host security and neglect network security.

7) Get the application developers at your site to read and follow Dave Wheeler's writing secure programs guidelines. This is a lower priority than OS/network security since these holes are likely to be specific to your site only. Only a determined hacker is likely to find and exploit them-- however exploiting application bugs/holes can severely disrupt your business. What happens when an electronic data interchange transaction gets bogus data inserted? How far will that bogus information make it in before it's detected? In the worst case these bugs could result in people getting free products/subscriptions, stealing credit card info, or destroying data inside your systems.

8) Now it's time to get that audit. They will be able to tell you what you missed in the previous 7 steps. Why wait so long? Most places will keep looking until they find something to report. If you do this too soon, the subtle security problems will be lost in the noise of all the obvious problems the previous 7 steps would have fixed. If you do this last, only the "hard" problems are left for them to find.

Remember above all that this is an ongoing process. Keep current on your patches, and repeat all the above steps regularly to keep all the bad guys away.

External audits are good because they bring in experts who focus on finding vulnerabilities in your network. These experts will come armed with a variety of vulnerability assessment tools to perform their audit. The only problem is that it will almost always happen less frequently than vulnerabilities are discovered, so this should only be 1 part of the overall solution.

You should adopt this practice internally, because if the tools are set up to check for vulnerabilities, you can be much more proactive about finding them than simply by scheduling consultants to come every few weeks, months, year. There are a variety of tools available, both freely and commercially.

A good tool will be updated frequently, check a lot of bugs, including the most critical (SANS Top 20, BugTraq, CERT.

Free Tools
SATAN -- Security Administrator Tool for Analyzing Networks
SAINT -- Security Administrator's Integrated Network Tool -- based on SATAN, GNU
SARA -- Security Auditor's Research Assistant -- similar to SATAN/SAINT check the Freshmeat page
NESSUS -- another free tool

Commercial Tools
ISS has a variety of tools avaiable depending on your needs
NeXpose -- try the free demo, great ui, demo only lets you assess 1 IP at a time though :( Here is a review
A Networking Computing article on Vulnerability Assessment tools. Reviews many of the major vendors (so I won't list them all). Includes some of the free tools.
Here is another overview of security tools to get you started.

My company provides Manged Network Security Monitoring and often times our clients will use an assessement as a chance to "test" our services. Afterwards they will also ask our opinion on how well the assessment was performed. Generally, I have found it's best to stay away from the Big 5 accounting firms (KPMG, E&Y,PWC, etc), Telcos, IBM, and other big businesses whose specialty isn't doing security assessments. These types of businesses tend to be way overpriced and provide a cookie cutter approach to security. At the same time watch out for the local "security consultant" who claims to be able to do everything in security as well as the local "hax0r" who has Nessus installed on his laptop (finally). Probably the worst assessments I have ever seen came from these types. (BTW, I am NOT bashing Nessus.)

In my opinion, your best bet is to go with a reputable company who only does security auditing and has a proven customer base (get and check references!!). In my opinion, these guys stand out as a group of people who know what they are doing, and do it well.

We had way too many false positives with their Scanner and Realsecure, even had an ISS guy onsite for a few days. Still, too many problems. With vendor support that... well... is a pain in the *@&%#$ to deal with we switched to Snort and Nessus . Much easier to manage and the false positives went to almost nothing. I'm not even going to start on the Managed firewall crap!

I've just rented a dedicated server running freebsd, and I get messages of relay denied daily, now I need to accept relay for my users... so i've been reading about pop before smpt, thats a good solution, since I am not used to sendmail, it has been very difficult to configure it for me...

I've handled local relaying by just adding IP addresses and/or address blocks to the server config. It works as long as nobody has a dynamic IP address...since the addresses that are let through are all private-subnet addresses (people behind the firewall), this isn't a problem. Their mail gets out, but spammers in search of an open relay are cut off.

You might also want to look into qmail...it's much simpler to get going than sendmail, and IIRC no security holes have been found yet.

Somebody linked to this article on using Apache to find the bots that swipe email addresses from websites. While you're waiting for the bots to respond to their suggested changes, you might also consider searching your logs for other attempts at sending mail through your system. Searching all the logged 404s on my server turned up 91 attempts at exploiting webmail systems. Some were the result of Nessus scans I had aimed at my server, but filtering those out left 36 confirmed attempts.

Here are the user-agents that turned up:

• EmailSiphon
• Microsoft URL Control - 6.00.8862
• Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)

• 07-127.057.popsite.net
• 209.85.24.157
• 24-161-169-176.san.rr.com
• 24.27.210.44.pinecastle-ubr-a.cfl.rr.com
• 251.cleveland-05-10rs.oh.dial-access.att.net
• 2cust165.tnt2.ladue.mo.da.uu.net
• 63.116.175.28
• 64-214-40-67.brv.frontiernet.net
• ac85c77d.ipt.aol.com
• ac894f07.ipt.aol.com
• ac8b6f74.ipt.aol.com
• acb5c2f6.ipt.aol.com
• adsl-64-169-101-147.dsl.lsan03.pacbell.net
• adsl-64-172-45-126.dsl.snfc21.pacbell.net
• cm092.8.234.24.lvcm.com
• ip68-0-166-201.tc.ph.cox.net
• lsanca1-ar2-143-206.lsanca1.dsl.gtei.net
• pool-151-201-153-163.phil.east.verizon.net
• roc-204-210-146-77.rochester.rr.com
• tide86.microsoft.com

checkout: nessus plugins

they have the two snmp vulnerabilities:

snmp_oversized_length_field_dos.nasl

and

snmp_oversized_length_field_dos_two.nasl

checkout: nessus plugins

they have the two snmp vulnerabilities:

snmp_oversized_length_field_dos.nasl

and

snmp_oversized_length_field_dos_two.nasl

checkout: nessus plugins

they have the two snmp vulnerabilities:

snmp_oversized_length_field_dos.nasl

and

snmp_oversized_length_field_dos_two.nasl

It would be nice to know that Guardent is contributing to the respective projects that are being implemented on this device (IPTables, Snort, Nessus), but I haven't been able to find any ackknowledgement of it on either Nessus's thanks page or in the credits for Snort.

Certainly they've got people working for them who have the know-how to add substancial features to the projects and it would be nice to know that they're not just freeriding on the software for the managed services platform that this device really is.

some are quite good

you know nessus?

• 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.

nessus-update-plugins would've helped. My guess is that these people used the stock nessus installation without retrieving the latest scans.

The two vulnerability missed by nessus are at

http://cgi.nessus.org/plugins/dump.php3?id=10318 and

http://cgi.nessus.org/plugins/dump.php3?id=10260

Again, I'm no security expert, but these people should've at least updated the list.

nessus-update-plugins would've helped. My guess is that these people used the stock nessus installation without retrieving the latest scans.

The two vulnerability missed by nessus are at

http://cgi.nessus.org/plugins/dump.php3?id=10318 and

http://cgi.nessus.org/plugins/dump.php3?id=10260

Again, I'm no security expert, but these people should've at least updated the list.

I was able to DoS my FreeBSD 3.4 machine (default install) using Nessus, but OpenBSD had no problems. Of course, I realize this means little, if anything in the real world. Any system will have holes.

Now, anyone will tell you that it's the admin that makes your system secure, and I will have to agree. Even with the most secure OS, if you create holes or don't look out for new exploits, you will be owned eventually. Conversely, if you know what you're doing, you can produce a relatively secure machine running almost any OS.

As far as the specifics of your implementation, Linux or any of the BSD's would do a fine job. It's just a matter of setting up NAT or IP forwarding to route the correct ports between the two networks.

For detecting possible security holes Nessus is a good tool to use, and it can be configured by a cron job to automatically pull down revised scripts. It works in conjunction with nmap. Be warned it can take a long time to run - it took me 20 minutes to scan 127.0.0.1.

The worst thing, though, is to rely 100% on security tools. Tools like Nessus rely upon known exploits. Its the unknown ones that cause the real problems.

Nessus Scan Report

Number of hosts which were alive during the test : 1
Number of security holes found : 5
Number of security warnings found : 1
Number of security notes found : 2

List of the tested hosts :

• 205.177.226.233 (Security holes found)

[ Back to the top ] 205.177.226.233 :

List of open ports :

• • telnet (23/tcp)
  • www (80/tcp) (Security hole found)
  • sunrpc (111/tcp)
  • shell (514/tcp)
  • unknown (2049/tcp)
  • general/udp (Security notes found)

[ back to the list of ports ]

Vulnerability found on port www (80/tcp)

• The 'perl' cgi is installed and can be launched
• 
  as a CGI. This is like giving a free shell to anyone, with the
  http server privileges (root or nobody).
  
  Solution : remove it from /cgi-bin
  
  Risk factor : Serious
  CVE : CAN-1999-0509
  

Vulnerability found on port www (80/tcp)

• The 'jj' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0260
  

Vulnerability found on port www (80/tcp)

• The 'glimpse' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Note that we could not actually check for the presence
  of this vulnerability, so you may be using a patched
  version.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0147
  

Vulnerability found on port www (80/tcp)

• The 'Count.cgi' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0021
  

Vulnerability found on port www (80/tcp)

• 'cgiwrap' is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious

Warning found on port www (80/tcp)

• The 'finger' cgi is installed. It is usually
  not a good idea to have such a service installed, since
  it usually gives more troubles than anything else.
  
  Double check that you really want to have this
  service installed.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CAN-1999-0197
  

Information found on port www (80/tcp)

• The remote web server type is :
  Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3
  
  
  We recommend that you configure your web server to return
  bogus versions, so that it makes the cracker job more difficult
  

Information found on port general/udp

• For your information, here is the traceroute to 205.177.226.233 :
  ?
  

Nessus Scan Report

Number of hosts which were alive during the test : 1
Number of security holes found : 5
Number of security warnings found : 1
Number of security notes found : 2

List of the tested hosts :

• 205.177.226.233 (Security holes found)

[ Back to the top ] 205.177.226.233 :

List of open ports :

• • telnet (23/tcp)
  • www (80/tcp) (Security hole found)
  • sunrpc (111/tcp)
  • shell (514/tcp)
  • unknown (2049/tcp)
  • general/udp (Security notes found)

[ back to the list of ports ]

Vulnerability found on port www (80/tcp)

• The 'perl' cgi is installed and can be launched
• 
  as a CGI. This is like giving a free shell to anyone, with the
  http server privileges (root or nobody).
  
  Solution : remove it from /cgi-bin
  
  Risk factor : Serious
  CVE : CAN-1999-0509
  

Vulnerability found on port www (80/tcp)

• The 'jj' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0260
  

Vulnerability found on port www (80/tcp)

• The 'glimpse' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Note that we could not actually check for the presence
  of this vulnerability, so you may be using a patched
  version.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0147
  

Vulnerability found on port www (80/tcp)

• The 'Count.cgi' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0021
  

Vulnerability found on port www (80/tcp)

• 'cgiwrap' is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious

Warning found on port www (80/tcp)

• The 'finger' cgi is installed. It is usually
  not a good idea to have such a service installed, since
  it usually gives more troubles than anything else.
  
  Double check that you really want to have this
  service installed.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CAN-1999-0197
  

Information found on port www (80/tcp)

• The remote web server type is :
  Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3
  
  
  We recommend that you configure your web server to return
  bogus versions, so that it makes the cracker job more difficult
  

Information found on port general/udp

• For your information, here is the traceroute to 205.177.226.233 :
  ?
  

Nessus Scan Report

Number of hosts which were alive during the test : 1
Number of security holes found : 5
Number of security warnings found : 1
Number of security notes found : 2

List of the tested hosts :

• 205.177.226.233 (Security holes found)

[ Back to the top ] 205.177.226.233 :

List of open ports :

• • telnet (23/tcp)
  • www (80/tcp) (Security hole found)
  • sunrpc (111/tcp)
  • shell (514/tcp)
  • unknown (2049/tcp)
  • general/udp (Security notes found)

[ back to the list of ports ]

Vulnerability found on port www (80/tcp)

• The 'perl' cgi is installed and can be launched
• 
  as a CGI. This is like giving a free shell to anyone, with the
  http server privileges (root or nobody).
  
  Solution : remove it from /cgi-bin
  
  Risk factor : Serious
  CVE : CAN-1999-0509
  

Vulnerability found on port www (80/tcp)

• The 'jj' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0260
  

Vulnerability found on port www (80/tcp)

• The 'glimpse' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Note that we could not actually check for the presence
  of this vulnerability, so you may be using a patched
  version.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0147
  

Vulnerability found on port www (80/tcp)

• The 'Count.cgi' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0021
  

Vulnerability found on port www (80/tcp)

• 'cgiwrap' is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious

Warning found on port www (80/tcp)

• The 'finger' cgi is installed. It is usually
  not a good idea to have such a service installed, since
  it usually gives more troubles than anything else.
  
  Double check that you really want to have this
  service installed.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CAN-1999-0197
  

Information found on port www (80/tcp)

• The remote web server type is :
  Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3
  
  
  We recommend that you configure your web server to return
  bogus versions, so that it makes the cracker job more difficult
  

Information found on port general/udp

• For your information, here is the traceroute to 205.177.226.233 :
  ?
  

Nessus Scan Report

Number of hosts which were alive during the test : 1
Number of security holes found : 5
Number of security warnings found : 1
Number of security notes found : 2

List of the tested hosts :

• 205.177.226.233 (Security holes found)

[ Back to the top ] 205.177.226.233 :

List of open ports :

• • telnet (23/tcp)
  • www (80/tcp) (Security hole found)
  • sunrpc (111/tcp)
  • shell (514/tcp)
  • unknown (2049/tcp)
  • general/udp (Security notes found)

[ back to the list of ports ]

Vulnerability found on port www (80/tcp)

• The 'perl' cgi is installed and can be launched
• 
  as a CGI. This is like giving a free shell to anyone, with the
  http server privileges (root or nobody).
  
  Solution : remove it from /cgi-bin
  
  Risk factor : Serious
  CVE : CAN-1999-0509
  

Vulnerability found on port www (80/tcp)

• The 'jj' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0260
  

Vulnerability found on port www (80/tcp)

• The 'glimpse' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Note that we could not actually check for the presence
  of this vulnerability, so you may be using a patched
  version.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0147
  

Vulnerability found on port www (80/tcp)

• The 'Count.cgi' cgi is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CVE-1999-0021
  

Vulnerability found on port www (80/tcp)

• 'cgiwrap' is installed. This CGI has
• 
  a well known security flaw that lets anyone execute arbitrary
  commands with the privileges of the http daemon (root or nobody).
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious

Warning found on port www (80/tcp)

• The 'finger' cgi is installed. It is usually
  not a good idea to have such a service installed, since
  it usually gives more troubles than anything else.
  
  Double check that you really want to have this
  service installed.
  
  Solution : remove it from /cgi-bin.
  
  Risk factor : Serious
  CVE : CAN-1999-0197
  

Information found on port www (80/tcp)

• The remote web server type is :
  Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3
  
  
  We recommend that you configure your web server to return
  bogus versions, so that it makes the cracker job more difficult
  

Information found on port general/udp

• For your information, here is the traceroute to 205.177.226.233 :
  ?