Slashdot Mirror

Another war that has been going on periodically is over so-called 'obscenity', which means different things to different people and, when banned, is subject to wildly different interpretations, and it's this one that I'm referring to. I file Senator Hatch under the category "An enemy of my enemy is not necessarily my friend", because it wasn't that long ago that he was trying to wipe servers off the WWW with legislation. (1, 2)

Perhaps you are just joking, but I do that too :). In fact, I added a special "random input" mode to Nmap for this sort of occasion. There is also a "turbo" mode for scanning just one port. If you are ever bored enough to check out some "random" web (or ftp, SMB, etc) servers, here is the command I use:

core/home/fyodor#nmap -iR -sS -PS80 -p 80 -oM- | grep Interesting
Interesting ports on lucus.creativepresence.com (216.181.159.18):
Interesting ports on 64.96.235.88:
Interesting ports on pddafb6.ykhmac00.ap.so-net.ne.jp (218.221.175.182):
Interesting ports on marudmz2-broadcast.interq.or.jp (210.172.130.199):
Interesting ports on rn068058189.dcmdw.dcma.mil (131.68.58.189):
Interesting ports on 208.167.47.3:
Interesting ports on 66-224-4-78.atgi.net (66.224.4.78):
Interesting ports on 225.245.70.200.ppp.nuria.net.ar (200.70.245.225):
Interesting ports on www.fortcollins.caddbase.com (65.127.93.15):
Interesting ports on 207.106.191.83:
Interesting ports on dsl-64-34-112-223.telocity.com (64.34.112.223):
Interesting ports on 64.119.66.83:
Interesting ports on arizonashomesonline.com.criticalpath.net (209.231.209.73):
Interesting ports on www.renavigator.net (217.170.39.157):
Interesting ports on 200.21.137.18:
Interesting ports on fornosenigaglia.it (209.227.205.157):
Interesting ports on BSN-250-18-26.dsl.siol.net (213.250.18.26):
Interesting ports on 213.196.33.90:
Interesting ports on 213.193.115.242:
Interesting ports on ridgewood77-77-213.bergen.org (168.229.77.213):
Interesting ports on dirweb03.search.aol.com (205.188.180.3):
Interesting ports on 161.58.90.51:
Interesting ports on www.tokyo-media.com (61.126.14.5):
Interesting ports on ppp39.plsntvl.eticomm.net (208.9.153.39):
Interesting ports on 210.122.215.2:
Interesting ports on YahooBB219030013082.bbtec.net (219.30.13.82):
Interesting ports on s9-66.umiva.9netave.net (216.149.9.66):
Interesting ports on www.thumbvault.net (210.18.207.67):
Interesting ports on CPE014080212685.cpe.net.cable.rogers.com (24.114.90.220):
Interesting ports on www.delmarlaw.com (209.251.144.77):
Interesting ports on ccvideo.com (204.167.145.27):
Interesting ports on 80.239.139.33:
Interesting ports on pathspeedweb.com (169.207.184.1):
Interesting ports on ns1.gloryworks.com (64.71.189.130):
Interesting ports on www.thechicagolighthouse.org (209.242.31.136):

Do remember to stop this scan when you are done. Otherwise it will never end and you may wake up to a nasty letter from your ISP. Trust me on this one ;).

-Fyodor
Concerned about your network security? Try the Free Nmap Security Scanner.

Perhaps you are just joking, but I do that too :). In fact, I added a special "random input" mode to Nmap for this sort of occasion. There is also a "turbo" mode for scanning just one port. If you are ever bored enough to check out some "random" web (or ftp, SMB, etc) servers, here is the command I use:

