So the answer is... it depends. Do you control the computer in question? If so, you can normally add the certificate to it and it will trust it.
But if you don't want to have to install the cert for every computer that will use it, then sadly only a CA signed cert (which are free, though) will work as you need to have the browser trust it and that is the only mechanism.
@pete-s said in "Site not secure" | Self-signed Certificate?:
You can't get or buy publicly trusted SLL certificates for any server on your LAN, only for public FQDNs/IPs
We get them. It's just more effort.
@dashrender said in appear to come from an IP:
@scottalanmiller said in appear to come from an IP:
The biggest products in use are the worst ones because anyone who doesn't rely on IT vetting on these things will always gravitate towards ancient, abandoned code.
I don't disagree they will end up there in many cases - but what makes you say they will gravitate? the fact that they are the biggest/most advertised/know by word of mouth? certainly you're not implying they would purposefully pick a product with abandoned code?
Because the nature of business people who ignore important factors is to focus on easily visible ones like age, popularity, name recognition, cost, experience, etc. all things that favour old and abandoned software because ghost ship software has the highest profit margins making it the easiest to advertise, promote, discount, etc.
@jaredbusch said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
@scottalanmiller said in "Site not secure" | Self-signed Certificate?:
@pete-s said in "Site not secure" | Self-signed Certificate?:
You can't get or buy publicly trusted SLL certificates for any server on your LAN, only for public FQDNs/IPs
We get them. It's just more effort.
Please elaborate Scott!
Yes, please.
Sure, you just have to do it via the DNS TXT process. The server has to be able to reach out, it can't be totally isolated from the Internet (unless you want to move the files around manually) but it verifies that you own the name without needed to provide a file. We do this for some clients all of the time. It's a pain and cannot be automated, so you need a human to get involved from time to time to make it work. But it works.
Here is a writeup that someone did..
https://gock.net/blog/2020/using-lets-encrypt-with-internal-web-server/
In this case they are using it for internal web servers. The reason that I normally use it is that I use LetsEncrypt for things that aren't web servers and so act the same as isolated LAN devices.
Loose socket is possible, but unlikely. But cleaning everything isn't a bad thing to do regardless.
I think the easiest thing is to provide us with the entire scenario. What is the computer used for? Why the weird port? Why don't you have a cert?
Weird port: 8080 is the generally accepted INSECURE secondary port. 8443 is the generally accepted SECURE secondary port. It's all random, but confusing to humans.
Easiest thing is to override DNS for that domain and point to the proxy. Then the proxy can point on to whatever is real.
@dashrender said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
I agree 99.9% of the time - the other .1% is what bites - when you have a bad patch and have to uninstall it.
WSUS doesn't fix the .1%. It just delays it, which doesn't help things.
@fredtx said in Wsus for remote vpn and on-premise users:
@irj said in Wsus for remote vpn and on-premise users:
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
That's another topic I want to get to as well. The topic of when and how to schedule/approve patching for your business in a Windows environment? And what is best practice? That may need to be a different post though.
Best practice (which is in my book that just came out, by the way) is ...
If you don't have a huge testing environment where you can test patches within ~24 hours of release, to patch blindly without delay.
If you create any delay, hesitation, or opportunity to not patch, you have a big problem. WSUS represents all of these. Basically, if you are asking the question, it means WSUS is wrong for you and you need immediate patching.
If you have any hesitation to that policy, it means you are running a platform you don't trust in production. That's valid as a concern. But your IT has committed its trust to Windows, so either you need to embrace that decision or you need to convince them to change.
@irj said in Wsus for remote vpn and on-premise users:
@pete-s said in Wsus for remote vpn and on-premise users:
If you are considering having clients download updates from Microsoft directly then that means that you are going to apply all updates, doesn't it?
If that is the case, what functionality does WSUS bring to the table?
95% of WSUS administration is blindly approving updates anyway. Just let them auto update and be done.
Yup, I'm a huge opponent of WSUS. Most of the time (nearly all of the time) it consumes huge resources, wastes ITs time, puts patching at risk, breaks things in dangerous ways, undermines security, and makes what should be simple hard and often generates more licensing needs for no reason.
It has its place, but it is so rare that it is actually beneficial. It has so many cons and effectively no pros. And only an organization with such insane scale could ever possibly truly test patches, WSUS is basically zero benefits with a HUGE invitation to problems.
@notverypunny said in Wsus for remote vpn and on-premise users:
If you're starting from scratch I'd suggest taking a serious look at leveraging TacticalRMM (or something paid if you really want to spend money) instead of WSUS. (As mentioned by others)
Yup, that's EXACTLY what I was thinking. Free, no licensing overhead, way less effort to configure, maintain and use. Far easier to understand. Isn't limited to Windows should that ever matter. Does tons and tons of stuff outside of just patching and reporting.
This is what we use and as it is free, it always makes me wonder what role something like WSUS would ever play given that Tactical covers the features of WSUS you generally want without all of the cost and limitations.
@dashrender said in Locking down vendors:
@scottalanmiller said in Locking down vendors:
@dashrender said in Locking down vendors:
They MIGHT have an internal team for this, but since we have our own IT department, my management has decide to take the costs internal versus paying the new vendor to set up remote access for themselves.
That doesn't really make sense as this is all questions about THEIR IT. All your team can do is get in the way
I don't follow:
NTG does support for clients that only want you to touch specific things - they don't want you to come in and setup a special network just for those things.. so their IT sets up some type of access for those things.
Not sure how this is different?
That's not really how any customers work as that would be expensive and super impractical (and almost universally, internal IT gets security horribly wrong and would expose themselves and us through their bad practices.)
Every real world customer that we deal with asks us what to do and we provide the tools. Because we have to manage the authorization, revocation, promotion, vetting, and such of our team, who they report to and so forth, we have to have the ability to manage the users and determine what level of our access they can have. The customer doesn't have the necessary visibility to manage security needs.
Letting the wrong IT department handle it risks things like VPNs, shared accounts, shared passwords and so forth because you are asking the team lacking the necessary access and visibility to try to manage a team that they don't know about or control. And it breaks workflows. NTG has workflows around hiring, firing, promoting, job role changes, emergency access and so forth, that are normal, regular, and secure. But a customer can't have that with our staff.
For a customer to do this effectively with us (or any outside vendor) you'd have to build out such a ridiculous about of infrastructure to be secure, that's almost never used because it's part time. It just doesn't make IT sense.
@jasgot said in Password Managers:
I'm trying to wrap my head around the idea of my passwords being stored on someone else's storage; in the cloud.
How do you reconcile this? What specifically makes you think it is safe to do so?
Easiest to reverse the question...
Try wrapping your brain around storing passwords locally on your own infrastructure. That's less secure on average (dramatically so) than on cloud. So if you can answer this for local, you've proven cloud is better (because cloud is better.)
There's nothing to reconcile. You want passwords to be secure, cloud is more secure and more importantly, available when needed.
The same thing makes it safe there as does locally ... encryption. If the password system is not encrypted then it isn't safe anywhere. If it is properly encrypted, it is safe anywhere. That doesn't mean that you want to expose it, but it means you could.
So because we have good encryption local storage is safe enough. Since cloud is better (more secure, more available), there's nothing to reconcile.
@jasgot said in Password Managers:
I have been avoiding password managers for years because I simply don't trust other people or organizations with my passwords.
Well, but... no one is asking you to do that. You are asking them to store the ENCRYPTED data of your passwords. You don't have to trust anyone. You should still use a vendor you trust, of course, but there's no need for trust. That's the point. With proper encryption you don't care that someone else theoretically (and it's truly only theoretical, the access to your data is generally greater on your own infrastructure than in the cloud) has access to the physical boxes.
Remember ALL super high security systems are run this way. From military to government to Wall St. - there are datacenters (cloud or otherwise, it's all the same from an access perspective) and the security assumption is always that the physical access should be protected, but that bad actors will get in, and encryption makes it so that the access has no value.
@dashrender said in Password Managers:
@jasgot said in Password Managers:
@rojoloco said in Password Managers:
@eddiejennings said in Password Managers:
I was a LastPass customer to turned to BitWarden.
BitWarden here too, still trying to get management buy in to deploy it for everyone.
@eddiejennings said in Password Managers:
I was a LastPass customer to turned to BitWarden.
I'm trying to wrap my head around the idea of my passwords being stored on someone else's storage; in the cloud.
How do you reconcile this? What specifically makes you think it is safe to do so?
I have been avoiding password managers for years because I simply don't trust other people or organizations with my passwords. But I am finding the sheer number of password I have -- to be getting too cumbersome to manage; so I am considering it again.
LastPass was does all the work locally only. Only the encrypted blob and your email address is stored on their system.
That's normal. I don't know anyone who does it otherwise, that's considered base functionality to be considered a viable password manager.
@fredtx said in Wsus for remote vpn and on-premise users:
So a little background about this company I'm trying to implement patch management, is that it's growing through acquisitions. There's currently about 12 locations, and I just heard recently they acquired another company, which adds it to 13 locations. I'm wondering if implementing an RMM will benefit this company for the future? They are growing at a fast rate, and it doesn't appear to be slowing down.
In my opinion, RMM almost always makes sense. It's weird that internal IT departments use it so infrequently. What makes it logical for MSPs also makes it logical for internal IT. There is little different between an MSP and internal IT. Once in a great while that difference could be reflected in different tooling. But typically, it would not. The similarities are too close.
Most internal IT today is heterogeneous and that almost guarantees that RMM is the right approach over more "traditional" internal tools. Most internal tools are built around homogenous LAN environments, not disparate heterogenous environments.
@obsolesce said in Wsus for remote vpn and on-premise users:
@scottalanmiller said in Wsus for remote vpn and on-premise users:
There is little different between an MSP and internal IT.
They are basically the same thing. In many cases the internal IT is a separate entity that basically bills the company and/or child companies, but is on the payroll of the company.
Yup, the key difference isn't their relationship to the rest of the org, effectively MSP, ITSP, Internal IT, etc. are all external in how they are approached. Only how they are paid really differs and the staff don't always see that.
What makes the two different is that an Internal IT department (even one treated as a consulting group) has only a single top level customer and MSPs have multiple. That's really it.
And that doesn't always make a real difference. If the top level internal IT customer doesn't force all underlying groups to unify under a single IT strategy you get an effective situation of multiple customers, sometimes as you said, even with separate billing.
@Pete-S said in What do you use as an identity provider?:
You mean if you paid for M365 then you're already using Azure AD as your identity provider in which case JumpCloud serves no purpose?
For one thing, Azure AD is lacking connectors for normal things like Linux desktops. Doesn't even WORK in our environment or most of our customers, almost none. At most it works for SOME workloads.
@WrCombs said in vLANs random question.:
Claiming its more secure, reduced PCI Questionaire (which I dont see how it reduced the questionaire), but they've been told it's possible - which I agree it is, but I still dont get why.
If the two can talk to each other, the PCI exposure spreads between them.
