I woke up this morning, and all my cable modem lights were on as usual.
I just had to switch my firewall from a static IP address to instead use DHCP, and everything was dandy. The AT&T nameservers provided by DHCP work. What's weird is that they provided about fifty nameservers, and a bunch of them are 0.0.0.0. However, the first two work fine.
E-mail works, usenet works, everything! I'm very impressed, and very happy with AT&T's transition. Kudos to their network engineers!
--Bruce
P.S. The service is a bit slower. I am getting about 800Kbps max download speed. With @Home I often got over 1Mbps. Still, it sure beats dialup.
Yeah, I know that I have to give them my credit card and that makes my connection ultimately traceable through one means or another, but it's a far cry better than surfing directly through my ISP.
We accept all standard credit cards and money orders.
I work for Orangatango as a developer, and we care a great deal about the privacy of our users. We specifically offered the money order option so that subscribers could maintain the highest degree of anonymity possible.
Fedor G. Pikus, a member of the Portland Linux Unix Group, gave an excellent presentation on 1 Nov that's basically a detailed, step-by-step guide to creating an iptables-based firewall.
I haven't checked Handspring's web site for a few months. However, on recommendation of people here, I went there and download a new version of Palm Desktop. It installed easily, and my trouble are gone. The new software worked perfectly.
I've had no end of trouble trying to get my Handspring Visor with a USB cradle to sync under Windows 2000. It simply won't do it.
I've read their web site, e-mailed tech support (only to be given an un-helpful boilerplate document), and tried everything I can think of.
If anyone has gotten this to work, I'd love to know how.
--Bruce
(Handspring did replace my Visor when I dropped it and the screen broke--at their cost, via 2-day FedEx. I was quite happy about that.)
FlipDog helped me (and their technology is cool!)
on
Searching for Jobs Online?
·
· Score: 2, Interesting
When I went to college in fall of 2000, I decided to get a part-time job. I had worked for the previous year doing contract programming at a large chip company, and I had started my own small online (and profitable) business. However, I had just moved to a different city, and I didn't really know anyone who could get me a tech job.
I decided that an online search just might do the trick. Monster.com yielded nothing interesting, nor did HotJobs. As I was walking home from class one day I saw a billboard ad for FlipDog, and decided to try it.
After a quick and easy search focused down very specifically by city and job category, I found about four relevant jobs within three miles of my home. After a bit of resume touch-up, I e-mailed my resume to the interesting-looking employers. I received two e-mails back, one with an interview offer. I called the company and scheduled it for the next day.
In short, I had a job three days after my search on FlipDog.
As an aside to the story, FlipDog has some verycool technology developed at WhizBang! Labs. WhizBang! was headquartered in the same city that I attended school, and I got to go to a lecture about them. They have their web spiders crawl the web looking for job listings on companies' own sites. Then they use machine learning software to recognize and extract information (job title, location, description, etc.) from the free-form web page. That gets dumped into a database that FlipDog uses to help you find a job. Instead of making employers post available jobs on a special job site, FlipDog goes to the employers' own web sites and extracts job postings. Very cool. Check it out. (No, I'm not affiliated with them, except that they helped me find a job.)
You can get personal web server (at least under win9x) to play around on home machines...
Set up a linux box as a Samba server with Apache/PHP and get them to work in Notepad (or a better text editor) to create the files, save them to the server and test from IE/Mozilla/Opera/Whatever.
This implies that you can't run Apache and PHP on Windows. However, I've developed entire sites with Apache/PHP/MySQL on Windows, which were then deployed to Linux or FreeBSD machines. It's certainly possible, and not very difficult.
I did quite a bit of research about this very thing as I was setting up my company's mail server. Here's what I found out:
SSL support is very widespread in both SMTP servers and clients. Postfix, Sendmail, and Exim support it on the server end. Outlook Express, Outlook, and Mozilla support it on the client side. These lists are by no means exhaustive.
Many mail servers in use don't have encryption support turned on, thereby forcing you (who wants to use encryption) to either send your message in plaintext, not send it, or encrypt it with something like PGP.
SSL/TLS is not a good e-mail security solution even if both servers (sending and receiving) support and use it. Why? SSL (secure sockets layer) and TLS (transport level security) only encrypt the message while it's in transit, between the servers. However, SMTP is a store and forward system, and SSL/TLS only protects the "forward" part of it. The messages usually sit unencrypted on disk for anyone to view. Any intermediate person with access to a mail server can read a message, even if it was sent using SSL/TLS.
Although SMTP SSL/TLS isn't optimal for complete security, it is still useful. Transit security is better than no security at all.
I decided to implement a Postfix server at my company, and enabling SSL/TLS isn't hard at all. You just patch the source, compile, and tell Postfix where to find its certificates.
Why did I choose to use SMTP encryption when it has all of the drawbacks listed above? Two reasons:
Some security is better than none.
It protects passwords used to allow relaying (for legitimate company users).
You can set Postfix to:
Only talk to servers that have SSL enabled (thereby prevent a large part of the internet from sending you mail)
Use it when it's available but send even if it's not
Never use encryption.
(Each of these setting is independently "settable" for sending mail and receiving mail.)
In short, use PGP or similar if you need real security. SSL/TLS is only useful as an added protection.
CRU IDE Mirroring -- "The MiniRAID is an IDE RAID-1 mirroring "Intermediate Adapter". Once the MiniRAID is installed, it will automatically write all the data to both the "PRIMARY" drive and the "MIRROR" drive at the same time. It is completely transparent and requires no special commands to functions.
"
DupliDisk II -- "DupliDisk II features include:... fast RAID mirroring... plug-and-play installation... support for IDE, E-IDE and U/DMA drives... transparent system operation"
RHC-IDE-2R -- "... the RHC-IDE-2R mirrors data to two hard drives simultaneously... [and] is Host transparent and OS independent, no device driver is required."
ARAID 99-300 -- "The ARAID unit with hard drives acts as a single IDE disk. This product has the following benefits: No interface card or driver is required -- the unit simply plugs into the IDE bus chain.... There is no special management software required"
I'm sure you could find more with a few more minutes of searching. Next time try Google before Asking Slashdot.
The problem with this solution is that CGI programs run with the same privileges as the web server itself. In other words, anyone who can write a CGI/PHP/whatever script can view everyone else's file. A wrapper program is needed, not just semi-restrictive permissions settings.
Assuming that OS X is fairly similar to Unix, and assuming you have control over both the client and server, you could just set up a PPP session through an SSH tunnel with routing on both ends.
And when they are smart enough to circumvent my spying with encryption, anonymizers, and mixnets, then they have proved they are smart enough to handle whatever they may see...
You've missed one thing: a kid that is smart enough to use encryption, etc. is technically mature enough to view those things. However, they may or may not be socially/emotionally/whatever mature enough to view the same.
You're not preventing your kid from viewing those things just because they're "not smart enough" yet, are you?
Postfix is well-designed, small, high-performance, and very secure. I recently had to select a new mail server for our company, and it fit the bill perfectly.
There are a number of things that I like about Postfix, but one of the most noticable is its ease of configuration. There are just two configuration files, and they're very simple -- much simpler than even Apache's httpd.conf. One of the things that you can configure is relaying--for certain hosts, certain networks, or authenticated users.
We had to deal with a similar problem where I work recently. It's not exactly the same, because we have port 22 open on our firewall. However, we did figure out how to establish a secure tunnel that's not vulnerable to man-in-the-middle attacks.
One of my coworkers wrote up the following. He explains it very clearly, so I'll just post it verbatim. Enjoy!
Quoted message follows.
I got an interesting reply from Richard Silverman, who appears to do
work on SSH.
I figured that you guys might find this interesting, especially if you
are trying to set up a tunnel from home.
We thought we had it down, but NO! There is a better way!
Here's what we are trying to overcome, basically. AAA (home machine)
can see FFF (the firewall machine) but not BBB (the CVS server, or another
machine in the internal network).
AAA <--> FFF <--> BBB
We can tunnel into BBB from AAA using SSH using two tunnels, and that is
what I have been doing. Like this:
Note the loop (<>): FFF forwards all connections from AAA:2401 to
itself:5000. The SSH tunnel is actually the login itself, and any
traffic hitting port 2401 on AAA will pass straight through the tunnel,
coming out on FFF, which then forwards that traffic to itself, port
5000. Hence the 2401:localhost:5000 (the hostname is relevant to the
end of the tunnel, not the beginning of the tunnel).
STEP 2) FFF === BBB <>
Again, note the loop: The tunnel is now setup from FFF to BBB (the SSH
login) and BBB forwards all appropriate connections to itself:2401. So,
for all intents and purposes, if we access CVS as though it was on AAA,
it will really get it as though we were sitting at BBB.
This scenario presents a problem. The tunnel on FFF is wide open to
anyone to use, provided that they are actually ON FFF. There are
probably ways around this, but what, for example, if someone tries to
forward the same port once they have logged in to FFF? Further, what if
FFF is cracked and the tunnel is open? Problems for everyone.
Anyway, there is a way to do it that makes the tunnel secure from one
end to the other, with no loose ends hanging about and no possibility of
port conflicts in the middle:
# Log in to FFF (creating a tunnel from AAA to FFF)
# Forward all connections from AAA:7000 to BBB:22
# (a tunnelled SSL connection)
AAA% ssh -L 7000:BBB:22 FFF
# Now login to BBB by ssh'ing to localhost port 7000, and
# forward the port (to itself -- BBB could also be localhost):
AAA% ssh -L 2401:BBB:2401 -p 7000 localhost
This way the tunnel looks like this:
AAA---FFF BBB
AAA=======BBB
AAA---FFF BBB
Does that make sense? We now have a secure tunnel from AAA to FFF (the
--- marks), with connections on AAA:7000 being sent through the
tunnel, then forwarded to BBB:22, which is waiting to receive SSH
connections.
Then, we simply login to localhost port 7000 (from AAA!), which has the
effect of logging in to BBB (the === marks) over a standard SSH
connection. While we're at it, we forward the localhost port 2401 to be
BBB:2401. Now we have a TRULY secure tunnel from end-to-end that nobody
else can use! So, CVS connections destined for localhost on AAA will
actually get forwarded in a secure fashion all the way to BBB. I think
that's pretty darn cool.
Additionally, we are not compromising the server anymore than it was
before, because NO EXTRA PORTS have been opened on FFF. FFF just takes
the tail end of your SSH tunnel and forwards all of the appropriate
traffic to the SSH port on BBB. No extra ports open on FFF, and we
haven't really opened anything up on BBB, either. Everything is
connecting either to port 22 ( from the outside ) or to port 2401, from
the machine BBB itself! This means that we could actually disallow
connection to any port except SSH from outside of the machine, and still
gain access to all of its services.
Since the previous double-tunnel (outlined at
the beginning of this message) has this problem with port hijacking in
the middle, we should not use it anymore. Connections using secure
tunnels should be done in exactly the way that I have outlined. This
avoids potential security hazards and keeps us from treading on one
another's toes.
Orangatango, the company I work for, is working on web mobility and privacy. We've built a web browser that you can log into from anywhere on the internet. You then have access to all of your bookmarks, your cookies, and other settings. (It's free.)
Some of the features we provide:
Anonymous surfing (ala SafeWeb or Anonymizer)
Very, very cool spam protection that really works
Anonymous e-mail (check out my e-mail address above)
Web mobility (your settings, including bookmarks, follow you)
Cookie management (and selective blocking)
Although I work for Orangatango, I am posting this becuase the VirtualBrowser is so cool. It's fun to work on it, and we almost exclusively use open source products (Apache, mod_perl, Linux, etc). Our developers have even made open source contributions themselves.
If you're interested in privacy, anonymity, encrypted surfing, mobility, or spam prevention, I'd urge you to come on over and try us out (it's free).
Slashdot Mirror
There are already at least two programs that can translate between C and English:
--Bruce
I woke up this morning, and all my cable modem lights were on as usual.
I just had to switch my firewall from a static IP address to instead use DHCP, and everything was dandy. The AT&T nameservers provided by DHCP work. What's weird is that they provided about fifty nameservers, and a bunch of them are 0.0.0.0. However, the first two work fine.
E-mail works, usenet works, everything! I'm very impressed, and very happy with AT&T's transition. Kudos to their network engineers!
--Bruce
P.S. The service is a bit slower. I am getting about 800Kbps max download speed. With @Home I often got over 1Mbps. Still, it sure beats dialup.
Well, actually, Orangatango's signup page states:
I work for Orangatango as a developer, and we care a great deal about the privacy of our users. We specifically offered the money order option so that subscribers could maintain the highest degree of anonymity possible.
--Bruce
Fedor G. Pikus, a member of the Portland Linux Unix Group, gave an excellent presentation on 1 Nov that's basically a detailed, step-by-step guide to creating an iptables-based firewall.
The slides are available on his site.
--Bruce
Original poster here.
I haven't checked Handspring's web site for a few months. However, on recommendation of people here, I went there and download a new version of Palm Desktop. It installed easily, and my trouble are gone. The new software worked perfectly.
--Bruce
I've had no end of trouble trying to get my Handspring Visor with a USB cradle to sync under Windows 2000. It simply won't do it.
I've read their web site, e-mailed tech support (only to be given an un-helpful boilerplate document), and tried everything I can think of.
If anyone has gotten this to work, I'd love to know how.
--Bruce
(Handspring did replace my Visor when I dropped it and the screen broke--at their cost, via 2-day FedEx. I was quite happy about that.)
When I went to college in fall of 2000, I decided to get a part-time job. I had worked for the previous year doing contract programming at a large chip company, and I had started my own small online (and profitable) business. However, I had just moved to a different city, and I didn't really know anyone who could get me a tech job.
I decided that an online search just might do the trick. Monster.com yielded nothing interesting, nor did HotJobs. As I was walking home from class one day I saw a billboard ad for FlipDog, and decided to try it.
After a quick and easy search focused down very specifically by city and job category, I found about four relevant jobs within three miles of my home. After a bit of resume touch-up, I e-mailed my resume to the interesting-looking employers. I received two e-mails back, one with an interview offer. I called the company and scheduled it for the next day.
In short, I had a job three days after my search on FlipDog.
As an aside to the story, FlipDog has some very cool technology developed at WhizBang! Labs. WhizBang! was headquartered in the same city that I attended school, and I got to go to a lecture about them. They have their web spiders crawl the web looking for job listings on companies' own sites. Then they use machine learning software to recognize and extract information (job title, location, description, etc.) from the free-form web page. That gets dumped into a database that FlipDog uses to help you find a job. Instead of making employers post available jobs on a special job site, FlipDog goes to the employers' own web sites and extracts job postings. Very cool. Check it out. (No, I'm not affiliated with them, except that they helped me find a job.)
You can get personal web server (at least under win9x) to play around on home machines ...
Set up a linux box as a Samba server with Apache/PHP and get them to work in Notepad (or a better text editor) to create the files, save them to the server and test from IE/Mozilla/Opera/Whatever.
This implies that you can't run Apache and PHP on Windows. However, I've developed entire sites with Apache/PHP/MySQL on Windows, which were then deployed to Linux or FreeBSD machines. It's certainly possible, and not very difficult.
--Bruce
I did quite a bit of research about this very thing as I was setting up my company's mail server. Here's what I found out:
I decided to implement a Postfix server at my company, and enabling SSL/TLS isn't hard at all. You just patch the source, compile, and tell Postfix where to find its certificates.
Why did I choose to use SMTP encryption when it has all of the drawbacks listed above? Two reasons:
You can set Postfix to:
(Each of these setting is independently "settable" for sending mail and receiving mail.)
In short, use PGP or similar if you need real security. SSL/TLS is only useful as an added protection.
--BruceI did a Google search for transparent ide mirroring, and here are some links from the first page:
I'm sure you could find more with a few more minutes of searching. Next time try Google before Asking Slashdot.
The problem with this solution is that CGI programs run with the same privileges as the web server itself. In other words, anyone who can write a CGI/PHP/whatever script can view everyone else's file. A wrapper program is needed, not just semi-restrictive permissions settings.
Check the Linux VPN HOWTO for details.
You've missed one thing: a kid that is smart enough to use encryption, etc. is technically mature enough to view those things. However, they may or may not be socially/emotionally/whatever mature enough to view the same.
You're not preventing your kid from viewing those things just because they're "not smart enough" yet, are you?
Postfix is well-designed, small, high-performance, and very secure. I recently had to select a new mail server for our company, and it fit the bill perfectly.
There are a number of things that I like about Postfix, but one of the most noticable is its ease of configuration. There are just two configuration files, and they're very simple -- much simpler than even Apache's httpd.conf. One of the things that you can configure is relaying--for certain hosts, certain networks, or authenticated users.
For mailbox services, I would recommend Cyrus (http://asg.web.cmu.edu/cyrus/imapd/ ). It's a very full-featured POP3/IMAP/KPOP server.
There are webmin modules for both Postfix and Cyrus, solving your web-based management problem.
We had to deal with a similar problem where I work recently. It's not exactly the same, because we have port 22 open on our firewall. However, we did figure out how to establish a secure tunnel that's not vulnerable to man-in-the-middle attacks.
One of my coworkers wrote up the following. He explains it very clearly, so I'll just post it verbatim. Enjoy!
Quoted message follows.
I got an interesting reply from Richard Silverman, who appears to do
work on SSH.
I figured that you guys might find this interesting, especially if you
are trying to set up a tunnel from home.
We thought we had it down, but NO! There is a better way!
Here's what we are trying to overcome, basically. AAA (home machine)
can see FFF (the firewall machine) but not BBB (the CVS server, or another
machine in the internal network).
AAA <--> FFF <--> BBB
We can tunnel into BBB from AAA using SSH using two tunnels, and that is
what I have been doing. Like this:
AAA ==1== FFF ==2== BBB
And we set it up something like this:
STEP 1: AAA% ssh -L 2401:localhost:5000 FFF
STEP 2: FFF% ssh -L 5000:localhost:2401 BBB
What this does is the following:
STEP 1) AAA === FFF <>
Note the loop (<>): FFF forwards all connections from AAA:2401 to
itself:5000. The SSH tunnel is actually the login itself, and any
traffic hitting port 2401 on AAA will pass straight through the tunnel,
coming out on FFF, which then forwards that traffic to itself, port
5000. Hence the 2401:localhost:5000 (the hostname is relevant to the
end of the tunnel, not the beginning of the tunnel).
STEP 2) FFF === BBB <>
Again, note the loop: The tunnel is now setup from FFF to BBB (the SSH
login) and BBB forwards all appropriate connections to itself:2401. So,
for all intents and purposes, if we access CVS as though it was on AAA,
it will really get it as though we were sitting at BBB.
This scenario presents a problem. The tunnel on FFF is wide open to
anyone to use, provided that they are actually ON FFF. There are
probably ways around this, but what, for example, if someone tries to
forward the same port once they have logged in to FFF? Further, what if
FFF is cracked and the tunnel is open? Problems for everyone.
Anyway, there is a way to do it that makes the tunnel secure from one
end to the other, with no loose ends hanging about and no possibility of
port conflicts in the middle:
# Log in to FFF (creating a tunnel from AAA to FFF)
# Forward all connections from AAA:7000 to BBB:22
# (a tunnelled SSL connection)
AAA% ssh -L 7000:BBB:22 FFF
# Now login to BBB by ssh'ing to localhost port 7000, and
# forward the port (to itself -- BBB could also be localhost):
AAA% ssh -L 2401:BBB:2401 -p 7000 localhost
This way the tunnel looks like this:
AAA---FFF BBB
AAA=======BBB
AAA---FFF BBB
Does that make sense? We now have a secure tunnel from AAA to FFF (the
--- marks), with connections on AAA:7000 being sent through the
tunnel, then forwarded to BBB:22, which is waiting to receive SSH
connections.
Then, we simply login to localhost port 7000 (from AAA!), which has the
effect of logging in to BBB (the === marks) over a standard SSH
connection. While we're at it, we forward the localhost port 2401 to be
BBB:2401. Now we have a TRULY secure tunnel from end-to-end that nobody
else can use! So, CVS connections destined for localhost on AAA will
actually get forwarded in a secure fashion all the way to BBB. I think
that's pretty darn cool.
Additionally, we are not compromising the server anymore than it was
before, because NO EXTRA PORTS have been opened on FFF. FFF just takes
the tail end of your SSH tunnel and forwards all of the appropriate
traffic to the SSH port on BBB. No extra ports open on FFF, and we
haven't really opened anything up on BBB, either. Everything is
connecting either to port 22 ( from the outside ) or to port 2401, from
the machine BBB itself! This means that we could actually disallow
connection to any port except SSH from outside of the machine, and still
gain access to all of its services.
Since the previous double-tunnel (outlined at
the beginning of this message) has this problem with port hijacking in
the middle, we should not use it anymore. Connections using secure
tunnels should be done in exactly the way that I have outlined. This
avoids potential security hazards and keeps us from treading on one
another's toes.
(shameless plug, but very relevant)
Orangatango, the company I work for, is working on web mobility and privacy. We've built a web browser that you can log into from anywhere on the internet. You then have access to all of your bookmarks, your cookies, and other settings. (It's free.)
Some of the features we provide:
Although I work for Orangatango, I am posting this becuase the VirtualBrowser is so cool. It's fun to work on it, and we almost exclusively use open source products (Apache, mod_perl, Linux, etc). Our developers have even made open source contributions themselves.
If you're interested in privacy, anonymity, encrypted surfing, mobility, or spam prevention, I'd urge you to come on over and try us out (it's free).