core/home/fyodor#nmap -iR -sS -PS80 -p 80 -oM- | grep Interesting
Interesting ports on lucus.creativepresence.com (216.181.159.18):
Interesting ports on 64.96.235.88:
Interesting ports on pddafb6.ykhmac00.ap.so-net.ne.jp (218.221.175.182):
Interesting ports on marudmz2-broadcast.interq.or.jp (210.172.130.199):
Interesting ports on rn068058189.dcmdw.dcma.mil (131.68.58.189):
Interesting ports on 208.167.47.3:
Interesting ports on 66-224-4-78.atgi.net (66.224.4.78):
Interesting ports on 225.245.70.200.ppp.nuria.net.ar (200.70.245.225):
Interesting ports on www.fortcollins.caddbase.com (65.127.93.15):
Interesting ports on 207.106.191.83:
Interesting ports on dsl-64-34-112-223.telocity.com (64.34.112.223):
Interesting ports on 64.119.66.83:
Interesting ports on arizonashomesonline.com.criticalpath.net (209.231.209.73):
Interesting ports on www.renavigator.net (217.170.39.157):
Interesting ports on 200.21.137.18:
Interesting ports on fornosenigaglia.it (209.227.205.157):
Interesting ports on BSN-250-18-26.dsl.siol.net (213.250.18.26):
Interesting ports on 213.196.33.90:
Interesting ports on 213.193.115.242:
Interesting ports on ridgewood77-77-213.bergen.org (168.229.77.213):
Interesting ports on dirweb03.search.aol.com (205.188.180.3):
Interesting ports on 161.58.90.51:
Interesting ports on www.tokyo-media.com (61.126.14.5):
Interesting ports on ppp39.plsntvl.eticomm.net (208.9.153.39):
Interesting ports on 210.122.215.2:
Interesting ports on YahooBB219030013082.bbtec.net (219.30.13.82):
Interesting ports on s9-66.umiva.9netave.net (216.149.9.66):
Interesting ports on www.thumbvault.net (210.18.207.67):
Interesting ports on CPE014080212685.cpe.net.cable.rogers.com (24.114.90.220):
Interesting ports on www.delmarlaw.com (209.251.144.77):
Interesting ports on ccvideo.com (204.167.145.27):
Interesting ports on 80.239.139.33:
Interesting ports on pathspeedweb.com (169.207.184.1):
Interesting ports on ns1.gloryworks.com (64.71.189.130):
Interesting ports on www.thechicagolighthouse.org (209.242.31.136):

Do remember to stop this scan when you are done. Otherwise it will never end and you may wake up to a nasty letter from your ISP. Trust me on this one ;).

-Fyodor
Concerned about your network security? Try the Free Nmap Security Scanner.

I don't understand why LinuxandMain (or Slashdot) doesn't give a link to the actual exchange of messages. Summaries are fine for the casual reader, but if one cares about the debate or wants to judge for herself, it's best to read the original.

Anyway, here's one URL for the thread, starting with RMS' comments on ethics.

No -- I mean DON'T relax, you should keep up with the latest threats and remain vigilant. But you can stop worrying about Idlescan.

The article clearly states that "The latest versions of Linux, Solaris, and OpenBSD are immune as zombies..." so I suppose that if you want to keep using linux, just upgrade to whatever version started being invulnerable to this type of attack.

Concerned about your network security? Try the Free Nmap Security Scanner.

Concerned about your network security? Try the Free Nmap Security Scanner.

I'm not telling them because I don't think I will convince Linus. Some others on lkml already feel BK is a bad idea, and they haven't changed his mind. It's still worth it to post my views here to try to convince others.

> Not really. like has been pointed out many many times on lkml, you don't need to even touch BK to be involved in kernel development.

Not being a kernel hacker, I don't know how much of a second-class citizen a non-BK user might become. If the others in the group really make it a priority to make things easy & inviting for non-BK users, I expect they can do it. On the other hand, while I don't follow lkml, Slashdot user fv believes that Linus is subtly encouraging BK.

