As the thread about Jesse doing this to protect small religious-oriented stations also touches on, the problem that the classical station is facing is that they're a niche market, while the standard music publisher packages are designed to handle the high-volume highly-commercial market. So you're paying the big bucks to broadcast the Top 40, or a couple of other big commercial genres (Country, etc.) even though you're not broadcasting it and you'd pay a lot less for your niche content. This probably affects web radio stations more than the broadcast radio market, because they're much more likely to be niche-content players as well as small players - the costs of getting into non-pirate broadcast radio, especially with the current Gosplan\\\\\FCC licensing rules, and the technical fact that broadcast radio is inherently local unless you burn huge amounts of power, means that you're going to have a mixed-content market, while the Web makes it much easier to find a listener base for your favorite Ukranian fuzz-grunge-collective dance music.
We're running pretty recent Outlook here, and this is real Outlook, not Outlook Express. Happened just last week (actually, it was two 5MB Powerpoints....) Sometimes you can do other things while receiving large files, but sometimes you can't - it may be that the difference is between steady-state where you're already running when the file arrives vs. having it queued up when you first dial in?
I use Outlook at work. It's vastly improved from MSMail on Win3.1, which was the third-worst mail system I'd ever seen.* It's mostly usable now, except when things go wrong, but there are some behaviours to avoid.
Keeping the mail in one huge monolithic binary undocumented-format file is a really bad idea.
Encrypting the mail file can be a good idea, but only if you use a credible encryption algorithm instead of some "compressible encryption" snake oil, and use it in a way that doesn't prevent somebody who has the password from recovering broken mailfiles.
Close interaction between the mail system and the network is a bad idea - Outlook has gotten less cranky about starting it up when you're not connected to a network, or connected to the Internet but not your WINS server, but it still doesn't adapt well when you turn the network on and off or change your IP address by moving your laptop or start a VPN. By contrast, Eudora just works - when you tell if to send or receive mail, it opens a network connection and works, but you can start the system without the network.
Having the user interface stall when you're receiving big mail messages is bad - if you want to look at something in your mailbox but somebody in marketing sent you a 5 MB Powerpoint that's trickling in over modem, it'll be a while before you can find out the phone number on that calendar entry you wished you could open.
Starting up the whole mail system just to get at your calendar or address book is a mistake, especially if starting the mail system is closely tied in to the network status. That means if you're trying to look up a calendar entry or phone number, it can be really slow (see previous two complaints); much better to be able to look it up directly.
Incrementally showing search results is nice, or at least showing results from local data while you're waiting for that LDAP server to respond.
Having separate local and network-based spam filter tables is fine if you can use both - it's really annoying if you can't add a spammer to the table without discarding the system table.
Undocumented files and file formats are bad bad bad...
------------- * IBM PROFS was the worst. The original Prodigy 300-baud 24x40-character mail system was heinous also. The homebrew Kermit-based system we used that crashed when receiving more than 200KB of mail was about on par with MSMail in those days...
One difference is that broadband internet lets you get more TV-like services, compared to the limited range of opinions on government and corporate TV, though satellites have already done much of that. But the more important difference is that having a broadband connection at home means you can easily put up your own web site, and distribute as much content as you've got disk drive for. In some places, like parts of the US, the broadband companies discourage this, but in most of the world you can run your own servers.
Just because 67% of the homes have broadband doesn't mean that 67% of the homes have good system administrators:-) Actually, the early problems weren't homes, but schools, which ran a standard software distribution that had lots of holes in it.
I'd decided not to write the rant about Microsoft not having a clue about networking or about working with existing standards (or at least about only rejecting them on purpose rather than through ignorance), and you go handing me this straight line... Sigh....
You could dredge through RFC1001 and 1002 to read lots about the NETBIOS-over-TCP protocols (which use a lot of UDP, and therefore might be spoofable), or read the source code if you're one of those miscreants who snarfed it, or spend a couple of minutes with a sniffer to see what information is passed on the wire in what packets. But you don't really need to, because the way people see the spam is that their system responds to the packet using the default popup application, which displays the sender's NETBIOS name, not their DNS name or IP address, so unless they're running a sniffer, they won't see the IP address (and if they're the type of people who are always running a sniffer in the background, they're probably also the type of people who have port 135 blocked and aren't going to receive the spam...) NETBIOS names are essentially user-settable. That's not always true, if you're on a corporate LAN with Microsoft file/print/wins servers, but if you're not trying to do that, you can set it to whatever you want. Maybe not 127.0.0.1, since that has dots and no alphabetics, but LOCALHOST would work, or you could set it to ADMINISTRATOR if you're trying to social-engineer the recipients, or WORKGROUP if you want a generic built-in Microsoft name.
Universities really do have different network security needs than businesses.
The traditional thing that business sysadmins worry about is some college kid cracking into their network, so they build firewalls to prevent that.
That's not as useful if the kids are already inside. On the other hand, I know some university administrators who've had to try to configure their systems to keep insiders from cracking outsiders' machines.
Businesses normally set their firewalls to allow insiders to initiate most outgoing connections, but only allow incoming connections for the few applications that the business is *trying* to run for outsiders, such as email, web/ftp, etc.
Universities are more likely to allow everything, because their users may be doing all kinds of new and interesting applications.
Is there much consensus out there about best practices for university network and firewall administration, or things to watch out for that they didn't teach you in business-related training?
One nitpick is that you don't need products like WebWasher if you're running Mozilla - you can set it not to "Open Unrequested Windows", and 95% of that stuff just vanishes.
In this case, it doesn't sound like the spamware lets the spammer relay their traffic through another machine - it's probably coming directly from them. Slapping them may actually be fun - here you are, some poor slob who bought a package telling you how you can M8ke Munny Fast! by promoting your 1-900-sex-spam line, you start this thing up on your PC, and now you've got 500 popup windows on your screen telling you to stop bothering people, plus one more saying that all your base are belong to them.
Kovacs sells the spamware. His customers are spammers. Most of the spam victims don't know to call Kovacs and yell at him, so all he gets is positive feedback, plus the occasional customer who's disappointed about not getting lots of calls. The spammers are spamming for 1-900-fone-sex, and really don't care if the spam victim calls to talk dirty to them or calls to yell at them, because its $3.99/minute either way.
In a business intranet, there may be uses for this service. But for a machine connected to the public internet (i.e. a spam target), there's simply no excuse for letting packets in unless they're running on a protocol you know you want to support across the net. For most couch potatoes at home, that means responses to outgoing queries, plus incoming packets on any Instant Messenger, Games, and P2P File Sharing type application you are running. If you're also running a web server, then there's that too. For couch potatoes at work, there may be all sorts of stuff, but there's no reason the business firewall should be letting them in from unknown sources.
Here in San Francisco, messengers not only do the Spandex pants and bicycle helmets, but also usually have tattoos and metal rings on their faces. I hadn't heard of anybody using nets to stop them, though....
The only time it's really a problem is Critical Mass.
Because it's not the US, they don't have the heavy censorship that US amateur radio users have to put up with (no crypto, no talking about business, no bad language, etc.) It doesn't sound like they're actively using either PGP or IPSEC, but they could, and if they were worried about eavesdroppers, they probably should consider it.
Since they're using SMTP, a *really* simple thing to do is to enable STARTTLS, which does encryption on SMTP connections if both sides support it, which doesn't have the user-visibility that PGP does and is simpler than IPSEC.
Wire is cool. Huh huh.. huh huh... (Sorry, but the pun was just sitting there unused...)
Wireless is fine for low-speed connections, or medium-speed connections that don't have to go very far, and can either interoperate between multiple users in the same space or else do some non-interference trick like spread spectrum. And it's really nice to have freedom of movement and ability to get some kind of service wherever you are, which means wireless in the most general case (though LANs with DHCP and VPNs are a good start.)
But fundamentally, wire-like technologies (including fiber as well as copper) are much more practical for high-speed connections, and can fit arbitrarily large capacity in a given area because separate wires don't interfere with each other, unlike multiple sets of radio waves. For high-speed connections over non-short distances, wireless needs line-of-sight, while wires don't need to be in straight lines, can leap under tall buildings at a single bound, wrap around mountains and curved planets, etc. Also, the physics for devices that mess with wires make it easy to put huge bandwidths on a fiber, limited by the cost of the high-tech equipment on the ends (which gets Moore's Law kinds of price/performance effects) - practical bandwidths get into the gigabit range for cheap short-distance equipment ($59 at Fry's) and into the terabit range per fiber for long-distance telco-quality equipment.
There is some relatively high-speed line-of-site equipment that can fit multiple separate connections in nearly the same space - free-space optics is the most focused, and there are microwave systems that are pretty tight. They can't do long distances, because of weather as well as because of the earth's curvature, but some of them are in the half-gigabit speed range over a few kilometers. They're really nice as a backup for building data feeds - they get rain fade, but they don't get backhoe fade, don't usually need permits to cross highways, and are surprisingly tolerant of earthquakes.
Faster than tape, too:-) Maybe I'm mixing up C64 and TRS80, but some of the tape drives for the early home computers were basically doing 300 baud modem codecs on cheap consumer audio tape. (Also, of course, the ham packet radio might not have been that fast when you were using your C64...)
First of all, this *is* Constitutionally interesting, and is probably caused by uncoordinated government stupidity instead of deliberate plotting by somebody. What should happen in a case like this is
Can't get visa, doesn't show.
Trial happens, bail confiscated, found guilty
Dmitri appeals because he was unConstitutionally prevented from challenging the witnesses against him and various other due process things.
Wins on appeal, prohibition against double jeopardy means he's off the hook
Profit!
In reality, the judge, prosecutor, and his lawyer will have some sort of discussion and they'll put off the trial until they can get him there, or else drop the charges.
The average US or EU.COM is certainly willing to spend $6/year for 99.999% reliability. But there are a lot of people in the.org world who might be happier paying a lot less for 99.9% uptime, as long as their names don't get lost. After all, it's not very often that you do a name registration - you care more about DNS availability, and lots of that comes from the root nameservers, or from caches in the big ISPs' nameservers, and while a big concern like ACLU.ORG or EFF.ORG may want better access to the registries, joebobs-home-pc.org doesn't mind that much if people can't do a new DNS resolution for 1.4 minutes/day, as long as it's up most of the time.
The costs of dispute resolution are likely to be much higher than the costs of registry servers - the monthly cost of a couple of hosted machines is less than the cost of a couple hours of lawyer time.
It's not that they don't believe in respecting copyrights - it's that they don't worry too much about respecting foreigners' copyrights. Things have changed somewhat with trade treaties, but on the other hand, duplicating CDs and DVDs keeps getting cheaper, so it probably balanaces out.
When I was in college in the mid-70s, a number of my fellow students from Taiwan and Hong Kong would bring pirated textbooks over with them, which typically had covers indicating they were cookbooks or written in Chinese or whatever; it reduced the attention of customs inspectors.
Real-time and going fast are two totally different problems. Satellite controllers may need real-time programming - there's physical stuff moving, and if a signal needs to be responded to in the 100ms before the bird turns another degree, you need hard real-time. But there's nothing that a bank does that needs real-time, unless the device in an ATM that hands out the cash is really badly designed. Yes, you need to know that the customer has taken the cash out of the slot or that the receipt-printer's finished, but if you find out 100ms late some of the time, it isn't going to hand out the wrong amount of money, it's just going to be slightly later drawing the next screenful of customer interaction. Some of their stuff needs to get high volumes of work done quickly, but that's a throughput problem, not a real-time problem, and you might get better throughput if some of the transactions have wait their turn rather than preempting other ones.
The phrase "high accuracy biometric algorithms" struck me as suspicious, and sure enough it's Big-Brother-Ware using NIST funding because it's "too risky to attract private investments". Face recognition and voice recognition are the primary goals, for "airport security" and "telecommunications applications". Well, the telecommunications world has plenty of development money available for commercially useful applications, and AT&T Labs has been developing technology like that for years, plus the computer business has been developing speech-to-text intensively and finally has enough CPU horsepower to make it much more usable. But this is targeted toward other applications, presumably surveillance.
I'd rather not have my money spent on this, thank you. It's not that it's wasted pork - it's development that actively reduces my civil liberties.
Sigh. Yet another set of exploits that are far worse because people run their mail systems as root. It's just not necessary - the System V side of the world hasn't done this in decades. Sendmail comes with a bunch of mechanisms to make it run as a user most of the time, but that just means you need to exploit it fast and hard:-) Here are some of the reasons people run mail systems as root
Too much embedded base to fix. Yes, that sendmail. There are competing mailers - postfix, qmail, smtpd, etc.
Delivering mail to users' mailboxes. The System V world handles this with group permissions, by making the mailboxes group mail and running the mail delivery system as group mail instead of user root. Works fine.
Port 25 "secure" because root-only. The naive implementation is to run the smtp daemon as root to access it; the other naive implementation is to use inetd or its relatives to open the port but run the application as a user. A much better solution would be to modify the kernel to do a least-privilege approach, letting some other approved user own the port, though that's got obvious portability issues for applications that want to run on multiple flavors of Unix. But it ought to be done.
Running user-provided filters on incoming mail, e.g. procmail or vacation-mail senders. This is a bit harder - it's easy enough to implement a mail-user vacation-mail daemon, but doing a procmail that doesn't need to be root but doesn't let arbitrary users abuse it takes a bit of work; the filter could easily require group root privileges to run, and only really needs to acquire the recipient's userid if it's accessing private directories - that's inherently unsafe (because a bad procmail script could let people attack you), but if you want to do it, it shouldn't be too hard to set the filter to r-sr-x--- jruser mail or something like that. Better to have the user set up directories that group-mail can write to.
FTP servers have a reputation for bad implementations, though perhaps I'm just annoyed at having had a wu-ftp crack let my machine get hosed a year or two ago. If it wasn't an inside job, then it's likely to have been some exploit like that - which is especially likely, since the HTTP server's version was clean.
MD5 checksums are good for detecting corruption - bad downloads, etc. They don't help against tampering, because the Bad Guy can also tamper with the checksum, unless there's some separate distribution method. That's why public-key signatures are so important.
Slashdot Mirror
As the thread about Jesse doing this to protect small religious-oriented stations also touches on, the problem that the classical station is facing is that they're a niche market, while the standard music publisher packages are designed to handle the high-volume highly-commercial market. So you're paying the big bucks to broadcast the Top 40, or a couple of other big commercial genres (Country, etc.) even though you're not broadcasting it and you'd pay a lot less for your niche content. This probably affects web radio stations more than the broadcast radio market, because they're much more likely to be niche-content players as well as small players - the costs of getting into non-pirate broadcast radio, especially with the current Gosplan\\\\\FCC licensing rules, and the technical fact that broadcast radio is inherently local unless you burn huge amounts of power, means that you're going to have a mixed-content market, while the Web makes it much easier to find a listener base for your favorite Ukranian fuzz-grunge-collective dance music.
We're running pretty recent Outlook here, and this is real Outlook, not Outlook Express. Happened just last week (actually, it was two 5MB Powerpoints....) Sometimes you can do other things while receiving large files, but sometimes you can't - it may be that the difference is between steady-state where you're already running when the file arrives vs. having it queued up when you first dial in?
-------------
* IBM PROFS was the worst. The original Prodigy 300-baud 24x40-character mail system was heinous also. The homebrew Kermit-based system we used that crashed when receiving more than 200KB of mail was about on par with MSMail in those days...
One difference is that broadband internet lets you get more TV-like services, compared to the limited range of opinions on government and corporate TV, though satellites have already done much of that. But the more important difference is that having a broadband connection at home means you can easily put up your own web site, and distribute as much content as you've got disk drive for. In some places, like parts of the US, the broadband companies discourage this, but in most of the world you can run your own servers.
Just because 67% of the homes have broadband doesn't mean that 67% of the homes have good system administrators :-) Actually, the early problems weren't homes, but schools, which ran a standard software distribution that had lots of holes in it.
You could dredge through RFC1001 and 1002 to read lots about the NETBIOS-over-TCP protocols (which use a lot of UDP, and therefore might be spoofable), or read the source code if you're one of those miscreants who snarfed it, or spend a couple of minutes with a sniffer to see what information is passed on the wire in what packets. But you don't really need to, because the way people see the spam is that their system responds to the packet using the default popup application, which displays the sender's NETBIOS name, not their DNS name or IP address, so unless they're running a sniffer, they won't see the IP address (and if they're the type of people who are always running a sniffer in the background, they're probably also the type of people who have port 135 blocked and aren't going to receive the spam...) NETBIOS names are essentially user-settable. That's not always true, if you're on a corporate LAN with Microsoft file/print/wins servers, but if you're not trying to do that, you can set it to whatever you want. Maybe not 127.0.0.1, since that has dots and no alphabetics, but LOCALHOST would work, or you could set it to ADMINISTRATOR if you're trying to social-engineer the recipients, or WORKGROUP if you want a generic built-in Microsoft name.
You're right, killing web bugs is a very good thing. I'd only been thinking about the pop-ups in that context.
Is there much consensus out there about best practices for university network and firewall administration, or things to watch out for that they didn't teach you in business-related training?
One nitpick is that you don't need products like WebWasher if you're running Mozilla - you can set it not to "Open Unrequested Windows", and 95% of that stuff just vanishes.
In this case, it doesn't sound like the spamware lets the spammer relay their traffic through another machine - it's probably coming directly from them. Slapping them may actually be fun - here you are, some poor slob who bought a package telling you how you can M8ke Munny Fast! by promoting your 1-900-sex-spam line, you start this thing up on your PC, and now you've got 500 popup windows on your screen telling you to stop bothering people, plus one more saying that all your base are belong to them.
Kovacs sells the spamware. His customers are spammers. Most of the spam victims don't know to call Kovacs and yell at him, so all he gets is positive feedback, plus the occasional customer who's disappointed about not getting lots of calls. The spammers are spamming for 1-900-fone-sex, and really don't care if the spam victim calls to talk dirty to them or calls to yell at them, because its $3.99/minute either way.
In a business intranet, there may be uses for this service. But for a machine connected to the public internet (i.e. a spam target), there's simply no excuse for letting packets in unless they're running on a protocol you know you want to support across the net. For most couch potatoes at home, that means responses to outgoing queries, plus incoming packets on any Instant Messenger, Games, and P2P File Sharing type application you are running. If you're also running a web server, then there's that too. For couch potatoes at work, there may be all sorts of stuff, but there's no reason the business firewall should be letting them in from unknown sources.
The only time it's really a problem is Critical Mass.
Since they're using SMTP, a *really* simple thing to do is to enable STARTTLS, which does encryption on SMTP connections if both sides support it, which doesn't have the user-visibility that PGP does and is simpler than IPSEC.
Wireless is fine for low-speed connections, or medium-speed connections that don't have to go very far, and can either interoperate between multiple users in the same space or else do some non-interference trick like spread spectrum. And it's really nice to have freedom of movement and ability to get some kind of service wherever you are, which means wireless in the most general case (though LANs with DHCP and VPNs are a good start.)
But fundamentally, wire-like technologies (including fiber as well as copper) are much more practical for high-speed connections, and can fit arbitrarily large capacity in a given area because separate wires don't interfere with each other, unlike multiple sets of radio waves. For high-speed connections over non-short distances, wireless needs line-of-sight, while wires don't need to be in straight lines, can leap under tall buildings at a single bound, wrap around mountains and curved planets, etc. Also, the physics for devices that mess with wires make it easy to put huge bandwidths on a fiber, limited by the cost of the high-tech equipment on the ends (which gets Moore's Law kinds of price/performance effects) - practical bandwidths get into the gigabit range for cheap short-distance equipment ($59 at Fry's) and into the terabit range per fiber for long-distance telco-quality equipment.
There is some relatively high-speed line-of-site equipment that can fit multiple separate connections in nearly the same space - free-space optics is the most focused, and there are microwave systems that are pretty tight. They can't do long distances, because of weather as well as because of the earth's curvature, but some of them are in the half-gigabit speed range over a few kilometers. They're really nice as a backup for building data feeds - they get rain fade, but they don't get backhoe fade, don't usually need permits to cross highways, and are surprisingly tolerant of earthquakes.
Faster than tape, too :-) Maybe I'm mixing up C64 and TRS80, but some of the tape drives for the early home computers were basically doing 300 baud modem codecs on cheap consumer audio tape. (Also, of course, the ham packet radio might not have been that fast when you were using your C64...)
In reality, the judge, prosecutor, and his lawyer will have some sort of discussion and they'll put off the trial until they can get him there, or else drop the charges.
The costs of dispute resolution are likely to be much higher than the costs of registry servers - the monthly cost of a couple of hosted machines is less than the cost of a couple hours of lawyer time.
When I was in college in the mid-70s, a number of my fellow students from Taiwan and Hong Kong would bring pirated textbooks over with them, which typically had covers indicating they were cookbooks or written in Chinese or whatever; it reduced the attention of customs inspectors.
We set them up the bomb. [.... technical more details
They are on their way to destruction.
Real-time and going fast are two totally different problems.
Satellite controllers may need real-time programming - there's physical stuff moving, and if a signal needs to be responded to in the 100ms before the bird turns another degree, you need hard real-time. But there's nothing that a bank does that needs real-time, unless the device in an ATM that hands out the cash is really badly designed. Yes, you need to know that the customer has taken the cash out of the slot or that the receipt-printer's finished, but if you find out 100ms late some of the time, it isn't going to hand out the wrong amount of money, it's just going to be slightly later drawing the next screenful of customer interaction. Some of their stuff needs to get high volumes of work done quickly, but that's a throughput problem, not a real-time problem, and you might get better throughput if some of the transactions have wait their turn rather than preempting other ones.
I'd rather not have my money spent on this, thank you. It's not that it's wasted pork - it's development that actively reduces my civil liberties.
FTP servers have a reputation for bad implementations, though perhaps I'm just annoyed at having had a wu-ftp crack let my machine get hosed a year or two ago. If it wasn't an inside job, then it's likely to have been some exploit like that - which is especially likely, since the HTTP server's version was clean.
MD5 checksums are good for detecting corruption - bad downloads, etc. They don't help against tampering, because the Bad Guy can also tamper with the checksum, unless there's some separate distribution method. That's why public-key signatures are so important.