I am a big supporter of Powershell, and while Powershell has supported remoting since almost day one, it will never enjoy quite as much support as SSH already receives (e.g. third party tools, firewall support, etc). It is also nice that they're looking into using something fairly "proven" secure, OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) so we can reasonably expect it to withstand day to day attacks.
In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future...
PS - I really hope later they expand this to SFTP support. SFTP is significantly better than either FTP or FTPS, and something Windows has lacked since forever.
I've been historically what can be described a Microsoft hater and I have to tell you, missing official SSH support has never been a hate generator and insinuating otherwise is insulting.
The first reason for which I have historically hated Microsoft is because of how they fought open standards. I can't believe that Microsoft changed in any meaningful way when I can't get a Lumia phone or Outlook to work with CalDAV / CardDAV. And that's just one current annoyance, as we can always talk about ODF, OpenGL and others.
The second reason for why I hated Microsoft is for their funding of SCO's lawsuit for the ownership of Unix. That was a long time ago, they must have changed right? Except that currently they are behaving like a patent troll, extracting profit out of Android through what can be described as racketeering, more profit than they do from Windows Phone.
The third reason for why I now hate Microsoft is for how they are (again) pushing for Trusted Computing. It's basically what happens when the OS provider becomes the gatekeeper of what you can install and do with your own computer. I never took this as a threat to personal computing, except that now Apple has made it acceptable. Things like insisting on logging in with Microsoft accounts, or only being able to install "modern apps" through their store (while taking a revenue cut of course) would have been unthinkable only 10 years ago. So thanks Apple for shifting the overton window, thanks Microsoft for delivering it to PCs.
Of course, "hate" is a strong word. I don't really hate them, I just speak against them. But given how people fill the forums lately with messages of the second coming, I'm wondering what the heck are these people smoking, because I want some.
CalDAV and CardDAV are supported on Windows Phone 8 since GDR2 as the method to sync Gmail accounts. OneDrive supports ODF via Office Online. OpenGL runs fine on Windows and is less relevant now than ever thanks to Metal and DirectX 12, etc. Oh and the new Outlook app for iOS and Android also has broad support for competitors and open standards. Sure, it's through the cloud, but it works. If you want to punish companies for sand boxing, sure, but hey, how are those iOS viruses and spyware treating you? Even Google's making a kid-safe part of their app store. There will always be ways to develop or hack these devices, but safer, saner defaults are appreciated by the majority of non-technical users.
> OpenGL runs fine on Windows and is less relevant now than ever thanks to Metal and DirectX 12, etc.
I have to express strong disagreement with this entire sentence. OpenGL on Windows desktop continues to suffer greatly from Microsoft's lack of support. OpenGL is more relevant now than ever before due to the dominance of OpenGL ES on mobile and web. Microsoft is starting to support it themselves with WebGL in IE11 and the announced iOS/Android app support for Windows 10. They even joined Khronos Group, but they're still clinging to proprietary DirectX for the Windows desktop, to nobody's benefit but their own. And finally, Vulkan is more interesting than either Metal or DX12 due to being cross-platform, and if Microsoft continues to ignore it in favor of DX12 and we have a repeat of the OpenGL vs DirectX situation it will be a huge shame.
> OpenGL on Windows desktop continues to suffer greatly from Microsoft's lack of support
In what way? I write graphics code for a living and from what I've seen opengl is basically fine on windows. They could do more, sure, but I never felt like they were getting in the way.
I have mixed feelings on the directx thing. In principle I'm not a fan of directx, but in terms of API quality it's vastly better than opengl. Admittedly that's not saying much: opengl's design kind of sucks. State management when almost every state you set is global is a nightmare.
> They could do more, sure, but I never felt like they were getting in the way.
If you would try to ship OpenGL game you'll find out that Windows 8+ shipped with crippled AMD Legacy driver (HD2XXX-4XXX) that don't have OpenGL support in it and can't be really replaced using AMD Catalyst installer until user manually install new driver via Device Manager using extremely tricky way.
There was also crippled Intel drivers without GL support, but as far as I aware new drivers are shipped with GL already.
You'd have to take that up with the hardware manufacturers, I guess. It's not like Microsoft writes said drivers and if AMD chooses to submit a DirectX-only driver for inclusion in the OS then where's MS's fault?
I don't believe that it's AMD and Intel decision to provide crippled drivers to them. After all they never really updated these drivers after hardware become "legacy" and you won't find any package without OpenGL except what Windows 8+ installing via Windows Update. Anyway I had no intention to blame Microsoft there as likely they removed GL support from those drivers not to "harm GL", but just because they won't able to test it as it's not exist for them.
In the end it's only Intel and AMD fault that they don't care enough to put pressure on Microsoft or at least release proper installers. BTW Intel's "The driver being installed is not validated for this computer" bullshit only prove how little they care about GL on Windows.
So comment above stated "opengl is basically fine on windows". No, it's not. Any person that tried to ship or support OpenGL-powered software know that.
Actually, drivers when you're talking about companies like these are developed with Microsoft involved nearly every step of the way. If they cared about OpenGL on Windows, it would've been avoided quite likely.
> CalDAV and CardDAV are supported on Windows Phone 8 since GDR2 as the method to sync Gmail accounts.
Yes, but it only works with Gmail (and iCloud) accounts, not arbitrary CalDAV/CardDav servers. Some people have had success with adding a fake iCloud account then modifying the server address, but it's not officially supported and really shouldn't be relied on to work properly.
I really hope that Windows 10 Mobile includes official support for CalDAV and CardDAV.
CalDAV and CardDAV are not supported on Windows Phone 8, as I'm not talking about Gmail accounts. Office Online supports ODF because they were forced to, but they continue to lobby against it. The new Outlook app for Android is a privacy invading and buggy piece of shit.
And the "grandma" argument falls flat on its face when you've got an app store filled with scams, mallware and trademark violations. It's also a funny argument given that platforms other than Windows haven't suffered from viruses as much. One could say that if Windows wouldn't exist, we wouldn't have this argument in the first place.
If lawsuits and not supporting something you like makes you dislike a company, I'd guess that almost all corporations would be on your 'hate' list.
My dislike of MS is quite simple. I simply don't like their products. That doesn't mean I automatically love OSX or Linux. IMO OSX is a mediocre product with a polished user experience and Linux as a desktop is just broken. Unfortunately, I can't say there is a single OS that I like at the moment.
I'd guess that almost all corporations would be on your 'hate' list.
This is a popular position, yes. But Microsoft in particular have tried to make Linux impossible on a number of occasions over a period of decades, so it'll take a while for the guerillas to come out of the jungle and stop fighting them.
But now they're in competition with the platform that want to annex all your personal data and the platform that want a veto over all applications, so they're not necessarily the most hated party in the room any more.
Linux survived because commercial vendors poured in over a billion dollars into making it a viable UNIX alternative. Microsoft's feeble attempts to sabotage it are pretty much irrelevant in that regard.
It's easy to call it "feeble" because it lost, but the worst-case outcome would have ruled the POSIX API was copyright SCO (funded by Microsoft), making it infringement to distribute Linux.
Linux could have survived in peaceful co-existence without the corporate billion. It would have been smaller and more hobbyist. It could not have survived if all the judgements had gone the wrong way.
> In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future...
I agree with you overall, MS has made GREAT strides in the last year towards moving my needle from "Wouldn't touch if my life depended on it" to "Huh, that's actually pretty interesting". The old MS still shows through with things like how they are handling Win 10 (Both in versions and cost) but overall they are looking up. That said MS still has a long ways to go and I still wouldn't use Windows for anything (other than gaming) but some other stuff MS has done does interest me.
> how they are handling Win 10 (Both in versions and cost)
I'm a bit confused by this. It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else. There are two SKUs (Home and Pro), rather than the multitude with XP or Vista. How is this not a reasonable approach? Especially since Windows 10 is supposed to be the last Windows release of this kind.
> There are two SKUs (Home and Pro), rather than the multitude with XP or Vista
Two SKUs, and then a bunch more; whole list currently is: Home, Mobile, Pro, Enterprise, Education, Mobile Enterprise, IoT core. There are also upcoming still unnamed "industrial" SKUs. Oh, and of course MS is going to offer 32 bit versions too.
Also of course there will also be full suite of Windows Server SKUs, because obviously those are completely different from the client OS...
I believe they also have Windows 10 Enterprise, Windows 10 education and if we include the phone OS: Windows 10 mobile and Windows 10 mobile enterprise.
This is correct - there are 6 Windows 10 SKUs[1]. 4 if you exclude the mobile SKUs. The "only 2 SKUs" was just a rumour/wish.
I'm echoing speculation I read elsewhere: the reason for the numerous versions is Federal Money. The US government demands that it pays the lowest price the vendors offers an item for. Since Microsoft likes to offer discounts to universities, the government would be entitled to the lowest discounted price on the SKU. Their solution is to make Education & Enterprise versions and maintain the price disparity. Money trumps simplicity.
Enterprise is understandable - businesses may prefer not to use Pro. I don't believe that you can count Windows 10 Mobile/Mobile Enterprise against the count as they are merely part of Microsoft's effort to combine all their platforms under one operating system.
> It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else.
It's free ONLY if you get it in their window (1 year I think) it just seems unnecessarily complicated when they should just make it free. Also they have 3-4 more SKUs than just Home and Pro (which really should only be 1).
> Windows 10 is supposed to be the last Windows release of this kind
I'll believe that when I see it also there is nothing I've seen so far to imply all further updates would be free.
Why should microsoft just make their primary commercial product free for everyone? I am curious to know what percentage of MS profit is from OS sales, but I assume it's very high?
Apple can make their OS free cause they make money on the hardware, which 99% of people buy from them to run the OS on.
And of course linux and other open source is another story.
I don't think microsoft makes that much money from customers buying their OS directly, but rather from OEMs installing Windows by default on the laptops/desktops they are selling.
Never once have I met a person buying a standalone windows upgrade/windows OS. Either they end up buying a new computer, they stick with whatever was installed on their computer (hello, XP/Vista users), or they illegally download the upgrades.
They definitely sell retail copies of Windows, and someone must be buying them, or else I can't imagine the retailers would bother stocking them.
For example, a good amount of the people that have Macs also need to run Windows virtual machines (or Bootcamp), and the primary way to do that is to buy a retail copy of Windows. I can't imagine that's a very high percentage of revenue, but I wouldn't say that nobody buys Windows directly.
If you illegally download upgrades, then you're almost certainly infecting your computer with significant malware.
Do people not care about this?
I'm not a big Windows fan (I've run Linux as my primary OS for years), but I've bought several Windows OS packages over the years for work (testing software).
SYSLOG! For the love of god, please support syslog! I work as a consultant supporting a SIEM, and the amount of hoops we need to jump through to get logs from Windows servers is crazy compared to changing one line in a syslog.conf file. I actually dread when a client says "we're an all Windows environment" because wow initial setup just got that much harder.
And if we want to install a syslog forwarder on their domain controllers... no one ever trusts software installed on their domain controllers. Everyone trusts a single line in syslog.conf.
MS has supported event forwarding since 2003. You can set machines to forward events or have them pulled. The events are XML that conform to a published schema. There is a WMI call that call pull the aggregated events off the collection servers.
I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works.
Why are they different? The event log has some transactional guarantees that were required for a specific kind of security evaluation...C2? I can't remember the rest.
The thing is...you don't have to install a client on the domain controllers. You can setup forwarding to some log hosts and collect them there.
It's like people don't even try to learn how it works
It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.
You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration.
To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.
That's a really good point, thank you. I've never really thought about it that way; e.g. the registry is something you should sort of treat as an opaque blob of state (like a smalltalk image?) that you just mutate over time programatically, rather than as a declarative set of configurations to bring the machine to at any time.
After coding for several years, the two aren't all that different.
I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX.
Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.
I think you have it backwards. Sysadmins are not the ones arguing in favor of "the one true way". That is squarely in the newer breed of developer/admin devops hybrid that the systemd camp is pandering.
For sysadmins the nix way of text in and text out allow systems to be as simple or complex as they need to be, because parts can be swapped, added or removed as needed.
The kernel don't care what your initial process is (you can for instance point the Linux kernel straight at the sh binary and be presented with a root shell the moment the kernel is done getting the hardware up and running), and the programs you want to run don't care either.
Thus you can run nix on anything from a dinky single core SoC to a warehouse sized compute cluster.
But systemd is pandering the latter while giving the former the middle finger. This by ignoring the text in text out loose bindings that has been the core of *nix.
I'm not trying to be facetious...What part of X11 matches the text in/text out -- small programs that do one thing -- mode? Even Linus says that "model" doesn't really apply any more.
Maybe systemD and it's author's are whatever...I think that the CoreOS people are demonstrating that programmatic administration is the best model for massive scale. That's my only point.
That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :)
I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system.
With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source
(I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)
Wow. Before I start...that's cool that you are using CE. What are you using it for? (If you don't mind and have a minute.)
I get what you are saying. I don't think that the programmatic model of administration works for running something like PeopleSoft, right? You use large hosts that are very special and benefit from the traditional admin model. It's very much a "pet"...where the CoreOS model is more "cattle".
I'm more ambivalent about access to source as long as there is good documentation and debugging tools. I'm not going to fix a kernel bug at this point in my development. Maybe one day...
From what I know, you can use Microsoft RPC to pull event logs or you can install a syslog forwarder, or you can do a combination of these two things (have a Windows syslog forwarder that is not a DC that can pull logs from a DC through RPC). The problem with the last option is, adding another Windows server costs an additional license. Installing a client on the DC doesn't. And there are limitations, so in a huge Windows environment, you're installing several extra Windows servers, each individually licensed, just to forward logs.
I've worked in security with several different SIEMs for half a decade and those are the only options I've ever seen. So if there's something else besides this that is easier, it's not just me who is missing it. HP, Dell, Intel and a dozen other companies are missing it as well.
Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.
Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large footprint and exposure at an organization. For what its worth... most IT people are just as bad. I'm trying to turn that around at my organization. I don't blame people...I get it. It just takes time to disseminate info.
>Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.
You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license.
There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.
You CAN export the event log data of course, even remotely. But it's rather ugly and I agree that some standard aggregation (syslog or anything) would be great.
A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)
You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though.
Also, sshd + fwknop (port knocking) is a very secure combo, IMO.
And both these things you never do in production because it takes little effort to establish there must be a port open, whereas the cumulative time you'll spend tracking down whether its a network issue or bad/wrong keys is just not worth it.
Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.
openvpn, which is just ssl, was vulnerable to heartbleed.
Like the GP said - you're trading VPN bugs for SSH bugs - and experience shows that betting on SSH is generally wiser.
If you only need TCP/DNS and not a full-blown VPN, a program called sshuttle uses ssh+python to provide excellent seamless poor man's VPN. It's not perfect - e.g., you lose the ip src address on the forwarded connections - but it works amazingly well, much better than e.g. openvpn and most other vpn products I've used.
PubkeyAuthentication and disabling password logins helps a lot too. I've also been using deny_hosts a lot over the last couple years as an extra layer.
That solution is secure, but I used the word "smarter" to describe the use of a VPN intentionally. You are introducing nonstandard practices (everybody knows what a VPN is and everybody's already able to deal with them) with nonstandard behavior (ever tried to debug fwknop? because I have) and creating an obscure way for your stuff to fail (and it will, at 3AM, and you will not be able to Google your way out of it).
And you're also manually creating SSH tunnels to do anything else inside that network, so you've got that going for you, too.
It's 2015. A VPN is the settled method for accessing sensitive services inside a private network. Doing otherwise may create great nerd cred but doesn't make you do your job better.
The reason that no one has given yet is that you can monitor more carefully when you have a VPN. With a VPN, you can follow the bastion model; the VPN server runs only the VPN code and nothing else (with as much crap removed as possible), with a really restrictive SELinux policy, every tiny error logged and forwarded.
So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs.
It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.
It's not necessarily better. But now you have two layers of security (VPN + SSH), rather than just one.
And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.
Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.
If you do this, keep it in the privileged range (< 1024) or you run the risk of your ssh server crashing and some malicious normal user binds to your unprivileged port with a fake sshd and grabs your root password.
Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing.
If you're whitelisting IPs, you may as well run it on port 22.
No it makes it harder and more of a pain. Trust me I have a friend who loves breaking into my personal server. That one trick two ssh running on different ports screwed with him for a long, long time. He is a genius of a hacker and has been doing it for a living for years. When he finally got in he was so pissed that threw him.
You are describing an anecdotal instance of a person whose capabilities are not established being thrown by something that nmap will catch on a normal scan.
Color me skeptical. I shall decline to "trust you."
Not my competence it his competence I trust and I got him good with that one since it never occurred to him that one stupid trick messed with him for so long. Lie 5 minutes a month.
One small benefit of using a non default port is that it keeps down the noise from automated scans. So any "real" suspicious activity will now stand out as it is not drowned out by the noise anymore.
If there is a defect with VPN and you gain arbitrary execution then you'd have access on the system as whatever user the VPN was running as. You don't necessarily have to break VPN and SSH.
The machines running your VPN are presumably not the same machines you're trying to access via SSH. A compromise in your VPN should't give anyone execution access to anything interesting.
From what I have seen FTPS seems as secure as SFTP if well configured (i.e. no fallback), why do you say FTP is such a bad protocol?
I have tried to look it up, but the answers seem to revolve around firewall being hard to setup and FTP being not secure (which is resolved by encapsuling it in SSL).
I am a big supporter of Powershell, and while Powershell has supported remoting since almost day one, it will never enjoy quite as much support as SSH already receives (e.g. third party tools, firewall support, etc). It is also nice that they're looking into using something fairly "proven" secure, OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) so we can reasonably expect it to withstand day to day attacks.
In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future...
PS - I really hope later they expand this to SFTP support. SFTP is significantly better than either FTP or FTPS, and something Windows has lacked since forever.