RawInfoSec

It was a hard decision sometimes, (as most boards gave only an hour so other people get a turn). Do I play Tradewars? LORD? What about downloading another half of disk 2 of UFO:Enemy Unknown? Maybe I should just stuff it all and go chat with the dude on line 2.

519 was an amazing and active BBS community. I still have friends that I see regularly. Some boards we used to chat all night or on occasion we'd insta-rush a bar, karaoke, or bownling alley at 3am just because we could. Some great memories, people etc. So far on the Interwebs I've found only dragons and monsters! lol

Okay there's something not right here.

People are reporting that it was too late, however the block post is gone, and I've yet to see an obit posted in any of the locals around here.

There's more to this.

Why guess when you can just sniff the network for the sequence?

Port knocking requires the network that you're using to knock is in fact as secure and trusted as the one you're knocking. So there's really no point as you could easily just limit SSH access to that network and save yourself all the bother and risk.

Restrict SSH access inbound to trusted networks only. Then you don't have to worry about all this hoopla.

There's a number of things I disagree with in the article, but it does have a few good points.

Here's what I disagree with and why:

- Portknocking. I've found from experience that it's far better to allow SSH access (for example) from only known IP addresses. Portknocking is far too easy to beat and really doesn't impede much.

- Non-standard ports. Sure if you're only interested in blocking bulk network scanners that limit themselves to known ports. Any manual scan or a solid in-depth scan is going to map every one of the lower 1024 ports, and possibly the rest depending on how interesting the target is.

- The Tank camouflage example. It all sounds fine and dandy until a maintenance crew roam the desert for 10 days looking for a tank they can no longer see. Same with security and IT... obscurity leads to lots of wasted time when newer techs try to diagnose things that aren't as they seem, and are undocumented. Not only that, but the since the enemy know that the new armour requires a special ammunition to beat, they will just throw new ammo at everything that moves in case it is a tank. i.e. you're going to scan for hidden SSID's, your going to nmap every port, etc etc. Takes more time, but you still get in.

- If there's a 0-day SSH vector, it's getting owned no matter which port it's on unless your security team are on top of patching. What if the new-hire that's told to go patch all the SSH servers accidentally misses the undocumented one that's running on port 24? It also doesn't matter if there's 10x more hits on port 22 than 24. All it takes is 1. It's that simple.

I just don't think obscurity belongs in an environment where clarity matters so much.

If you can't secure your email, why would you be surprised when your servers dissapop?

I understand that there should have been more layers beyond this and all, but really, what is the point if you're vulnerable across several OpSec levels?

Okay Wordfence CEO.

