metalruler

This could be handy for joining a fledgling peer-to-peer network, where there are connected peers forming a network, but for one reason or another new nodes cannot find them - just do a masscan of the default listen port to find IPs to attempt connections to.

Does this mean that a huge transaction for the right amount will hit the perfect low note, and cause everyone within earshot of listentobitcoin.com to simultaneously crap themselves?

I don't understand why it's necessary for the server to be open, and have recursion enabled. I run a couple of authoritative name servers and have seen them used for amplification attacks. Sure, it's not as easy as querying every open recursive DNS server you can find for <single_domain_with_huge_sized_reply>.com, but there's still (literally) billions of unique hostnames on the internet which can be resolved "legitimately" via their authoritative name servers. There is no magical config option to prevent this; the only way to block this type of activity is to analyze traffic to find IPs that are repeatedly sending the same [spoofed] request.

That's ~600GB compressed - over 9TB when decompressed...... extremely slowly by ZPAQ. Seriously, at current rates the entire data set would take over 100 days to decompress on my computer. I'm only downloading a subset so I expect decompression will only take a couple of weeks. -_-

This is a way cool idea. Probably not the best thing to happen to the internet on a daily basis, but an amazing project nevertheless.

Just waiting for someone to start mining bitcoins on 420,000 slightly underpowered CPUs...

(Ok, seriously now.) The traceroute data could be used to build an interesting map of the internet. I'm sure there's lots of cool things that can be done with what has been released.

Land? A single spoofed TCP SYN packet with identical src/dst addresses was enough to crash or at least impact many OSs.

http://www.physnet.uni-hamburg.de/physnet/security/vulnerabi...

From a site owner's perspective: if you have a LOT of data then scraping can be very disruptive. I've had someone scraping my site for literally months, using hundreds of different open proxies, plus multiple faked user-agents, in order to defeat scraping detection. At one point they were accessing my site over 300,000 times per day (3.5/sec), which exceeded the level of the next busiest (and welcome) agent... Googlebot. In total I estimate this person has made more than 30 million fetch attempts over the past few months. I eventually figured out a unique signature for their bot and blocked 95%+ of their attempts, but they still kept trying. I managed to find a contact for their network administrator and the constant door-knocking finally stopped today.

I checked my logs and there are several fetches from 72.94.249.37 and 72.94.249.38, over a number of domains that I host. None are particularly popular as far as the greater internet is concerned; one is a semi private site that I set up for my daughter's photos, another is one that has not yet been developed, apart from a few words of text and an image.

Interestingly, the fetches do not have a user-agent that identifies itself as the DDG crawler:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

I'm assuming this is the crawler because it does not fetch anything besides text/html.

Another hole that has been exploited in the past (speaking generally here, not about this specific startup) is a password reset function that confirms the email address it is sending the password/recovery link to. If the accounts are sequentially numbered, it's a trivial exercise to fetch a reset link for each member, and scrape the email address returned.

You could also argue that designing for the average phone may be holding others back.

My Nokia N900 has a screen 800px wide, supports CSS, can display inline images, execute flash, execute javascript. Yet a lot of the time I get redirected to the "m." version of a site, with bland default-font single-color text, perhaps an image or two thrown in if I'm lucky. I would guess the majority of the sites have just copy/pasted a list of mobile user-agents and use that to decide when to redirect to the mobile version. It's a pity that there's no simple way for the phone itself to tell the site what it is capable of rendering.

Last time I looked into javascript based mining perhaps a year ago, the effective earnings for a site with a few thousand uniques per day was only a few cents. Considering that a CPU intensive background process will impact negatively upon some of your visitors, is it really worth it?

Happy to be corrected if circumstances have changed since.

Speaking of slowdowns - until recently, a gmail login quietly set cookies by redirecting through multiple subdomains during the "Loading" prompt. Most notable was that it passed through accounts.youtube.com to set a cookie.

It now seems to achieve this by using ocsp.thawte.com. Not sure how that works, I can't see any HTTP or HTTPS fetches from youtube during gmail login, yet it still manages to set a third party cookie. Can OCSP do this?

Agreed. More likely a catastrophic and significant loss for a small number of customers rather than a fraction of a percentage of loss for a large number.

Similar deal for hard drive bit error rates, where the quoted average BER may not necessarily accurately represent what can happen in the real world. For example, an unrecoverable read error loses 4096 bits (512 byte sectors) or 32768 bits (4k sectors) all at once, rather than individual bits randomly flipped over a long period.

I've seen forum participants give matter-of-fact, state-the-obvious replies which I'm pretty sure must have come from simple.wiki. I don't think it's a bot, just someone copying and pasting, however the simplified language could be very useful for genuine AI development.

It really is a disgusting hack, and specific to FreeBSD. It does need to be a bit more sophisticated than "block an IP if it floods me" because as it is now someone can simply spoof the IP of an ISP's DNS server and effectively firewall them, blocking their users from being able to resolve the domain names I'm hosting.

I can give you one tip to get you started: if you're running named, you can enable logging of every query, something like (hope this formats ok) :

  logging {
    channel query_logging {
         file "/var/log/named/querylog"
         versions 3 size 100M;
         print-time yes;                 // timestamp log entries
      };

      category queries {
          query_logging;
      };

I've been seeing a lot of reflector attacks in the past couple of weeks, where the attacker sends a relatively small query for a valid domain that will return a large reply. The trick is that they spoof the source IP, so the DNS reply goes to the victim.

I ended up hacking something together to firewall any IPs which sent more than 1000 requests in a short period of time.