(link is copied from fv's slashdot post)

I for one plan to resist this bogus, anticompetitive license. As others have mentioned, this is like MS changing their EULA to exclude developers of competing operating systems. The best way to fight BK is to write a compelling replacement. My best wishes go out to those who are already doing such admirable work!

Cheers,
Fyodor

Concerned about your network security? Try the Free Nmap Security Scanner.

I for one plan to resist this bogus, anticompetitive license. As others have mentioned, this is like MS changing their EULA to exclude developers of competing operating systems. The best way to fight BK is to write a compelling replacement. My best wishes go out to those who are already doing such admirable work!

Cheers,
Fyodor

Concerned about your network security? Try the Free Nmap Security Scanner.

For those that don't know, the F00F bug was a notorious bug occuring on Pentium processors around 1997.

The above is a technical article on it; here is a simple one, which only lists the actual exploit.

nmap -sI zombiehost victimhost

ESR's refusal to update the patches to handle changes Linus made to the core code.

Sorry, you don't have permission to rewrite history. Eric updated his patches, and updated and updated, all the while waiting for Linus to suck in CML2 *like Linus promised*. Finally, he got burned out, and started to publicly wonder WTF was going on. All this time he was being roundly, soundly, and viciously abused by various people on the LKML.

All of which goes to show that Linus's promises are worth nothing. But we all knew that, didn't we?

Free Kevin!

SumDeusExMachina - crapflooder extraordinare - has his daily activities exposed to the public. Revenge is sweet.

I think nmap can make packets with forged source addresses.

It occurs to me that when security tools such as nmap, or crack or airsnort or SATAN come from places OTHER than the government, they are seen as threats to Internet security. Some people in government even want to make them illegal.

But when the government itself comes out with software to expose security holes, it's called the "Gold Standard".

What gives?

• "TCP/IP Illustrated Vol.1" by Richard Stevens published by Addison-Wesley
• "Intrustion Detection: An Analysts Handbook" by Stephen Northcutt published by New Riders
• "Unix System Administration" aka The Red Book by Nemeth, et. al. I believe the Purple Book is the 3rd edition (I am open to corrections)
• 2600 The Hacker Quartlery. A quarerly zine that most slashdotters have read, subscribe to, (or in this new-age, have either never heard of it and/or will flame or mod this into oblivion)
• the "Hacking Exposed" series by Stuart McClure, et. al.

nmap will tell you what the OS is, and give you a rough idea of how hard it would be to use the target's ISN against it.

Uptime 0.811 days (since Sat Jun 29 22:04:58 2002)

TCP Sequence Prediction: Class=random positive increments
Difficulty=2918407 (Good luck!)

IPID Sequence Generation: All zeros

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.

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow,
2. unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

• All the 'geeks' wearing tux t-shirts are actually MIS support guys who are still studying for their MCSE exam.
  
• 'The screaming fast Linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production network since every Linux (l)user seems to need nmap [insecure.org] to perform normal work-related computer operations.
  
• All the 'cool' Apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. )
  
  
• For the rare instance where a free UNIX is actually used in a production environment, management has smartened up and BSD is usually installed.

[root@maria /root]# nmap -O www.wehavethewayout.com -v -v

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up).
Host www.wehavethewayout.com (192.61.1.15) appears to be up ... good.
Initiating TCP connect() scan against www.wehavethewayout.com (192.61.1.15)
Adding TCP port 80 (state open).
The TCP connect scan took 655 seconds to scan 1523 ports.
For OSScan assuming that port 80 is open and port 30836 is closed and neither are firewalled
For OSScan assuming that port 80 is open and port 31259 is closed and neither are firewalled
For OSScan assuming that port 80 is open and port 39772 is closed and neither are firewalled
Interesting ports on www.wehavethewayout.com (192.61.1.15):
(The 1522 ports scanned but not shown below are in state: filtered)
Port State Service
80/tcp open http

TCP Sequence Prediction: Class=random positive increments
Difficulty=12042 (Worthy challenge)

