The loopholes discussed in some other +5 posts were probably due to recording/movie industry lobbying. Why hunt for a loophole when you can just buy one?
Cook County is more that 5 million people, second largest behind Los Angeles County which is more than 9 million. I think the map is showing number of votes for height. Checking county election results, I see 1 million votes in Cook, 2.7 million in LA. I would think the largest county would be the largest spike, but it seems smaller than Cook. It could be the 3D perspective. I can't find any mention of the methodology used.
New York City is split into several counties/boroughs, and on the map it looks like it was split up that way. There are several tall but narrow sections. Chicago and some surrounding area is shown as one huge Cook County spike.
I think he answered the Finux question a while ago, but I can't quite remember where I read it. The basic idea was that he wanted an operating system like Linux in the book, but he wanted to have some creative leeway with it to fit the story. He didn't want to confuse the real Linux with his fictional OS, so he named it Finux, thus avioding volumes of hate mail from Comic Book Guy types.
A multi-billion dollar company rushed a voting maching product to market to take advantage of the buzz following the 2000 election. Marketing trumped proper design.
There is nothing wrong with modernizing voting. A touch screen system's best attribute is a better user interface. Remember all the noise about "butterfly ballots" and accidentally voting for the Reform party candidate, or something like that.
Another possible advantage is a better ballot produced by the machine. Remember all the noise about hanging/dimpled/pregnant chads and how to count them.
The Diebold machines seem to solve the first, but not the second. There are a lot of engineers and computer science people posting here, and we know how to analyze these problems. Modernizing voting is fine, just do it properly. I see the Diebold machines as a quick hack to get something on the market while election officials were scrambling to do something while the 2000 election was still on our minds.
You could hook up the controller to the parallel port, not the game port, and have it work without extra hardware. You would need extra software drivers to implement the serial-style method for reading the controller. Some emulators had that feature built-in. The linux kernel includes drivers as well.
For some parallel ports that didn't source enough current on a single pin, you would need to wire up a few pins for power, which required some diodes.
First trade came in at 135.91 at 11:38 a.m. on my ticker. Pretty close to the high end of Google's early suggestion. We'll see where it closes, though.
In the long run, Comcast's move could be better for you than you realise. Providing that Comcast is able to block the outbound spam only, and work with their customers who are responsible, then email admins may not be so quick to drop Comcast's entire dynamic IP range in their blocklists.
An good idea, similar to how spam-trap addresses can be used to build spammer blacklists. However, you would have to do something to keep packets with forged return addresses from spoiling your blacklist. This might mean completing TCP connection setup, etc., to verify the source. Your darknet wouldn't be passive and totally silent, which is what the article seems to imply in it's definition of a "darknet." Of course, other analysis of the packets could weed out false positives.
While he probably is an active spammer, I definitely consider myself anti-spam. And I don't need anyone to attach that label for me.
It's more specific than that. There are those who consider themselves "anti-spam" and some call themselves "anti-spammers." But specific use of the word "anti" abbreviated like that is the mark of a spammer. It's like a jargon word among spammers. When you see someone ranting on about how "those antis are ruining commerce on the net!" you can bet it's a spammer. That's why I'm suspicious.
Re:Doesn't this seem like a put-on?
on
Junkie Loves His Spam
·
· Score: 5, Interesting
The whole article seems a bit phony. Especially the use of the word "anti" by Mr. Soto. There is one group of people who are fond of using the word "anti" to describe those who dislike spam. I get a strong feeling that this is not just some innocent guy that likes to buy from spam, and his admission of spamming once before leaves me even more suspicious.
I'll bet dollars for doughnuts Comcast and Road Runner never see their own IPs when they do queries on that spammer's domain. I first learned of this trick from NANAE poster "Spamless," so you can look it up for a more thorough explanation (can't find it myself just now). The short story is that the spammer's DNS responds differently depending on the IP that makes the request. When the ISP checks those DNS records, they get something in South America, or China, or another ISP, anything other than them. The cable modem machine is just a proxy.
It takes a little more effort to track down what is going on, and large broadband ISP's abuse desks are probably too swamped - which should be no excuse.
Um, why not install in peoples cars that have had at least one DUI or DWI or whatever?
This is how Florida has written their law. After a second conviction, or sometimes first, they require the driver to pay for the device's installation and monthly calibration. If you can't or won't pay, then I guess you just don't drive anymore. As for New Mexico, I have a suspicious theory about who is really responsible for the bill - manufacturers of the interlock device.
O'Reilly has had a book out for a while on writing kernel devices drivers. It's decent, and the author is probably already working on a new edition for 2.6.
"While defense in depth is a good thing, adding additional layers also create the opportunity for new holes, especially when the new layer is unproven and experimental."
While that is correct, in a general sense, it does not necessarily apply to port knocking in the specific sense. Port knocking is a very simple concept with a very simple implementation.
Famous last words.
So the daemon, reading the logs, presumably in real-time, is somehow infallible merely because it doesn't have listening sockets? It's not possible that someone trying to implement this in something other than Perl messes up the log reading, parses knock sequences incorrectly underheavy load, such as malicious packet-floods, causing bad things to happen? And all Perl code is presumably infallible by design? Is Perl itself infallible?
As I said, I'd use this to hide the existence of services. It would protect from new vulnerabilities discovered in those services, but it isn't infallible to it's own newly discovered vulnerabilities (the author in his response to security-through-obscurity critics didn't mention this). Any code that gets data from the public internet - despite any through-the-firewall-logs indirection - is potentially vulnerable to attack. It may be simple to implement, but don't pretend that it is inherently infallible.
Whether it's listening or not, software is software, and it's getting input from the outside world. Closed ports are irrelevant when they are generating data to be processed by code. I'll admit that it is more far-fetched than some potentially exploitable code, but do not kid yourself of the fact that this additional code running on your system (in the firewall, in the kernel, standalone, wherever) must process untrusted information.
The attack depends on the bad coding. Yes, even ssh, designed for security, has had security problems from some bad coding. Who's to say our port-knocking program is immune to problems?
One mistake I can imagine: the daemon stores the "knock" sequence in a static buffer, then a subtle logic error, timing error or race condition in the code introduces a case where it will accept an infinite sequence without flushing that buffer, overwriting something it shouldn't - a classic buffer-overflow exploit. Even though you can't "see" the port-knock service running, you can still run the exploit against random IPs until you get a live one.
Is the port-knocking problem so easy that it can't be screwed up? I would argue "no."
SSH can be vulnerable to the same things - the point is you have to have something listening to the outside world if you want remote access, so either way you have to choose software that you trust. It's your choice to choose port-knocking.
Though there are reasons you would want to hide ssh from port scans (say, your ISP doesn't like it) mitigating undiscovered exploits in services isn't one of them for me.
What if the port-knocking daemon itself is insecure? We already established that it can be vulnerable to a replay attack, but what if there is a more serious problem, like a buffer overflow while listening for knock packets? Perhaps it is easier to write a port-knocking daemon than a ssh daemon, thus harder to screw it up. But you are still replacing one service with another, which doesn't eliminate the possibility of an exploit against bad coding.
The only real use for this is hiding the existence of ssh, if for some reason that is important to you. After that you can use ssh to hide everything else, since that is effective against sniffing.
The difference that the singing text-to-speech was just a silly hack of the speech-synthesis software. It wasn't designed for any serious musical use. And Dr. Sbaitso isn't a real psychiatrist.
ISPs that provide SMTP-auth relaying accessible from outside their network usually make it available on an alternate port, say 2025. Most moderm mail apps now make it easy to use a different port. And I don't think it is too much to ask, or too dirty of a hack, since the only purpose of this port is authenticated mail relaying, not actual delivery. The distinction between the two is becoming more important for a useful system. E-mail is changing. Thank the spammers.
I've seen that site before. I don't remember all the exact research I did, but I came to my own conclusion that it was a hoax. Though we all see your point, that there are people who think this way, I don't think that site represents them honestly.
The loopholes discussed in some other +5 posts were probably due to recording/movie industry lobbying. Why hunt for a loophole when you can just buy one?
Cook County is more that 5 million people, second largest behind Los Angeles County which is more than 9 million. I think the map is showing number of votes for height. Checking county election results, I see 1 million votes in Cook, 2.7 million in LA. I would think the largest county would be the largest spike, but it seems smaller than Cook. It could be the 3D perspective. I can't find any mention of the methodology used.
New York City is split into several counties/boroughs, and on the map it looks like it was split up that way. There are several tall but narrow sections. Chicago and some surrounding area is shown as one huge Cook County spike.
I think he answered the Finux question a while ago, but I can't quite remember where I read it. The basic idea was that he wanted an operating system like Linux in the book, but he wanted to have some creative leeway with it to fit the story. He didn't want to confuse the real Linux with his fictional OS, so he named it Finux, thus avioding volumes of hate mail from Comic Book Guy types.
A multi-billion dollar company rushed a voting maching product to market to take advantage of the buzz following the 2000 election. Marketing trumped proper design.
There is nothing wrong with modernizing voting. A touch screen system's best attribute is a better user interface. Remember all the noise about "butterfly ballots" and accidentally voting for the Reform party candidate, or something like that.
Another possible advantage is a better ballot produced by the machine. Remember all the noise about hanging/dimpled/pregnant chads and how to count them.
The Diebold machines seem to solve the first, but not the second. There are a lot of engineers and computer science people posting here, and we know how to analyze these problems. Modernizing voting is fine, just do it properly. I see the Diebold machines as a quick hack to get something on the market while election officials were scrambling to do something while the 2000 election was still on our minds.
You could hook up the controller to the parallel port, not the game port, and have it work without extra hardware. You would need extra software drivers to implement the serial-style method for reading the controller. Some emulators had that feature built-in. The linux kernel includes drivers as well.
For some parallel ports that didn't source enough current on a single pin, you would need to wire up a few pins for power, which required some diodes.
First trade came in at 135.91 at 11:38 a.m. on my ticker. Pretty close to the high end of Google's early suggestion. We'll see where it closes, though.
In the long run, Comcast's move could be better for you than you realise. Providing that Comcast is able to block the outbound spam only, and work with their customers who are responsible, then email admins may not be so quick to drop Comcast's entire dynamic IP range in their blocklists.
An good idea, similar to how spam-trap addresses can be used to build spammer blacklists. However, you would have to do something to keep packets with forged return addresses from spoiling your blacklist. This might mean completing TCP connection setup, etc., to verify the source. Your darknet wouldn't be passive and totally silent, which is what the article seems to imply in it's definition of a "darknet." Of course, other analysis of the packets could weed out false positives.
For Mozilla Mail, there is Enigmail.
While he probably is an active spammer, I definitely consider myself anti-spam. And I don't need anyone to attach that label for me.
It's more specific than that. There are those who consider themselves "anti-spam" and some call themselves "anti-spammers." But specific use of the word "anti" abbreviated like that is the mark of a spammer. It's like a jargon word among spammers. When you see someone ranting on about how "those antis are ruining commerce on the net!" you can bet it's a spammer. That's why I'm suspicious.
The whole article seems a bit phony. Especially the use of the word "anti" by Mr. Soto. There is one group of people who are fond of using the word "anti" to describe those who dislike spam. I get a strong feeling that this is not just some innocent guy that likes to buy from spam, and his admission of spamming once before leaves me even more suspicious.
I'll bet dollars for doughnuts Comcast and Road Runner never see their own IPs when they do queries on that spammer's domain. I first learned of this trick from NANAE poster "Spamless," so you can look it up for a more thorough explanation (can't find it myself just now). The short story is that the spammer's DNS responds differently depending on the IP that makes the request. When the ISP checks those DNS records, they get something in South America, or China, or another ISP, anything other than them. The cable modem machine is just a proxy.
It takes a little more effort to track down what is going on, and large broadband ISP's abuse desks are probably too swamped - which should be no excuse.
Um, why not install in peoples cars that have had at least one DUI or DWI or whatever?
This is how Florida has written their law. After a second conviction, or sometimes first, they require the driver to pay for the device's installation and monthly calibration. If you can't or won't pay, then I guess you just don't drive anymore. As for New Mexico, I have a suspicious theory about who is really responsible for the bill - manufacturers of the interlock device.
O'Reilly has had a book out for a while on writing kernel devices drivers. It's decent, and the author is probably already working on a new edition for 2.6.
"While defense in depth is a good thing, adding additional layers also create the opportunity for new holes, especially when the new layer is unproven and experimental."
While that is correct, in a general sense, it does not necessarily apply to port knocking in the specific sense. Port knocking is a very simple concept with a very simple implementation.
Famous last words.
So the daemon, reading the logs, presumably in real-time, is somehow infallible merely because it doesn't have listening sockets? It's not possible that someone trying to implement this in something other than Perl messes up the log reading, parses knock sequences incorrectly underheavy load, such as malicious packet-floods, causing bad things to happen? And all Perl code is presumably infallible by design? Is Perl itself infallible?
As I said, I'd use this to hide the existence of services. It would protect from new vulnerabilities discovered in those services, but it isn't infallible to it's own newly discovered vulnerabilities (the author in his response to security-through-obscurity critics didn't mention this). Any code that gets data from the public internet - despite any through-the-firewall-logs indirection - is potentially vulnerable to attack. It may be simple to implement, but don't pretend that it is inherently infallible.
Whether it's listening or not, software is software, and it's getting input from the outside world. Closed ports are irrelevant when they are generating data to be processed by code. I'll admit that it is more far-fetched than some potentially exploitable code, but do not kid yourself of the fact that this additional code running on your system (in the firewall, in the kernel, standalone, wherever) must process untrusted information.
The attack depends on the bad coding. Yes, even ssh, designed for security, has had security problems from some bad coding. Who's to say our port-knocking program is immune to problems?
One mistake I can imagine: the daemon stores the "knock" sequence in a static buffer, then a subtle logic error, timing error or race condition in the code introduces a case where it will accept an infinite sequence without flushing that buffer, overwriting something it shouldn't - a classic buffer-overflow exploit. Even though you can't "see" the port-knock service running, you can still run the exploit against random IPs until you get a live one.
Is the port-knocking problem so easy that it can't be screwed up? I would argue "no."
SSH can be vulnerable to the same things - the point is you have to have something listening to the outside world if you want remote access, so either way you have to choose software that you trust. It's your choice to choose port-knocking.
Though there are reasons you would want to hide ssh from port scans (say, your ISP doesn't like it) mitigating undiscovered exploits in services isn't one of them for me.
What if the port-knocking daemon itself is insecure? We already established that it can be vulnerable to a replay attack, but what if there is a more serious problem, like a buffer overflow while listening for knock packets? Perhaps it is easier to write a port-knocking daemon than a ssh daemon, thus harder to screw it up. But you are still replacing one service with another, which doesn't eliminate the possibility of an exploit against bad coding.
The only real use for this is hiding the existence of ssh, if for some reason that is important to you. After that you can use ssh to hide everything else, since that is effective against sniffing.
The difference that the singing text-to-speech was just a silly hack of the speech-synthesis software. It wasn't designed for any serious musical use. And Dr. Sbaitso isn't a real psychiatrist.
ISPs that provide SMTP-auth relaying accessible from outside their network usually make it available on an alternate port, say 2025. Most moderm mail apps now make it easy to use a different port. And I don't think it is too much to ask, or too dirty of a hack, since the only purpose of this port is authenticated mail relaying, not actual delivery. The distinction between the two is becoming more important for a useful system. E-mail is changing. Thank the spammers.
The first three listed, and some I can see, are 200/8 addresses which, as far as I know, are in south america.
I've seen that site before. I don't remember all the exact research I did, but I came to my own conclusion that it was a hoax. Though we all see your point, that there are people who think this way, I don't think that site represents them honestly.
A church wouldn't promise him millions in return then not pay it.