Have you looked at Websense? How evil it is depends on how you deploy it. For a while I was using the eval version on my home Squid cache to asist in blocking porn site popups while not preventing intentional porn surfing. Not bad for censorware.
"...offering users a choice of viewing a site and having it logged, or not viewing it"
This may sound like quite an elegant solution, especially compared to the outright blocking of sites not recognised by their master database but this could well end up creating a far more dangerous climate of self-censorship.
But in an office enviroment, this may be exactly what you want to have!
Many an enlightened employer has put in an unrestricted DS3 connection for the office and expected that the employees will do the right thing (call it self-censorship, call it responsibility, whatever), only to start reviewing usage reports and discover that the sites that get hit most often are autopr0n and QuietSurfer.
Thus the need for a censorware product (such as websense) that let's employees continue to access the sites they need to get their job done, without hurting productivity as would happen if questionable sites were just blocked with no option to "click through".
For instance, if a perfectly legimate but not "mainstream" site, say an anti-war one, hasn't yet made it onto their database, you have to accept that your boss will be notified of your visit and made aware of your doubts about the government.
And what exactly are you doing accessing this site from work, using the shareholder's computer and bandwidth?
If you can justify how your visiting this "perfectly legitimate but not mainstream site" serves to maximize shareholder value, then you should not have anything to fear from your boss.
In that situation, most people will just give up and put the corporate propaganda feed-pipe back in their mouths.
Or just wait until you go home and access the "Dean for President" site on your own time.
I wonder if someone will come up with "reverse dictionary attacks". That is, generate random combinations of letters, numbers, and symbols, and then discard all the dictionary words, words with 1 digits, repeated letters, proper names, words with substituted digits, etc. Make the password policy strict enough, and at some point this might become faster than a dictionary attack on a system without so many rules.
Sounds like a good topic for a paper, assuming you have the patience to sit down and work out all of the math.
Otherwise, it just sounds like a demonstration of the "law of diminishing returns".
... it makes mroe sense to use a system where part of the password is static, set by the user and changed by the user, and the other part of the password changes every 60 seconds. You carry a token around and that token is sync'd to your auth server. only you know the static part of the password and only the token and the auth server know what the shifting password is from one minute to the next.
Like, say, SecurID!
Like say, patent ifringement.
The RSA SecurID time-based tokens are covered by US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
Yeah SecurID works, and can be secure, but it's also overpriced. There are alternative hardware token products (e.g. SafeWord from Secure Computing) which are less expensive and not much more difficult for the end user.
Most vendors that sell hardware tokens offer a "soft token" and/or PDA solutions, but these approaches are inherently less secure.
By all means have passwords from hell for admins, but I can't imagine that once they've already managed to break-in either virtually to steal the password file or physically then they've moved past the point of needing office-assistant-jane's file-sharing password?
Perhaps I managed to steal a copy of the backup tape from Jane's desktop, but what I really want is the financial data that she mounts from the fileserver. To get that, I need to crack Jane's password.
OpenBSD does do some of what you ask -- the root password has "heavier encryption" applied than for the average user accounts, which makes brute-force attacks against the saved (encrypted) root password more difficult than for other account's passwords.
One item I missed, there are now a number of worms which include simple "brute force" code for compromising share passwords on remote PCs. These tend to include a small list of common "power user" windows logins and a slightly larger list of trivial passwords to attempt.
More sophisticated versions of this type of automated brute-force network attack would be a concern, if only because thousands of infected hosts attacking at random would provide a highly distributed dictionary attack against hosts with weak passwords, and yet the most common reactions to dictionary attacks (block by source or lock the target account) would either be ineffective or just self-DoS the targets...
I happened to have seen Bowling for Columbine yesterday. In it the solution, provided by a very funny black entertainer. Make bullets $5000 a piece.
Bert
Who appreciates a lot of what Michael Moore makes.
I see that piece of political propaganda masquerading as a documentary worked on you.
Keep in mind that firearms are ancient technology, and bullets are basically a fraction of an ounce of shaped lead crimped onto the end of a brass cylinder containing a few grains of one of the simplest explosives ever discovered by humans (both smokeless and black powder each only require three simple ingredients).
The real problem with this comment is that the people who use the most rounds of ammunition are the hunters and competition shooters, the people least likely to be involved in a firearms death.
A mugger with a revolver might never fire any of the five rounds that were in it the day he bought it off some crackhead on the street, the estranged wife only needs one or two shots to off her husband, but the dedicated police officer or whitetail deer hunter goes through anywhere from twenty to two hundred rounds every time he visits the range (or his farmer buddies plinking quarry off the back forty).
Why is attack detection not given more attention than making users remember noisy passwords?
Because there are very few systems where a brute-force attack against the password-protected service itself is the most likely attack vector?
Attacks against passwords are generally going to be brute-force attempts against a copy of the encrypted password, not remote attempts across a network to "guess" the password. The latter does happen, but is seldom successful.
For example, let's say that somebody is paying Mr. Blackhat $8K get access to information stored in an "ecrypted volume" on your home Windows 2000 machine. Is the Blackhat going to try a brute-force attack across the network against your PC, or is he going to do a "black bag job", breaking into your apartment while you are at work, copying the entire drive, then running L0phtCrack against the SAM at his leisure?
It's come to a point where I have more logins than passwords and when presented with a login screen, it's the login I can't remember- I know the password.
Password Safe stores a title, username, password and a "Notes" block for each entry, and allows copying the username or password to the clipboard by simply double-clicking.
There has been discussion about added URL field in the next generation of the application. Currently I set the 'Title' to be the URL, but there is no shortcut for putting the Title on the clipboard.
Yes, the SecurID hardware tokens are relatively secure, compared to reusable passwords. There are weaknesses, and in the end SecurID authentication is only as secure as the SecurID/ACE server(s).
Unfortunately, many users don't like carrying around the card or key fob, so SecurID also offers software tokens, for MS-Windows desktops and various PDAs (IIRC, WinCE and PalMOS).
These software tokens are vulnerable to keystroke sniffers and other exploits, but because they carry the SecurID logo, they bring a false sense of security...
Hey, think of it this way. If you can't get off your ass and walk around your own building with a wireless kit, you probably don't care too much about security in the first place.
Great. The HQ building is over thirty stories, some of which I can only access with an escort from the "executive protection" group.
Then we have the primary metro plant, which covers a couple of square miles and is connected to HQ via "GigaMAN". Plus a half dozen major suburban sites connected via either leased line, ATM, microwave, or frame relay.
Both the building and the main plant use construction material which interferes with GPS reception.
Worse yet, when I do walk around the building with a wireless kit (I was a major code contributor to one open source wireless detection package), I have to manually eliminate the false positives from the WLAN networks deployed in nearby buildings. These change often, and signal strength can often be quite strong, so it's not as easy as doing a "diff" against the results from the previous walkthrough.
Hey manufacturers are you listening?
Stick an MP3 player with a card slot in a pair of noise cancelling headphones, repeat C-A-R-D S-L-O-T, N-O-I-S-E C-A-N-C-E-L-L-I-N-G H-E-A-D-P-H-O-N-E-S
Good idea. And please make it a "MMC/SD" slot, none of that proprietary stuff.
Actually, I'd settle for a pair of cordless noise-cancelling headphones that I could use with my home stereo.
This whole call-the-cops first and ask questions later scheme is getting frightening. I feel like I need a T-shirt that says "I'm not doing anything whatsoever
that is illegal. I specifically plan to do nothing whatsoever that is even remotely illegal. If you deem my actions suspicous for any reason, you just don't have
all the facts. Relax".
I think I need that T-shirt too.
Where can I order one? I checked CopyLeft and ThinkGeek, but they don't stock this.
As a side note, if you can't find a big enough list, you can always load the spyware on a test machine.
On that topic,
an instance of VMWare works great for providing a test "victim workstation" on which to install spyware, document the filesystem and network behavior, and easily revert back to a clean system with a minimum of effort.
It's even possible to execute two or more identical test systems on their own private "ethernet bridge" to watch the scanning and propagation behavior of a virus or worm.
I read this somewhere on the 'net, so don't give me credit for it.
...
If someone should try and opne your door, you will be jarred awake and you can say that you dropped some paper clips and were just reaching for them.
If I recall correctly (With a title like that,the book isn't exactly work-safe), Scott was actually quoting an email he received, so the description likely goes back many years...
Better yet, block internal hosts from communicating to the Internet on port 53, and require all internal hosts to use the local nameservers instead.
On these nameservers, override the zones for the biggest spyware domains and also for AIM, Yahoo Chat and the like, adding wildcard A records directing the request to the IP address of an internal machine running a HTTPd, or to 127.0.0.1.
The effect is twofold -- this will break 90% of the spyware programs, and you will have a log of all of the internal clients with spyware installed.
I use DJBDNS for the nameserver and publicfile for the HTTPd, but the same effect can be obtained with BIND and Apache.
There are a few programs out there that use or will fall back to hardcoded IP addresses, but these can be dealt with by adding NULL routes at the appropriate gateway routers.
The US has a long history of dealing with civil rights and similar issues by organized boycotts -- boycotts are a good analogy for a DNSBL, and boycotts are generally lawful in the US, particularly where the boycott is intended to reduce the harmful effects of the activity of the target of the boycott.
Try a search for "Montgomery bus boycott" on your search engine of choice.
Yes, some nations laws are less clear on boycotts (Canada), and in the US, certain types of organized boycott are unlawful (e.g. a group boycott by businesses meant to stifle competition, or where boycotts are used in certain labor disputes). But a "pure" voluntary organized boycott is lawful in the US.
All of the tough issues of implementing this are already implemented in existing public key encryption implementations and current PKI applications... certificates, certificate changes, revokation lists, expiration, etc etc.
How would a pay-per-email fee affect people like this? What about the "Forgot Your Password?" links on sites that email your registered email?
Easy. Add a field to the form, into which you paste your own "stamp" for the site to use on the email that is sent to you.
Same method could be used for those "mail this web page to a friend" links you find on CNet and the like. The concept is analogous to the "Self Addressed Stamped Envelope".
For a server that sends automated emails (e.g. weekly activity reports), you could provide a self-signed "reusable until revoked" certificate (aka "stamp") for all future emails.
The easiest way to do this would be for the web page to present you with a certificate naming their server and sending domain or full email address. you would "sign" this certificate with your personal email key, then paste the signed certificate back to the form and submit.
If the site "goes bad" and starts spamming you, you have the option to revoke the certificate.
You sign up on a website that sends you an activation code for your account there. The site you signed up on is a small business that can't afford to pay to get this email through to you. So either you have to remember to add their email address to your free whitelist, or you don't receive the email (and many users wouldn't have any clue why). The small business thus gets so much less business that they go under.
Simple solution -- They include on the sign up form a field in which you can paste an 'e-stamp', either an actual pre-paid single use postage, or a personal 'reusable delivery pass' (certificate) allowing their domain to send to your account.
This has a precedent in the real world, remember the ads that say "For more information, send a Self Addressed Stamed Envelope (SASE)" ?
The same goes for subscribing to an eZine or mail lists (can you imagine how many bounces bugtraq would have to deal with?), receiving any other email from a site where you sign up, etc. And every time a friend changed their email address or you met someone new, you'd have to update your whitelist.
This kind of system would be useless for an email address where you accepted bug reports for products, etc. (any address that you would HAVE to keep open for free).
Same idea would work for Bugtraq and vendor mailings -- when you sign up, there would be an additional field for you to supply a revokable "pass" permitting email inbound from their server for free to your email address without postage.
If a site abuses the pass you provide, you can revoke the certificate.
This will work... except when either the origin of SPAM is untraceable, or they make some claim you opted in to receive their valueable offer and have waived any fee. 100% of SPAM will fall under one of those two exceptions. Good luck collecting.
No need for "collecting".
The analogy is to a stamp -- an anonymous pre-paid postage unit that can only be used once, and has intrinsic value as well as anti-forgery features (strong crypto).
The sender would need to pre-purchase a quantity of "stamps", and would have to "spend" a stamp for a message to be accepted.
Some recipients might waive the fee for all senders, while others might issue "franking priviledges" to their friends, basically a sender-specific stamp that can be used repeatedly (unless revoked).
If you read the article, the idea is to whitelist your friends and mailing lists, and then you personally choose to set a fee that you charge for accepting mail from any person/business unknown to you.
So basically, you get paid for receiving email, but you only need to pay if you are in the habit of sending unsolicited email to random strangers.
Ah, so that's why my Windows XP keeps complaining about 'duplicate IP address found on network'.
I believe 127.0.0.2 is still available, please use that instead as my Kazaa downloads keep stalling when the router's arp-cache shifts to your MAC address.
That guy at 127.0.0.2 has got to be the most hated spammer in the known universe -- he's listed on every single RBL I've checked.
Strangely enough, my Linux-using coworkers can all ping him, but I can never get an answer from 127.0.0.2 on my Solaris box?
gmuslera writes:
I think RBL have no use if you use an smtp proxy, the connection to the core server always come from your proxy, and this one is not listed in RBL
I certainly hope the IP of your proxy is not listed in RBL!
There are RBL checking programs (milter-RBL, etc) which will do a RBL lookup on each IP address in each 'Received:' header in a message.
There are two bigger problems-
By the time your proxy has accepted the message and is prepared to hand it off to an internal mail server, if it's spam, you've already suffered from much of the cost of accepting and processing it.
Worse yet, if you decide that a message might be spam after your server has accepted it, the onus is on your server to generate and deliver a bounce message -- critical for dealing with false postives!
If your "edge" server can see the initial TCP connection request and immediately refuse to converse to the RBL-listed host (or launch rbl-smtpd), you obtain the maximum possible "savings" from the RBL.
Of course, there are more antispam measures at server level that don't are just RBL checking, and RBL checking in the border server is ok
The issue I face is that while I control the borders, I have many different internal groups that control their own local servers. Some of these want to refuse mail based on RBL (and have been trying to implement it on their own internal server, which is why I know about milter-RBL checking 'Received:' lines), while other internal users absolutely refuse to consent to having "their mail" refused at the edge because the sender is on some third-party blacklist.
Summary: Confederated enterprises are a pain. A good BOFH rules with an iron fist, consensus be damned!
From http://www.msnbc.com/news/880094.asp?0cv=CB10:
THE FLAW WAS ACTUALLY found in late December, but not revealed until today. That gave the Department of Homeland Security time to
organize efforts that would protect against possible attacks, said Alan Paller, director of security research firm SANS.
In other words, it gave the spooks plenty of time to root Sendmail-based mail gateways operated by certain foreign governments, and domestic media organizations, starting with those not in lock-step with the adminstration on the necessity of war with Iraq.
Slashdot Mirror
Many an enlightened employer has put in an unrestricted DS3 connection for the office and expected that the employees will do the right thing (call it self-censorship, call it responsibility, whatever), only to start reviewing usage reports and discover that the sites that get hit most often are autopr0n and QuietSurfer.
Thus the need for a censorware product (such as websense) that let's employees continue to access the sites they need to get their job done, without hurting productivity as would happen if questionable sites were just blocked with no option to "click through".
And what exactly are you doing accessing this site from work, using the shareholder's computer and bandwidth?If you can justify how your visiting this "perfectly legitimate but not mainstream site" serves to maximize shareholder value, then you should not have anything to fear from your boss.
Or just wait until you go home and access the "Dean for President" site on your own time.Otherwise, it just sounds like a demonstration of the "law of diminishing returns".
The RSA SecurID time-based tokens are covered by US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
Yeah SecurID works, and can be secure, but it's also overpriced. There are alternative hardware token products (e.g. SafeWord from Secure Computing) which are less expensive and not much more difficult for the end user.
Most vendors that sell hardware tokens offer a "soft token" and/or PDA solutions, but these approaches are inherently less secure.
OpenBSD does do some of what you ask -- the root password has "heavier encryption" applied than for the average user accounts, which makes brute-force attacks against the saved (encrypted) root password more difficult than for other account's passwords.
One item I missed, there are now a number of worms which include simple "brute force" code for compromising share passwords on remote PCs. These tend to include a small list of common "power user" windows logins and a slightly larger list of trivial passwords to attempt.
More sophisticated versions of this type of automated brute-force network attack would be a concern, if only because thousands of infected hosts attacking at random would provide a highly distributed dictionary attack against hosts with weak passwords, and yet the most common reactions to dictionary attacks (block by source or lock the target account) would either be ineffective or just self-DoS the targets...
Keep in mind that firearms are ancient technology, and bullets are basically a fraction of an ounce of shaped lead crimped onto the end of a brass cylinder containing a few grains of one of the simplest explosives ever discovered by humans (both smokeless and black powder each only require three simple ingredients).
The real problem with this comment is that the people who use the most rounds of ammunition are the hunters and competition shooters, the people least likely to be involved in a firearms death.
A mugger with a revolver might never fire any of the five rounds that were in it the day he bought it off some crackhead on the street, the estranged wife only needs one or two shots to off her husband, but the dedicated police officer or whitetail deer hunter goes through anywhere from twenty to two hundred rounds every time he visits the range (or his farmer buddies plinking quarry off the back forty).
Attacks against passwords are generally going to be brute-force attempts against a copy of the encrypted password, not remote attempts across a network to "guess" the password. The latter does happen, but is seldom successful.
For example, let's say that somebody is paying Mr. Blackhat $8K get access to information stored in an "ecrypted volume" on your home Windows 2000 machine. Is the Blackhat going to try a brute-force attack across the network against your PC, or is he going to do a "black bag job", breaking into your apartment while you are at work, copying the entire drive, then running L0phtCrack against the SAM at his leisure?
There has been discussion about added URL field in the next generation of the application. Currently I set the 'Title' to be the URL, but there is no shortcut for putting the Title on the clipboard.
Unfortunately, many users don't like carrying around the card or key fob, so SecurID also offers software tokens, for MS-Windows desktops and various PDAs (IIRC, WinCE and PalMOS).
These software tokens are vulnerable to keystroke sniffers and other exploits, but because they carry the SecurID logo, they bring a false sense of security...
Then we have the primary metro plant, which covers a couple of square miles and is connected to HQ via "GigaMAN". Plus a half dozen major suburban sites connected via either leased line, ATM, microwave, or frame relay.
Both the building and the main plant use construction material which interferes with GPS reception.
Worse yet, when I do walk around the building with a wireless kit (I was a major code contributor to one open source wireless detection package), I have to manually eliminate the false positives from the WLAN networks deployed in nearby buildings. These change often, and signal strength can often be quite strong, so it's not as easy as doing a "diff" against the results from the previous walkthrough.
Good idea. And please make it a "MMC/SD" slot, none of that proprietary stuff.
Actually, I'd settle for a pair of cordless noise-cancelling headphones that I could use with my home stereo.
Beyond the speed of the interface itself, there are two issues with actual "CompactFlash" storage (as opposed to CF-form factor spindles):
- Flash memory has a relatively low sustained write speed of 3MB/s (for 20X CF storage.)
- Flash memory has a limited (1 million cycles) re-write lifetime, strongly affected by the operating temperature.
Neither of these limitations are all that critical for a still camera, but can pose a real problem for a camcorder.I ran up against both of these limits while working out the issues of booting and running a firewall (OpenBSD on AMD) using only flash storage.
I think I need that T-shirt too.
Where can I order one? I checked CopyLeft and ThinkGeek, but they don't stock this.
It's even possible to execute two or more identical test systems on their own private "ethernet bridge" to watch the scanning and propagation behavior of a virus or worm.
I first read this in the Dilbert book "The Joy of Work: Dilbert's Guide to Finding Happiness at the Expense of Your Co-Workers" (1998).
If I recall correctly (With a title like that,the book isn't exactly work-safe), Scott was actually quoting an email he received, so the description likely goes back many years...
On these nameservers, override the zones for the biggest spyware domains and also for AIM, Yahoo Chat and the like, adding wildcard A records directing the request to the IP address of an internal machine running a HTTPd, or to 127.0.0.1.
The effect is twofold -- this will break 90% of the spyware programs, and you will have a log of all of the internal clients with spyware installed.
I use DJBDNS for the nameserver and publicfile for the HTTPd, but the same effect can be obtained with BIND and Apache.
There are a few programs out there that use or will fall back to hardcoded IP addresses, but these can be dealt with by adding NULL routes at the appropriate gateway routers.
Try a search for "Montgomery bus boycott" on your search engine of choice.
Yes, some nations laws are less clear on boycotts (Canada), and in the US, certain types of organized boycott are unlawful (e.g. a group boycott by businesses meant to stifle competition, or where boycotts are used in certain labor disputes). But a "pure" voluntary organized boycott is lawful in the US.
Easy. Add a field to the form, into which you paste your own "stamp" for the site to use on the email that is sent to you.
Same method could be used for those "mail this web page to a friend" links you find on CNet and the like. The concept is analogous to the "Self Addressed Stamped Envelope".
For a server that sends automated emails (e.g. weekly activity reports), you could provide a self-signed "reusable until revoked" certificate (aka "stamp") for all future emails.
The easiest way to do this would be for the web page to present you with a certificate naming their server and sending domain or full email address. you would "sign" this certificate with your personal email key, then paste the signed certificate back to the form and submit.
If the site "goes bad" and starts spamming you, you have the option to revoke the certificate.
This has a precedent in the real world, remember the ads that say "For more information, send a Self Addressed Stamed Envelope (SASE)" ?
Same idea would work for Bugtraq and vendor mailings -- when you sign up, there would be an additional field for you to supply a revokable "pass" permitting email inbound from their server for free to your email address without postage.If a site abuses the pass you provide, you can revoke the certificate.
The analogy is to a stamp -- an anonymous pre-paid postage unit that can only be used once, and has intrinsic value as well as anti-forgery features (strong crypto).
The sender would need to pre-purchase a quantity of "stamps", and would have to "spend" a stamp for a message to be accepted.
Some recipients might waive the fee for all senders, while others might issue "franking priviledges" to their friends, basically a sender-specific stamp that can be used repeatedly (unless revoked).
If you read the article, the idea is to whitelist your friends and mailing lists, and then you personally choose to set a fee that you charge for accepting mail from any person/business unknown to you.
So basically, you get paid for receiving email, but you only need to pay if you are in the habit of sending unsolicited email to random strangers.
That guy at 127.0.0.2 has got to be the most hated spammer in the known universe -- he's listed on every single RBL I've checked.
Strangely enough, my Linux-using coworkers can all ping him, but I can never get an answer from 127.0.0.2 on my Solaris box?
There are RBL checking programs (milter-RBL, etc) which will do a RBL lookup on each IP address in each 'Received:' header in a message.
There are two bigger problems-
If your "edge" server can see the initial TCP connection request and immediately refuse to converse to the RBL-listed host (or launch rbl-smtpd), you obtain the maximum possible "savings" from the RBL.
The issue I face is that while I control the borders, I have many different internal groups that control their own local servers. Some of these want to refuse mail based on RBL (and have been trying to implement it on their own internal server, which is why I know about milter-RBL checking 'Received:' lines), while other internal users absolutely refuse to consent to having "their mail" refused at the edge because the sender is on some third-party blacklist.
Summary: Confederated enterprises are a pain. A good BOFH rules with an iron fist, consensus be damned!
Okay, that's probably not the best example.
Speaking of Milter...
$ lynx -dump http://www.milter.org/
It's been like that for weeks...
Hey, cool, another feature to add to ChuckieMail!