How the hell does your product prevent SQL injection attacks on a payment processor outside of the Wordpress ecosystem??? ( http://www.theregister.co.uk/2016/04/11/hackers_pwn_mossack_... )

You guys are a joke.

While this helps *.wordpress.com users or custom domains using the wordpress.com back end, it's going to cause a ruckus with self hosted ones.

Neither WordPress or LetsEncrypt has any way to modify global server setting on any shared hosting environment. Slapping in an SSL certificate doesn't make a site secure, properly configuring the services that use the cert is what makes it secure.

GoDaddy isn't going to let Company Xyz rebuild Apache or configure cyphers server-wide...

In the end, while this is a move in the right direction, I fear it will give false confidence to many web providers that don't have enterprise experience with security fundamentals.

Forgot to mention, the RevSlider exploit used on your demo video will not give full access to the system as you stated. It'll give only access which the web server is currently executing as; www-data has no access beyond the webroot.

So your engaging in FUD as well.

I'm not sure why you've decided that they had no firewall in place before. You're not offering any data to support this other than the clear change in hosting which recently took place. This shows a reaction which is perfectly normal, it shows nothing in terms of firewalls.

All I am seeing is speculation after speculation in your article, with absolutely zero forensic evidence of your claim. You're not even addressing the fact that their Exchange server running an older OWA was running an improperly configured SSL certificate which left SSLv3 enabled, leaving it wide open to DROWN.

I'm also seeing many thanks in your comments, and seeing folks mention buying into your product. What I don't see though is you setting these people straight that WordFence is only a tiny part of a much larger solution and that WordFence would have done absolutely nothing to prevent this breach. I'm also not seeing my comment either, but that's okay.

At best, this article is amateur hour for WordFence. It's focused on the topmost layers of the OSI model in an ecosystem requiring attention at all layers, from the wire -> up. Don't sell your product as anything more than consumer grade snake oil.

At the top, whether WordPress is secure or not has zero impact on a properly designed network. If a company is dumb enough to use WordPress on internal hosts, they have bigger problems. Add to this, that a properly designed network should have mitigated the chance that a web server be compromised and at least segregate the network and provide access control to sensitive data.

In short, the network was doomed regardless if WordFence was in place or not and it's damned irresponsible for WordFence to suggest they could protect clients from the kind of attack which played out here.

WordFence are a typical WordPress development company, in that they're web developers first, security / network experts when they need to make a sale.... It's consumer grade crap, which is why this article needs to be treated as such.

I should also mention that just because a web server has an outside IP in the same subnet as the mail server pool, doesn't mean it's on the same physical network. It could be on it's own completely separate physical network or segmented via vlans with full access controls in place. If you understood network security you would know how NAT works.

These guys got hacked because they failed on every level of network best practice or even the fundamentals. Taking advantage of this to sell a product which is equally as naive, is as I said, irresponsible if not negligent.

I think there's actually more web sites being built than ever, and that the problem is that company's expect more for less.

The WordPress pollution has brought about a revolution in pricing within our field. Companies actually expect full e-commerce for under $1k because they've been spoiled with these easy-peasy systems that can be slapped together in no time at all.

How do I market a team of high end devs, engineers and security consultans to develop a company web presence which Joe Nobody is offering them for $599? Here lies the elephant. Not the folks turning quick bucks at our expense, but the mere fact that it's darned near impossible to convince clients to spend wisely.

There are still companies who know better, but in a world where everyone wants to be a 'startup', it's becoming less and less.

First thing I do when configuring a mail client. Enforce plain text only.

Thanks, but you misunderstand my point. Actually you pretty much prove my point that most MTAs are run by those who can't grasp that there are RFC standards out there.

An MTA should never resend after only 5 minutes. It should wait at least 25 minutes before even the first retry.

I've seen many set up to retry every 60 seconds, giving up after 5 tries. One IT tech even told me it was so his boss doesn't have to wait 3 days to get a non-delivery report! Lol.

It's email. SMTP. It's not instant messaging and it sure isn't a browser.

Point blank, it's easy to see that this is by design and not by quirk or fault. If anything Google are looking to maintain usability by keeping as close to RFC spec as possible.

One of the biggest problems facing email today is SPAM, and general deliverability. Once you veer far off spec it gets a lot more difficult to manage these two issues.

For example, look how nice Greylisting worked in theory, until you realize that most IT or hosting companies don't have a clue how to configure an MTA within RFC specs and do silly things like retrying delivery every 5 mins.

When your dealing with complex systems, it's better to keep each part of that system well oiled and within a predictable spec. And then Microsoft adds HTML support to Outlook so that marketing execs can throw 15 sales related images and some wording about saving trees...

Often, solution providers should have given an alternative when asked to do things that break from standards. As we often say in this field, "Just because you can, doesn't mean that you should."

Kc/

Can you post this dialog? I have trouble understanding how they gave a solid "No" on something which warrants much consideration.

Most companies won't even respond if they don't intend to fix something, that way they can claim they're working on a fix when it all blows up in their face.

Note: This information has been disclosed to Google appropriately, they have chosen to not fix this behavior.

The other day, my friend sent me a link

So did Google respond with a "No" or is 2-3 days with no fix considered too long?

I'm not diminishing the seriousness of this problem but it just got a whole lot worse being on HN after only 2-3 days head start on a fix to a major part of the Google product line.

Plus lack of identity validation. While the author of the article minimizes this, we shouldn't remove it from the equation just because users can't tell the difference. The right thing would be to fix the users understanding rather than weaken the product.

LetsEncrypt will be good for all those sites we deploy with self-signed certs, but won't be replacing major sites any time soon.

I can safely say that it's never to limit our own workload. Considering we'd get paid less if we had nothing to do, it would be pretty dumb to work towards that goal. It's to save the company from going bankrupt with explosive costs of maintaining infrastructure in a hostile environment.

Any and all restrictions are there to prevent risk, to both data security and operational costs. There's nothing worse than allowing a user to do as they please because as Bruce Schneier once said, "A user will choose dancing pigs over security every time."

This is why we work with management to show them the costs of allowing users the ability to roam free. Management makes the decisions, IT implement it.

Security is hard. It is highly invasive to usability. It's not your IT department's fault, it's actually yours.

If you want to get employees to lock their workstations, make it a policy and fire the ones who repeatedly break it. If you have to get their attention via childish pranks it's a waste of everyones time.

Also, the IT provider has put a lot effort into security for a reason. The second any employee starts shell coding of any type, it becomes a risk to the company. Management, as always, is blind to this and is probably why they rewarded the author. What they should have done is fire the person for breaching the company's User Access policy. (You do have one, right?)

It may be the employees lunch hour, but it's not their right to abuse company property.

"I have detailed files on human anatomy." - T-800

Every investment opportunity has risk, and many possible outcomes. There will always be investors who gained. There will always be investors who missed a chance to gain. Alternatively, there could be investors who lost, or those who dodged the bullet.

This one had gains and missed opportunity. No one lost anything except time reading a post that appears to be 'prodding the losers' when there weren't any. In fact, some of the investors probably made more elsewhere in something closer to their realm, so it can't readily be said that an opportunity was missed.

I should also note that no email provider should be trusted for 'important email' as mentioned in the article title.

Two reasons.

1) Email is not built with security in mind. Don't suggest SSL as it only protects (somewhat) while in transit and not at rest. You can also bet that not every recipient you send to is using an SSL-enabled POP3/IMAP connection to check mail, so you can't control that end of the conversation.