Sequence numbers: 82181185 82194841 821AAEC1 821BB8B4 821CAAE6 821E1005
No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
TSeq(Class=RI%gcd=1%SI=32F9)
TSeq(C lass=RI%gcd=1%SI=2083)
TSeq(Class=RI%gcd=1%SI=2F0 A)
T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=MNW NNT)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%A CK=O%Flags=R%Ops=)
T5(Resp=N)
T6(Resp=N)
T7(Res p=N)
PU(Resp=N)

Nmap run completed -- 1 IP address (1 host up) scanned in 677 seconds

18,157.130.99.246,528ms,unisys-70-gw.customer.ALTE R.NET
19,192.61.1.15,474ms,www.wehavethewayout.co m

And don't forget the Ping of Death

If the user, despite ISP encouragement, chooses not to use a proxy, that should be his choice. He is paying for the bandwidth, and is assumed to be aware of the possible performance hit.

This was discussed in the vuln-dev mailing list after Comcast implemented transparent proxying.

This raised quite a stink when Comcast's logging habits were revealed. Oops.

There is obviously a performance degradation involved with re-resolving the address given to the cache server. Furthermore, requests now appear to be coming from the server, not the actual user -- potentially breaking host-based authentication systems.

I've also seen these cache systems horribly implemented. An IRC network that I administer recently starting checking for HTTP proxies on connection. This was performed by connecting to the remote user's host on certain ports (80, 3128, 8000, and 8080) and then issuing a CONNECT request. In more than one case, a blatantly stupid ISP redirected _incoming_ port 80 traffic to their server -- WITHOUT any sort of access restrictions on their proxy. Sort of ironic that they were probably using untold amounts of bandwidth for 1337 bounce kiddiots.

Proxying without consent is an Evil Thing.

If the user, despite ISP encouragement, chooses not to use a proxy, that should be his choice. He is paying for the bandwidth, and is assumed to be aware of the possible performance hit.

This was discussed in the vuln-dev mailing list after Comcast implemented transparent proxying.

This raised quite a stink when Comcast's logging habits were revealed. Oops.

There is obviously a performance degradation involved with re-resolving the address given to the cache server. Furthermore, requests now appear to be coming from the server, not the actual user -- potentially breaking host-based authentication systems.

I've also seen these cache systems horribly implemented. An IRC network that I administer recently starting checking for HTTP proxies on connection. This was performed by connecting to the remote user's host on certain ports (80, 3128, 8000, and 8080) and then issuing a CONNECT request. In more than one case, a blatantly stupid ISP redirected _incoming_ port 80 traffic to their server -- WITHOUT any sort of access restrictions on their proxy. Sort of ironic that they were probably using untold amounts of bandwidth for 1337 bounce kiddiots.

Proxying without consent is an Evil Thing.

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like
2. MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

• All the 'geeks' wearing tux t-shirts are actually MIS support guys who are still studying for their MCSE exam.
  
• 'The screaming fast linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production network since every linux (l)user seems to need nmap [insecure.org] to perform normal work-related computer operations.
  
• All the 'cool' Apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. )
  
  
• For the rare instance where a free UNIX is actually used in a production environment, management has smartened up and BSD is usually installed.

Well, they're using Solaris 2.5.1, which initially came with SMI-8.6.

They have upgraded since that original version, however.

The latest Sendmail version for Solaris 2.5.1 was 8.8.8 plus a Sun patch, so hopefully they got rid of any and all potential problems.

MONOLINUX :: Imagine There's No Windows. It's Easy If You Try.

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like
2. MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

• All the 'geeks' wearing tux t-shirts are actually MIS support guys who are still studying for their MCSE exam.
  
• 'The screaming fast linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production network since every linux (l)user seems to need nmap [insecure.org] to perform normal work-related computer operations.
  
• All the 'cool' Apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. )
  
  
• For the rare instance where a free UNIX is actually used in a production environment, management has smartened up and BSD is usually installed.

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like
2. MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

• All the 'geeks' wearing tux t-shirts are actually MIS support guys who are still studying for their MCSE exam.
  
• 'The screaming fast linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production network since every linux (l)user seems to need nmap to perform normal work-related computer operations.
  
