Slashdot Mirror

Slashvertisements - by Google

Removes Spyware - Free
Removes Spyware, Adware & Parasites Stops PopUps & Identity Theft!
www.Adware-Remover.net

Automated C&A Of Systems
Get Free Whitepaper On FISMA Compliance Automation
www.securify.com

Free vulnerability scan
Security Vulnerability scanning & fixing with LANguard!
www.gfi.com

F'd company should serve as a very real warning to those out there that still work in companies held over from the "Internet Bubble" era. Apparently funding doesnt mean that your company does anything worth while. Just because your company has 50$ million dollars in funding doesnt mean they're worth 50mil.... it just means they're 50$ mil in debt! How can these companies expect to stay around in this economy if they owe their investors that much money with little to no revenue?? Not to mention pissed off workers.

Just look at the latest batch from today alone! Securify, Marrakech, Crescent Networks .... truly f'd!

"Breach"
Rumor has it, $50 million later, Securify just layed off around 20% of its workforce. Word is remaining employees get a 10% paycut.
When: 1/21/2003
Company: Securify.com
Severity: 80
Points: 180

Marred
$55 million later, Marrakech axed 30 -- 70 remain.
When: 1/21/2003
Company: Marrakech
Severity: 65
Points: 165

Croissanwich
"We regret to announce that Crescent Networks has ceased operations," says their site, $50 million later.
When: 1/20/2003
Company: Crescent Networks
Severity: 100 - new hall of fame inductee!
Points: 200

OK, first of all, this thing was built by Securify, by a now defunct group which was based in Boston. They are the same guys who, btw, built American Express Blue. The program includes a full fledged PKI solution, with your credentials stored on the chip. You can use it for signing in for special services, use it to purchase online. You just have to remember a PIN. The funny thing is that Providian, the first Issuer to give out the cards, SELLS the necessary Smartcardreader for 19.95. Speaking of consumer adoption ...

been a long time (3+ years) since I have seen a Linux as stable as Windows

Uhh... Windows 3.1? I have yet to see a properly-configured Win32 (sic) machine hold it's own against a properly-configured Linux machine. Especially considering that any Win32 machine put under any sort of actual use tends to get unstable after, oh, I'll give it 48 hours max.

I get security announcements and patches from Microsoft when problems are discovered. I read about them months after the fact for Linux - and if an RPM patch isn't available oh well.

It all depends on where you go looking for information. There are plenty of security related sites out there that cover Linux.

And what's this bullshit about RPM patches? Have you ever heard of just compiling your own and being done with it? That is why such things are provided for download -- if something goes wrong, you can fix it.

And as far as the level of expertise, I can hire Microsoft engineers all day long. Finding a competent Linux person is near impossible - make sure you add that cost into your evaluation.

I can hire MS engineers all day long too. Can I hire competent engineers of any sort all day long? I highly doubt it. MCSE's are a dime a dozen, but if something just happens to go wrong on that W2k server over there, what are they going to do to fix it? "Oh, reboot the machine, it'll all be fine." Er.. stability?

Well I have my own Cisco based [1 2 3] information which sums up networking to a tee. Security Focus, Packet Storm, SpyKing, and Cryptome all cover the other areas for information when I need it. Is it me or in the past 2 years did everyone jump on the "Hacker" bandwagon writing books on information that's already a point and click away? Not taking anything away from the book, but Information Security Management Handbook 2001, Cisco's Routing TCP/IP, and other security books in my library have done me justice. Makes I guess a nice intro for newer users, but personally I don't like books with "Hacker" in them, they tend to be geared for those with little clues, and who are often too lazy or dumb to find information and study it on their own.

First, DR-DOS. I can't argue that this is a matter of a Windows API breaking code, but it is an example of Microsoft deliberately introducing an incompatibility for the sake of defeating competition. This page explains that it was likely that only developers and computer makers saw this message because the routine (which was encrypted to prevent easy discovery) to display it was disabled before Windows 3.1 went to market (it was only in a beta, as you claim, but it still did significant harm to DR-DOS because computer makers saw it). The message was still present in the shipped binary, disproving the Microsoft assertion that this was all an urban legend, and this page has a utility you can grab (in addition to the source code) to find the message in Windows 3.1. The page also mentions that Microsoft QuickC under DR-DOS would emit an ominous message (but would presumably still run). So you can't say that malicious coding has never been on their mind and you can't blame people for being a bit suspicious when things break strangely.