2) It has no delivery assurance and wasn't built with that in mind. You can never be sure if it arrived, or will be read (by an actual person).

That said, if you need to transmit important documents, use FAX (if the destination has their own (not shared) FAX. Or simply drop it off.

If you need delivery assurance, pick up the phone and ask if they got it, or send if via courier with signature request on delivery.

I agree with him. False and useless.

There's zero evidence to show that, "Gmail not to be trusted with important email.", as the title suggests. None of it is factual. All of it is presented as-is with only what appears to be a very poor understanding of MTA configuration issues.

The answer has been here all along early in the thread. DKIM & SPF yet the complainant has simply shrugged it off with, "Well that would cause consistent issues." (which is also false.)

If he can not do basic troubleshooting or understand the importance of the SPF/DKIM settings in a modern MTA system, and as a basic starting point, he can not assert that Google can not be trusted with important emails.

So. False, and useless.

You're clearly not understanding this.

Random checks do belong in a large scale mail system such as GMail. Their system only checks 1 in x emails for DKIM/SPF.

Could you imagine running DKIM/SPF checks on EVERY single email coming in? That would take considerable compute power, not to mention increasing memory requirements in a system built to minimize such things so that it can be scaled properly.

Your problem is simple. Make your own MTA compliant to any applicable RFC's and GMail will just work. Skipping important items like SPF and DKIM will ALWAYS cause intermittent issues with various other MTA's.

> I'd be perfectly ok with all this if I had made changes on my end but I fail to see how not having made changes on my end this suddenly started happening and I'm supposed to be the one at fault.

You're making the assumption that every delivery is going to the same server, running the same code, which tests the same checks... every time. - It doesn't, and won't. Outcomes can change in a system designed to flex and deal with current problems.

Enable SPF and DKIM before jumping to uneducated conclusions please. Even if it's randomly accepting for the same address during repeat testing does not indicate that it's not caring about SPF or DKIM, it indicates a random check!

To put it into perspective, don't complain about the car, the road, weather, or the cop when you get ticketed for hitting a parked car in the rain while speeding.

Email is highly complex, and GMail are one of the few that are doing it right! (and per RFC's instead of making their own standards like some other unnamed companies do :)