• All the 'cool' Apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. )
  
• For the rare instance where a free UNIX is actually used in a production environment, management has smartened up and BSD is usually installed.
  

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like
2. MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

• All the 'geeks' wearing tux t-shirts are actually MIS support guys who are still studying for their MCSE exam.
  
• 'The screaming fast linux machines at work' are actually refurbished workstations at a separated network segment, not allowed on the production network since every linux (l)user seems to need nmap to perform normal work-related computer operations.
  
• All the 'cool' Apache web servers are actually IIS machines with forged host headers. (yes, you can do that in IIS without recompiling anything. Heck, I lived for years without a C compiler and still do. )
  
  
• For the rare instance where a free UNIX is actually used in a production environment, management has smartened up and BSD is usually installed.

1. it usually takes a whole support team to install a geeks' workstation

1. Installation and maintenance requires 4-5 times the bandwidth a 'normal' OS would require

1. Linux was deliberately made completely incompatible and inoperatible with turnkey solutions like
2. MS Exchange or MS SQL server. Investments in these products are therefore voided the minute you start rolling out Linux.

1. Applications developed in Perl or C, the languages of the linux community have proven to be slow, unreliable, insecure and headaching complicated. Once developed and debugged, nobody is able to understand the code.

Either way, SF has to be forking out some very serious money for the bandwidth, the machines, the admin staff and then any development they are trying to do on it all.

"it's my kernel and I'll cry if I want to" - Linus

Posted anonymously to protect me from Slashdot Linux Nazis

A very good, and insightful comment. It truly shows the simplicity at which OpenBSD 3.0's packet filter rules work.

I myself have been using OpenBSD for some time now and was very pleased with the way ipf dealt with things.. and I like the 'new features' aswell: Now pf will also take care that any hosts behind the firewall, even if they are the originators of a connection do not get hit by malicious packets who happen to have the right sequence number - just with this one statement "scrub all". Beautiful. And that ability to define variables with, say, lists of different IPs as in " hosts_that_want_to_do_us_bad="{1.2.3.4, 1.2.3.5}"? Great, this one really increases the maintenanceability of your firewall rules.

Otoh, I have just had the task of setting up a Linux server, directly exposed to the Internet, which obviously had to have a few packet filtering rules. I ran bastille, configured the box really quickly and fired up my nmap, which in turn showed great default results. It's just that until I got the time to look at the scripts this animal created for me, I did not really have a clue on what bastille did. ;-)

The Microsoft TCP/IP stack is not loaded by default in OpenBSD.

In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD.

That article doesn't cover too many port 80 exploits. It does cover the most common attacks, but, if you want some more information here is a more complete guide. There are also a lot of language translations of it at the top if you're not the most fluent in english.

Remember, these documenst are written to help server administrators get an idea of what to look out for, not to solve every single port 80 problem out there.

oops, I was close...it was made into a generic term of "F00F"...or foof....

This makes more sense

This archive still seems to be responding OK. Hopefully it won't get nailed too hard since this link isn't in the story header. The mailing list thread is an interesting read.

Obscurity isn't security. Look here. While I hope nobody would disclose sensitive info on Slashdot, a system that's comprimised by posting it's OS isn't secure in the first place.

tools like nmap can fingerprint a system's OS by the behavior of its tcp/ip stack. From there+the server software, the architecture is easier to find out, if the server does not directly provide the information.

Nowhere is this word/image culture tension better represented than in
the contrast between UNIX and NT. When the much-vaunted UNIX-killer
arrived a few years ago, backed by the full faith and credit of the
Redmond juggernaut, I approached it with an open mind. But NT left me
cold. There was something deeply unsatisfying about it. I had that
ineffable feeling (apologies to Gertrude Stein) there was no there
there. Granted, I already knew the major themes of system and network
administration from my UNIX days, and I will admit that registry
hacking did vex me for a few days, but after my short scramble up the
learning curve I looked back at UNIX with the feeling I'd been demoted
from a backhoe to a leaf-blower. NT just didn't offer room to move.
The one-size-fits-all, point-and-click,
we've-already-anticipated-all-your-needs world of NT had me yearning
for those obscure command-line flags and man -k. I wanted to craft my
own solutions from my own toolbox, not have my ideas slammed into the
visually homogenous, prepackaged, Soviet world of Microsoft Foundation
Classes.

