Checking the netstat counters on our router today, it seems that almost a third of our traffic is now IPv6:
3105502 packets received (IPv4)
2070329 packets received (IPv6)
An ISP has a mail cluster solution which is distributed over a number of hosts in a /24 subnet. The SPF record correctly reads:
$ host -t TXT isp.com
isp.com descriptive text "v=spf1 ip4:subnet/24"
$
Since the mail cluster has to deliver a large amount of mails per day, it is attached to a SAN and distributes message delivery over the various servers. A random server picks up a message and attempts to deliver it. Locking works well so no double attempts to deliver it are made, ever. This effectively prevents messages with delivery problems from clogging up the queue on a specific server.
Here's why the ISP can forget their great mail server: greylisting. A lot of implementors don't investigate in any way what they whitelist — there's a variety of options ranging from SPF over the RIPE database to server name wildcards (which would be nasty, though) — but instead whitelist one single host. Then, however, the likelyhood of the resend attempt being performed by the same server is fairly low, so the next server will also hit the greylisting barrier. This can continue for a long time until the mail is finally delivered — or, if things go really bad, rejected.
While this is not an argument against greylisting itself, it is one against a majority of implementations.
With a lot of noise, Dan Kaminsky released the security flaw in the DNS protocol now known as CVE-2008-1447.
The vulnerability is basically a lack of entropy in the XIDs which are used to differenciate between the different responses and to associate them with the corresponding queries. The DNS protocol allows additional information to be submitted in a response which was not asked for, for example if a CNAME is resolved, the corresponding A record which is pointed to may be returned in an additional section. This record is then learned by the DNS resolvers and will be returned on the next request, instead of querying the servers again.
Since the XIDs are rather short, an attacker can send DNS responses with various XIDs in order to poison the DNS cache with arbitrary information. Hosts querying the poisoned host names during the TTL will then receive the fake record and connect to an entirely wrong server.
Back in 2003, Dan Bernstein already published information about the vulnerability, only making slightly less noise than Kaminsky. According to his assessment, and to public perception, the port randomization performed by DJBDNS already protected against the poisoning attack. Thus, the ISC released a new bind version 9.5.0-P2 which also introduced port randomization, causing all of the various NAT problems already known from the FTP.
However, shortly thereafter, someone put up to actually calculate the odds of the attack with port randomization, and found that the birthday paradoxon actually decreased the complexity of the attack significantly. Shortly thereafter, an exploit for port randomized DNS was released, showing that the port randomization was not a solution to the problem. This leaves DJBDNS vulnerable, too.
Apparently, only one solution is available so far which really solves the problem: the DNS security extension DNSSEC (RFC4034). DNSSEC signs the zone with SHA1 and an RSA key. The complexity of forging this signature is significantly higher.
The disadvantage of DNSSEC is that all zones must be re-signed either on update (not so problematic) or every 30 days (harder to implement), or otherwise their content will be lost until a new signature is generated. Once one manages to automate this step, however, DNSSEC is really useful.
The ISC has prepared a little guide to help people implementing DNSSEC in 6 minutes – and that's already all that's required. However, DJB hates DNSSEC due to the amout of CPU time used to verify the signature, and thus did not implement it. Salvation can probably be achieved by creating a DNSSEC signed zone and converting it to a djbdns zone using the zone conversion tool.
PowerDNS also supports storage of DNSSEC records, but cannot create them or sign zones in any way. The only way to achieve it is again to sign a bind zone and to convert it. The same applies to MaraDNS: there are simply no DNSSEC tools available.
Nevertheless, various sources are still suggesting that DNSSEC does not help to prevent the attack, and that only source port randomization yielded salvation. Surely, source port randomization does increase the resilience to the attack, but the problem remains unresolved.
Only DNSSEC can provide a definitive solution to the spoofing attacks. Currently, the lack of a trust infrastructure still reduces this protection, since only the host record and the zone signature must be spoofed – which is however already far from feasible.
At the same time, people should stop repeating things which a single source told them – be it Dan Bernstein or Linus Torvalds. No matter if these people are idols, their competence is not universal.
These days we're living in a world which was stuffed with war, attacks and extremists of all sorts. In the one corner we have the islamic terror which, thanks to series like Sleepers Cell, can now also be enjoyed from the living room. People with the turbans carry around bombs and kill millions of people every day. The youths are sniffing anthrax and have nothing better to do than to segregate themselves from the community only in order to get angry about it and to adhere to extremism.
On the other hand, the communist culture of deportation is still alive. Women of all the world are deported to Moscow, there is not a family in this world who hasn't at least lost one member to them. The deported then have to build nuclear weapons which are specially crafted to attack the United States, the holy grail, the center of the prosper world. For this reason, a protection shield is being established around Poland, Czechia — not Turkey this time, there have been bad experiences with the last attempt.
However, the world of computer security is in no way comparable to it. After a recent security incident of the Baslerzeitung, reports said that “efforts were made to fend off the attacks”. On the bloody morning after, one tin soldier rides away.
In truth, the issue was very simple. The software used by the newspaper was written poorly and allowed to inject additional web site elements (“Javascript Injection”, apparently through SQL). Rather than to line up the tin soldier at the server room, armed with guns to fend off the attackers, the newspaper simply patched their software. Starting from this point, it doesn't matter how many attackers are running against the web site — it is “vaccinated” and no longer vulnerable to the attack.
It is very questionable if the people who write the type of articles quoted by BloggingTom can ever be educated on the issue. It should be clarified to them that computer programs are more comparable to dogs than to countries. Except to the point that there probably are no “badly coded dogs”.
Starting from 14:12 on Sunday, the 20th of January, massive packet loss started to occurr on all links at SwissIX. Shortly after that, all connectivity from many autonomous systems stopped. Swisscom GPRS fallback worked well though, apparently since Swisscom had enough peerings outside of SwissIX.
Investigating the situation in SwissIX, there were various incarnations of always the same packets flooding the network – it looked entirely like a switch loop. In theory, however, all switches used in datacenters should do spanning tree in order to avoid this situation, so this explanation appears somewhat vague. A mail on layerone-customer however also claims that a switch loop in InterXion was causing the failure. Maybe an unusual situation triggered a bug, causing STP to fail?
Cyberlink restored connectivity pretty quickly, once the interfaces at SwissIX were shut down, the traffic ran over Germany and similar fallback routes. swissix.ch remained unreachable, also via Swisscom GPRS. The SwiNOG coordination network was split into two pieces, rendering it ad absurdum.
Solnet took more than 2 hours to recover. Around 15:30, the full packet loss after the main Zuchwil router converted to a routing loop with the nexthop. Around 16:30, connectivity started to get back to normal. Maybe there are too few non-SwissIX peers available for this case?
Unfortunately, the outage falls right between the moving of the NGAS.ch network monitoring infrastructure, so there are no concise graphs available showing what exactly had happened. This has been corrected immediately afterwards.
In case Az. 7 O 80/07, the District Court of Lüneburg has ruled that the use of blacklists for mail filtering is an illegal process. The court thereby confirmed the view of a known spammer that the fact that mails from his servers were deleted by the SPAM filter was an act of censorship.
According to the ruling, the fact that a mail server is used to transmit soleily SPAM is not sufficient to block mails from it entirely. Blocking a single mail address would have been sufficient, according to the court. However, even this step would only have been acceptable in order to prevent an immanent danger of a virus attack.
From a mail filtering point of view, however, this view is very unsatisfactory. Nowadays, most of the SPAM mails are indeed originating from hosts which are used soleily for spamming purposes (dedicated SPAM servers or hijacked Windows clients in bot networks), but the addresses used contain an unique ID most of the time which is used for only one mail.
The German Federal Court of Justice has decided in case Az. I ZR 102/05 that even stronger age verification mechanisms are required for providing access to adult content on the Internet. According to the Federal Court, the current practice of verification of ID card numbers and bank accounts are not sufficient, because any minor could gain access to this information easily.
The court proposes a verification process which involves the local postal delivery services. The deliverer is supposed to verify the age of the future web site user in an eye-to-eye process.
For the various providers of adult content which are not subject to German law, the Federal Court sees the Internet Service Providers in the responsability to block the web sites in question.
In case Az. 5 C314/06 against the Federal Ministry of Justice, the District Court of Berlin Central has decided that all retained data must be deleted by the end of the contract with the customer. According to the judges, retention of data even beyond the contract period is a violation of the right to informational self-determination.
Starting from yesterday afternoon, the IP-Plus network (AS3303) has suffered from severe difficulties, and initially even outages. Starting from the afternoon, IP-Plus started pushing an enormous amount of prefixes out to all peers.
For most routers, pushing an enormous amount of routes causes an emergency shutdown of the corresponding peering, and that was what IP-Plus must have experienced a lot that evening. (At least it happened on all routers I have access to, and I heard reports from others indicating the same.)
IP-Plus has a trouble ticket suggesting that a DDoS attack was the direct cause of the outages. However, no DDoS attack could ever have caused the effects we were seeing, so it appears that IP-Plus is trying to disguise human error as a force they are unable to control. This is not appropriate.
Instead of the daily Worse Than Failure, a weird message can be read today on the home page:
Not sure what it was, but it was logged. A human will eventually look at it. If the problem persists, please Contact Us. If the problem is on the contact form, then ... well ... that pretty much sucks. You can email instead: alexp-at-WorseThanFailure.com.
Seems these people should look for some software which is not based on ASP.