Sometimes the latter, but sometimes, even if you were to follow all his points, there's just not enough interest in the project to make it sustainable. It all sounds so easy coming from a developer who works at one of the biggest open source companies there is that can devote enough resources to a project to make it successful. Try asking some independent developers of a successful project what they attribute their success to and they may have a different list altogether.
He hasn't always worked for Red Hat. They are a good list of rules to use if you want to see where your project could be improved. I suspect you have some obscure definition of success, and/or missed the implicit definition of FAIL.
Try asking independent developers for a list of general reasons why projects fail to get wider usage, grow, and last - I have (that's an old list), the resulting list is pretty much the same, only the scores seem to change.
If it is common sense why do we have to pound it into people time and time again? Or do we just never learn?
Everything is obvious when you understand it?
If common sense was common... would people still say patently stupid things like "you can lead a horse to water but you can't make it drink" (want a bet?), "doesn't have the horse sense to stay out of the rain" (clearly never owned horses, they will seek shelter from rain - in some conditions - it's the broad brush of stupid, though some horses are smarter than others), "you'll catch more flies with honey than with vinegar" (try that with a fly trap).
Why do people think he's not going to get an open trial?
Um, because some people know, what's it called - yeah, history.
Osama Bin Laden. Tell me the plan was to take him alive and put him on public trial. And I'm allowing for the Hollywood factor in the books about his "capture".
Snowden will be "reaching for a weapon" if the USA ever get hold of him.
Jesus Christ don't use AdBlock Pro. They do some pretty shifty shit to try and get paid to let ads around their filters on default configuration.
What "shifty shit" do "they" do. A current citation would be informative.
Nice that you include default. The first thing I do when I install it click on the radio button that disables the default "show acceptable ads". (second sentence)
Use uBlock.[...].
Interesting. You say that. A lot. Is that out of altruism?
Which uBlock are you promoting? There are two. uBlock Origin (or uBlock) and uBlock.
I tried both uBlocks, and found they had a number of failings for my use case. I'll reassess my reasons for not using or recommending it if you show me which reasons are incorrect:-
It didn't block as many ads, or pop ups - so it's not as fit for it's stated purpose. That's clearly stated in the documentation - they support the majority of ads in the ABP filters.
Neither uBlock support regex filters, which I use a lot.
The uBlocks don't support $sitekey
ABP removes social buttons
ABP stops most tracking
ABP has Typo Protection (it has to be added as an extension in Firefox)
Caveats: I use ABP in Iceweasel (Firefox) on Linux, all my boxen have >2GB of RAM. I add a lot of extra blocking to the standard filters (and some specifically for/.).
Balance - I have no interest in support for Chrome. I'll happily trade a few extra MB of RAM usage, or a few microseconds of page load time for improvements in blocking. Not seeing ads, seeing relatively more content, customisability, exploit blocking, and decreased data transfer are high priorities for my use case.
For people that need something simple for Chrome to block some ads, and run an OS that chews up most of their RAM, and only want to block ads - uBlock Origin is probably the best choice.
Also use https everywhere.
I use NoScript - which makes HTTPS Everywhere redundant while giving me extra valuable features. I'd add FlashBlock to the minimal recommended extension - if someone has Fffflash installed.
His list, instead of the link to a blog with an article about the list. That blog post is interesting - though the picture of the author scratching is just weird. Was that taken at a lice convention?
So for this "hack" to work, you need to have access to the target machine to install malware.
Umm, ok, then I just hacked my companies corporate network by using remote desktop to access a server from home.
About the same level of hack, no?
No. Because you're just using an existing network connection. They're creating one. A covert channel. And not even close to the same level.
Other posters have constructed scenario based on the most secure conditions to demonstrate the hack is worthless - while conveniently overlooking the fact that many companies have an air gapped computer with little tight security. In which case the evil maid scenario would work just fine.
Is it a hack, or a crack? It's both. The hack is used to crack the air gap security.
Is it no news because TEMPEST is old news. No. Because TEMPEST has distance, difficulty and space limitations. This attack will work anywhere you can get access to the air gapped computer and put a suitably modified mobile phone within reception range. Mobile phones are easy to hide. It wouldn't be difficult to put one in a wall or roof cavity and power it from a simple puncture clip (a plastic clamp with two pin that penetrate the insulation).
It could also be used to bypass encryption and firewalls that protect non-air gapped computers. Lots of those in places where you can have a mobile phone and get reception. One scenario where this might work is ATMs - which would be easiest if you had the willing assistance of anyone who services them. If it was possible to to pull useful information from the system you'd then be able to siphon off useful info without needing to try and break the encryption used for transmission between the ATM and the bank. Generation II Skimmers.
Petrol bowsers (cheap or free petrol), vending machines (free snacks) and similar devices (cheap tickets, credit card information) - if the information can be reconstructed from the data, and if the method could be used in both directions to allow data injection (which is theoretically possible).
I have been to defcon in the past. What is amusing is all the people there from a variety of three letter agencies.
Spot the Fed is always fun. I've always wondered how many that look obvious then are just low ranking Postal workers taking the piss.
There's been talk in the past of banning them - but I don't think the organisers are actually serious about it. I think it's one of the main attractions. They have the best swag to swap.
No, you have no reason why XP is wrong for the job, you're just parroting what you've heard others say without understanding why.
In an embedded environment with limited attack vectors, XP is fine.
Note: They aren't even attacking XP here, they are attacking the software Brink's themselves wrote. Might be a good idea to get a clue before blaming the wrong thing fanboy.
Agreed. Likely version that ATMs that run XP it's probably the embedded version (on a cheap single board computer with a USB sevice port). Most of the insecurities in XP vanish when you don't attach a web browser, many of the rest when you strip out what isn't in the embedded version. So XP can be made pretty secure. It's possible that it's firewalled - I'd hope so.
It's also possible the Brinks app is Java - and that the exploit is an MiM. In which case the same weakness would likely remain on whatever OS is was running on.
Granted that's a lot of "possibilities". However they're presumptions (mostly a guess based on something) - most of the posts in this thread are pure assumption.(pure guess).
Why does Brinks use software running on an OS? Two reasons I can think of:- they want to see easy customisability as a feature, it's a cheap platform for them to work with. Now they may have to reassess the costs for the latter reason.
And I'm not a fan boi - I run Linux except where I run BSD. I also have more tools than a hammer, and my pepper grinder can be adjusted to grind the size appropriate for the desired result.
The context of the original post was discussing recovering plaintext when a bit of the ciphertext was corrupted - assuming you have the key and no backups.
Um, no - you responded to my post. I responded to a post by bdubSOv1iKIJ403M. No mention of plaintext there.
In this case 'plain' dm-crypt results in typically 128-256 bits of plaintext not being recovered. This guy has done some experiments and says in practice it's similar between corrupted encrypted and unencrypted data.
Interesting reference. Thanks. I don't have immediate comments on it other than: nothing looks dodgy about his tests; SS writes and erases are quite different from HDD (I don't understand them). I've bookmarked as something to ask some one of the ASD SME's about.
I use LUKS (and dm-crypt) for personal and work computers, with critical information also encrypted - because I don't know of a better option, and because it's the highest standard set by main clients (audits aren't a huge concern, penetration is). I have tried to recover data from a damaged drive for which I did have a backup LUKS head and key stripe - and failed. As have others - that not proof it's impossible. I'm now curious if the ASD rules for privileged environments which ban SSD devices even with LUKS in the highest category sector may be related (though it could we be for other reasons e.g. Shamir's third law?).
With LUKS, if the corruption is in the data, then the result should be the same as for dm-crypt.
Maybe. It'd be worth actually testing - which shouldn't be difficult. Until I saw some empirical data I'd be reluctant to form an opinion either way. If it is possible it's game over. (like AES-256 encrypted images, pointless)
But with LUKS, if the corruption is in the header, then there is a possibility *all* the data will be lost (again, we are talking of with the key, but no backups). LUKS is actually designed to maximise this possibility.
Agreed (with qualifications). As I previously stated, that's something I regard as a strength of LUKS, and, as also previously stated, I suspect you are using encryption to different ends.
I don't trust encryption completely - if Shamir's 2nd Law holds true it's likely that there's simply not enough expense involved to make it impossible for all the "information" to be recovered through reconstruction. You keep conflating data and information. Which gives weight to the possibility that you don't even bother to read what you reply to - or worse, don't know what the fuck you're talking about.
The logic is that an attacker is more likely to have a corrupted file. With a password based encryption sheme, the best proxy you have to an 'authorised' person is one who knows the password - in fact that's the only proxy you have.
So making it more difficult for people with the password to read the data, without making it more difficult for people without it to read the data, is a misfeature IMO.
An attacker maliciously changing the ciphertext to change the plaintext in a predictable way is another issue, but LUKS and dm-crypt are equally bad in this respect as neither support authenticated encryption modes.
I suspect you mean the conclusion of your unstated logic is that the attacker is more likely to have a corrupted file. Maybe (if they try the less likely approach of encrypting your data to access the information). Again, I suspect you are using encryption to different ends (to hide something you've secured). Why you would hide something you don't wish to access again seems stupid - and I don't think you are. What I do think is that you've overlooked the most likely attack to succeed (Shamir's 3rd Law) which is to bypass encryption. If you are keeping something that contains a secret it's likely you'll look at it agai
I've only worn glasses since I was thirty. Two years ago I had to get a second pair for distanc
I hate to tell you this, but you're well within the normal range of variation. Sorry to break the news to you.
You will die ; maybe not because of this medical issue, but you will die.
No-oooo. Tell me that you're just trolling. Please.
I'm a special snowflake that will last throughout the year. If you don't take that back I'll hold my breath. Oh wait....
I'll pay that. Thanks for the laugh. If there are any moderators left that don' t just mod down that should be modded Funny.
Incidentally, I'm following the same progress of eye disease, within about 25%. I'm going to die too.
[shrug] I guess I've read over 20K books, so I'm not complaining - I just felt a little stupid after thinking that the prescription for two pairs of glasses was wrong. And that was after "thunking" it was an issue with displays. You'd think all the wrinkles would've been a clue. Just goes to show that it's not just the eyes that getting past their peak.
I sort of like all my wrinkles. Which is just, um, weird. My girlfriend freaks out about hers. I catch sight of mine in a mirror and it just makes me laugh, which causes her to lecture me about not making the laugh lines worse (which just makes it harder not to laugh).
We all get our time in the sun. I can't say I've missed out on much of the good, have any real regrets - or look forward to senility and a loss of physical ability. But that's another subject. (one I also find hilarious)
That was a very long post with very little content and attempted to retort my comments by talking about admins failing to enforce password policy, and missplacing trust in fail2ban.
So I invite you to re-read my post above. If you don't want to let me highlight the critical parts of my post:... the passwords are strong...... before any talk of login limits...
So if we take talk about admins enforcing strong passwords and the use of fail2ban out of your post above explain to me again why I am so very vulnerable? Even bouncing through proxies you're not brute forcing a local file. You can't do millions of attempts per second, and with a simple 8 character with capital and number password you have 220 trillion possible combinations.
I'm pretty sure even the dumbest and most incompetent system administrator would notice the high bandwidth / CPU utilisation of brute forcing SSH long before it's broken.
Oh and since we're talking humans and intuitions, what makes you think that someone who can't enforce basic password security is capable of securing their private key?
Logic clearly escapes you. I responded to all your previous points. You ignored them and now resort to leaping from bank to bank astride the horse of desperation.
I've never wrestled a pig before and I don't intend to start with you. I'd just wind up covered in shit and you'd just enjoy it.
Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment)
[Unbalanced parentheses.] Which guide to configuring keys in popular SSH clients does your documentation link to?
We don't provide one. Support refers users to the official security guides for the appropriate distro, general questions are answered using this as the main source. Documentation for users is almost identical to that on Digital Ocean (they target the same market segment). We don't write subject documentation for users. They do, if we approve it we pay them and publish it (it's the low cost end of the market, minimal SLA).
Internally we follow NIST procedures and are audited to meet several ISO 27K standards (mainly for insurance purposes). We don't own any data centres, or control the hardware. That's a very common practise, with all but the high-end hosting providers (usually). Our internal procedures are more stringent with the main (non-hosting) business as most of the clients are Defence related (this is Canberra, the majority of work here is Defence related).
However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP.
Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?
Because the odds of cracking a strong password via SSH on a server with root logins disabled and a 3 attempt before a long temporary ban are so infinitesimally small that I'm more worried about the sun not rising tomorrow.
There's nothing inherently insecure about a password based login providing the passwords are sent over an encrypted channel, the passwords are strong, and neither machine is compromised, and that even before any talk of login limits.
That belief is common, and incorrect.
Bear with me and I'll demonstrate why that's the case, and explain why it's a common belief.
It's complex, and most people won't invest the time to consider and understand the reasons why it's incorrect.
Many people believe it because many people believe it (a form of circular authority). And because they over-invest in an emotionaly based opinion (which they won't test because they worry about where the results will lead - to further testing of their beliefs). It's foolish because they expend more time and energy defending their beliefs than it takes to test them, and change them when they prove wrong. Note that those people get very angry when that emotional investment in "gut instinct" is challenged. Hence the title of this thread (it's a form of "la la la I can't hear you")
If it was correct there wouldn't be so many instances of attackers gaining access to password protected SSH.
The most common attacks (which your fail2ban logs will be full of) try a list of common passwords. That does have a low probability of success - but there are a lot of boxes allowing password SSH access. Sadly, most of those allow root logins.
fail2ban does limit attempts - by source. IPv4 only. Unless you enforce strong complex passwords dictionary attacks will succeed in a large number of cases.
Most admins do not enforce strong passwords. Key based authentication enforces the equivalent of very strong passwords - far stronger than the login buffer allows. There's no need to guess - you can test the complexity of user passwords. Or simply enforce it by setting the default to key authentication only.
The default of encryption for a SSH connection is not relevant - it's the default. It doesn't render password access more secure than key authentication. In short it's a red herring. (there is no "providing" about it)
tl;dr your belief in the security of fail2ban is misplaced. An attacker can make unlimited attempts by just changing proxy every 3 attempts. There is a high-probability of them doing that. The more desirable access to your box, the higher the probabability.
The vast majority of unauthorised attempts you'll see in your logs are brain-dead bots looking for low-hanging fruit. Those attacks will only get smarter. Best to stay ahead of that curve.
Good security is about reducing risk as much as possible. Doing so is not about whether you "feel" it's secure, it's about whether it can be mathematically demonstrated it's safe. The point of the lead summary, and the article it references, is that it's been well demonstrated that poor passwords lead to poor security. The same big-brains that proved that also strongly recommend the banning of remote logins as root, and passwords for SSH access. There's a reason why the default SSH setting for all recent Linux and BSDs does just that - it's not to make your life hard, or the remote clients - it's to make life hard for attackers.
On the one hand as techs we want (proven) facts, on the other we are human and want to trust our intuitions, and we are lazy. It's that biased hand that is the cause of most security failures.
I imagine that hosting providers default to password logins because it reduces support costs. Their customers tend to be unfamiliar with SSH public key authentication and especially with synchronizing these keys across multiple devices including mobile ones.
Sadly - that's the case with some VPS hosting providers, though I suspect you are being to optimistic about their motivations.
Most of the ones I'm familiar with do promote keybased ssh logins - e.g. it's the default in the images they provide. In the case of the low-cost VPS hosting company in which I have a proprietary interest, all the images we deploy (Ubuntu, Debian, and CentOS) default to no remote root login, no remote password authentication. Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment. TFA for the web management console is available - but not the default. We don't stop users from weakening their direct access to their VMs (it's the low-end box market sector) - nor does the (bare minimum) SLA cover "shoot-own-foot". Where I deal with hosting providers that do high-level SLAs (e.g. obsessive) BP SSH configurations are mandatory.
Why the hell don't you have port knocking enabled for SSH?
I imagine that hosting providers default to not requiring port knocking because it reduces support costs. Their customers tend to be unfamiliar with port knocking.
Again sadly that is the case - they like to keep the bar low to allow drunk toddlers drive Ferraris as long as they enter valid credit card details.
However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP. That's distinct from why some businesses allow their clients to shoot-own-foot, that's just servicing a demand.
No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits).
Could you expand on that? Do you mean - "it isn't true that if encrypted data is modified it can still be unencrypted and the information recovered"? It does sound like a self-defeating encryption scheme (see further down as to why your user case may significantly differ). If the point of encryption is to "prevent modification or access to information at any point in time" rather than "to prevent the reading of the drive at one, known, point in time".
Recovering data from a dm-encrypted disk which has damaged sectors is possible (trickier with SSDs) - even if it's LUKS (BP is to backup the headers and the key-stripe area in addition to the information). dm-crypt does block level encryption, I assuming you are referring to the discussion in context - dm-crypt.
tl;dr you are correct, it is possible to recover data from a disk if sectors have been damaged. Whether that will result in information being reconstructed depends on the the encryption schemes employed.
Which is why backups are kept (typically 3 if that information is important to retain), and damaged disks destroyed. If someone encrypts a partition and doesn't do that I can only presume that information is not something they value as much as they don't want others to know that they have it.
I "assume" that your interest in encryption is focussed on hiding information - in which case information integrity may be less important. I have no firm opinions on that subject, and the conflicts between obscurity and security aspects of being able to detect injected malware make it too complex for me to even hazard guesses.
LUKS OTOH has a feature called "anti-forensic stripes" that is deliberately designed to *maximise* the data loss if bits are corrupted on disc. One of the worst/best examples of a mis-feature ever.
If you use encryption and want to be able to recover information if that information has changed in any way by an unauthorised process - you're doing it wrong.
At this point, I see more attacks against SASL than SSH and root usually has password based logins disabled.
All remote logins as root should be disabled whether they require a password or TFA. AFAIK that's the default in all current release Linux and BSD distros - as is enforcing key based authentication instead of passwords. Those things won't reduce the amount of brainless brute-forcing attempts at gaining SSH access - but will reduce the likelihood of any of them succeeding to almost zero.
Changing the default port that SSH runs on will greatly reduce the traffic you'll see. Using some form of portknocking will reduce the stupid attack attempts even further.
In no way do any of those measures replace actual security. They do reduce the chances of dumb attacks succeeding. And in many instances I'm familiar with they allow service as normal. i.e. military contractors that get so many attacks per second that no one can login until the SSH port is reassigned. That still leaves logging as a problem - hundreds of port scans a day as slightly more intelligent attacks try and find the SSH port. The addition of some form of portknocking removes most of the noise from logs leaving mostly serious attack attempts - which makes monitoring and responding easier.
Reducing the number of SASL attacks is much harder. It's relatively easy to change client settings for SSH as it's rarely baked into programs. I don't have any opinions on how to deal with that, it's something we don't deal with.
Have you even read it? Or did you "think" no one else would?.
Was that the only thing you could find about portknocking in your Google rush?
It only says three "bad" things about portknocking:-
Portknocking is bad because malware might install some form of portknocking
portknocking is bad because it's security through obscurity - which is stupid as saying running ssh on a non-standard port is security through obscurity. i.e. obscurity is only bad if it's the only security.
. Which is irrelevant because not installing portknocking doesn't affect in any way whether malware might install it's own portknocking.
Knowing the knock can open your system. If it's the only system authentication you use. It shouldn't be.
There are other, more valid risks with port knocking which your "security powerslide presentation for n00bs from 2004 overlooked":-
The knock sequence could be captured. Only if you don't enforce sequence rotation. Or better, use SPA
It's another piece of software that could go wrong. Maybe, it's pretty well time tested and audited.
It's hard to log. Not really. But if you find it hard you can do the same thing with iptables or authpf.
Portknocking is not a perfect solution - it's a way to lower your profile, just like using a non-standard port, which it very effectively does - which is why it's one way of meeting the mandatory requirements for ASD privileged networks. Keeping the hordes from the gates is just as important as securing the gates. Employ it using default settings is not recommended, I'd increased the time outs (port knock fails, the port is locked out for a few minutes).
There are alternative solutions (I've already mentioned using iptables to achieve the equivalent of kernel level portknocking, and authpf) but there are also others. But you're the expert.
Allowing ssh passwords is certainly not Best Practise security. TFA is.
fail2ban? It works with IPv6 does it? (try sshguard it does). With passwords enabled, your ssh port visible and protected from bruteforce attacks only by fail2ban you must chew a shitload of bandwidth and log space. Given that, and your earlier post, you're definitely not in a position to decide whether I'm a security professional. I don't claim to be - that'd be a full-time job in itself, but the people who work for me are, as are the clients. Just about every client here is defence or directly connected, failing an audit would be to costly to rely on the sort of citations you supply to justify using well documented Bad Practice security.
My server logs disagree with your assumptions. Fail2ban is running constant blocks on botnets trying to guess passwords on SSH, FTP, SASL and webesites and this goes for my day job, my personal server and my evening contracts.
Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?
Blizzard's Battle.net does this. Or at least to, I haven't checked recently. I did contact them about it and they just scoffed it off as a "security measure."
It's a bullshit excuse on their part. See my earlier post earlier in thread for some javascript that may get around that.
Your argument has one flaw - just because someone uses a password manager doesn't mean he will pick strong passwords...
The flaw you see is not where you think it is. The OP never said a password manager requires strong passwords. That would require idiot proofing - that's a whole other subject.
Using a password manager does not necessarily enforce good passwords - or prohibit the reuse of them.
Writing passwords down means you have to read them out, and type them in to use them - a practise that also does not necessarily enforce good passwords - or prohibit the reuse of them.
Writing passwords down means you have to read them out, and type them in to use them - a practise that encourages bad passwords and the reuse of them.
Using a password manager does not encourage bad passwords and the reuse of them.
The reason for the difference is in ease of use and amount of effort involved. People cut corners because they are lazy or in a hurry. I touch type - most people don't, I make mistakes typing in complex passwords that have been written down. The more I use those passwords, and the more passwords I need to keep, the greater the incentive to practise bad security. Given that most people can't touch type - they have an even stronger incentive than me to practise poor security - the evidence from all the password list dumps and all the security tests on password usage just proves the same thing. People use dumb passwords, people reuse passwords. When they are asked why they do so they say it's because it's too hard to remember them - or to write them all down, keep control of the pieces of paper, and to type them back in each time.
The other risk with using either method for storing password is loss of the passwords. Passwords managers have to be backed up. Paper records of password needed to be backed up and secured. Password manager use passphrase protection so they are secured. (or should be - see my previous comment about idiot proofing)
Some script/program having access to a password field is totally irrelevant from a security standpoint. Heck, even browsers most of the times can't even tell that some html field is THE password field (because there's no standard...often they just guess).
That's interesting. Which browsers guess which form field takes a password please? It'd save me some time if you could tell me the function is used to guess it - but I can just dig through the documentation if you don't remember precisely.
I know how Iceweasel/Firefox finds a password form field - and it's not "guess" work.(it remembers the form field positions from when you hit the Submit button - if you have autologin enabled). The password manager I use knows nothing of form fields - it handles password request from applications. When I'm not using Iceweasel I just copy and paste from the password manager (which I use to hold additional information relevant to each password).
IMHO, this is a browser problem, not a website problem. Browser shouldn't allow scripts to interact with a password field. Period.
[Disclaimer: I'm not the GP AC.]
I'd have to disagree with that opinion. I would reconsider if someone showed me good reason. Typing password manually lead to password reuse and insufficiently complex password use.
Slashdot Mirror
Dear coward
Sometimes the latter, but sometimes, even if you were to follow all his points, there's just not enough interest in the project to make it sustainable. It all sounds so easy coming from a developer who works at one of the biggest open source companies there is that can devote enough resources to a project to make it successful. Try asking some independent developers of a successful project what they attribute their success to and they may have a different list altogether.
He hasn't always worked for Red Hat. They are a good list of rules to use if you want to see where your project could be improved. I suspect you have some obscure definition of success, and/or missed the implicit definition of FAIL.
Try asking independent developers for a list of general reasons why projects fail to get wider usage, grow, and last - I have (that's an old list), the resulting list is pretty much the same, only the scores seem to change.
If it is common sense why do we have to pound it into people time and time again? Or do we just never learn?
Everything is obvious when you understand it?
If common sense was common... would people still say patently stupid things like "you can lead a horse to water but you can't make it drink" (want a bet?), "doesn't have the horse sense to stay out of the rain" (clearly never owned horses, they will seek shelter from rain - in some conditions - it's the broad brush of stupid, though some horses are smarter than others), "you'll catch more flies with honey than with vinegar" (try that with a fly trap).
I could go on... oh wait, I just did.
Why do people think he's not going to get an open trial?
Um, because some people know, what's it called - yeah, history.
Osama Bin Laden. Tell me the plan was to take him alive and put him on public trial. And I'm allowing for the Hollywood factor in the books about his "capture".
Snowden will be "reaching for a weapon" if the USA ever get hold of him.
I hope he lives a long, quality, life.
If the page loads slow, the user will go. Elsewhere.
This is good news. I sincerely hope it triggers a fevered rush by advertisers to outdo each other in slowing down page loads.
One of the rare occasions I've found a compelling reason to endorse stupid.
Dear coward
Jesus Christ don't use AdBlock Pro. They do some pretty shifty shit to try and get paid to let ads around their filters on default configuration.
What "shifty shit" do "they" do. A current citation would be informative.
Nice that you include default. The first thing I do when I install it click on the radio button that disables the default "show acceptable ads". (second sentence)
Use uBlock.[...].
Interesting. You say that. A lot. Is that out of altruism?
Which uBlock are you promoting? There are two. uBlock Origin (or uBlock) and uBlock.
I tried both uBlocks, and found they had a number of failings for my use case. I'll reassess my reasons for not using or recommending it if you show me which reasons are incorrect:-
Caveats: I use ABP in Iceweasel (Firefox) on Linux, all my boxen have >2GB of RAM. I add a lot of extra blocking to the standard filters (and some specifically for /.).
Balance - I have no interest in support for Chrome. I'll happily trade a few extra MB of RAM usage, or a few microseconds of page load time for improvements in blocking. Not seeing ads, seeing relatively more content, customisability, exploit blocking, and decreased data transfer are high priorities for my use case.
For people that need something simple for Chrome to block some ads, and run an OS that chews up most of their RAM, and only want to block ads - uBlock Origin is probably the best choice.
Also use https everywhere.
I use NoScript - which makes HTTPS Everywhere redundant while giving me extra valuable features. I'd add FlashBlock to the minimal recommended extension - if someone has Fffflash installed.
His list, instead of the link to a blog with an article about the list. That blog post is interesting - though the picture of the author scratching is just weird. Was that taken at a lice convention?
My current identity sucks ass.
So? Stop whining, scrape up $20 and buy a better one.
$100 will get you one with 500 Fffacebook friends and 1000 Twitter followers.
$1000 will get you one with no Ffffacebook friends or Twitter followers.
For $5 you could be Depak Chopra.
So for this "hack" to work, you need to have access to the target machine to install malware.
Umm, ok, then I just hacked my companies corporate network by using remote desktop to access a server from home.
About the same level of hack, no?
No. Because you're just using an existing network connection. They're creating one. A covert channel.
And not even close to the same level.
Other posters have constructed scenario based on the most secure conditions to demonstrate the hack is worthless - while conveniently overlooking the fact that many companies have an air gapped computer with little tight security. In which case the evil maid scenario would work just fine.
Is it a hack, or a crack? It's both. The hack is used to crack the air gap security.
Is it no news because TEMPEST is old news. No. Because TEMPEST has distance, difficulty and space limitations. This attack will work anywhere you can get access to the air gapped computer and put a suitably modified mobile phone within reception range. Mobile phones are easy to hide. It wouldn't be difficult to put one in a wall or roof cavity and power it from a simple puncture clip (a plastic clamp with two pin that penetrate the insulation).
It could also be used to bypass encryption and firewalls that protect non-air gapped computers. Lots of those in places where you can have a mobile phone and get reception. One scenario where this might work is ATMs - which would be easiest if you had the willing assistance of anyone who services them. If it was possible to to pull useful information from the system you'd then be able to siphon off useful info without needing to try and break the encryption used for transmission between the ATM and the bank. Generation II Skimmers.
Petrol bowsers (cheap or free petrol), vending machines (free snacks) and similar devices (cheap tickets, credit card information) - if the information can be reconstructed from the data, and if the method could be used in both directions to allow data injection (which is theoretically possible).
I have been to defcon in the past. What is amusing is all the people there from a variety of three letter agencies.
Spot the Fed is always fun. I've always wondered how many that look obvious then are just low ranking Postal workers taking the piss.
There's been talk in the past of banning them - but I don't think the organisers are actually serious about it. I think it's one of the main attractions. They have the best swag to swap.
Because?
No, you have no reason why XP is wrong for the job, you're just parroting what you've heard others say without understanding why.
In an embedded environment with limited attack vectors, XP is fine.
Note: They aren't even attacking XP here, they are attacking the software Brink's themselves wrote. Might be a good idea to get a clue before blaming the wrong thing fanboy.
Agreed. Likely version that ATMs that run XP it's probably the embedded version (on a cheap single board computer with a USB sevice port). Most of the insecurities in XP vanish when you don't attach a web browser, many of the rest when you strip out what isn't in the embedded version. So XP can be made pretty secure. It's possible that it's firewalled - I'd hope so.
It's also possible the Brinks app is Java - and that the exploit is an MiM. In which case the same weakness would likely remain on whatever OS is was running on.
Granted that's a lot of "possibilities". However they're presumptions (mostly a guess based on something) - most of the posts in this thread are pure assumption.(pure guess).
Why does Brinks use software running on an OS? Two reasons I can think of:- they want to see easy customisability as a feature, it's a cheap platform for them to work with. Now they may have to reassess the costs for the latter reason.
And I'm not a fan boi - I run Linux except where I run BSD. I also have more tools than a hammer, and my pepper grinder can be adjusted to grind the size appropriate for the desired result.
The context of the original post was discussing recovering plaintext when a bit of the ciphertext was corrupted - assuming you have the key and no backups.
Um, no - you responded to my post. I responded to a post by bdubSOv1iKIJ403M. No mention of plaintext there.
In this case 'plain' dm-crypt results in typically 128-256 bits of plaintext not being recovered. This guy has done some experiments and says in practice it's similar between corrupted encrypted and unencrypted data.
Interesting reference. Thanks. I don't have immediate comments on it other than: nothing looks dodgy about his tests; SS writes and erases are quite different from HDD (I don't understand them). I've bookmarked as something to ask some one of the ASD SME's about.
I use LUKS (and dm-crypt) for personal and work computers, with critical information also encrypted - because I don't know of a better option, and because it's the highest standard set by main clients (audits aren't a huge concern, penetration is). I have tried to recover data from a damaged drive for which I did have a backup LUKS head and key stripe - and failed. As have others - that not proof it's impossible. I'm now curious if the ASD rules for privileged environments which ban SSD devices even with LUKS in the highest category sector may be related (though it could we be for other reasons e.g. Shamir's third law?).
With LUKS, if the corruption is in the data, then the result should be the same as for dm-crypt.
Maybe. It'd be worth actually testing - which shouldn't be difficult. Until I saw some empirical data I'd be reluctant to form an opinion either way. If it is possible it's game over. (like AES-256 encrypted images, pointless)
But with LUKS, if the corruption is in the header, then there is a possibility *all* the data will be lost (again, we are talking of with the key, but no backups). LUKS is actually designed to maximise this possibility.
Agreed (with qualifications). As I previously stated, that's something I regard as a strength of LUKS, and, as also previously stated, I suspect you are using encryption to different ends.
I don't trust encryption completely - if Shamir's 2nd Law holds true it's likely that there's simply not enough expense involved to make it impossible for all the "information" to be recovered through reconstruction. You keep conflating data and information. Which gives weight to the possibility that you don't even bother to read what you reply to - or worse, don't know what the fuck you're talking about.
The logic is that an attacker is more likely to have a corrupted file. With a password based encryption sheme, the best proxy you have to an 'authorised' person is one who knows the password - in fact that's the only proxy you have. So making it more difficult for people with the password to read the data, without making it more difficult for people without it to read the data, is a misfeature IMO. An attacker maliciously changing the ciphertext to change the plaintext in a predictable way is another issue, but LUKS and dm-crypt are equally bad in this respect as neither support authenticated encryption modes.
I suspect you mean the conclusion of your unstated logic is that the attacker is more likely to have a corrupted file. Maybe (if they try the less likely approach of encrypting your data to access the information). Again, I suspect you are using encryption to different ends (to hide something you've secured). Why you would hide something you don't wish to access again seems stupid - and I don't think you are. What I do think is that you've overlooked the most likely attack to succeed (Shamir's 3rd Law) which is to bypass encryption. If you are keeping something that contains a secret it's likely you'll look at it agai
I hate to tell you this, but you're well within the normal range of variation. Sorry to break the news to you.
You will die ; maybe not because of this medical issue, but you will die.
No-oooo. Tell me that you're just trolling. Please.
I'm a special snowflake that will last throughout the year. If you don't take that back I'll hold my breath. Oh wait....
I'll pay that. Thanks for the laugh. If there are any moderators left that don' t just mod down that should be modded Funny.
Incidentally, I'm following the same progress of eye disease, within about 25%. I'm going to die too.
[shrug] I guess I've read over 20K books, so I'm not complaining - I just felt a little stupid after thinking that the prescription for two pairs of glasses was wrong. And that was after "thunking" it was an issue with displays. You'd think all the wrinkles would've been a clue. Just goes to show that it's not just the eyes that getting past their peak.
I sort of like all my wrinkles. Which is just, um, weird. My girlfriend freaks out about hers. I catch sight of mine in a mirror and it just makes me laugh, which causes her to lecture me about not making the laugh lines worse (which just makes it harder not to laugh).
We all get our time in the sun. I can't say I've missed out on much of the good, have any real regrets - or look forward to senility and a loss of physical ability. But that's another subject. (one I also find hilarious)
That was a very long post with very little content and attempted to retort my comments by talking about admins failing to enforce password policy, and missplacing trust in fail2ban.
So I invite you to re-read my post above. If you don't want to let me highlight the critical parts of my post: ... the passwords are strong ... ... before any talk of login limits ...
So if we take talk about admins enforcing strong passwords and the use of fail2ban out of your post above explain to me again why I am so very vulnerable? Even bouncing through proxies you're not brute forcing a local file. You can't do millions of attempts per second, and with a simple 8 character with capital and number password you have 220 trillion possible combinations.
I'm pretty sure even the dumbest and most incompetent system administrator would notice the high bandwidth / CPU utilisation of brute forcing SSH long before it's broken.
Oh and since we're talking humans and intuitions, what makes you think that someone who can't enforce basic password security is capable of securing their private key?
Logic clearly escapes you. I responded to all your previous points. You ignored them and now resort to leaping from bank to bank astride the horse of desperation.
I've never wrestled a pig before and I don't intend to start with you. I'd just wind up covered in shit and you'd just enjoy it.
Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment)
[Unbalanced parentheses.] Which guide to configuring keys in popular SSH clients does your documentation link to?
We don't provide one. Support refers users to the official security guides for the appropriate distro, general questions are answered using this as the main source. Documentation for users is almost identical to that on Digital Ocean (they target the same market segment). We don't write subject documentation for users. They do, if we approve it we pay them and publish it (it's the low cost end of the market, minimal SLA).
Internally we follow NIST procedures and are audited to meet several ISO 27K standards (mainly for insurance purposes). We don't own any data centres, or control the hardware. That's a very common practise, with all but the high-end hosting providers (usually).
Our internal procedures are more stringent with the main (non-hosting) business as most of the clients are Defence related (this is Canberra, the majority of work here is Defence related).
However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP.
Because BP got hacked by Chinese? Naaah.
[smile] where following BP means jumping in a tug and telling the captain to "follow that slick".
Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?
Because the odds of cracking a strong password via SSH on a server with root logins disabled and a 3 attempt before a long temporary ban are so infinitesimally small that I'm more worried about the sun not rising tomorrow.
There's nothing inherently insecure about a password based login providing the passwords are sent over an encrypted channel, the passwords are strong, and neither machine is compromised, and that even before any talk of login limits.
That belief is common, and incorrect.
Bear with me and I'll demonstrate why that's the case, and explain why it's a common belief.
It's complex, and most people won't invest the time to consider and understand the reasons why it's incorrect.
Many people believe it because many people believe it (a form of circular authority).
And because they over-invest in an emotionaly based opinion (which they won't test because they worry about where the results will lead - to further testing of their beliefs). It's foolish because they expend more time and energy defending their beliefs than it takes to test them, and change them when they prove wrong.
Note that those people get very angry when that emotional investment in "gut instinct" is challenged. Hence the title of this thread (it's a form of "la la la I can't hear you")
If it was correct there wouldn't be so many instances of attackers gaining access to password protected SSH.
The most common attacks (which your fail2ban logs will be full of) try a list of common passwords. That does have a low probability of success - but there are a lot of boxes allowing password SSH access. Sadly, most of those allow root logins.
fail2ban does limit attempts - by source. IPv4 only. Unless you enforce strong complex passwords dictionary attacks will succeed in a large number of cases.
Most admins do not enforce strong passwords. Key based authentication enforces the equivalent of very strong passwords - far stronger than the login buffer allows.
There's no need to guess - you can test the complexity of user passwords. Or simply enforce it by setting the default to key authentication only.
The default of encryption for a SSH connection is not relevant - it's the default. It doesn't render password access more secure than key authentication. In short it's a red herring. (there is no "providing" about it)
tl;dr your belief in the security of fail2ban is misplaced. An attacker can make unlimited attempts by just changing proxy every 3 attempts. There is a high-probability of them doing that. The more desirable access to your box, the higher the probabability.
The vast majority of unauthorised attempts you'll see in your logs are brain-dead bots looking for low-hanging fruit. Those attacks will only get smarter. Best to stay ahead of that curve.
Good security is about reducing risk as much as possible. Doing so is not about whether you "feel" it's secure, it's about whether it can be mathematically demonstrated it's safe. The point of the lead summary, and the article it references, is that it's been well demonstrated that poor passwords lead to poor security. The same big-brains that proved that also strongly recommend the banning of remote logins as root, and passwords for SSH access. There's a reason why the default SSH setting for all recent Linux and BSDs does just that - it's not to make your life hard, or the remote clients - it's to make life hard for attackers.
On the one hand as techs we want (proven) facts, on the other we are human and want to trust our intuitions, and we are lazy. It's that biased hand that is the cause of most security failures.
Why do you allow password logins for SSH?
I imagine that hosting providers default to password logins because it reduces support costs. Their customers tend to be unfamiliar with SSH public key authentication and especially with synchronizing these keys across multiple devices including mobile ones.
Sadly - that's the case with some VPS hosting providers, though I suspect you are being to optimistic about their motivations.
Most of the ones I'm familiar with do promote keybased ssh logins - e.g. it's the default in the images they provide. In the case of the low-cost VPS hosting company in which I have a proprietary interest, all the images we deploy (Ubuntu, Debian, and CentOS) default to no remote root login, no remote password authentication. Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment. TFA for the web management console is available - but not the default.
We don't stop users from weakening their direct access to their VMs (it's the low-end box market sector) - nor does the (bare minimum) SLA cover "shoot-own-foot".
Where I deal with hosting providers that do high-level SLAs (e.g. obsessive) BP SSH configurations are mandatory.
Why the hell don't you have port knocking enabled for SSH?
I imagine that hosting providers default to not requiring port knocking because it reduces support costs. Their customers tend to be unfamiliar with port knocking.
Again sadly that is the case - they like to keep the bar low to allow drunk toddlers drive Ferraris as long as they enter valid credit card details.
However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP. That's distinct from why some businesses allow their clients to shoot-own-foot, that's just servicing a demand.
No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits).
Could you expand on that? Do you mean - "it isn't true that if encrypted data is modified it can still be unencrypted and the information recovered"? It does sound like a self-defeating encryption scheme (see further down as to why your user case may significantly differ). If the point of encryption is to "prevent modification or access to information at any point in time" rather than "to prevent the reading of the drive at one, known, point in time".
Recovering data from a dm-encrypted disk which has damaged sectors is possible (trickier with SSDs) - even if it's LUKS (BP is to backup the headers and the key-stripe area in addition to the information). dm-crypt does block level encryption, I assuming you are referring to the discussion in context - dm-crypt.
tl;dr you are correct, it is possible to recover data from a disk if sectors have been damaged. Whether that will result in information being reconstructed depends on the the encryption schemes employed.
Which is why backups are kept (typically 3 if that information is important to retain), and damaged disks destroyed. If someone encrypts a partition and doesn't do that I can only presume that information is not something they value as much as they don't want others to know that they have it.
I "assume" that your interest in encryption is focussed on hiding information - in which case information integrity may be less important. I have no firm opinions on that subject, and the conflicts between obscurity and security aspects of being able to detect injected malware make it too complex for me to even hazard guesses.
LUKS OTOH has a feature called "anti-forensic stripes" that is deliberately designed to *maximise* the data loss if bits are corrupted on disc. One of the worst/best examples of a mis-feature ever.
If you use encryption and want to be able to recover information if that information has changed in any way by an unauthorised process - you're doing it wrong.
At this point, I see more attacks against SASL than SSH and root usually has password based logins disabled.
All remote logins as root should be disabled whether they require a password or TFA. AFAIK that's the default in all current release Linux and BSD distros - as is enforcing key based authentication instead of passwords. Those things won't reduce the amount of brainless brute-forcing attempts at gaining SSH access - but will reduce the likelihood of any of them succeeding to almost zero.
Changing the default port that SSH runs on will greatly reduce the traffic you'll see. Using some form of portknocking will reduce the stupid attack attempts even further.
In no way do any of those measures replace actual security. They do reduce the chances of dumb attacks succeeding. And in many instances I'm familiar with they allow service as normal. i.e. military contractors that get so many attacks per second that no one can login until the SSH port is reassigned. That still leaves logging as a problem - hundreds of port scans a day as slightly more intelligent attacks try and find the SSH port. The addition of some form of portknocking removes most of the noise from logs leaving mostly serious attack attempts - which makes monitoring and responding easier.
Reducing the number of SASL attacks is much harder. It's relatively easy to change client settings for SSH as it's rarely baked into programs. I don't have any opinions on how to deal with that, it's something we don't deal with.
"Why the hell don't you have port knocking enabled for SSH?"
Because http://www.giac.org/paper/gsec... maybe.
Have you even read it? Or did you "think" no one else would?.
Was that the only thing you could find about portknocking in your Google rush?
It only says three "bad" things about portknocking:-
. Which is irrelevant because not installing portknocking doesn't affect in any way whether malware might install it's own portknocking.
There are other, more valid risks with port knocking which your "security powerslide presentation for n00bs from 2004 overlooked":-
Portknocking is not a perfect solution - it's a way to lower your profile, just like using a non-standard port, which it very effectively does - which is why it's one way of meeting the mandatory requirements for ASD privileged networks. Keeping the hordes from the gates is just as important as securing the gates.
Employ it using default settings is not recommended, I'd increased the time outs (port knock fails, the port is locked out for a few minutes).
There are alternative solutions (I've already mentioned using iptables to achieve the equivalent of kernel level portknocking, and authpf) but there are also others. But you're the expert.
Allowing ssh passwords is certainly not Best Practise security. TFA is.
fail2ban? It works with IPv6 does it? (try sshguard it does). With passwords enabled, your ssh port visible and protected from bruteforce attacks only by fail2ban you must chew a shitload of bandwidth and log space. Given that, and your earlier post, you're definitely not in a position to decide whether I'm a security professional. I don't claim to be - that'd be a full-time job in itself, but the people who work for me are, as are the clients. Just about every client here is defence or directly connected, failing an audit would be to costly to rely on the sort of citations you supply to justify using well documented Bad Practice security.
"Do you have a citation for that Mr. Scraps of Bad Security on Paper?"
Every fucking government agency that uses a fucking AIR GAP like a REAL PROFESSIONAL.
That's not a citation - that's just stupid. Hint: you can't use an air gapped machine on the internet you moron.
My server logs disagree with your assumptions. Fail2ban is running constant blocks on botnets trying to guess passwords on SSH, FTP, SASL and webesites and this goes for my day job, my personal server and my evening contracts.
Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?
Blizzard's Battle.net does this. Or at least to, I haven't checked recently. I did contact them about it and they just scoffed it off as a "security measure."
It's a bullshit excuse on their part. See my earlier post earlier in thread for some javascript that may get around that.
Your argument has one flaw - just because someone uses a password manager doesn't mean he will pick strong passwords...
The flaw you see is not where you think it is. The OP never said a password manager requires strong passwords. That would require idiot proofing - that's a whole other subject.
Using a password manager does not necessarily enforce good passwords - or prohibit the reuse of them.
Writing passwords down means you have to read them out, and type them in to use them - a practise that also does not necessarily enforce good passwords - or prohibit the reuse of them.
Writing passwords down means you have to read them out, and type them in to use them - a practise that encourages bad passwords and the reuse of them.
Using a password manager does not encourage bad passwords and the reuse of them.
The reason for the difference is in ease of use and amount of effort involved. People cut corners because they are lazy or in a hurry.
I touch type - most people don't, I make mistakes typing in complex passwords that have been written down. The more I use those passwords, and the more passwords I need to keep, the greater the incentive to practise bad security. Given that most people can't touch type - they have an even stronger incentive than me to practise poor security - the evidence from all the password list dumps and all the security tests on password usage just proves the same thing. People use dumb passwords, people reuse passwords. When they are asked why they do so they say it's because it's too hard to remember them - or to write them all down, keep control of the pieces of paper, and to type them back in each time.
The other risk with using either method for storing password is loss of the passwords. Passwords managers have to be backed up. Paper records of password needed to be backed up and secured. Password manager use passphrase protection so they are secured. (or should be - see my previous comment about idiot proofing)
And why not?
Some script/program having access to a password field is totally irrelevant from a security standpoint. Heck, even browsers most of the times can't even tell that some html field is THE password field (because there's no standard...often they just guess).
That's interesting. Which browsers guess which form field takes a password please? It'd save me some time if you could tell me the function is used to guess it - but I can just dig through the documentation if you don't remember precisely.
I know how Iceweasel/Firefox finds a password form field - and it's not "guess" work.(it remembers the form field positions from when you hit the Submit button - if you have autologin enabled).
The password manager I use knows nothing of form fields - it handles password request from applications. When I'm not using Iceweasel I just copy and paste from the password manager (which I use to hold additional information relevant to each password).
A stock page login form field:-
Refs: Firefox password debugging, the login manager
IMHO, this is a browser problem, not a website problem. Browser shouldn't allow scripts to interact with a password field. Period.
[Disclaimer: I'm not the GP AC.]
I'd have to disagree with that opinion. I would reconsider if someone showed me good reason. Typing password manually lead to password reuse and insufficiently complex password use.