Tuesday, October 18, 2016
Friday, August 26, 2016
Before I get into this, there are some provisos. This server was using Linux kernel 2.6.32. The SSDs involved are Samsung 850 Pro SATA-style solid state disks. SSD is not quite ready for prime time in the 2.6.32 kernel; NVMe support was first added in 3.3, TRIM wasn't available at all until 2.6.33,
and a ton of other things we all take for granted like the device mapper are part of the 4.* kernel.
Consumer-level Samsung drivers bring their own issues. Despite what the knuckle-heads on Reddit have to say about the topic, the Linux kernel still blacklists queued TRIM functions from every Samsung SSD in the 8** series. As of the latest Github commit as of this writing for kernel 4.8 queued TRIM still doesn't work for these devices.
More importantly, the R900 isn't a new server. This is an 8 year old box. There is a SAS backplane involved which, although having a theoretical max data transfer of 3.0 Gbps, was designed before SSDs were widely available, and introduces a bunch of contacts, wiring and complexity that is likely all screwed up and almost certainly not optimized for fat-guy Peta Belly Flops of computing power.
Initial benchmarking with fio and ioping in addition to monitoring CPU iowait times with top and checking out iostat had this server's SSDs performing *slower* than a similar server with 7500 RPM sata disks in a ZFS pool.
I did a bunch of stuff to this box hoping to shake a few extra IOPS out of it. I installed Dell's dsu to get my hands on the latest drivers & firmware (under the mistaken belief that an update on either front had been released in the last decade). I had never physically seen this server; so there was a lot of lspci-ing and modprobe-ing.
Luckily, I stayed focused on the controller & backplane a SAS 6/iR (FW 00.25.47.00.06.22.03.00) and LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08) (FW 1.06), respecticely. Eventually I stumbled upon this post that described - accurately - how the Dell was automatically stepping down the SATA port speed on non-Dell-certified disks from SATA II (3gbps) to SATA I (1.5gbps).
Many moons ago, Dell's RAID cards would simply not allow users to install non-Dell disks. My experience with the R900 using BIOS version 1.2.0 would indicate that - although I am able to use non-certified disks without fatal errors, the backplane deliberately slows these disks down without reason, and in a way that is almost always transparent to the end user. I will hold off on making accusations here until I get my hands on the source code for this firmware, but the evidence up to this point is fairly damning. If anyone from Dell has an explanation for this sort of behavior, I would be happy to publish your feedback here.
- unzip the file in a directory of your choice; # unzip LSIUtil_1.62.zip -d /home/joshw/lsiutil/
- navigate to the directory referencing your OS; # cd /home/joshw/lsiutil/Linux/
- identify the version of the application matching your processor/OS bit type. For linux, there is a 32 bit, AMD64 and x86_64 version. I selected the x86_64 and applied an executable bit: # chmod +x lsiutil.x86_64
- make sure youre root: # sudo su
- run the application: # ./lsiutil.x86_64
You should see something like this:
LSI Logic MPT Configuration Utility, Version 1.62, January 14, 2009
1 MPT Port found
Port Name Chip Vendor/Type/Rev MPT Rev Firmware Rev IOC
1. /proc/mpt/ioc0 LSI Logic SAS1068E B3 105 00192f00 0
Select a device: [1-1 or 0 to quit]
Select a Phy: [0-7, 8=AllPhys, RETURN to quit] 8
Again, you will be prompted for several values. You want to be very careful here as we only want to change one value - MinRate (this should be the second value you are prompted to modify. Every other value should remain default by pressing RETURN.
Link: [0=Disabled, 1=Enabled, or RETURN to not change]
MinRate: [0=1.5 Gbps, 1=3.0 Gbps, or RETURN to not change] 1
MaxRate: [0=1.5 Gbps, 1=3.0 Gbps, or RETURN to not change]
Initiator: [0=Disabled, 1=Enabled, or RETURN to not change]
Target: [0=Disabled, 1=Enabled, or RETURN to not change]
Port configuration: [1=Auto, 2=Narrow, 3=Wide, or RETURN to not change]
Once you've finished you will be dumped back to the port menu:
PhyNum Link MinRate MaxRate Initiator Target Port
0 Enabled 3.0 3.0 Enabled Disabled Auto
1 Enabled 3.0 3.0 Enabled Disabled Auto
2 Enabled 3.0 3.0 Enabled Disabled Auto
3 Enabled 3.0 3.0 Enabled Disabled Auto
4 Enabled 3.0 3.0 Enabled Disabled Auto
5 Enabled 3.0 3.0 Enabled Disabled Auto
6 Enabled 3.0 3.0 Enabled Disabled Auto
7 Enabled 3.0 3.0 Enabled Disabled Auto
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m] [100.0% done] [74324K/24284K/0K /s] [18.6K/6071 /0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=59026: Fri Aug 26 19:10:52 2016
read : io=3070.6MB, bw=74180KB/s, iops=18545 , runt= 42386msec
write: io=1025.5MB, bw=24775KB/s, iops=6193 , runt= 42386msec
cpu : usr=8.79%, sys=55.13%, ctx=796212, majf=0, minf=20
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=786053/w=262523/d=0, short=r=0/w=0/d=0
Monday, August 15, 2016
|Building a gaming rig. Notice how decades of IT work has resulted in a Quasimodo hunch|
- Intel i7 6700K CPU
- NZXT Kraken x61 liquid cooling system
- Nvidia GeForce GTX 1080 graphics card
- ASUS Z170-E motherboard
- NZXT S340 case
- Corsair Vengeance LPX DDR4 RAM
- Samsung EVO 850 SSD
- EVGA Fully Modular GQ 650W power supply
During build-out I encountered two issues that weren't the result of my own fumbling, shaky hands. One of these issues I think is forgivable and the other is not.
The ASUS 7170-E motherboard and its associated BIOS is specifically designed with gaming and overclocking in mind. I'll save the overclocking for another time; what I had problems with is the BIOS' "QFan" monitoring system, which was unable to recognize the Kraken x61 CPU fan. Both the BIOS and motherboard appears to have more of a focus on open loop cooling systems - the 7170-E has a dedicated on-board four port connector labeled "WPUMP" for water pumps, and the QFan monitoring within the BIOS treats CPU fans and pumps as separate entities.
Booting with default BIOS settings continuously failed with an error message complaining of an invalid RPM lower limit assigned to the CPU Fan, and that I should resolve this by either disabling that lower limit within the BIOS or confirming that the CPU Fan was attached to the on-board CPU Fan Header. Of course, neither of these resolved the problem. I tried a ton of alternatives - plugging the CPU fan into the WPUMP header, changing the fan type from "auto" to "PWM", etc - without any success. Eventually I was forced to resort to Google, where I found a post on a message board suggesting to completely disable QFan's CPU Fan monitoring functionality (you can do this by pressing F9 to go the Advanced Setup menu, then goto Monitor, scroll down to CPU Fan monitoring and press space to disable). Doing this resolved the issue.
Once I had Windows installed and I had installed NZXT's CAM application (through which I was able to manage and monitor CPU Fan speed and other metrics without any problems), I decided to update the BIOS in one more attempt to resolve this whole QFan business. I can't remember the BIOS versions involved off hand other than that I know it was a major release - something similar to a leap from 0230 to 1205. I was pleasantly surprised to see that immediately after upgrading the BIOS the x61 CPU fan was recognized. With this confirmed, I powered off the system one last time to do some last minute-cable management (I'll post a pic at some point). However, when I rebooted a second time, the error reappeared even though the BIOS upgrade was successful - strangely, the BIOS screen became heavily pixelated At that point I gave up and disabled QFan again which once again got be through POST without issues (the pixelation disappeared).
This obstacle didn't bother me; I'm not sure whether the issue with the Kraken or with the ASUS BIOS, but the fix was simple enough (even if it took me a while to figure out). The second obstacle I ran into, also related to an NZXT part, was more frustrating.
We went with the Kraken x61 fan for two reasons. First - because its claimed stats for air circulation along with its claimed decibel rating were among the best in its price range. And second - the case preferred by my gamer customer was an NZXT S340, so I rubbed both of my brain cells together and reasoned that NZXT coolers are bound to fit more easily into NZXT cases than other comparable coolers. Of course, I didn't reach this conclusion on my own. NZXT's documentation for their mid-size S340 case clearly says "Full 280mm radiator support for the latest Kraken cooler".
So let me be the first to say that, no, a 280mm radiator will not fit within the NZXT S340. There is, in fact, 280mm of fan space. You can easily install two separate 140mm fans. And you can also install a 280mm radiator in addition to those fans (after physically modifying the case). What will not fit as the case is designed is the two thick rubber tubes that are attached to every cooling radiator on the market. Compounding the bullsh*t nature of the claim is that NZXT only manufactures closed-loop coolers, and the x61 is the only 280mm cooler that NZXT makes.
I did get it to work (that's why I make the big bucks), but the installation should have been much easier. There are conceivably a few different ways to do this, but here is what I did:
- I removed the front panel and used a pair of wire cutters to remove the series of small,
completely pointless plastic tabs inside the panel that prevent the case from closing with the
Kraken radiator inside.
- There are two metal holes in the front of the S340 case where the fans are designed to be
mounted. I threaded the CPU cooler and tubes through the top-most hole. This, in turn, makes it impossible to mount the fans where they are designed.
- I then proceeded to install the top fan into the top hole, leaving enough space for the tubes. This
means that only two screws can be used to secure the fans instead of 8. These two screws will connect the bottom of the top fan where the top of the bottom fan was designed to be screwed in.
- This leaves *just* enough clearance for the bottom fan to be squeezed into the remaining space.
To avoid shaking, I installed a pair of adhesive bumper strips to the bottom of this fan. Instead of using screws, a series of zip ties can be used to make sure the fans stay in place. This, in addition to gravity and pressure, will keep the fans and radiator in place.
This is very much a hack. There are other options for getting this to work, but the list is narrowed by the very small amount of clearance in the front of the server and the radiator itself.
Is it possible that I overlooked something significant in the install of the cooler with this case? Absolutely. If that is in fact the case, and I made a mistake, I'm still going to blame NZXT - because the case provided no documentation for how to install a 280mm cooler, and the documentation for the cooler only included instructions for larger cases (where the cooler is installed on top).
Anyway, I hope this post helps save readers some time and prevents a few headaches.
Sunday, August 14, 2016
Thursday, August 4, 2016
Sunday, July 31, 2016
Over the last week or so I've begun getting my hands on and reviewing the emails and attachments from the Democratic National Committee that have been leaked to the public by a shadowy figure(s) named Guccifer 2.0. This hack became international news beginning last month when the controversial "cyberwarfare" company Crowdstrike announced that the DNC had been hacked, and shortly afterward documents from the DNC began being leaked to a variety of different news outlets, from the Smoking Gun to Wikileaks.
From the very beginning of the DNC hack's injection into the news cycle, the blame for the incident has been squarely laid at the feet of Russian intelligence services. The Russian connection was established by Crowdstrike, who had been asked by the DNC to investigate a hack before the leaks began. Crowdstrike CTO Dmitri Alperovitch published a public report of the findings of their investigation, apparently at the behest of the DNC, in which samples of malware were provided that had links to other attacks that had already been attributed to Russian intelligence, like the compromise of the German Bundestag's network discovered earlier this year.
The attribution to Russian intelligence has gained steam over the last few weeks until we reached the point we are at now - where news outlets are now reporting the Russian intelligence attribution as fact. It is primarily this that I take issue with. Please note that it may very well be the case that Russian intelligence is behind all this. My concern is there is not nearly enough evidence to declare that attribution as fact without additional evidence.
Crowdstrike's report does not provide the required evidence to establish the attribution. Although the report provides a malware sample and a list of IP addresses associated with prior Russian intelligence-attributed hacks that Crowdstrike claims to have recovered through their investigation, these samples are provided without any form of context and in a format that makes it impossible for other researchers to attempt to replicate their findings. There is no explanation of how these samples were acquired. This is a bit like if your doctor told you that you have lung cancer, and as evidence offers you a picture of a cancer cell that's been cut out of a medical journal instead of, say, an X-Ray of your chest. The Crowdstrike report is an explanation of Crowdstrike's findings. It is not proof of Crowdstrike's findings.
And, to be fair, Crowdstrike provided their findings to two other companies - Fidelis, Mandiant and ThreatConnect - all of whom have apparently confirmed at least some of Crowdstrike's findings.
So I am willing to overlook the fact that Kurtz has a long standing history of making inflammatory accusations that are both demonstrably false and troublingly indicative of someone with little to no understanding of infosec. I am willing to overlook the fact that Crowdstrike's claim to fame was not for its skill in solving complex hacking investigations but for offering so-called "hack-back" retaliation services - a business opportunity that Crowdstrike was able to capture because their methodology was so ethically and legally questionable that no one else in the infosec community would have anything to do with it.
I am even willing to overlook the fact that Crowdstrike has corporate partnerships with the two out of three of "independent" companies that confirmed their findings.
Let's take for granted that Crowdstrike's report is 100% accurate and Russian intelligence services did, in fact, compromise DNC systems.
Even if we take that for granted, it still doesn't mean that the DNC email leaks can be objectively attributed to Russian intelligence.
In addition to this finding, journalists relied on retweets from Tait's Twitter account for confirmation of other findings, such as the Bundestag link, as illustrated here:
As I was reading through Tait's tweets and his subsequent blog guest posts, I saw myself 10 years ago, with the rock reseller. The DNC hacks significantly increased Tait's cache on social media, as can be seen here (the hack became public June 14th).Reminder: Malware control servers used in DNC hack were also used in the hack on Bundestag linked to Russian intel. https://t.co/0SBvifDxKR— Pwn All The Things (@pwnallthethings) July 23, 2016
|@pwnallthethings follower growth for July 2016|
Tait rejects the claim that his findings are influenced by bias:
Tweeps saying the #DncLeak/Russia thing is conf-bias: My analysis was to prove @CrowdStrike's Russia link wrong. https://t.co/8V40VSYgo1— Pwn All The Things (@pwnallthethings) July 24, 2016
Also, I use Tait here because the media has decided to rely on his findings so consistently, but he is not alone in transforming tenuous circumstantial findings into Objective Truth. Some of my personal favorites are:
- Vice Magazine brought in linguists (I am very much avoiding the use of a hackneyed but still-amusing pun here) to analyze the transcript of an interview between a Vice reporter and Guccifer 2.0. Even the honey-picked quotes provided by Vice made it clear that nothing could be proved from these transcripts other than that Guccifer 2.0 likely used Google Translate, but the article has been used as further "proof" that Guccifer 2.0 is Russian and not Romanian.
- The version of MS Office used to modify leaked files appears to be cracked. Cracked versions of Office are "popular among Russians and Romanians". Because no one anywhere else in the world pirates Microsoft software (certainly I don't - stop looking at my torrents).
This is just silly, but its taken as gospel by a media that is both hungry to spark a Cyber War and whose reporters frequently have the technical acumen of my 94 year old grandmother.@_fl01 @pwnallthethings Get it now ;) »Grizli777«'s cracked MS Office seems 2b popular among Russians and Romanians. pic.twitter.com/LtdgQn0hVy— Florian Wagner (@_fl01) June 15, 2016
So before we wrap this post up lets quickly review the fallacies that are used to confirm the Russian Connection:
THE RUSSIANS HACKED THE DNC, SO THE DNC LEAKS CAME FROM THE RUSSIANS
This is the big one. As I said earlier, I am taking for granted that Crowdstrike's report is God's Own Truth, and that a pair of separate Russian intelligence services hacked the DNC and had access to the DNC's network for up to a year.
Even if we accept that Russian Intelligence hacked the DNC, it does not mean that Russian Intelligence leaked the documents. Let's consider some scenarios.
The number 1 reason why networks and servers are compromised is because those networks / servers are vulnerable to compromise. That's such an obvious statement it comes across as a tautology. But its not, and there are important consequences of this obvious statement. I am regularly called in to help companies that have discovered a breach in their IT infrastructure. Something that often happens is I find evidence of multiple compromises; either the victim is using multiple vulnerable software packages, or multiple parties have taken advantage of the same exploit, or the network was compromised a long time ago by a clever hacker who was able to maintain a presence on the network until some much-less-competent hacker came along and defaced a website or broke something.
One of the most compelling alternate explanations relies on a similar chain of events happening at the DNC. Russian intelligence had compromised the DNC for a long time using the sophisticated techniques described by CrowdStrike. The Russians stayed present in the network for a year in order to accomplish what intelligence services typically want to accomplish - compiling as much information as possible. Then, some knucklehead(s) named Guccifer 2.0 comes along and compromises an email server with the goal of accomplishing some hare-brained political goals known only to him/them. Guccifer 2.0, being a moron, sets off the bells and whistles that cause the DNC to contact CrowdStrike, who in turn discover the Russian intelligence presence.
There's other options. Remember that guy name Edward Snowden? Remember how he worked for a US intelligence agency? Remember how he leaked a bunch of documents to the media? Remember this other person Chelsea Manning? Remember how Chelsea released all of those cables that included detailed intelligence analyses of foreign countries? Remember how those documents had huge political implications in those countries, like maybe sparking the Arab Spring? The point is that leaks within intelligence services happen that aren't necessarily planned by that intelligence service. Those leaks can have devastating impacts on the elections of foreign countries. Here, Guccifer 2.0 is either a Russian intelligence employee or a hacker whose true target was Russian intelligence. Theres a few options within this option - Guccifer 2.0 as working for another nation hoping to influence the US election and increasing US/Russian tensions, Guccifer 2.0 as a Russian intelligence employee who has for whatever reason a *huuuuuuuuuge* (get it?) man-crush on Trump. Some of these options are crazy. But its no more crazy than the explanations of the Putin-Trump Axis of Evil floating through the media.
EVERYONE WHO SPEAKS RUSSIAN WORKS FOR THE GRU/FSB
It sounds silly when its put into words, doesn't it? But this is what the "metadata" and "language analysis" comes down to. Guccifer 2.0 is using Office with Russian language settings. Guccifer 2.0 is chatting the way a Russian would chat. ERGO Guccifer 2.0 is Russian. ERGO Guccifer 2.0 is really Russian Intelligence. I'm not sure how to explain how stupid this is, other than to just point out that, no, not everyone who speaks Russian is a GRU agent. Maybe visit Russia and meet some of them? There are some people who speak Russian who are butchers and bakers and candlestick makers. By golly, there are even people who speak Russian that don't live in Russia at all! I know, your mind is blown, right?
EVERY POLITICAL HACK IS STATE SPONSORED
Not every hacker is state-sponsored. Gee whiz, there are even *groups* of hackers who *cooperate* with each other and even *manipulate the media* and *lie about their identity* who are just teenagers somewhere. There is a rich, long standing history of teenagers playing such pranks. Kids have been hacking for longer and frequently using more sophisticated techniques than governments have. Some of the first government "cyber warfare" programs were just field agents who paid kids to hack for them and paid them in drugs. Really.
One of the most recent, well known examples of this is the lulzsec hacking group. lulzsec had a very pointed political agenda and targeted government agencies, law enforcement groups, media companies and others that opposed that agenda. The lulzsec political agenda did not fall into the binary Team Red / Team Blue archetypes that inform what passes for American political commentary, but it was there and it clearly was important to lulzsec and their supporters. Before the indictments began, there were plenty of rumors that lulzsec was state-sponsored.
If you've made it this far - congratulations. You're almost at the end. Let's wrap up.
Some companies tell us that there is evidence the DNC was hacked by Russian intelligence. That evidence hasn't been published. There is different evidence that Russian intelligence is behind the Guccifer 2.0 account. Most of that evidence turns out to be at best incredibly flimsy and circumstantial and at worst utterly irrelevant.
It may very well be the case that Russian intelligence is responsible for the DNC email leaks, but the fact remains that further investigation is required to confirm the identity of Guccifer 2.0. Attributing the attacks to the Russians before such an investigation can occur does an enormous dis-service. The Cold War actually completely sucked. We should avoid repeating that experience based on the flimsy BS that has largely informed the coverage of the DNC hacks up to this point.
I plan on writing a post on how assumptions about user behavior are frequently inaccurate, and how assumptions based on the behavior of Wikileaks researchers analyzing email dumps based on the typical behavior of normal email users is particularly prone to failure, but for now I'll just leave this here:
Has anybody's InfoSec experts advised abt wisdom of opening WikiLeaks sound files? Are we all just downloading Russian malware like morons?— David Fahrenthold (@Fahrenthold) July 28, 2016
Earlier this week a young government contractor named Reality Winner was accused by police of leaking an internal NSA document to news outle...
UPDATE March 1st, 2017 : I'm glad to see that people are finding this helpful, and thanks to everyone that has contacted me here or via ...
Those following Cryptome on Twitter saw some messages that were a little nerve-wracking yesterday. The flood of torrents attributed to Cr...
So it turns out that setting your AWS EC2 server's hostname to be persistent across reboots is a surprising pain in the ass, at least wi...