NT was definitely much too close to image culture for my comfort:
endless point-and-click graphical dialog boxes, hunting around the
screen with the mouse, pop-up after pop-up demanding my attention. The
experience was almost exclusively reactive. Every task demanded a
GUI-based utility front-end loaded with insidious assumptions about
how to visualize (and thus conceptualize) the operation. I couldn't
think "outside the box" because everything literally was a box. There
was no opportunity for ad hoc consideration of how a task might
alternately be performed.

Read that post from bugtraq archives: The proposal of creating such an automatic healer worm started a fierce discussion.

No, it isn't. At least according to the helpdesk drones. Level 2 support tries the old, "These are not the IPs you are looking for..." Jedi mindtrick.

It certainly looks like the Code Red activity is to blame for the storm of ARP packets. Makes stealing @Home IPs rather easy right now, seeing as how ARP requests for identical IPs roll in about 1-2 times per minute. If only there were an example of an ARP exploit that could be tweaked to feed my paranoia...

Hundreds of thousands of W2K boxes are hooked up to 24/7 broadband connections right now. Default installs, with IIS running, you bet. Not in server rooms, but in people's homes. And most of these folks don't know Jack about security. Yet.

Last week, we learned here about the writeup the Honeynet.org people put together on the fantastic aggressiveness of modern "blackhats". About how an unhardened RedHat 6.2 box, connected to the Internet without any publicity or announcement, gets root compromised in about 3 days on average.

Well, folks, what Lance Spitzner and friends are also doing is simulating your average non-technical American with a shiny, new 24/7 connection. You recall, the Honeynet is set up in Mr. Spitzner's home, at the end of a DSL connection. Without firewalls or host-hardening.

You know, early this week, I went through firewall log data which was clearly the traces of three reconnaissance probes against my company's networks. Now I'm not going to tell you who we are, or what netblocks we use. But it is not saying too much to relate that what I monitor (today) consists of a /26 and a /27 netblock. The /26 has 64 IPs. Throw away the first and last IP (network wire and broadcast address) gives you 62 IPs for boxes. The /27 has 32, the same exercise yields 30 IPs for boxes. The two netblocks are close in IP space. So I expect competent attackers to sweep anywhere from 92 to 97 (adding in the external firewall interface) IPs when they check us out.

These probes sucked. One tried for 35 of our IPs, another for 55, the third for 93 (and missed 3 IPs actual boxes might have lived on). What script kiddy could be so dense? I quipped to my boss about "script infants", and he laughed.

Interesting thing is, all three attacks showed up in the same day's logs. And they all came from IPs owned by broadband providers. Hell, one IP was specifically spelled out, right there in the "whois" output, to live in a netblock reserved for cable modem customers.

weave's post leaves me with a wonder and a speculation.

My wonder is: were those incompetently executed sweeps the result of worm activity?

My speculation is simply this: CodeRed behaves precisely like the Honeynet Project's "blackhats", and what others, such as myself, call "script kiddies". They simply probe and probe and probe. And when they find a box that may be vulnerable, they fire off their exploit. Sometimes, compromising and then infecting the target box, which then replicates the same essentially mindless behavior. Where is such a strategy going to make the biggest splash? Easy answer: America's dens and living rooms, where, more often than not, nobody in the family has even heard of a firewall, and "hackers" are evil phantoms that the media depicts as targeting big outfits like Microsoft, Yahoo, and eBay. The attitude is "Hack US? Never, we're insignificant small fry. Where are the bragging rights in that?"

