Damage: Level3 won't accept Cogent traffic. Horrible hack: tunnel BGP traffic to Level3 customer who masquerades requests as local traffic.
You don't need to masquerade anything, if you're connected to Level3 and Cogent, just configure your router to advertise your route to the Level3 network on the Cogent side and vice-versa.
Then watch your router melt under the hundreds of gigabits of traffic -- that you'll have to pay for both ways. Congratulation, you're the new peering agreement between Level3 and Cogent!
I'm pretty sure that the CIA's job these days is just to tell Bush whatever it is he wants to hear.
According to this New Yorker article, Bush and the CIA don't like each other. Bush basically made his own personal Intelligence Agency inside the Pentagon. The President pretends that this "task force" doesn't have to provide answers about their acts to Congress.
From the article:
The President has signed a series of findings and executive orders authorizing secret commando groups and other Special Forces units to conduct covert operations against suspected terrorist targets in as many as ten nations in the Middle East and South Asia.
The President's decision enables Rumsfeld to run the operations off the books--free from legal restrictions imposed on the C.I.A. Under current law, all C.I.A. covert activities overseas must be authorized by a Presidential finding and reported to the Senate and House intelligence committees. (The laws were enacted after a series of scandals in the nineteen-seventies involving C.I.A. domestic spying and attempted assassinations of foreign leaders.) "The Pentagon doesn't feel obligated to report any of this to Congress," the former high-level intelligence official said. "They don't even call it 'covert ops'--it's too close to the C.I.A. phrase. In their view, it's 'black reconnaissance.' They're not even going to tell the cincs"--the regional American military commanders-in-chief. (The Defense Department and the White House did not respond to requests for comment on this story.)
Here's a statement from Carl Hutzler, Director, AntiSpam Operations, America Online Mail Operations.
> We do welcome any statements directly from AOL or any network > operations group regarding their plans for Sender ID or CSV. However, > we ask that they respect the fact that this is a discussion list and be > prepared to answer any technical questions that may arise from their > statements. > > -andy, MARID co-chair
We remain committed to sender identity technologies.
We intend to begin beta testing SPF on our inbound systems very soon (weeks from now). SPF is low hanging fruit that will benefit AOL and many other domains although it will not work for 100% of the mail we receive. But it will work for >80% of the mail we receive and that is good enough for a first strike.
We also believe that the best way to secure the 822 FROM address is a content signing approach which is out of the scope of this working group. We hope to see a new group formed to tackle the issues in this arena. DomainKeys, IIM and TEOS are all reasonable technologies in this arena. We are sure their will be more which is a good thing for a working group:-)
We remain committed to other IP based approaches and see a lot of benefit to the "newer" CSV idea. AOL already gets >85% of our spam from other ISPs main outbound MTAs. SPF, SenderID, and Domainkeys will not change that as this mail also uses the legit domain of that local ISP in the 821/822 headers. CSV and certain best practice documents (BCPs) shift the responsibility to the sending organization for the mess they create through their insecure networks and insecure practices (like lack of SMTP AUTH of any form, lack of any outbound controls, inability to suspend accounts, insecure web servers, etc).
-Carl
-- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell
Andy posted a clarification on his statement, they are not dropping the MS patent...:-(
To: IETF MARID WG From: Andrew Newton Subject: Work plan for Sender ID Date: Mon, 13 Sep 2004 18:03:23 -0400
Due to the fact that we released statements in two separate messages, there seems to be some confusion on how we intend this working group to proceed on Sender ID.
First, the PRA document is not being dropped. Instead, we are proceeding with a document set that includes a non-encumbered (as far as we know) scope, "mailfrom", in addition to the "pra" scope. As we stated before, the objection to PRA is based on questions of deployment caused by incompatibilities with open source licenses. However, there were also a significant number for responses from participants stating that they had no such deployment issues.
Second, it does not make sense to discuss alternatives to PRA if those alternatives may be reasonably inferred to be covered by the patent application (though not necessarily the license) since this working group does not wish to discount Microsoft's patent application. And since we do not know the specific claims of the patent application, construction of such an alternative would need to take into account a few things we do know:
1. The patent application covers at least -core and -pra in combination. There is no reason to think that Microsoft's application is limited to the technology in these two drafts.
2. It does not cover MAIL FROM because this question has been specifically asked of Microsoft.
3. The algorithm in -pra has changed through multiple revisions of the draft(s). This would seem to at least exclude any scopes that use 2822 headers to identify the party most recently responsible for injecting the message.
1 No one pays for bounce mesgs - there's never a fee, just like today
How do you decide what's a bounce and what's not? AFAIK, the only thing that identifies a bounce is a null sender (MAIL FROM: <>). Spammers would just need to use that to bypass the system...
Good luck with that system, because it seems very complex, and ironing out all the details is going to take a very long time.
'd been thinking about this for years - having a "SQL" like file system
What I would like from SQL in a filesystem is the possibility to roll back:
> df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s9 37G 33G 4.0G 89%/ > rm -rf/ > df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s9 37G 0G 37G 0%/ > rollback rm -rf/ > df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s9 37G 33G 4.0G 89%/
Re:Going the way of the dinosaurs
on
Field Day 2004
·
· Score: 1
As an outsider, it seems to me that there's a connection between the lack of popularity of ham radio and the severe restrictions placed on what can be done with it.
For instance: sure, I can check my email over ham radio, but I'm not allowed to use encryption.
I've been following the work of the ARRL High Speed MultiMedia (HSMM) WorkGroup and they found a nice hole in the law. You can actually use encryption as long as you publish the key. If someone (the FCC) wants to listen to your broadcast, they only need to get a copy of the publicly available key. So what the workgroup proposes is to publish your WEP/IPSec key on an obscure web page and not tell anyone but your friends about it. If the FCC comes knocking on your door, give them the URL.
Granted, I'm not an American so maybe my perception is different, but the sight of nervous 19 year olds with M16s at Logan airport in late 2001 did not make me feel "protected".
Don't worry, I read in Bruce Scheiner's Beyond Fear that there are no bullets in the M16s, it would be way too dangerous. It's really just for the show.
Damn, the guys with these empty weapons must feel like complete morons.
I've read the article and I can't figure out what the test is. Does this mean that AOL is publishing SPF records (in which case it's old news) or does it mean that AOL is going to start rejecting incoming mail which fails the SPF tests?
So now AOL users are SOL if they want to use any of the large number of applications that send mail for you, such as all those "Mail this story to a friend" links, or tools like eVite which manage party invitations for you. And tons of other applications, many of them useful.
The idea behind Internet Mail 2000 [cr.yp.to] is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?
Because it's not backward compatible.
SPF is a simple and backward compatible solution to email forgeries. People who don't use it are still able to use email, while people who use it are protected against forgeries.
Everyone and their brother are reinvented email theses days without realising that you need to improve the existing email system. It's not possible to throw away the existing system.
Before looking at SPF you may want to read what Claus Assmann [theaimsgroup.com], and Wietse Venema [theaimsgroup.com] have to say on the subject.
You might also want to read what Steve Bellovin (one of the guys who invented USENET among other things) and Eric Raymond have to say about it. They spend a little more time understanding SPF...
We will need to colonize Mars! Here's what I propose:
General "Buck" Turgidson: Doctor, you mentioned the ratio of ten women to each man. Now, wouldn't that necessitate the abandonment of the so-called monogamous sexual relationship, I mean, as far as men were concerned?
Dr. Strangelove: Regrettably, yes. But it is, you know, a sacrifice required for the future of the human race. I hasten to add that since each man will be required to do prodigious... service along these lines, the women will have to be selected for their sexual characteristics which will have to be of a highly stimulating nature.
Ambassador de Sadesky: I must confess, you have an astonishingly good idea there, Doctor.
Well, I'm in Quebec and I'm subscribing to Videotron's cable modem services. They have three plans: 1) 128 Kbps for CAN$25/month (modem included) It has a 1 GB/month up down limit. 2) 3 Mbps down / 15 Kbps up for CAN$35/month (modem not included) It has a 10 GB/month down and 5 GB/month up limit. 3) 4 Mbps down / 30 Kbps up for CAN$60/month (modem not included). No usage limit.
Also, I think the messages should be stored on the relay, with just a URL sent in the mail body. It would solve two problems:
* The size of the message will be limited by the size of the sender's mailbox.
* It will use more resources on the relay, and the admin should be less likely to run an open relay.
This has allready been proposed by Dan Bernstein: IM2000
My old Supra FAX Modem 288 has a feature called "silent answer". When the phone rings, it listen to the line without answering it, if it hears a fax's beep beep beep it answers the call, otherwise it doesn't. That worked pretty well, but I'm not sure if Panther supports it.
Background The rsync team has received evidence that a vulnerability in rsync was recently used in combination with a Linux kernel vulnerability to compromise the security of a public rsync server. While the forensic evidence we have is incomplete, we have pieced together the most likely way that this attack was conducted and we are releasing this advisory as a result of our investigations to date.
Our conclusions are that:
rsync version 2.5.6 and earlier contains a heap overflow vulnerability that can be used to remotely run arbitrary code. While this heap overflow vulnerability could not be used by itself to obtain root access on a rsync server, it could be used in combination with the recently announced brk vulnerability in the Linux kernel to produce a full remote compromise. The server that was compromised was using a non-default rsyncd.conf option "use chroot = no". The use of this option made the attack on the compromised server considerably easier. A successful attack is almost certainly still possible without this option, but it would be much more difficult. Please note that this vulnerability only affects the use of rsync as a "rsync server". To see if you are running a rsync server you should use the netstat command to see if you are listening on TCP port 873. If you are not listening on TCP port 873 then you are not running a rsync server.
New rsync release In response we have released a new version of rsync, version 2.5.7. This is based on the current stable 2.5.6 release with only the changes necessary to prevent this heap overflow vulnerability. There are no new features in this release.
We recommend that anyone running a rsync server take the following steps:
Update to rsync version 2.5.7 immediately. If you are running a Linux kernel prior to version 2.4.23 then you should upgrade your kernel immediately. Note that some distribution vendors may have patched versions of the 2.4.x series kernel that fix the brk vulnerability in versions before 2.4.23. Check with your vendor security site to ensure that you are not vulnerable to the brk problem. Review your/etc/rsyncd.conf configuration file. If you are using the option "use chroot = no" then remove that line or change it to "use chroot = yes". If you find that you need that option for your rsync service then you should disable your rsync service until you have discussed a workaround with the rsync maintainers on the rsync mailing list. The disabling of the chroot option should not be needed for any normal rsync server. The patches and full source for rsync version 2.5.7 are available from http:// rsync.samba.org/ and mirror sites. We expect that vendors will produce updated packages for their distributions shortly.
Credits The rsync team would like to thank the following individuals for their assistance in investigating this vulnerability and producing this response:
Timo Sirainen Mike Warfield Paul Russell Andrea Barisani The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0962 to this issue.
I'm presently considering sending this letter to the IEEE. Let me know what you think.
-------- What is happening between the United States government and the IEEE reminds me of the events that occurred when Phil Zimmermann released his cryptographic software Pretty Good Privacy (PGP) in 1991.
Let me summarize the main events for those who did not follow this battle. The US law would consider cryptographic software as "munitions" and forbid its exportation out of the US or Canada. Similarly as the matter that oppose the US government and the IEEE, this law was put in place for - admittedly vague - national security reasons. Because of this law, PGP could not be exported out of the US. Two important actions were taken to fight this restriction. First, groups of people filed law suits opposing this law. In 1999, after many years of debate, the government changed the law to allow the exportation of cryptographic software out of the US, before a ruling could be made by a judge. The second action was taken before the law changed, PGP International (PGPi), an independent organism was created in Europe to legally distribute an "international" version of PGP. The PGPi web site is still available at pgpi.org. The PGPi group found a hole in the law that would permit the exportation of cryptographic code in the form of a book, so the people from PGP published a book containing the whole source code for the cryptographic program. In Europe, the book was scanned and passed in an Optical Character Recognition software to reconstruct the program. You can read more on the monumental task accomplished by PGPi to scan the PGP book at http://www.pgpi.org/pgpi/project/scanning/
I believe that the IEEE should take similar actions in the matter that is opposing it to the US government. First, it should take immediate legal action against the law in question. I am certain that lots of very good lawyers would be ready to work pro bono for this cause. Also, the IEEE should sponsor, or at least endorse, an independent web site or magazine that would publish the articles that are censored by this law. A short summary of the articles and a link to the web site could be printed in the Spectrum magazine each month.
I have read well written articles saying that the IEEE opposes to this law, but to this day, I have not seen action action by the IEEE that would show its dedication to this cause. It is my belief that actions similar to these would send a clear signal that the IEEE clearly opposes to this law and is ready to fight it in every way it legally can.
Slashdot Mirror
The Internet Health Report shows the interruption
Your link doesn't work, use http://www.internethealthreport.com/
Damage: Level3 won't accept Cogent traffic. Horrible hack: tunnel BGP traffic to Level3 customer who masquerades requests as local traffic.
You don't need to masquerade anything, if you're connected to Level3 and Cogent, just configure your router to advertise your route to the Level3 network on the Cogent side and vice-versa.
Then watch your router melt under the hundreds of gigabits of traffic -- that you'll have to pay for both ways. Congratulation, you're the new peering agreement between Level3 and Cogent!
94.5% of chicks dig guys who read porocrom.poromenos.org
But you are in the 5.5%!
(put an "Uncle Sam wants you" picture here)
BSD is for people who love UNIX.. Linux is for people who hate Windows.
and MacOS X is for people who get laid!
Alarm companies will sell you a monitored service to do just what you want. That's what we use.
That's what we use too. Best of all, if I don't answer the phone, they'll send the police over to cool down that server room!
I'm pretty sure that the CIA's job these days is just to tell Bush whatever it is he wants to hear.
According to this New Yorker article, Bush and the CIA don't like each other. Bush basically made his own personal Intelligence Agency inside the Pentagon. The President pretends that this "task force" doesn't have to provide answers about their acts to Congress.From the article:
Spare that poor server, use a mirror from Coral CDN
page 1 page 2 page 3 page 4 page 5 page 6 page 7 page 8 page 9
page 10 page 11 page 12 page 13 page 14 page 15 page 16 page 17 page 18 page 19 page 20
Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg04
Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg04
1 No one pays for bounce mesgs - there's never a fee, just like today
How do you decide what's a bounce and what's not? AFAIK, the only thing that identifies a bounce is a null sender (MAIL FROM: <>). Spammers would just need to use that to bypass the system...
Good luck with that system, because it seems very complex, and ironing out all the details is going to take a very long time.
'd been thinking about this for years - having a "SQL" like file system
What I would like from SQL in a filesystem is the possibility to roll back:
As an outsider, it seems to me that there's a connection between the lack of popularity of ham radio and the severe restrictions placed on what can be done with it. For instance: sure, I can check my email over ham radio, but I'm not allowed to use encryption.
I've been following the work of the ARRL High Speed MultiMedia (HSMM) WorkGroup and they found a nice hole in the law. You can actually use encryption as long as you publish the key. If someone (the FCC) wants to listen to your broadcast, they only need to get a copy of the publicly available key. So what the workgroup proposes is to publish your WEP/IPSec key on an obscure web page and not tell anyone but your friends about it. If the FCC comes knocking on your door, give them the URL.
Granted, I'm not an American so maybe my perception is different, but the sight of nervous 19 year olds with M16s at Logan airport in late 2001 did not make me feel "protected".
Don't worry, I read in Bruce Scheiner's Beyond Fear that there are no bullets in the M16s, it would be way too dangerous. It's really just for the show.
Damn, the guys with these empty weapons must feel like complete morons.
and at the end of the conference, they'll pretend that it's over and say:
and one more thing... we found life on Mars!
I've read the article and I can't figure out what the test is. Does this mean that AOL is publishing SPF records (in which case it's old news) or does it mean that AOL is going to start rejecting incoming mail which fails the SPF tests?
It's the old news.
So now AOL users are SOL if they want to use any of the large number of applications that send mail for you, such as all those "Mail this story to a friend" links, or tools like eVite which manage party invitations for you. And tons of other applications, many of them useful.
I've got 1 word for you: Sender Rewriting Scheme, well three words.
The idea behind Internet Mail 2000 [cr.yp.to] is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?
Because it's not backward compatible.
SPF is a simple and backward compatible solution to email forgeries. People who don't use it are still able to use email, while people who use it are protected against forgeries.
Everyone and their brother are reinvented email theses days without realising that you need to improve the existing email system. It's not possible to throw away the existing system.
Before looking at SPF you may want to read what Claus Assmann [theaimsgroup.com], and Wietse Venema [theaimsgroup.com] have to say on the subject.
You might also want to read what Steve Bellovin (one of the guys who invented USENET among other things) and Eric Raymond have to say about it. They spend a little more time understanding SPF...
Wired story with Raymond's comments.
Bellovin's comments in an email to the SPF mailing list.
We will need to colonize Mars! Here's what I propose:
General "Buck" Turgidson: Doctor, you mentioned the ratio of ten women to each man. Now, wouldn't that necessitate the abandonment of the so-called monogamous sexual relationship, I mean, as far as men were concerned?
Dr. Strangelove: Regrettably, yes. But it is, you know, a sacrifice required for the future of the human race. I hasten to add that since each man will be required to do prodigious... service along these lines, the women will have to be selected for their sexual characteristics which will have to be of a highly stimulating nature.
Ambassador de Sadesky: I must confess, you have an astonishingly good idea there, Doctor.
Well, I'm in Quebec and I'm subscribing to Videotron's cable modem services. They have three plans:
1) 128 Kbps for CAN$25/month (modem included) It has a 1 GB/month up down limit.
2) 3 Mbps down / 15 Kbps up for CAN$35/month (modem not included) It has a 10 GB/month down and 5 GB/month up limit.
3) 4 Mbps down / 30 Kbps up for CAN$60/month (modem not included). No usage limit.
This kernel received the codename: Angus; it should be refered to as "Kernel Angus," for example:
Daddy: Oh, watch out, Melinda! Once a woman is introduced to Kernel Angus, she'll settle for nothing less.
Melinda: Daddy, they say all the womenfolk just love Kernel Angus!
Daddy: Hmm.. I don't know why people make such a big fuss over Kernel Angus!
Miss Anabelle: I myself never much cared for Kernel Angus! He rubs me the wrong way. I'm not sure why.. can't put my finger on it..
Daddy: Kernel Angus is an acquired taste! Bedelia!
Props to Tina Fey for writing this great SNL skit.
(BTW, It's easier to catch the joke if you read it out loud...)
Also, I think the messages should be stored on the relay, with just a URL sent in the mail body. It would solve two problems: * The size of the message will be limited by the size of the sender's mailbox. * It will use more resources on the relay, and the admin should be less likely to run an open relay.
This has allready been proposed by Dan Bernstein: IM2000
My old Supra FAX Modem 288 has a feature called "silent answer". When the phone rings, it listen to the line without answering it, if it hears a fax's beep beep beep it answers the call, otherwise it doesn't. That worked pretty well, but I'm not sure if Panther supports it.
here the security advisory of rsync.samba.org:
/etc/rsyncd.conf configuration file. If you are using the option
rsync 2.5.6 security advisory
December 4th 2003
Background
The rsync team has received evidence that a vulnerability in rsync was
recently used in combination with a Linux kernel vulnerability to compromise
the security of a public rsync server. While the forensic evidence we have is
incomplete, we have pieced together the most likely way that this attack was
conducted and we are releasing this advisory as a result of our
investigations to date.
Our conclusions are that:
rsync version 2.5.6 and earlier contains a heap overflow vulnerability that
can be used to remotely run arbitrary code.
While this heap overflow vulnerability could not be used by itself to obtain
root access on a rsync server, it could be used in combination with the
recently announced brk vulnerability in the Linux kernel to produce a full
remote compromise.
The server that was compromised was using a non-default rsyncd.conf option
"use chroot = no". The use of this option made the attack on the compromised
server considerably easier. A successful attack is almost certainly still
possible without this option, but it would be much more difficult.
Please note that this vulnerability only affects the use of rsync as a "rsync
server". To see if you are running a rsync server you should use the netstat
command to see if you are listening on TCP port 873. If you are not listening
on TCP port 873 then you are not running a rsync server.
New rsync release
In response we have released a new version of rsync, version 2.5.7. This is
based on the current stable 2.5.6 release with only the changes necessary to
prevent this heap overflow vulnerability. There are no new features in this
release.
We recommend that anyone running a rsync server take the following steps:
Update to rsync version 2.5.7 immediately.
If you are running a Linux kernel prior to version 2.4.23 then you should
upgrade your kernel immediately. Note that some distribution vendors may have
patched versions of the 2.4.x series kernel that fix the brk vulnerability in
versions before 2.4.23. Check with your vendor security site to ensure that
you are not vulnerable to the brk problem.
Review your
"use chroot = no" then remove that line or change it to "use chroot = yes".
If you find that you need that option for your rsync service then you should
disable your rsync service until you have discussed a workaround with the
rsync maintainers on the rsync mailing list. The disabling of the chroot
option should not be needed for any normal rsync server.
The patches and full source for rsync version 2.5.7 are available from http://
rsync.samba.org/ and mirror sites. We expect that vendors will produce
updated packages for their distributions shortly.
Credits
The rsync team would like to thank the following individuals for their
assistance in investigating this vulnerability and producing this response:
Timo Sirainen
Mike Warfield
Paul Russell
Andrea Barisani
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0962 to this issue.
Regards,
The rsync team
I'm presently considering sending this letter to the IEEE. Let me know what you think.
--------
What is happening between the United States government and the IEEE reminds me of the events that occurred when Phil Zimmermann released his cryptographic software Pretty Good Privacy (PGP) in 1991.
Let me summarize the main events for those who did not follow this battle. The US law would consider cryptographic software as "munitions" and forbid its exportation out of the US or Canada. Similarly as the matter that oppose the US government and the IEEE, this law was put in place for - admittedly vague - national security reasons. Because of this law, PGP could not be exported out of the US. Two important actions were taken to fight this restriction. First, groups of people filed law suits opposing this law. In 1999, after many years of debate, the government changed the law to allow the exportation of cryptographic software out of the US, before a ruling could be made by a judge. The second action was taken before the law changed, PGP International (PGPi), an independent organism was created in Europe to legally distribute an "international" version of PGP. The PGPi web site is still available at pgpi.org. The PGPi group found a hole in the law that would permit the exportation of cryptographic code in the form of a book, so the people from PGP published a book containing the whole source code for the cryptographic program. In Europe, the book was scanned and passed in an Optical Character Recognition software to reconstruct the program. You can read more on the monumental task accomplished by PGPi to scan the PGP book at http://www.pgpi.org/pgpi/project/scanning/
I believe that the IEEE should take similar actions in the matter that is opposing it to the US government. First, it should take immediate legal action against the law in question. I am certain that lots of very good lawyers would be ready to work pro bono for this cause. Also, the IEEE should sponsor, or at least endorse, an independent web site or magazine that would publish the articles that are censored by this law. A short summary of the articles and a link to the web site could be printed in the Spectrum magazine each month.
I have read well written articles saying that the IEEE opposes to this law, but to this day, I have not seen action action by the IEEE that would show its dedication to this cause. It is my belief that actions similar to these would send a clear signal that the IEEE clearly opposes to this law and is ready to fight it in every way it legally can.
Actions speak louder than words.
Guillaume Filion, ing. jr
IEEE member