Another example, though one I'm less likely to attribute to malicious incompatibility for the reason I give at the top of this reply, can be found under 'Smothering Freeware' on this site. Equally interesting (and also mentioned on this page) was the breaking of Professor Felten's demonstration in the recent antitrust trial of Microsoft that Internet Explorer did not need to be integrated into the operating system for the operating system to function. Felten had to provide his program to Microsoft as part of discovery and at some point between then and the trial his program no longer functioned properly. There was some speculation that Microsoft deliberately broke the program, though I tend to believe that their updates just didn't take the functioning of this program into account because, by definition, Felten's program was trying to convert Windows 98 into a non-standard state.

Finally, Kerberos in Windows 2000. Though that was broken from the start (i.e., it wasn't a change to break existing software on Windows), one could argue that it was specifically broken to discourage compatibility of a nature Microsoft didn't want between their system and competitors' systems. Or one could argue that Microsoft liked the technology but didn't want to invest any more effort into development than was necessary to meet their goals (compatibility with other Win2k, whatever other compatibility exists is purely a bonus). Discussion here (search for 'Kerberos') suggests that the incompatibility is a benign by-product of innovation. This (search for 'clickwrap') suggests that it wasn't... putting the specification of the Microsoft changes to the protocol under NDA clickwrap forces an incompatibility between standard Kerberos and MS Kerberos. A matter of perspective, to be sure, but a reminder that seamless compatibility is hardly a priority.

---

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

Just download Sniffit and "Touch of Death" from HERE

Will autokill any connection you see ;-)
--
echo '[q]sa[ln0=aln80~Psnlbx]16isb15CB32EF3AF9C0E5D7272 C3AF4F2snlbxq'|dc

1. It allocates disk sectors in extents - therefore, it absolutely requires defragmentation. See Executive Software's Diskeeper benchmarks, and their white paper. You don't have to believe Executive Software, and there may be good reasons for disbelieving them. Think about it: every other filesystem that has had extent-based allocation ended up with defragementers: DEC's ODS-2 (VMS), SGI's EFS (Irix) are two examples of radically different filesystems by radically different vendors, yet each required defragmentation. Fortunately, SGI provided such a good one, that 3rd party vendors didn't even bother.
2. Each file has multiple "streams". These could very obviously promote security problems. Alternatively, see this for another example. Microsoft itself has had a bunch of problems with NTFS streams, including bizarre interactions with IIS.
3. It's broken by design. Any fool can extend the MFT and use up all of a partition's disk space.

To be blunt, they all suck. Just look here.

Later they'll go back to irc and brag to their friends, especially about any social engineering hacks. That's how they "get the chicks" (uhhh, right)

Frankly, in this day and age social engineering takes more ingenuity and originality than any insipid root kit or named exploit (imho, of course). Firewalls, honeypots, and NIDSes can't compete against a single gullible sysadmin and a phone.

---

Under some circumstances, an intruder who is able to observe an SSL-encrypted session, and subsequently interrogate the server involved in the session, may be able to recover the session key used in that session, and then recover the encrypted data from that session.

The vulnerability can only be exploited if the intruder is able to make repeated session-establishment attempts to the same vulnerable web server which was involved in the original session. In addition, the server must return error messages that distinguish between several modes of failure. Although the number of session-establishment requests is large, it is significantly more efficient than a brute-force attack against the session key. Note that, although web servers comprise the majority of vulnerable servers, other PKCS#1-enabled servers may be vulnerable.

Note that the server's public and private key are not at risk from this vulnerability, and that an intruder is only able to recover data from a single session per attack. Compromising a single session does not give an intruder any additional ability to compromise subsequent sessions. Further, as mentioned above, this vulnerability does not affect all PKCS#1-enabled products.

Snipped from CERT advisory CA-98.07.PKCS

Here is an OpenSSL issue
OpenSSL bypassing

Last but not least there is ssldump, an SSLv3/TLS network protocol analyzer which identifies TCP connections on the chosen network interface and attempts to interpret them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it decodes the records and displays them in a textual form to stdout. If provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic.

Someone said they'd never heard of issues with SSL made me want to get the info on this so apologies for making a redundant post if it seems this way. This does not include issues with Mozilla, Netscape and IE and SSL since it would've taken a lot more space... ./shrugs

home sweet home

black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.

