Paul Dixon, owner of pastebin.com, received a DMCA takedown order from Texas Instruments, relating to a pastebin post that a user had submitted to pastebin.com, "containing the signing keys for a range of Texas Instruments calculators which, if I understand correctly, allow you to digitally sign a replacement operating system so that the hardware will accept it"
They seem to overlook the fact that Paul is in the UK, and pastebin.com is hosted in the UK, so throwing DMCA notices around is a little pointless, acheiving nothing more than making themselves look bad.
In fact, the Streisand Effect pretty much guarantees that such attempts backfire, and result in nothing more than causing the material they desire to censor to be more widely distributed.
In fact, with information leaked to wikileaks, it’s a lost cause already.
When will companies learn that attempting to artificially control what people can do with their devices which they bought and legally own needs to stop, and that the Internet routes around censorship attempts?
I wanted to do this tonight and couldn’t remember the exact iptables incantation, and I know I’ll want it again, so sharing it here for me and for anyone else it may be useful to.
If you need SSH to be world-accessible, but don’t want to be plagued by SSH brute-force login attempts, the following ought to do the trick:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/minute -j ACCEPT
That will allow inbound SSH connections, but only 3 per minute (averaged) – this should be more than a user would normally need, but isn’t sufficient for a brute-force login attack. If someone tries a brute-force attack against you, after a few connections they’ll be ignored.
This is assuming that your default INPUT policy is to drop or reject packets, as it should be. For it to work, it also assumes that you have a rule to allow inbound connections which are part of an established connection – something like:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Of course, if you’re going to open SSH to the world, even with the above protection, you’ll still want to ensure passwords are secure (or disable password-based authentication totally, using SSH keys instead), and I’d recommend disabling root logins via SSH (the PermitRootLogin setting in /etc/ssh/sshd_config)
Surely this can’t be right – the FAA claims that the 787’s passenger compartment network is connected to the plane’s control systems!
From the Wired story:
The computer network in the Dreamliner’s passenger compartment, designed to give passengers in-flight internet access, is connected to the plane’s control, navigation and communication systems, an FAA report reveals.
The revelation is causing concern in security circles because the physical connection of the networks makes the plane’s control systems vulnerable to hackers. A more secure design would physically separate the two computer networks. Boeing said it’s aware of the issue and has designed a solution it will test shortly.
I find it hard to believe that the network to which passengers are granted access would have any link to the plane’s private control/navigation systems, but, if it is, whoever thought that was a sensible idea needs shooting!
I got a phone call earlier today from Bytemark, who host a VPS server for me. I’ve had this box with them for a couple of years, and it’s been good.
However, it seems some idiot script-kiddie has used a vulnerability in some webapp to download and run a Perl script named udp.pl to do a UDP DoS against another server (something IRC related).
This had been happening since late Friday evening, and the excess bandwidth charge came to over £80 :( Now I don’t blame Bytemark for charging me really, they’ll be charged for the traffic so they have to pass it on – I blame the bastard who was abusing my server, and myself for (a) not having kept up to date enough, and (b) not noticing quicker (if I’d looked at my mrtg traffic graphs over the weekend I’d have instantly seem that something was amiss).
I’ve not been able to find any evidence as to how the attack came in, but I suspect it may have been WordPress – I hadn’t upgraded from 2.1.2, and apparently there was a remote code exploit in PHPMailer, which WP used, so WP was vulenerable to it. Other possibilities are Dokuwiki (which I’ve updated to latest version) and Gallery, which I’ve deleted.
On the plus side, I’m pretty sure they didn’t get actual access to the box beyond running their flooding script, although I’m still nervous trusting it, so I think I’ll have to move everything off it ASAP anyway.
In the meantime it’s behaving itself. Really not a good day today – slept through my alarm somehow and woke way, way late for work, then have this shite to deal with this evening… bah, hope tomorrow is better!
Lesson learned: make much more effort to stay up to date with all software; keep a much closer eye on the system; install Tripwire or similar; be more vigilant.
I’ve set up a couple of honey pots to help out, and donated several MX records (it’s easy, just create a sub-domain MX record pointed to their server.
As well as my normal development duties I deal with some of the incoming abuse reports at work, and recently I’ve dealt with a number of phishing sites which submit data to a script named “Mr-Brain.php”. A quick Google showed no useful results, so I’m posting about it here.
Uh-oh. According to this security announcement from WordPress, a server hosting WordPress downloads was recently compromised, and a cracker modified the 2.1.1 download, adding code in wp-includes/theme.php and/or wp-includes/feed.php.
The announcement states:
It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.
This is the kind of thing you pray never happens, but it did and now we’re dealing with it as best we can. Although not all downloads of 2.1.1 were affected, we’re declaring the entire version dangerous and have released a new version 2.1.2 that includes minor updates and entirely verified files. We are also taking lots of measures to ensure something like this can’t happen again, not the least of which is minutely external verification of the download package so we’ll know immediately if something goes wrong for any reason.
If you downloaded 2.1.1 in the last few days, you may have a compromised version. However, for safety, even if you downloaded it before then, it’s probably worth upgrading anyway. Get 2.1.2 from the WordPress download page, then follow the upgrade instructions.