But that's a strawman. His actual argument was not "if it's on a shirt it's free speech", his argument was "if I can put it on a shirt, it's speech." (period).
At that point, it's protected by the first amendment and subject to the restrictions you pointed out. If something is not speech (code is not considered speech, even now) then it dosn't have any first ammendment protections.
Well, you're right on not wanting to force a refresh every second. Your best bet is a custom server speaking HTTP (for firewalled proxies) that sends a slow update back to the client. It's gotta be custom since you're going to be handling 10k idle threads at any one time. You probably can't delay sending data by more then a minute or so, some firewall proxies may time out. (Anyone with hard experience on this field, feel free to speak up)
The idea is the client sends a request, and waits for for the update. Probably initially it will recieve a dump of current data and display that, waiting for updates as they arrive. Alternately, you can send a sequence number with each update and the client sends it back. Any data that's updated after that date gets sent, again, blocking till the socket gets closed and sending as needed.
I don't believe you need to do multipart/mime for this, since the proxies should _NOT_ know about the internals of HTTP beyond how to get it through the firewall. You're probably fine returning XML snippets for each update 'datagram' you want to send the client.
IRC is a good model. 99% of the time, the client is idle, waiting for more input. It's a persistant socket connection with some header setup (User/nick/MOTD for IRC, URL/Metadata/HTTP headers for you)
Writing a custom server to handle this should be fairly straightforward. Watch out for those buffer overflows, though.;-)
Unfortunately what you end up with is the ISPs backpeddling: "Well, this is a residential service, not a business service, tough bounce, we're gonna keep trunking DSLAMs with fractional-speed frame relay cause we're cheap and dishonest."
That's one way of putting it. another would be "I'm willing to sell you 1.5 meg of guaranteed bandwidth if you're willing to actually pay for it."
Let's go back to grade school. Today, we learn about fractions of big numbers!
1.5meg bandwidth costs the ISP between $1000 and $2000, depending on the quality (and how it's delivered.) Your 1.5 meg DSL circuit costs them between $28 and $40, depending on how many they buy. Let's say 30. The ATM circuit that your DSL rides on to the ISP costs them $400-$500 (for 1.5 meg).
Now, jimmy, let's do the math. How much does it cost them to let you leach your warez, pr0n and mp3's full speed, all day?
$1500 + $500 + $30 = $2030.
Now, Johnny, how much does your DSL cost? $79 per month? Call it 80.
So, kate, what fraction of the cost are you paying?
Why, you're paying 8/203's of the cost. We'll call that 1/25th for this assignment.
So, Robby, why shouldn't 24 other people get their turn at the DSL-go-round? They're paying for it too, arn't they?
Bottom line: Put your money where your mouth is. You want to (ab)use a lot of bandwidth, pay for it.
Wait, 120k per year for T3? That's expensive, to be sure, but hardly out of line. Most places give you local loop for 3-4k per MONTH. 120k per year for a longhaul is only an additional 6-7k. Expensive? Yes. Compared to the 20-50k per month in bandwidth charges to run data on it? No.
I'm sorry, but their ain't no such thing as a free lunch. If you can't afford to be an ISP, sell your buisness to someone who can.
It may not be exactly what you want it to be, but I'll put the success of private-sector communications networks against any government-funded program or system you can name.
I'll bite.
The interstate highway system. One of the few major projects that worked out. Where there's not enough immediate demand for the corperate sector to fill, at least an incentive is in order.
If rural areas arn't getting fiber, open up rights-of-way between the points that are desired and give huge discounts to any carrier willing to lay there. As soon as you get dark fiber in the ground, someone will turn it up.
As an aside, the article is awfully shallow. There's so much network buildout that there is a major fiber shortage. Nobody is getting as much as they need, so it's getting prioritized. Move to a networking center if you want a network. Almost any major city will do.
How about a more useful blacklist. Say, how about "Drop packets from these networks, they allow source-forged packets out unto the global internet."
How about blocking any BGP routes advertised by ASs that have refused to fix their broadcast amplifiers?
Basically, fix the problem at the source rather then forcing ISPs to spend hundreds of times more effort cleaning up the mess afterwards. (Hint, kids, dialup is a losing buisness at best. Want all the ISPs to just do webhosting and leave the dialup to the telcos? We _KNOW_ how friendly they are. Right?) Basically, on your proposed blacklist you can list any ISP not backed by a mega-corp, since all the competitive, geek friendly and *GASP* shell-access ISPs are the small guy.
And here's another hint: There usually are "innocent victims" of DoS attacks. If they truly didn't do it, it turns out that they gave their password out to 'a friend' who leaked it out to IRC. That right there is abuse worth getting kicked for.
That said, I will say that occasionally the DoS is malicious, rather then retaliatory. One was aimed at a MUD that the attacker didn't get his way on. A few have been takeovers of specific IRC channels that are not your usual skript-kiddie hangout. Those are the only types I'll take any action to protect. If I find war-bot tools in your account after a DoS, you're gone. If you gave out your password, you're gone. If you go out trolling on IRC, you get a warning. Once.
And hey, talk to your ISP. If that's their atitude you've found an intelligent one because they WILL let you run services on their hardware. They WON'T portscan your machine for servers. They will do everything in their power to protect you _IF_ you are honest (and responsible). But why in hell should I waste time protecting the next generation of net.vandals? Being a skript kiddie is not a free speech issue. It should be a one-way ticket off the internet.
The small percentage is what I concentrate on when attempting to block DoS attacks. I could care less if a skript kiddie gets punted offline, but if someone is legitimatly being attacked, I will (and have) do whatever it takes to keep them online. This generally means getting specific upstream blocks put in place.
Actually, from what I understand, an upgrade to Cisco's newest IOS will prevent most DoS attacks. I think the default setting is to block all packets that are identified as DoS packets. Also, do you really need to allow ping? If you are checking to see if your web server is running, just do: I'm not sure what feature of the new IOS magically prevents DoS attacks. In fact, I know that rejecting addressed broadcast has been around at least since 11.x. Filtering outbound packets based on source has been around forever as well. The problem is that if ONE isp somewhere dosn't filter spoofed addresses, and ONE network somewhere dosn't reject addressed broadcast, an entire class of attacks is still possible.
In fact, even if there were no broadcast multipliers anywhere, that one ISP could still be used to send out the source-forged command packets to the 'zombie' flood networks.
And telling people to turn off ping is a bad idea. Huge sections of the net are broken because idiot admins think that ICMP=Ping, and thus PMTU discovery breaks, packets get blackholed because no ICMP errors are returned... Not Good.
Dropping the user may solve their immediate problem, but it also hands victory to the attacker, thereby encouraging him, thereby guaranteeing more attacks in the future.
It dosn't work that way, actually. People comparing this to terrorism are all wrong. In this case, the terrorists have already achieved their goals. Whatever their target was is offline. At that point, all you can do is try to contain the damage, much like the fire department putting out the fires after a bomb blows up a building.
Killing the account must have come later during the "how do we prevent this from happening again" discussion. Obviously this is a stupid reaction. DOS attacks are something you can't ignore by placing your head in the ground and refusing to believe legimate people are being attacked.
I covered this in a previous post, so I'll be brief.
A) Legit accounts don't get DoSed. If they do, they've been cracked. The account provoked the attack by their behavior, 99.9% of the time on IRC, and 95% of the time in the course of channel wars.
B) Secondly, terminating the target is the FIRST thing you should do. This means the DoS has succeeded, and generally means the attacker gloats in his attack and turns it off. (After all, they're (wrongly) afraid of the FBI coming after them, so why leave it on if it's done it's job?) Once they see the victims bot part IRC, they know they've got it. Mind you, this brings up another major point. On the Internet, DoS attacks WORK. As long as they work, they will happen. If you don't terminate the account, it will be kept offline by DoS until the attacker gets bored. It is The Fastest way, by far, to end an attack
As for tracing it back to the source, why bother? Unless you're yahoo or amazon or e*trade, nobody is going to prosecute the kids involved. Period. I've tried. Nobody cares unless you're a big DotCom. Law enforcement is generally completely incompetent and the few people who can do their job are busy doing it (But only for the major cases).
I've also found that reporting cracked boxes and misconfigured network amplifiers is a waste of time. If the admin has two braincells to rub together, they've fixed it already. If they don't, you've just volunteered to fix them, for free. Too bad the kids arn't doing rm -rf * on roothack boxes anymore, that'd at least shut the dammed things down.
Well, having had to deal with this more times then I care to recall, let me share with you some of my thougts on it.
First off, before everyone gets indignant, I have very rarely seen an 'unprovoked' DoS attack. More often, you have a skript kiddie of your own attempting a channel takeover of some other skript kiddie. At that point, the two escalate hostilities until someone brings out the BFGs... smurf, TFN, whatever. If your kiddie does it first, you get to save your logs for when the FBI comes with a subpoena. If he isn't as quick on the draw, you wait for the other kiddie to get bored before you can get your buisness back online. Either outcome sucks.
The first thing I do when I see a DoS is I take out whatever their target is. It's gonna get killed anyway, might as well hurry up the process. If it's a colo, their eithernet goes. If it's an eggie, it dies. If it's a dialup... well, it's already offline. I disable the account.
Second stage is to determine _WHY_ the attack happened. I generally don't bother calling the kiddie in question because they always lie about what they were doing, when a quick glance at their eggdrop tells you what hostilities were involved. This usually involves lurking on IRC. I have yet to deal with a non-IRC related DoS.
Now, occasionally you have a legitimate user with a legitamate bot running their own channel. They get nuked/DoSed, etc as part of the takeover. In which case you re-enable their account and say 'sorry'. That's perhaps 5% of the time.
As for 'differing religeous viewpoints' that translates in english to 'Trolling for jesus in #foo' where foo generally is a gay pride group. They're wrong, but your client was rude. He (it's always he) needs some cool-off time.
Finally, I'd like to point out that it's a balancing act. You've got to balance the serious strech of 'free speach' of one user verses the legitimate, responsable right to free speach the rest of your users need to have. A DoS dosn't just silence one person, it silences everyone in the area. Is it right to silence one? No. Is it less wrong to uphold the rights of the (responsible) majority? Yes.
No, I'm not trolling. I haven't seen an rationale for a firewall which is any better than "Well, we're too stupid and lazy to lock down N Unix hosts, so we're going to lock down one. Somehow we will become less stupid and lazy because there is only one machine."
I'll bite. First off, there's a number of things you can do with a firewall that you cannot do on a host. First off, we'll start with the reason why we want a firewall. Obviously, we need to connect to the net. If we were just talking to ourselves, the most efficient method would be to not connect at all. So, we have something that needs to be on the net. In the case of/., it's a webserver running on port 80.
Your argument is that having a firewall + N hosts simply means you're wasting resources. In fact, you are allocating them where it's most useful.
First and foremost: human resources. It takes time to process firewall logs. If each and every machine is handling it's own firewall, then you have to go to each and every machine and investigate both firewall logs AND service logs. (You already have to check service logs on each machine) And, of course, you can't have a central log server since that's yet another N+1 situation.
Secondly, computing resources. On a host machine, every packet is handled by the TCP/IP stack. On a dedicated firewall, your firewall (software) can be the ONLY recipient of packets coming from the external interface. This means you don't have to worry about OS level bugs, since your OS is never seeing those packets to begin with. A load balancing solution can generate it's OWN packet to your webserver, rather then passing it on. This means all traffic inside your network is directly under your control, a very good thing. Any attacks relying on wierd TCP options fall on the floor, since the firewall never lets those packets past.
Remember, if it's passing traffic it's a _PACKET FILTER_. A true firewall re-encapsulates the traffic. (as a bonus it can load balance).
Back to the resources point: By your argument, every machine on the net should be running every possible service, since to dedicate any machine for any single service creates a N+1 situation (which for some reason is to be avoided?)
Of course, you're leaving out that many (most) services have maintenence processes that run, taking resources not related to the traffic they recieve. Running all of these takes CPU time. If every machine has to be a webserver AND a firewall, then they all have to process both sets of logs all the time... not the way to conserve resources.
Then we have different hardware requirements... a firewall is an IO/bound process, with generally not a lot of CPU overhead (per packet). It also requires very little state. Compare to a webserver with database backend that has to handle continual processing, both in CPU and RAM. Add in plenty of local filesystem for the logs (because spitting them out over the net is expensive). Factor in those costs and suddenly we're talking about an N +.01 situation.
From a security standpoint, your firewall can (and should) be running completely different software (and possibly hardware) then your systems, so even when it's compromised they still have to deal with the security on your servers.
I also don't trust only using private IP bindings for internal services. All that takes is an upstream(!) compromise and suddenly all your "private" IP space is available to the attacker. If your upstream router is compromised, 5 lines of config turn it into a VPN-tunneling attack source. Of course, you could prevent those packets from getting to your network at all... if you used a firewall. Do you trust your upstream with your security? No? Then don't rely on private addressing schemes.
One other thing. There was only one post that could even be considered infringement. Microsoft's lawyers demanded that seven be removed. Forgetting common carrier status for a moment, would Slashdot have the right to deny Microsoft's demand in their entirety because parts (most of it in fact) aren't legitimate claims? Would it be different if the demand only asked for the removal of the infringing material and nothing more?
In fact, since they claimed 7 posts were infringing, under penalty of perjury, the whole thing is rendered null-and-void, since they have obviously committed perjury. Have you read the seven posts? At least one has nothing to do with their "copywritten trade secret. (How the hell can a trade secret be copywritten? It's two incompatable bits of laws)
When this goes to court, it'll be nice to see them go down for perjury. Having a few of their lawyers chillin in club fed (and disbarred, for that matter) would send a strong message about not tolerating these kinds of strongarm tactics.
--Dan (Feel free to moderate dedundant, I've got no time to read 1400+ comments today)
Good luck trying to get those anymore, most of the major telcos have refused to provision them.
Even then, they sure as hell won't condition them if it competes with their own DSL service (even if you are in a non-serviced area)
Oh, and since he had no idea why they were designed to be connected to a switch... sounds like they are 'dumb' bridges... everything is forwarded. Thus the switch is needed to cut down the amount of traffic sent. Better would be to route it (just use an ethernet port on your router and a crossover.) BEST would be a v.35 interface...
Big tobacco interests caused the reefer-madness scare at the beginning of this century and the subsequent crop of ill-formed, unfair and non-justifiable laws to persecute people who chose to smoke a non-addictive peaceful alternative to alcohol or tobacco
Actually, you're wrong. Phillip-Morris &pals already have 'weedarette' plans prepared in case somehow the anti-green legislation goes away. The actual backing of the laws was due to hemp, and it's commercial (and profitable) compitition in nylon.
Well, I can't disagree with the ruling. As a preliminary injunction, it erred on the side of caution. He treated the code as a 'trade secret', and restricted distribution. That follows from the arguments he was presented.
Now, new strategy. Let's get rid of css-auth. There's a wonderful paper on the actual encryption behind DVDs. Get that PUBLISHED, and have someone create css-auth2 from that source.
Besides, css-auth/css-cat are a pain in the ass to use. Just create libcss that decrypts using a key that you provide, (But does NOT come with one) and perhaps a seperate keygen utility. Since it wasn't reverse engineered, but instead created from a published paper on the weakeness of CSS (Hint: they failed badly. It's only 2^25 bits strong) then this whole trade secret case is moot.
I've seen at least one excellent paper on the weaknesses of CSS. It's an easy matter to look it up, but it needs to be made hardcopy.
Common misperception. Win2k is _NOT_ repeat _NOT_ NT. Thats Win2K professional. This of course, will be priced much like NT. This also means you won't see much of it. Win2k that you will see is Personal and that is a direct successor to win95+bugfix3
And I would be that win'00 is indeed doing the file replacement trick... that would be nice. Of course, any and all microsoft products get to 'upgrade' vxds and dlls.
Actually, they can. Basically, it works like this. They pass a line-item before the fiscal year starts that says "Place decided tax here." Then, by the end of the year, they decide what it is. So it's not retroactive, it's just not finalized by the beginning of the fiscal year.
What, that sounds retroactive to you? It does to me, too. Do your duty as a red blooded american citizen, go shoot some politicians.
A one line change to GCC is NOT your own work. "Your own work" is something you wrote from scratch. The GPL only restricts your options with derivitave works.
In three words, the reason GPL is important to the continuance of free software? "Embrace And Extend". Put GCC in the public domain. Intel releces the Merce^H^H^H^H^HItanium processor, and forks GCC to run on it. At the same time, they give it the ability to use the hidden opcodes in every processor from a 386 on. (Yes, I'm specifically being x86 centric.) The result? Everyone would start using the Intel version. What would happen to the public domain release? It would languish. Nobody likes working on a project that will never be used.
Now, what stops Intel from locking up the source? Absolutly nothing. So now they gain complete ownership of a large body of code for the work they put into one small independant module.
Except, of course, the GPL specifically stops that from happening.
Don't believe it could happen? Most software categories ends up with one dominant app. How many free compilers are there? How many forks of the perl tree? What's the dominant webserver? Heck, where's BCC? (BSD-cc)
Once a program is good enough to be accepted, and has a edge over the others in the category, it takes over. If that is allowed to become closed, the freedom of everyone is restricted.
As for releasing your own source (that you wrote yourself, from scratch) under GPL, it's done to prevent people from taking it away from you. I want the right to CONTINUE to give away my software for free. If someone makes a better program from their own work, so be it. But, in all fairness, can you honestly say it's wrong to prevent them from stealing your work and claiming it as their own?
As for BSD, they write great code. Hopefully nobody abuses that. I prefer not to trust my fellow man that much.
it is. compare against a constant is often equal to subtracting the constant and checking the zero flag. (cmp is a sub but dosn't modify the operands if I remember right. Been too long since I've hit the bit level) Whereas a decrement sets the zero flag for you, so you save an instruction per loop.
From reading other comments, some people are pointing this out as well. So to avoid being redundant, I'll try my hand at some possible solutions.
First off, quality. Probably a simple voting system requiring a registration would suffice. Since it's not a religous issue (no freshly developed code fragment has the religous overtones of VI or EMACS) there shouldn't be too much ballot stuffing. Email registration takes care of the casual skript kiddy.
Simply rating the software on it's stability and efficiency would be nice. Comments on it's usability (how clean is the API) and the like would also be good.
Finding what you're looking for. A much harder topic indeed. Not many people go in looking for a Red-Black tree code fragment, so there probably needs to be some documentation on what functions do what you're after. Pointers to some excellent books on programming also apply.
How about Compatability? The whole thing is useless if every component depends on yet another different piece of software. (Which is why I'm so happy that aprintf is in glibc. That's a major improvement) Perhaps defining common APIs for common functions is a good idea? There's not too many ways to handle string classes, so if they were compatable, eventually they would be mergable into one well-done class instead of 35 mediocre classes. Identifying what is good and what sucks and standardizing should be the primary goal.
Lastly, Licence conflicts. If such a thing is done, to be truly useful it will have to be usable by everyone, not just GPL software. Nobody will contribute if we lock out all BSD style licences. My reccomendation here is that anything that's more then just a fragment of code be LGPL. Moreso, all of it should be linkable into a single LGPLed library. This avoids namespace bloat, as well as./configure bloat. Code fragments? If you really want to GPL the code to free the first node of a linked list, you need to take a large, blunt object and beat yourself with it. Save the GPL for a PROJECT, leave simple coding examples public domain. Let the download counter of your snippet be your reward.
And as soon as such a thing exists, I've got a handful of code of varying utility I'd put in there. timer management, IO, buffering, whatever I've had to write. I'd like to clean out my attic and see if anyone else gets a use out of it.
Obviously a lot of people here are either failing to read the article or having reading comprehension. He's not just saying "Hey, we've got an infinite supply of oil!". He's actually got a theory that explains a lot of things that we've discovered recently. He also has a history of being right. And far from a crackpot who just comes up with things, he spends a lot of time studying the experiments already done in the field. The second value of his theory is that if he forces someone to prove him wrong, they have to do it using new experiments and a new way of thinking, since he already accounts for all or most of the experiments that have been done.
His history of shaking up stagnant fields and forcing them to rethink some of their assumptions is his greatest value. And no, we don't have an infinite supply of hydrocarbons, just a renewable one. This means that if we can find more efficient ways to use our natural resources, we can balance production and consumption. Our current efforts have been to phase out the use entirely, under the assumption that there was a limited supply. With a limited production rate, we can set our goals differently.
It's server-side latency. They're doing a lot of work on the server side... it requires a LOT more horsepower then the clients do. A celeron 450 can't handle more then 8 players without chugging... and this on a local lan! With some tweaking of the server code it should be quite a bit faster and smoother. As is, if you are on a very fast server (high P2 works better then a celeron here) it's a very nice game to play.
Client side I'm only on a 400mhz K6-2, so it's lighter then a lot of games out on that end.
Slashdot Mirror
At that point, it's protected by the first amendment and subject to the restrictions you pointed out. If something is not speech (code is not considered speech, even now) then it dosn't have any first ammendment protections.
Free speech is always legal. Speech is not.
--Dan
The idea is the client sends a request, and waits for for the update. Probably initially it will recieve a dump of current data and display that, waiting for updates as they arrive. Alternately, you can send a sequence number with each update and the client sends it back. Any data that's updated after that date gets sent, again, blocking till the socket gets closed and sending as needed.
I don't believe you need to do multipart/mime for this, since the proxies should _NOT_ know about the internals of HTTP beyond how to get it through the firewall. You're probably fine returning XML snippets for each update 'datagram' you want to send the client.
IRC is a good model. 99% of the time, the client is idle, waiting for more input. It's a persistant socket connection with some header setup (User/nick/MOTD for IRC, URL/Metadata/HTTP headers for you)
Writing a custom server to handle this should be fairly straightforward. Watch out for those buffer overflows, though. ;-)
--Dan
That's one way of putting it.
another would be "I'm willing to sell you 1.5 meg of guaranteed bandwidth if you're willing to actually pay for it."
Let's go back to grade school. Today, we learn about fractions of big numbers!
1.5meg bandwidth costs the ISP between $1000 and $2000, depending on the quality (and how it's delivered.) Your 1.5 meg DSL circuit costs them between $28 and $40, depending on how many they buy. Let's say 30. The ATM circuit that your DSL rides on to the ISP costs them $400-$500 (for 1.5 meg).
Now, jimmy, let's do the math. How much does it cost them to let you leach your warez, pr0n and mp3's full speed, all day?
$1500 + $500 + $30 = $2030.
Now, Johnny, how much does your DSL cost? $79 per month? Call it 80.
So, kate, what fraction of the cost are you paying?
Why, you're paying 8/203's of the cost. We'll call that 1/25th for this assignment.
So, Robby, why shouldn't 24 other people get their turn at the DSL-go-round? They're paying for it too, arn't they?
Bottom line: Put your money where your mouth is. You want to (ab)use a lot of bandwidth, pay for it.
--Dan
I'm sorry, but their ain't no such thing as a free lunch. If you can't afford to be an ISP, sell your buisness to someone who can.
--Dan
I'll bite.
The interstate highway system. One of the few major projects that worked out. Where there's not enough immediate demand for the corperate sector to fill, at least an incentive is in order.
If rural areas arn't getting fiber, open up rights-of-way between the points that are desired and give huge discounts to any carrier willing to lay there. As soon as you get dark fiber in the ground, someone will turn it up.
As an aside, the article is awfully shallow. There's so much network buildout that there is a major fiber shortage. Nobody is getting as much as they need, so it's getting prioritized. Move to a networking center if you want a network. Almost any major city will do.
--Dan
How about blocking any BGP routes advertised by ASs that have refused to fix their broadcast amplifiers?
Basically, fix the problem at the source rather then forcing ISPs to spend hundreds of times more effort cleaning up the mess afterwards. (Hint, kids, dialup is a losing buisness at best. Want all the ISPs to just do webhosting and leave the dialup to the telcos? We _KNOW_ how friendly they are. Right?) Basically, on your proposed blacklist you can list any ISP not backed by a mega-corp, since all the competitive, geek friendly and *GASP* shell-access ISPs are the small guy.
And here's another hint: There usually are "innocent victims" of DoS attacks. If they truly didn't do it, it turns out that they gave their password out to 'a friend' who leaked it out to IRC. That right there is abuse worth getting kicked for.
That said, I will say that occasionally the DoS is malicious, rather then retaliatory. One was aimed at a MUD that the attacker didn't get his way on. A few have been takeovers of specific IRC channels that are not your usual skript-kiddie hangout. Those are the only types I'll take any action to protect. If I find war-bot tools in your account after a DoS, you're gone. If you gave out your password, you're gone. If you go out trolling on IRC, you get a warning. Once.
And hey, talk to your ISP. If that's their atitude you've found an intelligent one because they WILL let you run services on their hardware. They WON'T portscan your machine for servers. They will do everything in their power to protect you _IF_ you are honest (and responsible). But why in hell should I waste time protecting the next generation of net.vandals? Being a skript kiddie is not a free speech issue. It should be a one-way ticket off the internet.
--Dan
--Dan
In fact, even if there were no broadcast multipliers anywhere, that one ISP could still be used to send out the source-forged command packets to the 'zombie' flood networks.
And telling people to turn off ping is a bad idea. Huge sections of the net are broken because idiot admins think that ICMP=Ping, and thus PMTU discovery breaks, packets get blackholed because no ICMP errors are returned... Not Good.
--Dan
It dosn't work that way, actually. People comparing this to terrorism are all wrong. In this case, the terrorists have already achieved their goals. Whatever their target was is offline. At that point, all you can do is try to contain the damage, much like the fire department putting out the fires after a bomb blows up a building.
But then again, RL metaphors suck anyway.
--Dan
I covered this in a previous post, so I'll be brief.
A) Legit accounts don't get DoSed. If they do, they've been cracked. The account provoked the attack by their behavior, 99.9% of the time on IRC, and 95% of the time in the course of channel wars.
B) Secondly, terminating the target is the FIRST thing you should do. This means the DoS has succeeded, and generally means the attacker gloats in his attack and turns it off. (After all, they're (wrongly) afraid of the FBI coming after them, so why leave it on if it's done it's job?) Once they see the victims bot part IRC, they know they've got it. Mind you, this brings up another major point. On the Internet, DoS attacks WORK. As long as they work, they will happen. If you don't terminate the account, it will be kept offline by DoS until the attacker gets bored. It is The Fastest way, by far, to end an attack
As for tracing it back to the source, why bother? Unless you're yahoo or amazon or e*trade, nobody is going to prosecute the kids involved. Period. I've tried. Nobody cares unless you're a big DotCom. Law enforcement is generally completely incompetent and the few people who can do their job are busy doing it (But only for the major cases).
I've also found that reporting cracked boxes and misconfigured network amplifiers is a waste of time. If the admin has two braincells to rub together, they've fixed it already. If they don't, you've just volunteered to fix them, for free. Too bad the kids arn't doing rm -rf * on roothack boxes anymore, that'd at least shut the dammed things down.
--Dan
First off, before everyone gets indignant, I have very rarely seen an 'unprovoked' DoS attack. More often, you have a skript kiddie of your own attempting a channel takeover of some other skript kiddie. At that point, the two escalate hostilities until someone brings out the BFGs... smurf, TFN, whatever. If your kiddie does it first, you get to save your logs for when the FBI comes with a subpoena. If he isn't as quick on the draw, you wait for the other kiddie to get bored before you can get your buisness back online. Either outcome sucks.
The first thing I do when I see a DoS is I take out whatever their target is. It's gonna get killed anyway, might as well hurry up the process. If it's a colo, their eithernet goes. If it's an eggie, it dies. If it's a dialup... well, it's already offline. I disable the account.
Second stage is to determine _WHY_ the attack happened. I generally don't bother calling the kiddie in question because they always lie about what they were doing, when a quick glance at their eggdrop tells you what hostilities were involved. This usually involves lurking on IRC. I have yet to deal with a non-IRC related DoS.
Now, occasionally you have a legitimate user with a legitamate bot running their own channel. They get nuked/DoSed, etc as part of the takeover. In which case you re-enable their account and say 'sorry'. That's perhaps 5% of the time.
As for 'differing religeous viewpoints' that translates in english to 'Trolling for jesus in #foo' where foo generally is a gay pride group. They're wrong, but your client was rude. He (it's always he) needs some cool-off time.
Finally, I'd like to point out that it's a balancing act. You've got to balance the serious strech of 'free speach' of one user verses the legitimate, responsable right to free speach the rest of your users need to have. A DoS dosn't just silence one person, it silences everyone in the area. Is it right to silence one? No. Is it less wrong to uphold the rights of the (responsible) majority? Yes.
--Dan
I'll bite. First off, there's a number of things you can do with a firewall that you cannot do on a host. First off, we'll start with the reason why we want a firewall. Obviously, we need to connect to the net. If we were just talking to ourselves, the most efficient method would be to not connect at all. So, we have something that needs to be on the net. In the case of /., it's a webserver running on port 80.
Your argument is that having a firewall + N hosts simply means you're wasting resources. In fact, you are allocating them where it's most useful.
First and foremost: human resources. It takes time to process firewall logs. If each and every machine is handling it's own firewall, then you have to go to each and every machine and investigate both firewall logs AND service logs. (You already have to check service logs on each machine) And, of course, you can't have a central log server since that's yet another N+1 situation.
Secondly, computing resources. On a host machine, every packet is handled by the TCP/IP stack. On a dedicated firewall, your firewall (software) can be the ONLY recipient of packets coming from the external interface. This means you don't have to worry about OS level bugs, since your OS is never seeing those packets to begin with. A load balancing solution can generate it's OWN packet to your webserver, rather then passing it on. This means all traffic inside your network is directly under your control, a very good thing. Any attacks relying on wierd TCP options fall on the floor, since the firewall never lets those packets past.
Remember, if it's passing traffic it's a _PACKET FILTER_. A true firewall re-encapsulates the traffic. (as a bonus it can load balance).
Back to the resources point: By your argument, every machine on the net should be running every possible service, since to dedicate any machine for any single service creates a N+1 situation (which for some reason is to be avoided?)
Of course, you're leaving out that many (most) services have maintenence processes that run, taking resources not related to the traffic they recieve. Running all of these takes CPU time. If every machine has to be a webserver AND a firewall, then they all have to process both sets of logs all the time... not the way to conserve resources.
Then we have different hardware requirements... a firewall is an IO/bound process, with generally not a lot of CPU overhead (per packet). It also requires very little state. Compare to a webserver with database backend that has to handle continual processing, both in CPU and RAM. Add in plenty of local filesystem for the logs (because spitting them out over the net is expensive). Factor in those costs and suddenly we're talking about an N + .01 situation.
From a security standpoint, your firewall can (and should) be running completely different software (and possibly hardware) then your systems, so even when it's compromised they still have to deal with the security on your servers.
I also don't trust only using private IP bindings for internal services. All that takes is an upstream(!) compromise and suddenly all your "private" IP space is available to the attacker. If your upstream router is compromised, 5 lines of config turn it into a VPN-tunneling attack source. Of course, you could prevent those packets from getting to your network at all... if you used a firewall. Do you trust your upstream with your security? No? Then don't rely on private addressing schemes.
--Dan
In fact, since they claimed 7 posts were infringing, under penalty of perjury, the whole thing is rendered null-and-void, since they have obviously committed perjury. Have you read the seven posts? At least one has nothing to do with their "copywritten trade secret. (How the hell can a trade secret be copywritten? It's two incompatable bits of laws)
When this goes to court, it'll be nice to see them go down for perjury. Having a few of their lawyers chillin in club fed (and disbarred, for that matter) would send a strong message about not tolerating these kinds of strongarm tactics.
--Dan (Feel free to moderate dedundant, I've got no time to read 1400+ comments today)
Even then, they sure as hell won't condition them if it competes with their own DSL service (even if you are in a non-serviced area)
Oh, and since he had no idea why they were designed to be connected to a switch... sounds like they are 'dumb' bridges... everything is forwarded. Thus the switch is needed to cut down the amount of traffic sent. Better would be to route it (just use an ethernet port on your router and a crossover.) BEST would be a v.35 interface...
--Dan
Actually, you're wrong. Phillip-Morris &pals already have 'weedarette' plans prepared in case somehow the anti-green legislation goes away. The actual backing of the laws was due to hemp, and it's commercial (and profitable) compitition in nylon.
Blame the right megacorps, please.
--Dan
--Dan
Now, new strategy. Let's get rid of css-auth. There's a wonderful paper on the actual encryption behind DVDs. Get that PUBLISHED, and have someone create css-auth2 from that source.
Besides, css-auth/css-cat are a pain in the ass to use. Just create libcss that decrypts using a key that you provide, (But does NOT come with one) and perhaps a seperate keygen utility. Since it wasn't reverse engineered, but instead created from a published paper on the weakeness of CSS (Hint: they failed badly. It's only 2^25 bits strong) then this whole trade secret case is moot.
I've seen at least one excellent paper on the weaknesses of CSS. It's an easy matter to look it up, but it needs to be made hardcopy.
--Dan
And I would be that win'00 is indeed doing the file replacement trick... that would be nice. Of course, any and all microsoft products get to 'upgrade' vxds and dlls.
--Dan
What, that sounds retroactive to you? It does to me, too. Do your duty as a red blooded american citizen, go shoot some politicians.
--Dan
In three words, the reason GPL is important to the continuance of free software? "Embrace And Extend". Put GCC in the public domain. Intel releces the Merce^H^H^H^H^HItanium processor, and forks GCC to run on it. At the same time, they give it the ability to use the hidden opcodes in every processor from a 386 on. (Yes, I'm specifically being x86 centric.) The result? Everyone would start using the Intel version. What would happen to the public domain release? It would languish. Nobody likes working on a project that will never be used.
Now, what stops Intel from locking up the source? Absolutly nothing. So now they gain complete ownership of a large body of code for the work they put into one small independant module.
Except, of course, the GPL specifically stops that from happening.
Don't believe it could happen? Most software categories ends up with one dominant app. How many free compilers are there? How many forks of the perl tree? What's the dominant webserver? Heck, where's BCC? (BSD-cc)
Once a program is good enough to be accepted, and has a edge over the others in the category, it takes over. If that is allowed to become closed, the freedom of everyone is restricted.
And if Intel decides to have a "nice" licence for a few years, it will happen even faster. But nothing would prevent them from doing it, since if it's public domain, THEY own the code. And under your definition of "your own work", all of GCC became theirs the second they put "This program ©Intel corp." in the source.
As for releasing your own source (that you wrote yourself, from scratch) under GPL, it's done to prevent people from taking it away from you. I want the right to CONTINUE to give away my software for free. If someone makes a better program from their own work, so be it. But, in all fairness, can you honestly say it's wrong to prevent them from stealing your work and claiming it as their own?
As for BSD, they write great code. Hopefully nobody abuses that. I prefer not to trust my fellow man that much.
--Dan
You europeans have no clue just how BIG the US really is.
--Dan
it breaks down to:
add 1
compare 10
jump if zero
versus:
subtract 1
jump if zero
--Dan
First off, quality. Probably a simple voting system requiring a registration would suffice. Since it's not a religous issue (no freshly developed code fragment has the religous overtones of VI or EMACS) there shouldn't be too much ballot stuffing. Email registration takes care of the casual skript kiddy.
Simply rating the software on it's stability and efficiency would be nice. Comments on it's usability (how clean is the API) and the like would also be good.
Finding what you're looking for. A much harder topic indeed. Not many people go in looking for a Red-Black tree code fragment, so there probably needs to be some documentation on what functions do what you're after. Pointers to some excellent books on programming also apply.
How about Compatability? The whole thing is useless if every component depends on yet another different piece of software. (Which is why I'm so happy that aprintf is in glibc. That's a major improvement) Perhaps defining common APIs for common functions is a good idea? There's not too many ways to handle string classes, so if they were compatable, eventually they would be mergable into one well-done class instead of 35 mediocre classes. Identifying what is good and what sucks and standardizing should be the primary goal.
Lastly, Licence conflicts. If such a thing is done, to be truly useful it will have to be usable by everyone, not just GPL software. Nobody will contribute if we lock out all BSD style licences. My reccomendation here is that anything that's more then just a fragment of code be LGPL. Moreso, all of it should be linkable into a single LGPLed library. This avoids namespace bloat, as well as ./configure bloat. Code fragments? If you really want to GPL the code to free the first node of a linked list, you need to take a large, blunt object and beat yourself with it. Save the GPL for a PROJECT, leave simple coding examples public domain. Let the download counter of your snippet be your reward.
And as soon as such a thing exists, I've got a handful of code of varying utility I'd put in there. timer management, IO, buffering, whatever I've had to write. I'd like to clean out my attic and see if anyone else gets a use out of it.
--Dan
His history of shaking up stagnant fields and forcing them to rethink some of their assumptions is his greatest value. And no, we don't have an infinite supply of hydrocarbons, just a renewable one. This means that if we can find more efficient ways to use our natural resources, we can balance production and consumption. Our current efforts have been to phase out the use entirely, under the assumption that there was a limited supply. With a limited production rate, we can set our goals differently.
Client side I'm only on a 400mhz K6-2, so it's lighter then a lot of games out on that end.
--Dan