You are right - it is a matter of opinion. I based my statement on the fact that any system that involves Alice, Bob and Trent automatically has one more place to attack than a system just involving Alice and Bob. Hence, because SSH does not support the model involving Trent (or more to the point, Trent is the system administrator or user), if Trent's real name turns out to be Mallory it's less of a problem. (Alice and Bob are the two people trying to communicate, Trent is a trusted arbitrator, and Mallory is a malicious user)

On the other hand, if Alice and Bob don't know how to ensure that their communications aren't being snooped (ie, they don't know to pick up the phone and verbally check, or swap keys, or securely exchange SSH keys), and the system they are using doesn't present suitable warnings and instructions, then yes - the certificate authority is more secure. But IMHO this is a flawed "bullshit security" model that happens to be what Certificate Authoritys' business models are based on.

For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X".

Don't be so hostile. How do you know I'm not an encryption expert?

The point I was making was that it's better to get those identification methods straight from the horse's mouth than trust some agency that might be corrupt. And I explained why there are financial incentives for them to be selectively corrupt; the "purchase-key" attack.

IMO, the only way that works is the web of trust model, designed for PGP, but the concepts apply equally to SSH keys or anything else really.

Why do you think Carl Ellison and Bruce Schneier warn of the risks of PKI?

To me, the CA's are selling people the right to cast aside the problem of teaching and learning secure key exchange, whilst reaping in the profits. They are capitalising on "the path of least resistance" - either learn some basic security concepts, and go to great lengths to ensure your keys are exchanged properly or pay them $5 a year for their "snake oil" certificates of security that cost them next to nothing to produce.

First it was firewalls, then intrusion detection systems, then VPNs, and now certification authorities (CAs) and public-key infrastructure (PKI). "If you only buy X," the sales pitch goes, "then you will be secure." But reality is never that simple, and that is especially true with PKI.

Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you afee for every certificate he issues, you're also in good shape. It's no wonder so many companies are trying to cash in on this potential market.With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors. And this literature leaves some pretty basic questions unanswered: What good are certificates anyway? Are they secure? For what?

Taken from a prior document written by Bruce Schneier which can be found here.

Man in the middle attacks have been rampant for some time now so I don't know why anyone would use an article such as this for 'clarity's' sake where security is concerned. Sure it assists in dealing with issues and bringing them to light but when you need that much of a level of trust the easiest way to circumvent ANY man in the middle attack or any other form of an authentication issue can be achieved simpler via way of verifying a PGP key id over the phone before any trusted information is encrypted and sent down the wire using any key.

Would've made a nice longer post but Monday morning hangovers leave me feeling pissy

My Slashdot Spoof

> Have you tried to make zImage?

That's what modules and bzImage are for.

So do you think BeOS has a smaller memory resident kernel? I doubt it.

I use the RBL hooks in Postfix, and I find them very useful. This is a bit much, though. While I have enormous respect for Vix & co., I think this is way over the line.

How is software that is designed to send bulk email any "worse" than software that is designed explictly for the purpose of, say sniffing user passwords or performing denial-of-service attacks? Indeed, why aren't we, as the Internet community, tracking down those people arrogant enough to write these tools -- tools that are clearly used to commit all manner of subversion havoc -- and blackholing them?

It's because (most) technical people understand that tools are just tools. Somebody who writes a password grinder is "just" a programmer. The Unix admin who downloads it and runs it against her password file is just doing her job. The peeved help-desk guy who uses the password grinder to get the VP of Finance's Unix password and then uses it to access the nifty Oracle financial system is acting-- in the words of AUPs everywhere-- in excess of his authority, and if caught, will be squashed by the Law.

It's not valid to want it both ways, to want software that you think is "bad for the net" blackholed out of existence, yet allow other software -- arguably more damaging -- to exist unchallenged. If this was, say, WIPO vs. nmap, would those of you in favour of MAPS' stance take offense? Software is speech. Censor it and contribute to the decline of your freedom to write it. I'm sure the brains behind WIPO are very interested in seeing how this plays out; if an .org which essentially controls access to and from the large nationwide ISPs can succesfully censor software without question, then certainly WIPO can.

And finally: simply because MAPS says "These are our guidelines, and we are following them" doesn't mean the guidelines have merit.

I use the RBL hooks in Postfix, and I find them very useful. This is a bit much, though. While I have enormous respect for Vix & co., I think this is way over the line.

How is software that is designed to send bulk email any "worse" than software that is designed explictly for the purpose of, say sniffing user passwords or performing denial-of-service attacks? Indeed, why aren't we, as the Internet community, tracking down those people arrogant enough to write these tools -- tools that are clearly used to commit all manner of subversion havoc -- and blackholing them?

It's because (most) technical people understand that tools are just tools. Somebody who writes a password grinder is "just" a programmer. The Unix admin who downloads it and runs it against her password file is just doing her job. The peeved help-desk guy who uses the password grinder to get the VP of Finance's Unix password and then uses it to access the nifty Oracle financial system is acting-- in the words of AUPs everywhere-- in excess of his authority, and if caught, will be squashed by the Law.

It's not valid to want it both ways, to want software that you think is "bad for the net" blackholed out of existence, yet allow other software -- arguably more damaging -- to exist unchallenged. If this was, say, WIPO vs. nmap, would those of you in favour of MAPS' stance take offense? Software is speech. Censor it and contribute to the decline of your freedom to write it. I'm sure the brains behind WIPO are very interested in seeing how this plays out; if an .org which essentially controls access to and from the large nationwide ISPs can succesfully censor software without question, then certainly WIPO can.

And finally: simply because MAPS says "These are our guidelines, and we are following them" doesn't mean the guidelines have merit.

I don't know about anyone else, but I read Packetstorm regularly and I've never heard of any vulnerability that sounded like a programmer put it in there intentionally, unless they are talking about default passwords or vulnerabilities on internal DoD software.

If someone was more conspiratorial than me, they might conclude that this was just another ploy by the DoD to get more funding through public panic.

This will come off as a bit biased (which it is), but I work for a company that has written some software called Hailstorm that's very good at helping you test your own security. It's especially good in situations where you have written something custom, whether it be a CGI script or some sort of server program. It succeeds where security scanners fail, because it can help you find problems that are previously unknown. To see it in action analyzing IDS systems, check out the article at SecurityFocus. Good security consulting firms are VERY expenseive, so Hailstorm may be a good choice depending on what you are really looking for.

If you want to hire a security firm, I would suggest a few different companies: Securify, a division of Kroll-O'Gara; Guardent; Ernst & Young; @Stake; and Foundstone.

Also, if you are interested in trying out Hailstorm (which, for the time being, only runs on NT 4.0/W2K, although it can test applications on any OS), shoot me an email (removing the obvious part), and I'll help you out. A trial version can be downloaded at www.ClickToSecure.com.

If you are curious on what the FBI has on it's files regarding you make a FOIA request. They are obligated under law to provide you with your file unless it compromises national security or an impending investigation (which tells you almost as much as if you recieved it!) Packetstorm has the instructions at the URL below.

Getting your FBI file

-- Greg

I think this is silly, and can't wait to get my hands on the actually system. If what they say is true, its only a matter of time before censorship is enforced in evil ways. For instance, the author of the article states that, and I quote:

"Mechanisms are in place to detect if the content has been tampered with. The publishing process produces a special URL that is used to recover the data and the shares. The published content is cryptographically tied to the URL, so that any modification to the content or the URL results in the retriever being unable to find the information, or a failed verification. "

The Key words were "any modification to the content or the URL results in the retriever being unable to find the information". This tells me that if I wanted to hack into their system that I should focus on modifing the content, or rather the text file that is stored on the server.

The smallest deviation in the encrypted content will break the encryption as it is being decyphered by the respective keys.

Also, what about linking? I saw no mention of the effects of "deep linking" in the article anywhere. What I mean to say is that a site, say slashdot, might decide to link to an article on the Publius system. Do they intend to block all headers comeing from IP's that are non-Publius? They simply state that "content is cryptographically tied to the URL". What does that mean? Are they saying the url is dynamically generated by the Publius system with a changing key, or static but the keys are somehow encoded into the URL all the time, in a static way? Who knows.

That being said, would you want to even attempt to decypher the URL? Not me! Considering todays high-power cyrphtographic technologies, hacking the cypher is crazy(with todays best technology). However, methods to cause a system to grant root access by means of are available online the instant they are discovered. Typically the discovery is caused by a honey-pot system being hacked, and watching how they script-kiddies did it. Too late, your content is now being displayed as a bunch of garbage, and the root kit is being passed around the circles of wanna'be crackers. By the time packet storm shows how to proctect the system, hundreds of sites could be comprimised.

Now that might be a relitively short time frame from from hacked, to protected from. But still, the system could be hacked, and thats the bottom line.

I'm waitting for the formal anouncment. This is vaporware until then, just remember that! =)

Knowing the FBI, Carnivore is probably just running an outdated Mandrake distro with this crap piping into a file.
---

I would have to say that I view Slashdot not just as a discussion group but also as a new service.

It just happens that I am generally interested in a large fraction of most of the news articles pointed at by the /. community, a much larger fraction than lets say the news on either Rootprompt or Salon. It is in a happy medium between the technical and the real world where I like to be.

For this reason I view the comments to be more of a source of supplementary information. People who are in the know, or at least think they are chime in with extra info and links, and of course, opposing viewpoints on even the slightly objectionable points. Moderation generally takes care of the rest. In general I could care less about someone's opinion or a rant; I just want more infor and perhaps another viewpoint on the topic to facilitate making my own decisions on the issue.

Oh cr*p, I just made a huge rant about my opinion, and contributed no new information. Um... check out all these neat papers on security your Linux system. Whew, I think I saved myself from commiting a SIN.

like the top ten Baby Gates and Bill Gates similarities
so back to the top ten ten petty gripes microsoft has with the Justice Department

like the top ten Baby Gates and Bill Gates similarities
so back to the top ten ten petty gripes microsoft has with the Justice Department

http://www.cryptome.org
http://jya.com/crypto-free.htm
Learning About Cryptography
Ritter's Crypto Glossary and
Dictionary of Technical Cryptography
Encryption & Security Tutorial
N.A. Crypto Archives
International PGP site
NSA National Cryptologic Museum
EFF
attrition.org crypto archive
Bruce Schneier's Crypto-Gram

and last, but not least (the archive i developed) ....

PacketStorm Crypto Archives

there are lots and lots of excellent tutorials, docs, glossaries, and links to many of the great crypto sites in the world at all of the URLs above.

for the best info on NSA, ECHELON, misc paranoia, you should first check out Cryptome/JYA. i archived quite a bit of stuff related to your questions at the packetstorm site too - packetstorm.securify.com/crypt/nsa/.

feel free to email me directly if you like too. over the years, i have had some interesting experiences with the NSA, BXA, etc - primarily regarding my hosting of crypto archives, and personal investigations of NSA, ECHELON. if you want to discuss these things, get the pgp key for ken.williams@ey.com from www.keyserver.net, and send your key(s) and crypted msgs to tattooman@genocide2600.com

http://www.cryptome.org
http://jya.com/crypto-free.htm
Learning About Cryptography
Ritter's Crypto Glossary and
Dictionary of Technical Cryptography
Encryption & Security Tutorial
N.A. Crypto Archives
International PGP site
NSA National Cryptologic Museum
EFF
attrition.org crypto archive
Bruce Schneier's Crypto-Gram

and last, but not least (the archive i developed) ....

PacketStorm Crypto Archives

there are lots and lots of excellent tutorials, docs, glossaries, and links to many of the great crypto sites in the world at all of the URLs above.

for the best info on NSA, ECHELON, misc paranoia, you should first check out Cryptome/JYA. i archived quite a bit of stuff related to your questions at the packetstorm site too - packetstorm.securify.com/crypt/nsa/.

feel free to email me directly if you like too. over the years, i have had some interesting experiences with the NSA, BXA, etc - primarily regarding my hosting of crypto archives, and personal investigations of NSA, ECHELON. if you want to discuss these things, get the pgp key for ken.williams@ey.com from www.keyserver.net, and send your key(s) and crypted msgs to tattooman@genocide2600.com

better ideas and info can be found here:

http://packetstorm.securify.com/distri buted/

http://packetstorm.securify.com/pap ers/contest/

Make sure to check out the papers by Mixter, RFP, and Simple Nomad.

better ideas and info can be found here:

http://packetstorm.securify.com/distri buted/

http://packetstorm.securify.com/pap ers/contest/

Make sure to check out the papers by Mixter, RFP, and Simple Nomad.

better ideas and info can be found here:

http://packetstorm.securify.com/distri buted/

http://packetstorm.securify.com/pap ers/contest/

Make sure to check out the papers by Mixter, RFP, and Simple Nomad.

better ideas and info can be found here:

http://packetstorm.securify.com/distri buted/

http://packetstorm.securify.com/pap ers/contest/

Make sure to check out the papers by Mixter, RFP, and Simple Nomad.

better ideas and info can be found here:

http://packetstorm.securify.com/distri buted/

http://packetstorm.securify.com/pap ers/contest/

Make sure to check out the papers by Mixter, RFP, and Simple Nomad.

Packetstorm had a contest for papers regarding defense against DDOS attacks. These papers covered the territory fairly well, I think.

Packetstorm had a contest for papers regarding defense against DDOS attacks. These papers covered the territory fairly well, I think.

Heres another 'true story' doing the rounds, for more stories go to Unix Humour :

It's official: Microsoft SUCKs
Microsoft announced today its decision to formally abandon Java in favour of its new Simple Unified C++ Kit (SUCK). The name of the project, previously codenamed COOL, was changed to reflect Microsoft's new corporate image.
"We've decided to take a much more aggressive approach to software industry standards," said SUCK development spokesman Pout Tantrum.
"In the past, Microsoft has been extremely gracious and supportive of open industry protocols and standards, even when it challenged our desktop monopoly. And what did we get for it?
Lawsuits from Sun, the Department of Justice, and some tiny companies out in the boondocks that nobody's ever heard of.
Well, that's going to change. SUCK is 100% Microsoft invented, owned, patented and controlled.
It's our way of giving something back to the computing industry. A clear message saying, 'Up yours, Charlie, we're Microsoft.'"
SUCK is slated to replace VBA, VBScript, J++, C++, CMD.EXE shell, and 8086 assembler as Microsoft's official systems integration language, and will debut with the long-awaited Windows 2000.
In keeping with their new streamlined corporate philosophy, Microsoft will also launch a global saturation advertising campaign featuring the digitally-recreated likeness of J. Edgar Hoover wearing silk lingerie.

From the man page:

Auditd is part of the linux kernel auditing toolkit. It will capture auditing trails created by the kernel auditing facility from /proc/audit, filter them, and save them in specific log files. For the moment, auditd only supports the -t option, which enables audit trails timestamping. Other command line options will probably be implemented in the next releases to add more flexibility to the package.

Check here and scroll down or search for "auditd".

L0phtCrack, like many other software utilities, is a valuable tool. Like any other tool, it can be used for good or harm.

While it is not the case in this situation, it will be a sad day if mere possession of software is ever categorized as a crime.

At my job I am responsible for the security of a corporate network. What better way to ensure that we are relatively safe than to use the same tools that crackers will use to compromise our security?

Sites like SecurityFocus and PacketStorm are valuable resources for the full disclosure of security related issues. I hope we never lose legal access to tools because of their potential abuse.

Read bugtraq, visit packetstorm and Security Focus regularly. Keep an eye out for weird utilization on your box, read your logs, and make sure you have as much locked down as possible. If you don't need a service, don't run it.

The winning articles (all of em) are referenced at: http://packetstorm.securify.com/paper s/contest/ 'Mixter's' is found at: http://packetstorm.securify .com/papers/contest/Mixter.doc

The winning articles (all of em) are referenced at: http://packetstorm.securify.com/paper s/contest/ 'Mixter's' is found at: http://packetstorm.securify .com/papers/contest/Mixter.doc

It could have easily been defeated with a utility like Tripwire

NJV

an interesting discussion was recently held on packetstorm: http://packetstorm.securify.com/pap ers/contest/ ... read them.

1) stacheldraht"
2) trinoo
3) tfn tribe flood network
4) tfn2k
5) Cert's denial of service tools
Useful?

Don't forget the other following security references:

Cert: http://www.cert.org/

Packetstorm: http://packetstorm.securify.com/index.s html

and Attrition has some stuff too http://www.attrition.org/

Old news about tfn
Old news about trinoo

Old news about tfn
Old news about trinoo

it took so damned long not because a hack didn't exist (ProFTPd has been vulnerable for some time) but because the standard method used to crack the, a buffer overflow, probably wasn't written with PPC assembly in mind. most BO's out there are for x86, with a good number for SPARC, as well, but ony recently did some PPC shellcode (along with Alpha shell code) get put out in wide release. after the ProFTPd crack was well known, it became, unfortunately, more of an exercise of security through obscurity.

a link to a recent piece on PPC shellcode is at http://packetstorm.se curify.com/papers/unix/ppc.shellcode.txt. i just checked for proftpd exploits on packetstorm and found quite a few; the presence of a writable incoming/ directory helps a LOT.

so, it still took longer than most challenges out there, and that's why i like LinuxPPC for various servers. that and they're just damn fast.

IMO, some *much* better computer humor:

http://packetstorm.securify.com/unix-hu mor/

http://packetstorm.securify.com/

You won't find a /jp directory, though.

--