What about packet loss / mixup / duplication? Since you get no feedback from the knocks, there's no way to tell if some of them got lost or otherwise screwed up, hence your OTPs can get out of sync. How do you detect this, and how do you resync?
The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer.
That reminds me of a Steve Martin joke: How to get A MILLION DOLLARS and PAY NO TAXES. First, get a million dollars. Then, don't pay any taxes.
Golly, port knocking doesn't protect against an attacker standing behind me and watching what I type either. And it doesn't protect against someone opening up the computer with a screwdriver and taking out the disk drives. It doesn't even protect against someone capturing me and forcing me to confess the secret sequence.
On the other hand, it does offer an extra layer of protection against 99.999% of Internet-based attacks, so maybe it has some benefit after all.
If your Comcrap smegment is anything like mine, the bandwidth due to the ARP drizzle is negligible. It's about 10-20 kbit/second here, i.e. about 1% of my bandwidth allocation. Yeah, it's annoying because it keeps the activity LEDs lit up at all times, but it's not really wasting bandwidth.
Not even! It was the threat of HTTP GET requests -- SCO deleted the DNS for www.sco.com pre-emptively, before the worm even got a chance to attack. Their web page is currently available at sco.com apparently none the worse for the wear.
Could they have withstood the attack transparently by 302-redirecting www.sco.com to sco.com? Maybe yes, maybe no; we'll never know. Not that it matters either way -- with no products and no customers, they have little need for a reliable web site anyway.
It's already impossible to spoof your IP address in TCP/IPv4. Sure, you can forge a bogus source IP address on the SYN but you'll never get the ACK so you can't complete the connection, and any data you transmit will be ignored. The best you can do with address spoofing in TCP/IPv4 is a SYN flood DoS attack; you certainly can't send any spam with a forged source IP address. (Route it through a proxy/relay/zombie? You can do that in IPv6 too.)
There's a typical newbie programming error in the date comparison code in the trojan. In WIN32, dates are stored as a 64-bit struct of two 32-bit integers. Instead of using the system API to compare dates, or writing their own correct 64-bit integer comparison, they just compared each 32-bit integer separately like this:
if (u1 > v1 && u2 > v2) { attack(); }
Beginner programmers have been making that same mistake since the beginning of time....
The upshot is that the attack still happens, but with about a 25% duty cycle -- 2 minutes on, 6 minutes off, etc.
Right on, brother. This worm is bad because it fucks up innocent people's computers and increases the spam load on everybody, not because it attacks SCO. The latter almost makes up for the former. Almost. But not quite. If I catch the guy who set this thing loose there probably won't be anything left to turn in for a reward.
(Now that I'm buying Lian Li aluminum cases, I'll probably start swapping motherboards into cheaper steel cases, and putting new motherboards into the Lian Li case.)
Good luck squeezing your new BTX motherboard into that Lian Li ATX case!
Same here, and that's because it actually was a bounce. The worm forged my address when it spammed itself out to some non-existent address, whose MTA dutifully bounced the entire mess "back" to me. Too bad that receiving MTA ignored my domain's SPF records.... Fortunately I was able to identify the user at the original sending IP address and warn them about being infected.
I'll bet someone you know has been infected and their copy of the worm is forging your email address (along with whatever else it found in their address book).
Remember, this thing has an SMTP client built into it, so it has to be able to send strings like "HELO" and "RCPT", which do not appear anywhere in the executable. Clearly there's some serious text obfuscation going on here, and any plaintext strings that we see in the executable are most likely decoys.
Also I've been getting tons of these aimed at (common-first-name)@(my-domain) which implies that it has a common first name dictionary in it somewhere, which we also don't see anywhere in the executable.
I haven't installed a Windows security update in years, and my Windows 2000 systems are definitely not r00ted. I have this thing called a "firewall", and I don't use Internet Explorer or Outlook. If I didn't mind wasting electricity I could have left these machines on for months at least.
Is XP that much more vulnerable than 2000? What vulnerabilities besides IE and Outlook can be attacked through a firewall? Or do you consider a host with an unroutable address behind a NAT firewall to be not "connected to the Internet"?
Hey, if it cuts down on the silly crap my relatives and casual acquaintances forward to me, I'm all for it. Maybe those lusers will think twice about hitting the Forward To Entire Address Book every time they see a picture of a kitten.
If you really want Joe to get your message, you won't mind the slight risk of having to pay someone a few cents if you happen to fat-finger the address. Also, consider your hypothetical situation from Joel's perspective -- he really does have to spend a few cents' worth of his time trying to figure out who the heck you are and what you're talking about before he can decide it was a "wrong number" that he can just ignore. If he wants to bill you (who made the mistake that wasted his time) a few cents for the trouble, I'd say that's his right.
it's a violation of Serman Networks TOS, not copyright infringement
If they violate the TOS then (at least according to the doctrine of the EULA) they have no right to use Kazaa or any derivative work at all. According to Sharman, whatever software RIAA used to access the Kazaa network was an unlicensed derivative work of Kazaa, which implies copyright infringement.
If you could somehow go back to those times you'd probably discover they weren't really all that fun either.
Re:IPv6 is MUCH more than a replacement for IPv4
on
The State of IPv6
·
· Score: 1
I'm not opposed to IPV6. I have no opinion about it, really.
My quick&dirty IPV4 solution to the problem you pose -- assuming no universal plug&play webserver/appliance multiplexing protocol in the futuristic 5-years-from-now world -- is port forwarding. Yeah, you have to flip a switch in your router config to enable it. But you'd have to flip a switch anyway to give the outside world access your PVR through your firewall -- and you'd almost certainly want to configure some kind of authentication and access control too. So plug&play in this case isn't, really.
Just hooking everything up directly to the public internet without configuration may be a lot easier with IPV6 but it's not really a good idea! Since you're going to have to configure something somewhere anyway, IPV4 doesn't put that much more of a hurdle in the way. We can make do with IPV4+NAT for a long while yet, even with TCP/IP embedded in every appliance, fixture, tool, box of cereal, whatever, by having a single server on a single public address acting as a gateway for many small appliances. Personally I think it's a bad idea to put every little gizmo with its own embedded webserver directly onto the public internet, either with a unique public address or with port forwarding.
Obviously IP-enabled mobile devices present some very good reasons for moving to a larger address space, but all the nifty IP-everywhere-world-of-the-future devices listed in the quote I was responding to were fixed-position and could be easily handled with a restricted and multiplexed address space.
Maybe he enjoys posting on Slashdot, but doesn't enjoy listening some salesman blather on and on about some half-baked nonsense? Doing what you enjoy is not a waste of time.
As a "professional" (whatever that means) I might hesitate to tell a customer or client to stop wasting my time, but I certainly wouldn't hesitate to say it to some random jackass who walked in off the street and tried to extort money out of me using vague and wildly implausible claims.
So they asked IBM for all the code that IBM has written, trying to find out exactly what code from IBM made it into both Unix and Linux. This leads me to the conclusion that they consider all code written by IBM for Unix to belong to SCO as a 'derivative work'.
Not quite. AT&T's standard Unix source license included a clause about maintaining confidentiality of derivative works. SCO doesn't claim that JFS et al are SCO's property, only that since those features were developed as part of a derivative work of Unix (AIX) IBM must keep them confidential along with the rest of their Unix derivative. Since SCO does not have automatic access to the AIX source code or its change-logs they can't necessarily tell which parts of AIX ended up in Linux, which is why they need to see IBM's AIX code and detailed records about how and when it was written. In their suit they present a lot of circumstantial evidence that IBM must have violated that "keep confidential" clause in making such sweeping improvements in Linux so quickly, but they can't show any detailed evidence until they can get ahold of the AIX code during discovery. They also need records pertaining to which IBM employees developed which parts of AIX and Linux in order to find "smoking gun" confidentiality leaks.
SCO's case against IBM is not about copyright at all, it's about an alleged violation of an obscure and subtle clause of a contract which may or may not actually apply to IBM.
As far as I can tell, most of the noise SCO is making in the press, and all these extortion letters they're sending out to Linux users, have nothing whatsoever to do with their suit against IBM. They just happened to start about the same time as part of an "intellectual property enforcement" campaign. SCO basically noticed that all that wonderful Unix IP they bought at bargain-basement prices really was worthless as a product, having been superceded by something that's effectively exactly the same, but better. Hmm, exactly the same, what a coincidence....
Re:IPv6 is MUCH more than a replacement for IPv4
on
The State of IPv6
·
· Score: 1
That's like saying residential telephone users don't need to have a phone number at which they can be reached.
No, it's like saying residential telephone users don't need a separate number for every phone in the house. Which they don't.
None of those gee-whiz services listed in the article require IPV6 or separate per-device addresses. They can all be aggregated and gatewayed through shared addresses, and arguably should be for many reasons. E.g. imagine exploitable web server bugs in every camera, refrigerator, thermostat, traffic sensor, etc, etc, and having to keep them all patched and operational separately. Alternatively you can have a single web server handling public queries, doing proper authentication, and aggregating and presenting data from the various data-collecting devices according to a single set of configuration profiles. IMHO that would be much more maintainable.
Better a few spam get through than to be blocking mail from non-offending ip addresses.
Actually, that's backwards. It's better to get a positive rejection during the SMTP session so the sender immediately knows their message was not delivered and can attempt some other means of communication, rather than to have enough real spam get through that legit messages get accidentally JHD'd. ("JHD" = "Just Hit Delete", as in, "What's the problem? If someone sends you spam, why not Just Hit Delete like I do?") Legit mail that gets accidentally deleted in a spam flood just disappears without a trace, nobody knows where it went; the sender doesn't know it wasn't received, the receiver doesn't know it was sent. This is true whether the "JHD" was done by a human manually hitting "Delete" on the wrong message (easy enough to do) or by a spam filter making a mistake (which does happen, regardless of what the Bayesian filter fans claim).
RBL blocking is commonly handled by rejecting the SMTP session. This means the originating MTA knows the message couldn't be delivered and can send a "bounce" message to that effect back to the sender. Unless the sender's MTA is very badly broken the delivery this "bounce" is effectively guaranteed, so the sender finds out right away that their message was not delivered. This is a good thing! Well, not as good as their message actually being delivered, but the ongoing deluge of spam has pretty much made that impossible to guarantee. At least knowing what went wrong is the next best thing.
Slashdot Mirror
What about packet loss / mixup / duplication? Since you get no feedback from the knocks, there's no way to tell if some of them got lost or otherwise screwed up, hence your OTPs can get out of sync. How do you detect this, and how do you resync?
Golly, port knocking doesn't protect against an attacker standing behind me and watching what I type either. And it doesn't protect against someone opening up the computer with a screwdriver and taking out the disk drives. It doesn't even protect against someone capturing me and forcing me to confess the secret sequence.
On the other hand, it does offer an extra layer of protection against 99.999% of Internet-based attacks, so maybe it has some benefit after all.
If your Comcrap smegment is anything like mine, the bandwidth due to the ARP drizzle is negligible. It's about 10-20 kbit/second here, i.e. about 1% of my bandwidth allocation. Yeah, it's annoying because it keeps the activity LEDs lit up at all times, but it's not really wasting bandwidth.
A nerd fixates on technology, science, math. I'm a nerd, not a geek. Are you really a geek?
Could they have withstood the attack transparently by 302-redirecting www.sco.com to sco.com? Maybe yes, maybe no; we'll never know. Not that it matters either way -- with no products and no customers, they have little need for a reliable web site anyway.
It's already impossible to spoof your IP address in TCP/IPv4. Sure, you can forge a bogus source IP address on the SYN but you'll never get the ACK so you can't complete the connection, and any data you transmit will be ignored. The best you can do with address spoofing in TCP/IPv4 is a SYN flood DoS attack; you certainly can't send any spam with a forged source IP address. (Route it through a proxy/relay/zombie? You can do that in IPv6 too.)
if (u1 > v1 && u2 > v2) { attack(); }
Beginner programmers have been making that same mistake since the beginning of time....
The upshot is that the attack still happens, but with about a 25% duty cycle -- 2 minutes on, 6 minutes off, etc.
Right on, brother. This worm is bad because it fucks up innocent people's computers and increases the spam load on everybody, not because it attacks SCO. The latter almost makes up for the former. Almost. But not quite. If I catch the guy who set this thing loose there probably won't be anything left to turn in for a reward.
I'll bet someone you know has been infected and their copy of the worm is forging your email address (along with whatever else it found in their address book).
Also I've been getting tons of these aimed at (common-first-name)@(my-domain) which implies that it has a common first name dictionary in it somewhere, which we also don't see anywhere in the executable.
Is XP that much more vulnerable than 2000? What vulnerabilities besides IE and Outlook can be attacked through a firewall? Or do you consider a host with an unroutable address behind a NAT firewall to be not "connected to the Internet"?
If you really want Joe to get your message, you won't mind the slight risk of having to pay someone a few cents if you happen to fat-finger the address. Also, consider your hypothetical situation from Joel's perspective -- he really does have to spend a few cents' worth of his time trying to figure out who the heck you are and what you're talking about before he can decide it was a "wrong number" that he can just ignore. If he wants to bill you (who made the mistake that wasted his time) a few cents for the trouble, I'd say that's his right.
Or something like that.
If you could somehow go back to those times you'd probably discover they weren't really all that fun either.
My quick&dirty IPV4 solution to the problem you pose -- assuming no universal plug&play webserver/appliance multiplexing protocol in the futuristic 5-years-from-now world -- is port forwarding. Yeah, you have to flip a switch in your router config to enable it. But you'd have to flip a switch anyway to give the outside world access your PVR through your firewall -- and you'd almost certainly want to configure some kind of authentication and access control too. So plug&play in this case isn't, really.
Just hooking everything up directly to the public internet without configuration may be a lot easier with IPV6 but it's not really a good idea! Since you're going to have to configure something somewhere anyway, IPV4 doesn't put that much more of a hurdle in the way. We can make do with IPV4+NAT for a long while yet, even with TCP/IP embedded in every appliance, fixture, tool, box of cereal, whatever, by having a single server on a single public address acting as a gateway for many small appliances. Personally I think it's a bad idea to put every little gizmo with its own embedded webserver directly onto the public internet, either with a unique public address or with port forwarding.
Obviously IP-enabled mobile devices present some very good reasons for moving to a larger address space, but all the nifty IP-everywhere-world-of-the-future devices listed in the quote I was responding to were fixed-position and could be easily handled with a restricted and multiplexed address space.
Maybe he enjoys posting on Slashdot, but doesn't enjoy listening some salesman blather on and on about some half-baked nonsense? Doing what you enjoy is not a waste of time.
As a "professional" (whatever that means) I might hesitate to tell a customer or client to stop wasting my time, but I certainly wouldn't hesitate to say it to some random jackass who walked in off the street and tried to extort money out of me using vague and wildly implausible claims.
SCO's case against IBM is not about copyright at all, it's about an alleged violation of an obscure and subtle clause of a contract which may or may not actually apply to IBM.
As far as I can tell, most of the noise SCO is making in the press, and all these extortion letters they're sending out to Linux users, have nothing whatsoever to do with their suit against IBM. They just happened to start about the same time as part of an "intellectual property enforcement" campaign. SCO basically noticed that all that wonderful Unix IP they bought at bargain-basement prices really was worthless as a product, having been superceded by something that's effectively exactly the same, but better. Hmm, exactly the same, what a coincidence....
None of those gee-whiz services listed in the article require IPV6 or separate per-device addresses. They can all be aggregated and gatewayed through shared addresses, and arguably should be for many reasons. E.g. imagine exploitable web server bugs in every camera, refrigerator, thermostat, traffic sensor, etc, etc, and having to keep them all patched and operational separately. Alternatively you can have a single web server handling public queries, doing proper authentication, and aggregating and presenting data from the various data-collecting devices according to a single set of configuration profiles. IMHO that would be much more maintainable.
RBL blocking is commonly handled by rejecting the SMTP session. This means the originating MTA knows the message couldn't be delivered and can send a "bounce" message to that effect back to the sender. Unless the sender's MTA is very badly broken the delivery this "bounce" is effectively guaranteed, so the sender finds out right away that their message was not delivered. This is a good thing! Well, not as good as their message actually being delivered, but the ongoing deluge of spam has pretty much made that impossible to guarantee. At least knowing what went wrong is the next best thing.
Just who the fuck else is supposed to appoint an activist?