Your understanding of Sun Enterprise class systems is clearly lacking, as is your understanding of production level networks.
Scanning for data in real time when you're looking at several near-full gigabit lines isn't exactly trival, and the more keywords to search on, the harder it gets.
The advantage of a Sun system with a fair number of CPUs is that each IO board can have dedicated CPUs handling it to make sure that the process that's doing the work never blocks waiting for IO, CPU or both (remember kids, handling IO requires cycles, and blocking on CPU is bad when you're trying for soft realtime).
Of course, there are other problems as well. The network card drivers have to be able to keep up (remember kids, that needs CPU cycles as well). You have to watch that the system is balanced in terms of how fast you write IO to memory, and how fast you process what's in memory and flush it to disk (gee Billy, that takes CPU as well).
In short, if you're just grepping through mail spools, you're more likely to be disk IO bound, though there are high-end tricks for getting around that by making it more CPU bound, and adding more CPUs. If you're decoding packets in real-time off the wire on multiple gigabit networks, you're bound to network IO, which is bound to the CPUs.
From what I've heard, at best the FBI's infamous surveillance equipment is an x86 system, and most likely won't have more than 8 cpus in it (if that).
The kind of firepower that a major ISP can throw at a problem of this nature can include 64-cpu Sun Enterprise class computers with gigabit ethernet cards connected to every mail network that the ISP has.
If said ISP is commited to not having other people's machines connected to it's internal networks, the ISP can provide a lot heavier duty monitoring firepower than anyone else.
In the bit about importing the X.509 certificate after you export it from Netscape in pkcs12 format, the command for importing it should read: "openssl pkcs12 -in netscape.p12 -out temp.certs".
That little typo of "-i" rather than "-in" is a touch embarassing.
Just a quick bit I put together; don't blame me if it doesn't work right for you.:)
This only works for UNIX/Linux, it assumes that you have OpenSSL installed in/usr/local/ssl, and assumes that you've got Pine setup already.
Do these things (and do 'em the way I did 'em) and you'll end up with a Pine that can send S/MIME signed messages, and S/MIME signed+encrypted messages. As for decoding messages, for the moment, export them to a file, strip off the mail headers, and manually decrypt them with openssl. More directions on that later in the post.
- Fire up Netscape or Internet Explorer. My Mozilla nightly from 01/09/2001 couldn't handle this.
- Go to www.thawte.com and sign up for their FreeMail service. You'll end up with a valid, signed by a known CA X.509 certificate.
- When the process of creating your certificate with Thawte asks what kind of certificate you want, choose "Netscape".
- You'll go through a song and dance with Thawte, eventually, you'll have the option to import your X.509 certificate into Netscape. Do it.
- Once the X.509 cert is imported into Netscape, bring up the Security Info window, click into the box to look at "Your Certs", and export your FreeMail cert to a file.
- Use OpenSSL to get the cert out of the pkcs12 format that Netscape saved it in. If you saved the X.509 cert as "netscape.p12" something like.. "/usr/local/ssl/bin/openssl pkcs12 -i netscape.p12 -out temp.certs" would be a good command to try.
- Break the temp.certs file into four parts
* Private Key [save as private.cert]
* Thawte FreeMail Key [save as thawte.cert]
* Thawte Root CA Key [don't save, just toss it]
* Public Key (the one with your email addy) [save as public.cert]
In temp.certs you should see the Private Key first, then the Thawte FreeMail Key, then Thawte Root CA, and finally your Public Key.
- chmod *.cert to something safe. -r-------- might be good.
- Make a.ssl directory in your home directory, and chmod it to something safe. "mkdir ~/.ssl; chmod go-rwx ~/.ssl" might be useful.
- Su up to root.
- Create a shell script named smime-sign.sh in/usr/local/bin, and chmod ugo+x it. The source for smime-sign.sh is later in this post.
- Create a shell script named smime-sign+enc.sh in/usr/local/bin and chmod ugo+x it. The source for smime-sign+enc.sh is later in this post.
- Log out of root.
- Fire up Pine, go into Setup, then Configure.
- Find the "sending-filters" option.
- Create a sending filter that reads "/usr/local/bin/smime-sign+enc.sh _TMPFILE_ _RECIPIENTS_"
- Create another sending filter that reads "/usr/local/bin/smime-sign.sh _TMPFILE_"
- And done!
- Note, you *must* put the public keys of anyone you want to send email to into files in the.ssl directory in your home directory before you can send encrypted email to them.
- Note, these scripts have only been tested on SuSE Linux 6.4, and I have nasty idea that/bin/sh may really be bash rather than bourne shell in SuSE. Syntax in the scripts may have to be updated for use with a real bourne shell.
- Note, you can only send encrypted email to one person at a time using the smime-sign+enc.sh script. If anyone wants to fix that, feel free.
- Decrypting mail that was sent to you encrypted would use a command something like this (if you exported the email to temp.crypt): "openssl smime -decrypt -in temp.crypt -inkey.ssl/private.cert -recip.ssl/public.cert > temp.plaintext"
- For notes on verifying mail that was sent to you, try www.kfu.com/~nsayer/encryption/openssl.html and look near the bottom of the page.
"When battles can be won or lost with the push of a button, both victory and defeat become miserable."
The more automated war becomes, the less that the human aspects of compassion, remorse and civility will come into play. Wars that lack compassion, regret for the lost souls, and civility towards the enemy give rise to massaceres, and wars become tragadies.
A machine will never see the death, and be able to mourn for the lost.
That's not to say that I feel the current world situation reflects wonderful amounts of civility and compassion in war, but social issues on that level are rather outside the scope of this particular post.
----------
- Does Katz actually think about this stuff before he posts?
I'm of two minds about MAPS. On one hand, the service they provide to the community is valuable. On the other hand, I've had first-hand experience with why some people have said that MAPS is starting to abuse it's position. They aren't always the most understanding about situations which will take time to resolve.
That being said, the idea behind MAPS is a Good Thing (tm), and in my mind, they are far less abusive of their position than ORBS is.
Another good way of handling spam is Brightmail. They have a wonderful system for filtering spam out of POP3 accounts. I've been working with Brightmail on various levels for about four months now and have yet to see them mark a "real" message as spam. Single user Brightmail acounts are free, by the way.
While all this sounds quite impressive to the uneducated, this really comes down to a mix of things that could be done in the UNIX world with a combination of nmap, netcat and forcing anyone who you want to scan to connect to your web server.
If someone really saw a need to do this, all that would really be needed would be Apache with a custom module as the web server (having the scanee connect to your web server is what gives you one of the paths back through NAT firewalls), some nifty perl scripts to control netcat (to generate the "hand-crafted" packets and record the results), and maybe a nice MySQL || DB2 || whatever database on the back end for long term storage of your results.
Heck, with a custom Apache module and a database on the backend, you could set a cookie in the scanee's browser so that you could automagically let the scanee pull up the results of the last few scans you did on on him.
The summary: I feel for anyone who has spent that much time coding custom TCP stacks, custom webservers, and custom who knows what else in ASM, just to do what perl, apache, a bit of C++, a simple DB and netcat could do. What I feel for such a person will remain unstated.
--------------------------------
There is no backbone cabal.
According to ARIN, it's in the Michigan State Government's net block. Unless this is someone having a happy time on the State's servers, or an trigger happy State person, it's legit.
Direct Democracy isn't the reality that
American citizens are dealing with. For various reasons, a representative democracy is the way that the US works.
It would be correct in a direct democracy to say that the American population is entirely to blame for it's troubles. Unfortanately, with a representative democracy, there's not much choice.
:reflectively: Of course, a direct democracy has it's troubles as well. It doesn't always scale well, it takes money to get noticed by enough people to form a majority, and there's always the danger that you'll elect a rutabaga farmer. (That's a joke son.)
If you do happen to be an EarthLink user, Spaminator will do fairly good spam filtering for you. I've been using the system since about 8 hours after EarthLink brought it online, and it's never sidelined any email that wasn't real spam.
Also, in regards to the main subject: That wasn't a press release there. No names, no real quotes. That leads me to believe that it may not be "official".
First, AntiOnline as others have mentioned has a nasty reputation. I'm sure that the IP of anyone even viewing a web page on a host in that network is logged.
Second, has anyone heard anything from the LinuxPPC folks confirming this? *I* certainly haven't, and as of the time of this posting, crack.linuxppc.org has no announcement about the box moving to AntiOnline's network. Until I see something offical from the LinuxPPC folks, I'm writing this off as another attempted publicity stunt by AntiOnline.
Slashdot Mirror
Your understanding of Sun Enterprise class systems is clearly lacking, as is your understanding of production level networks.
Scanning for data in real time when you're looking at several near-full gigabit lines isn't exactly trival, and the more keywords to search on, the harder it gets.
The advantage of a Sun system with a fair number of CPUs is that each IO board can have dedicated CPUs handling it to make sure that the process that's doing the work never blocks waiting for IO, CPU or both (remember kids, handling IO requires cycles, and blocking on CPU is bad when you're trying for soft realtime).
Of course, there are other problems as well. The network card drivers have to be able to keep up (remember kids, that needs CPU cycles as well). You have to watch that the system is balanced in terms of how fast you write IO to memory, and how fast you process what's in memory and flush it to disk (gee Billy, that takes CPU as well).
In short, if you're just grepping through mail spools, you're more likely to be disk IO bound, though there are high-end tricks for getting around that by making it more CPU bound, and adding more CPUs. If you're decoding packets in real-time off the wire on multiple gigabit networks, you're bound to network IO, which is bound to the CPUs.
From what I've heard, at best the FBI's infamous surveillance equipment is an x86 system, and most likely won't have more than 8 cpus in it (if that).
The kind of firepower that a major ISP can throw at a problem of this nature can include 64-cpu Sun Enterprise class computers with gigabit ethernet cards connected to every mail network that the ISP has.
If said ISP is commited to not having other people's machines connected to it's internal networks, the ISP can provide a lot heavier duty monitoring firepower than anyone else.
Pardon my typo, please...
In the bit about importing the X.509 certificate after you export it from Netscape in pkcs12 format, the command for importing it should read: "openssl pkcs12 -in netscape.p12 -out temp.certs".
That little typo of "-i" rather than "-in" is a touch embarassing.
Just a quick bit I put together; don't blame me if it doesn't work right for you. :)
/usr/local/ssl, and assumes that you've got Pine setup already.
.ssl directory in your home directory, and chmod it to something safe. "mkdir ~/.ssl; chmod go-rwx ~/.ssl" might be useful.
/usr/local/bin, and chmod ugo+x it. The source for smime-sign.sh is later in this post.
/usr/local/bin and chmod ugo+x it. The source for smime-sign+enc.sh is later in this post.
.ssl directory in your home directory before you can send encrypted email to them.
/bin/sh may really be bash rather than bourne shell in SuSE. Syntax in the scripts may have to be updated for use with a real bourne shell.
.ssl/private.cert -recip .ssl/public.cert > temp.plaintext"
;)
This only works for UNIX/Linux, it assumes that you have OpenSSL installed in
Do these things (and do 'em the way I did 'em) and you'll end up with a Pine that can send S/MIME signed messages, and S/MIME signed+encrypted messages. As for decoding messages, for the moment, export them to a file, strip off the mail headers, and manually decrypt them with openssl. More directions on that later in the post.
- Fire up Netscape or Internet Explorer. My Mozilla nightly from 01/09/2001 couldn't handle this.
- Go to www.thawte.com and sign up for their FreeMail service. You'll end up with a valid, signed by a known CA X.509 certificate.
- When the process of creating your certificate with Thawte asks what kind of certificate you want, choose "Netscape".
- You'll go through a song and dance with Thawte, eventually, you'll have the option to import your X.509 certificate into Netscape. Do it.
- Once the X.509 cert is imported into Netscape, bring up the Security Info window, click into the box to look at "Your Certs", and export your FreeMail cert to a file.
- Use OpenSSL to get the cert out of the pkcs12 format that Netscape saved it in. If you saved the X.509 cert as "netscape.p12" something like.. "/usr/local/ssl/bin/openssl pkcs12 -i netscape.p12 -out temp.certs" would be a good command to try.
- Break the temp.certs file into four parts
* Private Key [save as private.cert]
* Thawte FreeMail Key [save as thawte.cert]
* Thawte Root CA Key [don't save, just toss it]
* Public Key (the one with your email addy) [save as public.cert]
In temp.certs you should see the Private Key first, then the Thawte FreeMail Key, then Thawte Root CA, and finally your Public Key.
- chmod *.cert to something safe. -r-------- might be good.
- Make a
- Su up to root.
- Create a shell script named smime-sign.sh in
- Create a shell script named smime-sign+enc.sh in
- Log out of root.
- Fire up Pine, go into Setup, then Configure.
- Find the "sending-filters" option.
- Create a sending filter that reads "/usr/local/bin/smime-sign+enc.sh _TMPFILE_ _RECIPIENTS_"
- Create another sending filter that reads "/usr/local/bin/smime-sign.sh _TMPFILE_"
- And done!
- Note, you *must* put the public keys of anyone you want to send email to into files in the
- Note, these scripts have only been tested on SuSE Linux 6.4, and I have nasty idea that
- Note, you can only send encrypted email to one person at a time using the smime-sign+enc.sh script. If anyone wants to fix that, feel free.
- Decrypting mail that was sent to you encrypted would use a command something like this (if you exported the email to temp.crypt): "openssl smime -decrypt -in temp.crypt -inkey
- For notes on verifying mail that was sent to you, try www.kfu.com/~nsayer/encryption/openssl.html and look near the bottom of the page.
Scripts:
smime-sign.sh
#!/bin/sh
user=`whoami`
tmpfile="$1"
certdir="/home/$user/.ssl"
sslbin="/usr/local/ssl/bin"
$sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile > $tempfile.signed
mv $tmpfile.signed $tmpfile
exit 0
--
smime-sign+enc.sh
#!/bin/sh
tmpfile="$1"
if [ ! $# = 2 ]; then
rm $tmpfile
exit 1
fi
user=`whoami`
certdir="/home/$user/.ssl"
sslbin="/usr/local/ssl/bin"
error=0
recipients=`echo $* | sed "s,$tmpfile,,g"`
recipentcerts=`for r in $recipients; do
cd $certdir
grep -l $r *
if [ $? = 1 ]; then
return 1
fi
done`
if [ $? = 1 ]; then
rm $tmpfile
exit 1
fi
$sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile | $sslbin/openssl smime -encrypt $certdir/$recipientcerts > $tmpfile.signed
mv $tmpfile.signed $tempfile
exit 0
Please consider all code to be firmly under the GPL v2 license. (www.gnu.org/copyleft/gpl.html)
Notes: I only gave this brief testing - there may be a few bugs, particularly in the error handling.
That's all folks!
You can email glorian@eudoramail.com with questions, compliments, praise, etc, but I don't promise replies.
"When battles can be won or lost with the push of a button, both victory and defeat become miserable."
The more automated war becomes, the less that the human aspects of compassion, remorse and civility will come into play. Wars that lack compassion, regret for the lost souls, and civility towards the enemy give rise to massaceres, and wars become tragadies.
A machine will never see the death, and be able to mourn for the lost.
That's not to say that I feel the current world situation reflects wonderful amounts of civility and compassion in war, but social issues on that level are rather outside the scope of this particular post.
----------
- Does Katz actually think about this stuff before he posts?
I'm of two minds about MAPS. On one hand, the service they provide to the community is valuable. On the other hand, I've had first-hand experience with why some people have said that MAPS is starting to abuse it's position. They aren't always the most understanding about situations which will take time to resolve.
That being said, the idea behind MAPS is a Good Thing (tm), and in my mind, they are far less abusive of their position than ORBS is.
Another good way of handling spam is Brightmail. They have a wonderful system for filtering spam out of POP3 accounts. I've been working with Brightmail on various levels for about four months now and have yet to see them mark a "real" message as spam. Single user Brightmail acounts are free, by the way.
-------
All opinions stated are my personal opinions.
Mini-review states:
While all this sounds quite impressive to the uneducated, this really comes down to a mix of things that could be done in the UNIX world with a combination of nmap, netcat and forcing anyone who you want to scan to connect to your web server.
If someone really saw a need to do this, all that would really be needed would be Apache with a custom module as the web server (having the scanee connect to your web server is what gives you one of the paths back through NAT firewalls), some nifty perl scripts to control netcat (to generate the "hand-crafted" packets and record the results), and maybe a nice MySQL || DB2 || whatever database on the back end for long term storage of your results.
Heck, with a custom Apache module and a database on the backend, you could set a cookie in the scanee's browser so that you could automagically let the scanee pull up the results of the last few scans you did on on him.
The summary: I feel for anyone who has spent that much time coding custom TCP stacks, custom webservers, and custom who knows what else in ASM, just to do what perl, apache, a bit of C++, a simple DB and netcat could do. What I feel for such a person will remain unstated.
--------------------------------
There is no backbone cabal.
Name: www.ag.state.mi.us
Address: 167.240.254.37
According to ARIN, it's in the Michigan State Government's net block. Unless this is someone having a happy time on the State's servers, or an trigger happy State person, it's legit.
Direct Democracy isn't the reality that American citizens are dealing with. For various reasons, a representative democracy is the way that the US works.
It would be correct in a direct democracy to say that the American population is entirely to blame for it's troubles. Unfortanately, with a representative democracy, there's not much choice.
:reflectively: Of course, a direct democracy has it's troubles as well. It doesn't always scale well, it takes money to get noticed by enough people to form a majority, and there's always the danger that you'll elect a rutabaga farmer. (That's a joke son.)
"Always count on the power of human stupidity." and "There's a sucker born every day." These seem to be the motto spammers live by.
Sometimes the fact that spam does make profit based on these ideas leaves me rather disappointed in humanity.
Somewhat off the main topic, but interesting.
If you do happen to be an EarthLink user, Spaminator will do fairly good spam filtering for you. I've been using the system since about 8 hours after EarthLink brought it online, and it's never sidelined any email that wasn't real spam.
Also, in regards to the main subject: That wasn't a press release there. No names, no real quotes. That leads me to believe that it may not be "official".
This comes on the same day that Cnet (yes, such high quality information) stated that "Emergency services still lag in Y2K preparations".
A few comments:
First, AntiOnline as others have mentioned has a nasty reputation. I'm sure that the IP of anyone even viewing a web page on a host in that network is logged.
Second, has anyone heard anything from the LinuxPPC folks confirming this? *I* certainly haven't, and as of the time of this posting, crack.linuxppc.org has no announcement about the box moving to AntiOnline's network. Until I see something offical from the LinuxPPC folks, I'm writing this off as another attempted publicity stunt by AntiOnline.