I've been worrying about this for almost two years, now. I swear, there are times when I almost want to wear a sandwich board when I walk down the street to work, which announces something like "REPENT, SINNERS! FIREWALL YOUR BROADBAND CONNECTIONS OR GOD WILL PUNISH YOU WITH ETERNAL HELLFIRE!". :-)

The fellow who wrote the CodeRed worm failed in his primary goal (DDoS against www.whitehouse.gov) mostly because he was a moron. He hardcoded the target by IP, not by FQDN. So the feds kept moving whitehouse.gov from one IP to another, updating DNS records all the while. BUWAHAHAHAHA!

The assh@le who writes CodeRed-II will probably not be such a knuckle-dragging dimbulb.

And he will produce a highly successful infector, if Ramen, Lion, and now, CodeRed are any indication.

In which case, the DDoS could very well succeed.

This will scare a lot of people badly. Including congresscritters.

Next thing you know, laws will begin their trip through Capitol Dung^H^H^H^HHill requiring that folks who purchase 24/7 connections register their IP addresses (or, perhaps their boxes, assuming DHCP-based IP allocation by ISPs survives the panic) by location. So that whatever constabulary organization(s) ultimately get tasked can verify (by use of nmap or something similar) that said IPs are properly firewalled, and write citations to serve to the folks whose IPs are not. Or a summons. Or just seize the box as a "menace".

And the next thing you know, the existing registration structure will lead to calls to use it to defray enforcement costs, on the local or national level. Holy shit, an Internet PC tax!

And heightened logging requirements imposed on ISPs will make it trivial for the self-appointed Guardians Of Public Morality to Save The Children by tracking porn downloads to their ultimate destination much more easily. Using rich data sources, legal compulsion mechanisms, and automated analysis tools these vermin only dream about today.

Of course, the next little item would be some real TEETH in DMCA enforcement.

Not to mention the disappearance of anonymity in chat boards, as multiple-terabyte ISP log partitions nab not only packet headers, but much of the packet body as well.

GODDAM! I've just GOT to get my lazy ass out to Home Depot! TOMORROW! Let's see .. 2 24"x36" pieces of plywood .. two 12" pieces of strapping to hold the upper edges together .. a couple of sheets of 24"x36" pasteboard .. an extra-large magic marker .. maybe I should have the lettering done by a print shop .....

For RH 6.2, before you even connect it to a network, I reccomend you have a copy of Bastille Linux (Which is actually a script, not a distrobution) on hand. This is great for newbies.

As a general rule:
run the "ntsysv" tool, and disable portmap, httpd, bind... hell disable EVERYTHING, and begin turning on things as you need them. (If you don't know what it does, turn it off, if something stops working, you know what that was and can turn it back on.)

Comment out everything in the /etc/inetd.conf file (which only appears in a server install).

Have nmap on hand, and scan 127.0.0.1 (yourself) with it, to make certain your ports are closed. Nmap should only find port 113 (and 22 if you install SSH). Sure, you can have more open ports after that - but that is providing you know what they do.

There is no way I can give you enough advice on how to secure a machine on a simple /. post, but the above is a good start for Red Hat 6.2.

Actually, it's a (mild) security risk. From the nmap(1) man page:

As noted by Dave Goldsmith in a 1996 Bugtraq post, the ident protocol (rfc 1413) allows for the disclosure of the username that owns any process connected via TCP, even if that process didn't initiate the connection. So you can, for example, connect to the http port and then use identd to find out whether the server is running as root.

Nmap allows one to do exactly that with the -I option.

There is a huge difference between checking whether a port is open and actively trying to exploit a security hole. You are trying to blur the distinction between the two.

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

Never download from a site or mirror you don't trust.

It's more complicated than that. Someone can set up> a server that looks like the master .rpm or .deb server, and pollute a DNS cache so that the name of the real server points at the fake server for anyone using that cache.

As you say, the best way to know for certain (for some value of "certain") is by using cryptographic techniques.

M