Other than the production of tons of very highly radioactive waste forwhich, to date, we have no effective means of disposal.
When's the last time a coal fired plant rendered an area permanently uninhabitable? When a coal plant blows up, you wait for the fire to go out and build a new one. When a nuke plant blows, it makes the area around it (possibly for hundreds of miles) too radioactive for humans to live there. [granted, we've only had such a thing happen once. So far.]
(I'm not sayin' nuke's are bad. I'm just sayin' they present a number of problems, too.)
It doesn't necessarily have to be dynamic DNS. Merely by listing a machine in DNS, you are indicating it's status as "up and available". And it's just about as reliable as any P2P gatekeeper -- applications crash, people turn off things, networks do break, etc. so it's very likely for the "database" to be inaccurate w.r.t. one's availability.
Re:Presence Servers in VOIP, IM have Prior Art
on
Net2phone Sues Skype
·
· Score: 2, Informative
Funny you mention Cisco... they actually do use SIP these days. Skinny, while depreciated and "removed from IOS" long ago, is still present and functional in IOS 12.4.
W.r.t. STMP, Microsoft's "Remote Help" does exactly this. It'll email an XML attachment to the "helper" which tells the remote desktop client where to connect.
If you want prior art, look no further than FTP -- PORT and later PASV both communicate an IP address for "direct communication." (granted, there's no "database" involved.)
Maybe, maybe not. The raid made no difference on the saturation of my cablemodem. AZ has been pumping out 24kb/s continuously for months. (except when I forget to start it after Winblows weekly patchfest "requires" me to reboot.) TPB may be LARGE, but they are not the totality of bittorrent.
Also, keep in mind, TPB's servers were not the only ones taken. In this, it's not very different from an ISP/Host dropping off the planet.
... and would do ZERO damage. Most drives made in the last ~5 years can take a 300G (three zero zero, three HUNDRED) shock when not running. In some drives, the heads are parked completely off the surface of the disk (mostly laptop drives.) Others park the heads (locked, I might add) at the center of the platters... in contact with the platter. If it's not spinning, it's very difficult to damage the disk by simply dropping it.
You'll have to work a lot harder to destroy a drive. A sledgehammer comes in handy... most people not having a blast furnace, or a metal shredder.
First, the USPS is NOT a reliable transport. They do lose, destroy, and otherwise misdeliver items. Every. Day. Statistically, they have a high sucess rate, but they move a huge number of things around every day -- 0.001% lose turns out to be a big-ass number of lost postcards and fruit cakes. Second, "registered" mail only means the carrier put it in A mailbox. It is not a 100% blanket certainty that it was (a) put in the correct mailbox, (b) actually seen by the addressee, or (c) not subsequently removed from the mailbox by the postal service.
Unless it's delivered and signed for in person, there's no guarantee it's been delivered. This is why process servers ask for you by name and hand you the papers in person.
... this is almost certainly a highly deceptive account, incorrectly reported....
You are just as much in the dark as we are, so you're simply guessing. Maybe you don't make this kind of mistake. Maybe the firm(s) where you've worked are the few good, upstanding, ethical law firms that never make any mistakes. (most likely y'all are simply better at covering your oopses.)
However, it's also entirely possible the firms involved dropped the ball and actually did file without his legal authorization -- and possibly despite his request to remain anonymous. We don't have the complete story, assuming there's one to be had.
No, the paralegals and clerks dot the i's and cross the t's. If you'd seen a single word doc directly from almost any lawyer, you'd wonder how anything ever gets done. They are, in fact, as bad or worse than the average slashdot geek. ('tho far more entertaining.)
It won't actually get hot enough to burst into flame (unless you've rigged it.) It'll eventually get so hot the processor fails, and then it stops getting hotter. I have the same problem with my non-mac laptop -- sony didn't really design it to run at 100% constantly... after about 12hrs the processor locks up. (I keep it underclocked when I'm doing stuff like that.)
There are non-tivo people that know how exactly how the little boxes work. (and I can atest, first hand, it's not that hard to figure out.) If Tivo went the way of the dodo, I'm certain their knowledge would bubble to the surface -- most of it's already out there, but you've gotta know where to go sniffing.
Simple... the people who know how this sort of stuff work love their tivo and will do nothing to kill them. Plus, there's no reason to do so; one can build a functionally equiv. system with MythTV and any number of tv listing scripts.
Most ("some"?) RR areas already filter port 25. You cannot send email directly from your cable modem to the world; it must first be handed to one of RR's MICROSOFT SMTP servers. Mindspring/Earthlink does the same to all their dialup users (or used to.) But, surprisingly, they don't do it to their cable modem users (i.e. RR users with Mindspring IP's.)
Honestly, it's not really something for RR to fix, nor something they actually can fix. After all, they cannot stop the billions of clueless fscks from placing Windows machines naked on the Internet. However, we, as email admins, can easily block them all. (24/8 was specifically set aside for cable modem use, but I doubt ARIN is being held to that anymore.)
[Comcast and Rogers also do this. And so do various Hilton's around the country:-)]
Actually, it's rpmbuild -ba <spec file> . And the spec file for 90+% of the stuff was written a long time ago -- and, honestly, they aren't that hard to create. The hard work is in all the little patchy bits they do to screw with everything they sell. And, in theory, quality control, but the whole story behind Fedora is to foist that process on the "free loaders".
It can be done. With the removal of ataraid, the kernel will not automatically detect them. Some smarty thought it was better to force everyone to use an initrd and 100% userland crap to setup one's root volume. *I* think forcing anyone to use an initrd is a patently stupid f'ing idea. Doing so makes it trivial to break a system, and difficult to repair.
As I said, it. does. not. work. like. that. The NOTIFY has to appear to come from a master server. Assuming one can get the timing exactly right and fake the SOA QUERY result, all it will do is trigger a zone transfer from that master server; an (optionally) authenticated process done via TCP, not UDP, and thus not generally succeptable to ip spoofing. No where in there is there a place for a 3rd party to specify where to send/receive anything. The slave is only going to talk to the master(s) it's explicitly configured to use.
The whole "DDoS by hacking someone's zone file", AGAIN, has nothing at all to do with enabling or disabling recursion. In this case, you've managed to replace an AUTHORITATIVE RECORD forwhich the server will ALWAYS answer; it's authoritative for the domain, so it has to. Historically, such crap has been done by buffer overflows compromising the entire DNS server, and less often by specific, complex cache/internal db poisoning attacks -- both the result of bugs in the dns server, unrelated to "recursion on".
Key words: with a spoofed IP address of your target
Ah, thanks for the picture. Recursion isn't the problem. IP Spoofing is the problem. Turning off recursion is only a band-aid...
If you are successfully spoofing the address of your target, disabling recursion won't prevent you from making requests. You can ask the dns servers for authoritative information or simply make non-recursive queries. The replies may be smaller, but they'll be larger than the requests. (once it's in cache, it no longer needs to be a recursive query. the trick then is to get it into the cache.)
Preventing IP spoofing (both at the router and the dns server) will stop this sort of crap.
I don't think you understand what NOTIFY is or how it works:
When a slave receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.
Why doesn't the slave simply take the master's word that the zone has changed? It's possible that a miscreant could forge NOTIFY announcements to slaves, causing lots of unnecessary zone transfers and amounting to a denial-of-service attack against a master name server.
First off, it only applies to authoritative zones which means there aren't any caches to exploit. Second, query recursion and dns notify are completely unrelated.
If you send a NOTIFY for a domain that isn't a slave, the server will ignore it. Even if you happen to be in a position to mount a man-in-the-middle attack and forge the SOA QUERY results, all you'll manage to do is trigger a zone transfer -- which happens over TCP, not UDP, so poisoning the zone will be much more difficult. But we're straying off topic... this has nothing to do with recursion, nor is it a DDoS. (and very few people are in a position to mount such an exploit.)
Notify messages are validated, if not authenticated. They have to come from a configured master or they're ignored. At best, for each NOTIFY properly forged, 2 (*two*) packets, almost exactly the same size, will be generated: the NOTIFY response, and a QUERY for the SOA. If a 2x amplification is enough to be an effective DDoS, then it's very likely the script kiddie's zombie botnet is large enough to not need any amplification. Oh yeah, and the entire process is hinged on IP SPOOFING, not on the status of any dns server's "query recursion" settings.
Disabling recursive queries on public dns servers, and properly configuring the feature on internal dns servers is a good practice. HOWEVER, it's not the solution to using DNS servers in DDoS attacks. It is at best, a small part of the solution. All of this depends on successful ip spoofing; and that is what needs to be fixed, but because of lazy, and/or incompotent networking professionals, ip spoofing is going to be with us for a long time. (we've had the necessary technology for nearly a decade.)
Turning off recursion won't prevent such attacks. At best, the script kiddies will simply stop sending requests to your server(s).
Think about... The zombies can fire spoofed requests at the target dns server just as easily as an open server. And they can do so at the exact same rate. When the zombie sends a request to an open server, that server is going to send basically the exact same request on to the target. The request won't magically be 3x larger. And one zombie request will not be magnified into more than one target request. (ignoring timeouts.) There's no need for a middle man either, since the source is spoofed anyway.
The only reason to turn off recursion is to stop people from consuming your resources (maybe killing your server), and limit one avenue of possible bugs that could compromise the server.
Right. I left off the bit about "WHERE" being mostly useless. Zombie or not, that *is* where the spam came from. It's surprisingly helpful to ban those addresses and even the surrounding netblock(s). The DNS server IP(s) are completely useless -- I've never seen a spammer hosting his own DNS. Banning the dns server address(s) won't do much to stop the spam, but could break a number of things.
The attacks work in the following manner: a malicious attacker sends several thousand spoofed requests to a DNS server that allows recursion. The DNS server processes these requests as valid and then returns the DNS replies to the spoofed recipient (i.e., the victim). -- US-CERT
You'd think CERT would have enough sense to realize, recursion is not the problem here. Spoofed. F***ing. Requests. Are the problem. Recursion will add to the load of any dns servers in the party, but disabling recursion will NOT stop a DDoS from spoofed requests. If the server answers the request at all, it's participating in the DDoS.
In a DNS amplification DDoS, attackers use a botnet to send a large volume of requests to DNS servers, spoofing the target's URL [correction: IP] as the "from" address on the request. Instead of responding to the machines in the botnet, the DNS servers send responses to the target, in this case stormpay.com. Because nameserver responses can be significantly larger than DNS requests, the attack can be amplified. -- NetCraft
... and recursion doesn't matter at all. This works even with a properly secured, non-recursing server. The ONLY way to stop such attacks is for networking professionals to properly configure their networks to prevent IP spoofing. It's not that hard to do with modern router hardware.
If you're running an open DNS server, you're very likely participating in someonelse's DDoS attack and have been for the last couple years.
Then please explain to me how RECURSION contributes to DDoS attacks? Every example or attempted explaination I've seen so far immediately falls on IP SPOOFING and/or various well timed cache tricks. In the case of ip spoofing, if your dns server answeres any request, it can be using as an amplifier. There's nothing the dns server can do about that; ISP's are the only ones in the right place to stop ip spoofing.
Recursion can certainly be used to DoS the dns server itself -- by making it do a whole bunch of requests. But DoS'ing someone else...
Yes, I did. That explanation doesn't make any sense. You may be able to change the dns servers on record at the registrar in seconds, but the root name servers may not update for days. Most modern DNS servers detect "lame servers" and stop asking them about those domains. For example, if foo.com lists 1.1.1.1 as the authoritative server but it has no records for the domain (not configured, not in cache), any server asking about foo.com will tag 1.1.1.1 as a lame server and not bother asking it any more. (obviously, the "lameness" will eventually expire, but not soon enough for a DDoS.) And btw, the coopted server will still have the original NS records cached -- if it has anything at all in it's cache.
It looks like you are hosting the spammer.
Only an idiot blames the listed authoritative DNS server IP's for spam. The DNS server didn't send you spam. You find the spammer by looking at WHO registered the domain and WHERE the spam actually originated (i.e. what IP address connected to your SMTP server.) Who's hosting the DNS for it is completely immaterial.
Slashdot Mirror
Other than the production of tons of very highly radioactive waste forwhich, to date, we have no effective means of disposal.
When's the last time a coal fired plant rendered an area permanently uninhabitable? When a coal plant blows up, you wait for the fire to go out and build a new one. When a nuke plant blows, it makes the area around it (possibly for hundreds of miles) too radioactive for humans to live there. [granted, we've only had such a thing happen once. So far.]
(I'm not sayin' nuke's are bad. I'm just sayin' they present a number of problems, too.)
It doesn't necessarily have to be dynamic DNS. Merely by listing a machine in DNS, you are indicating it's status as "up and available". And it's just about as reliable as any P2P gatekeeper -- applications crash, people turn off things, networks do break, etc. so it's very likely for the "database" to be inaccurate w.r.t. one's availability.
Funny you mention Cisco... they actually do use SIP these days. Skinny, while depreciated and "removed from IOS" long ago, is still present and functional in IOS 12.4.
W.r.t. STMP, Microsoft's "Remote Help" does exactly this. It'll email an XML attachment to the "helper" which tells the remote desktop client where to connect.
If you want prior art, look no further than FTP -- PORT and later PASV both communicate an IP address for "direct communication." (granted, there's no "database" involved.)
Maybe, maybe not. The raid made no difference on the saturation of my cablemodem. AZ has been pumping out 24kb/s continuously for months. (except when I forget to start it after Winblows weekly patchfest "requires" me to reboot.) TPB may be LARGE, but they are not the totality of bittorrent.
Also, keep in mind, TPB's servers were not the only ones taken. In this, it's not very different from an ISP/Host dropping off the planet.
badblocks -w... it'll write a series of patterns to the drive. It takes "a while" to overwrite a large drive 4 times.
... and would do ZERO damage. Most drives made in the last ~5 years can take a 300G (three zero zero, three HUNDRED) shock when not running. In some drives, the heads are parked completely off the surface of the disk (mostly laptop drives.) Others park the heads (locked, I might add) at the center of the platters... in contact with the platter. If it's not spinning, it's very difficult to damage the disk by simply dropping it.
You'll have to work a lot harder to destroy a drive. A sledgehammer comes in handy... most people not having a blast furnace, or a metal shredder.
First, the USPS is NOT a reliable transport. They do lose, destroy, and otherwise misdeliver items. Every. Day. Statistically, they have a high sucess rate, but they move a huge number of things around every day -- 0.001% lose turns out to be a big-ass number of lost postcards and fruit cakes. Second, "registered" mail only means the carrier put it in A mailbox. It is not a 100% blanket certainty that it was (a) put in the correct mailbox, (b) actually seen by the addressee, or (c) not subsequently removed from the mailbox by the postal service.
Unless it's delivered and signed for in person, there's no guarantee it's been delivered. This is why process servers ask for you by name and hand you the papers in person.
... this is almost certainly a highly deceptive account, incorrectly reported. ...
You are just as much in the dark as we are, so you're simply guessing. Maybe you don't make this kind of mistake. Maybe the firm(s) where you've worked are the few good, upstanding, ethical law firms that never make any mistakes. (most likely y'all are simply better at covering your oopses.)
However, it's also entirely possible the firms involved dropped the ball and actually did file without his legal authorization -- and possibly despite his request to remain anonymous. We don't have the complete story, assuming there's one to be had.
No, the paralegals and clerks dot the i's and cross the t's. If you'd seen a single word doc directly from almost any lawyer, you'd wonder how anything ever gets done. They are, in fact, as bad or worse than the average slashdot geek. ('tho far more entertaining.)
It won't actually get hot enough to burst into flame (unless you've rigged it.) It'll eventually get so hot the processor fails, and then it stops getting hotter. I have the same problem with my non-mac laptop -- sony didn't really design it to run at 100% constantly... after about 12hrs the processor locks up. (I keep it underclocked when I'm doing stuff like that.)
Nope. That's a mix of perl and shell... "for $foo" is a perlism.
There are non-tivo people that know how exactly how the little boxes work. (and I can atest, first hand, it's not that hard to figure out.) If Tivo went the way of the dodo, I'm certain their knowledge would bubble to the surface -- most of it's already out there, but you've gotta know where to go sniffing.
Simple... the people who know how this sort of stuff work love their tivo and will do nothing to kill them. Plus, there's no reason to do so; one can build a functionally equiv. system with MythTV and any number of tv listing scripts.
Most ("some"?) RR areas already filter port 25. You cannot send email directly from your cable modem to the world; it must first be handed to one of RR's MICROSOFT SMTP servers. Mindspring/Earthlink does the same to all their dialup users (or used to.) But, surprisingly, they don't do it to their cable modem users (i.e. RR users with Mindspring IP's.)
:-)]
Honestly, it's not really something for RR to fix, nor something they actually can fix. After all, they cannot stop the billions of clueless fscks from placing Windows machines naked on the Internet. However, we, as email admins, can easily block them all. (24/8 was specifically set aside for cable modem use, but I doubt ARIN is being held to that anymore.)
[Comcast and Rogers also do this. And so do various Hilton's around the country
Actually, it's rpmbuild -ba <spec file> . And the spec file for 90+% of the stuff was written a long time ago -- and, honestly, they aren't that hard to create. The hard work is in all the little patchy bits they do to screw with everything they sell. And, in theory, quality control, but the whole story behind Fedora is to foist that process on the "free loaders".
kernel ... ro ... md=d0,0,2,0,/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd root=/dev/md/d0p0
*whistles innocently*
It can be done. With the removal of ataraid, the kernel will not automatically detect them. Some smarty thought it was better to force everyone to use an initrd and 100% userland crap to setup one's root volume. *I* think forcing anyone to use an initrd is a patently stupid f'ing idea. Doing so makes it trivial to break a system, and difficult to repair.
As I said, it. does. not. work. like. that. The NOTIFY has to appear to come from a master server. Assuming one can get the timing exactly right and fake the SOA QUERY result, all it will do is trigger a zone transfer from that master server; an (optionally) authenticated process done via TCP, not UDP, and thus not generally succeptable to ip spoofing. No where in there is there a place for a 3rd party to specify where to send/receive anything. The slave is only going to talk to the master(s) it's explicitly configured to use.
The whole "DDoS by hacking someone's zone file", AGAIN, has nothing at all to do with enabling or disabling recursion. In this case, you've managed to replace an AUTHORITATIVE RECORD forwhich the server will ALWAYS answer; it's authoritative for the domain, so it has to. Historically, such crap has been done by buffer overflows compromising the entire DNS server, and less often by specific, complex cache/internal db poisoning attacks -- both the result of bugs in the dns server, unrelated to "recursion on".
Key words: with a spoofed IP address of your target
Ah, thanks for the picture. Recursion isn't the problem. IP Spoofing is the problem. Turning off recursion is only a band-aid...
If you are successfully spoofing the address of your target, disabling recursion won't prevent you from making requests. You can ask the dns servers for authoritative information or simply make non-recursive queries. The replies may be smaller, but they'll be larger than the requests. (once it's in cache, it no longer needs to be a recursive query. the trick then is to get it into the cache.)
Preventing IP spoofing (both at the router and the dns server) will stop this sort of crap.
-- DNS and BIND, 4th Ed.
First off, it only applies to authoritative zones which means there aren't any caches to exploit. Second, query recursion and dns notify are completely unrelated.
If you send a NOTIFY for a domain that isn't a slave, the server will ignore it. Even if you happen to be in a position to mount a man-in-the-middle attack and forge the SOA QUERY results, all you'll manage to do is trigger a zone transfer -- which happens over TCP, not UDP, so poisoning the zone will be much more difficult. But we're straying off topic... this has nothing to do with recursion, nor is it a DDoS. (and very few people are in a position to mount such an exploit.)
Notify messages are validated, if not authenticated. They have to come from a configured master or they're ignored. At best, for each NOTIFY properly forged, 2 (*two*) packets, almost exactly the same size, will be generated: the NOTIFY response, and a QUERY for the SOA. If a 2x amplification is enough to be an effective DDoS, then it's very likely the script kiddie's zombie botnet is large enough to not need any amplification. Oh yeah, and the entire process is hinged on IP SPOOFING, not on the status of any dns server's "query recursion" settings.
Disabling recursive queries on public dns servers, and properly configuring the feature on internal dns servers is a good practice. HOWEVER, it's not the solution to using DNS servers in DDoS attacks. It is at best, a small part of the solution. All of this depends on successful ip spoofing; and that is what needs to be fixed, but because of lazy, and/or incompotent networking professionals, ip spoofing is going to be with us for a long time. (we've had the necessary technology for nearly a decade.)
Notify doesn't work like that. Oh, and it has nothing to do with recursion.
Turning off recursion won't prevent such attacks. At best, the script kiddies will simply stop sending requests to your server(s).
Think about... The zombies can fire spoofed requests at the target dns server just as easily as an open server. And they can do so at the exact same rate. When the zombie sends a request to an open server, that server is going to send basically the exact same request on to the target. The request won't magically be 3x larger. And one zombie request will not be magnified into more than one target request. (ignoring timeouts.) There's no need for a middle man either, since the source is spoofed anyway.
The only reason to turn off recursion is to stop people from consuming your resources (maybe killing your server), and limit one avenue of possible bugs that could compromise the server.
Right. I left off the bit about "WHERE" being mostly useless. Zombie or not, that *is* where the spam came from. It's surprisingly helpful to ban those addresses and even the surrounding netblock(s). The DNS server IP(s) are completely useless -- I've never seen a spammer hosting his own DNS. Banning the dns server address(s) won't do much to stop the spam, but could break a number of things.
The attacks work in the following manner: a malicious attacker sends several thousand spoofed requests to a DNS server that allows recursion. The DNS server processes these requests as valid and then returns the DNS replies to the spoofed recipient (i.e., the victim). -- US-CERT
You'd think CERT would have enough sense to realize, recursion is not the problem here. Spoofed. F***ing. Requests. Are the problem. Recursion will add to the load of any dns servers in the party, but disabling recursion will NOT stop a DDoS from spoofed requests. If the server answers the request at all, it's participating in the DDoS.
In a DNS amplification DDoS, attackers use a botnet to send a large volume of requests to DNS servers, spoofing the target's URL [correction: IP] as the "from" address on the request. Instead of responding to the machines in the botnet, the DNS servers send responses to the target, in this case stormpay.com. Because nameserver responses can be significantly larger than DNS requests, the attack can be amplified. -- NetCraft
... and recursion doesn't matter at all. This works even with a properly secured, non-recursing server. The ONLY way to stop such attacks is for networking professionals to properly configure their networks to prevent IP spoofing. It's not that hard to do with modern router hardware.
If you're running an open DNS server, you're very likely participating in someonelse's DDoS attack and have been for the last couple years.
Then please explain to me how RECURSION contributes to DDoS attacks? Every example or attempted explaination I've seen so far immediately falls on IP SPOOFING and/or various well timed cache tricks. In the case of ip spoofing, if your dns server answeres any request, it can be using as an amplifier. There's nothing the dns server can do about that; ISP's are the only ones in the right place to stop ip spoofing.
Recursion can certainly be used to DoS the dns server itself -- by making it do a whole bunch of requests. But DoS'ing someone else...
Did you bother reading the linked site?
Yes, I did. That explanation doesn't make any sense. You may be able to change the dns servers on record at the registrar in seconds, but the root name servers may not update for days. Most modern DNS servers detect "lame servers" and stop asking them about those domains. For example, if foo.com lists 1.1.1.1 as the authoritative server but it has no records for the domain (not configured, not in cache), any server asking about foo.com will tag 1.1.1.1 as a lame server and not bother asking it any more. (obviously, the "lameness" will eventually expire, but not soon enough for a DDoS.) And btw, the coopted server will still have the original NS records cached -- if it has anything at all in it's cache.
It looks like you are hosting the spammer.
Only an idiot blames the listed authoritative DNS server IP's for spam. The DNS server didn't send you spam. You find the spammer by looking at WHO registered the domain and WHERE the spam actually originated (i.e. what IP address connected to your SMTP server.) Who's hosting the DNS for it is completely immaterial.
(Oh yeah, since when is "hosting spam" a "DDoS"?)