|
ghostinmyshell posted:My favorite is the quarterly vulnerability scanning where things like 3389/22 gets marked as high. Boss doesn't read report and just says fix everything or else. I'm going to tell him to bring all the servers in house and I'll work on them hooking up a monitor and keyboard. Makes no difference to me. It is a pretty high vulnerability if anyone can connect to them and you don't have an IP lock out system in place tho.
|
#
?
Nov 10, 2015 05:05
|
|
|
|
| # ? May 12, 2024 16:22 |
|
|
RFC2324 posted:It is a pretty high vulnerability if anyone can connect to them and you don't have an IP lock out system in place tho. Should they be firewalled off in some manner? Maybe, it depends on the network. If it were me, I would just block the scanner IP with the OS firewall and call it good. Easy fix.
|
|
#
?
Nov 10, 2015 06:16
|
|
|
adorai posted:Should they be firewalled off in some manner? Maybe, it depends on the network. If it were me, I would just block the scanner IP with the OS firewall and call it good. Easy fix. You're what I like to call "dangerously incompetent"
|
|
#
?
Nov 10, 2015 07:00
|
|
|
adorai posted:It's not a vulnerability. If your definition of vulnerability is public ability to login, every web based application has a vulnerability. Any sane system policy is going to restrict failed logins to some number, so the mere fact that those ports are open is not a vulnerability in and of itself. I was talking about fail2ban or whatever applies to windows. And logging into a webpage is world different than logging into the operating system. If you don't understand that difference, you REALLY need to get out of IT in every way shape and form, I wouldn't even trust you on helpdesk.
|
|
#
?
Nov 10, 2015 07:29
|
|
|
adorai posted:Should they be firewalled off in some manner? Maybe, it depends on the network. If it were me, I would just block the scanner IP with the OS firewall and call it good. Easy fix. If your "fix" is simply to fool internal security auditing tools and I found out, I'd be actively lobbying for you to be fired. Holy poo poo. I really hope you're just a minion and not someone with real responsibility.
|
|
#
?
Nov 10, 2015 14:11
|
|
|
VPS provider X has a sea of Windows servers with RDP open to the outside world. As long as you follow the normal procedures of secure passwords and non-standard user names you should be okay 99.9% of the time. At minimum you would want some kind of firewall or at least allow connections only from certain IP's, and ideally you would like a VPN login required. RDP is a lot more secure than it was just a few years ago but you still run the risk of a new exploit coming out and then a worm popping every open RDP server on the internet in like 2-3 days. It's just a lot more likely to happen with RDP than it is something like SSH.
|
|
#
?
Nov 10, 2015 14:44
|
|
|
adorai posted:It's not a vulnerability. If your definition of vulnerability is public ability to login, every web based application has a vulnerability. Any sane system policy is going to restrict failed logins to some number, so the mere fact that those ports are open is not a vulnerability in and of itself. You are the person who turns SELinux off. You are the person I hate.
|
|
#
?
Nov 10, 2015 14:48
|
|
|
Also this is literally what Remote Desktop Gateway exists for.
|
|
#
?
Nov 10, 2015 14:52
|
|
|
^^EFB because I am phone posting on the train. Ideally you stand up a Remote Desktop Gateway that runs over HTTPS and requires you know the hostname/IP and have access to the destination through AD permissions in the gateway. I did that at my last job so we could stop handing out full access VPN to loving everyone, including consultants and vendors.
|
|
#
?
Nov 10, 2015 14:55
|
|
|
This is the first time I've ever done a physical SAN install with two CEs - I've never felt less necessary in my life heh
|
|
#
?
Nov 10, 2015 21:34
|
|
|
Goddam the Skype PSTN dial-in service is pretty much flawless 
|
|
#
?
Nov 10, 2015 22:18
|
|
|
We're doing an IPSec evaluation for our core business stuff. It involves a number of Gateway servers, including VDI and RDP. One of the senior platform guys just asked why we don't just automatically generate and hand out IPSec certificates to every computer on the domain. ....um. Because why do IPSec then? I mean, it's like 9 servers that need IPSec certificates.
|
|
#
?
Nov 10, 2015 22:18
|
|
|
Got an email from the CEO's assistant at the old place. I replied that this month will be a year since I left and I loved her reply: "I can’t believe it’s been a year…there are no calendars in this I.T. HELL!"  The department has been handed off to a new manager, again! This time it's their new Chief Risk Officer, the fifth executive to oversee I.T. in the last five years. This person has no technology or operations background. Low C on the totem pole I guess.
|
|
#
?
Nov 10, 2015 23:35
|
|
|
adorai posted:It's not a vulnerability. If your definition of vulnerability is public ability to login, every web based application has a vulnerability. Any sane system policy is going to restrict failed logins to some number, so the mere fact that those ports are open is not a vulnerability in and of itself. SSH generally should not be exposed to the Internet without some kind of firewalling. You're going to want to have IPTables or another firewall restricting which source hosts can connect to the box. Leaving it open to any source is not a good practice, at all.
|
|
#
?
Nov 11, 2015 00:07
|
|
|
ssh is totally fine. Use fail2ban if password auth is on (which it shouldn't be, at least on something public-facing)
|
|
#
?
Nov 11, 2015 00:13
|
|
|
Does RDP have something equivalent to SSH keys and/or fail2ban?
|
|
#
?
Nov 11, 2015 00:47
|
|
|
Client certs. And you can trigger scripts on event log actions, so powershell to add firewall rules on failed logins should be really easy. Or there are 3rd party tools, of course. But you should just use an RDP gateway and configure it properly
|
|
#
?
Nov 11, 2015 01:00
|
|
|
You should never have SSH open to the world, ever, for the simple fact that eventually someone will make a mistake and a machine will get put on the network an an insecure configuration (yeah, this BMS appliance has the default login, I only just installed it yesterday...) and it'll get hosed. SSH/RDP should always be closed, if remote access is needed then a role-based VPN solution is the way to do it. Alternatively, if people need SSH access in then secure it based on source-ip and keep track of who it is so at least you can point the finger at someone if you get compromised.
|
|
#
?
Nov 11, 2015 01:26
|
|
|
abigserve posted:You should never have SSH open to the world, ever, for the simple fact that eventually someone will make a mistake and a machine will get put on the network an an insecure configuration (yeah, this BMS appliance has the default login, I only just installed it yesterday...) and it'll get hosed. Allowing SSH into hosts on your company's network still requires some sort of NATing so it's not like someone standing up an insecure server internally will mean that server is automatically exposed to external networks, absent the creation of additional configurations to make that possible.
|
|
#
?
Nov 11, 2015 01:30
|
|
|
It's not that any one type of exposure is bad, it's that anything that's left open will always have the chance of being exploited sometime down the road, hence the best practice of only leaving open or available what you have to. That's really all there is to it. Unless there is a good reason to have something like that public facing, disable it.
|
|
#
?
Nov 11, 2015 01:31
|
|
|
ACLs or certs sound a lot more convenient for ssh than a VPN. Another vote for RDG for remote desktop too
Roargasm fucked around with this message at 01:37 on Nov 11, 2015 |
|
#
?
Nov 11, 2015 01:32
|
|
|
A complete VPN setup can solve other problems though. It's good plumbing to have in place.
|
|
#
?
Nov 11, 2015 02:06
|
|
|
It can also cause loads of problems if your VPN gives the same level of access as a device connected directly to the LAN because you did a bit of set-and-forget with the configuration. I'd prefer to exhaust all other options before resorting to VPN.
|
|
#
?
Nov 11, 2015 02:10
|
|
|
just turn it all off and use paper
|
|
#
?
Nov 11, 2015 02:56
|
|
|
If you're giving someone access to a RDG and then allowing that box to talk to internal resources then that's literally an SSL VPN that only does port 3389. Any hardware VPN box can do that with the added bonus of it not being transparent to your network and security administrators. Then again every place I've worked so far basically does not trust server admins to not to stupid poo poo so if you have a better relationship with your security staff I can certainly see how such a solution would be better than a full on VPN. Regardless I think client VPN's will eventually be replaced by VDI solutions except for very niche things.
|
|
#
?
Nov 11, 2015 03:10
|
|
|
abigserve posted:Regardless I think client VPN's will eventually be replaced by VDI solutions except for very niche things. That's going to be a long while considering the cost of desktop storage versus SAN storage. VDI works well for non-persistent instances and terribly for everything else unless you want to spend a fortune.
|
|
#
?
Nov 11, 2015 03:19
|
|
|
abigserve posted:If you're giving someone access to a RDG and then allowing that box to talk to internal resources then that's literally an SSL VPN that only does port 3389. Any hardware VPN box can do that with the added bonus of it not being transparent to your network and security administrators. Like I mentioned before, RDG only listens on port 443 via HTTPS, and does not require software to install like almost all VPNs do. Also, if you are doing it right, you can limit the internal resources that any user has access to via AD groups and the fact that standard users are not part the the Remote Desktop Users group by default. Yes you can do similar configs for VPN, but typically with way more work. Also, you know that Windows has logs right? I don't know how it would be "transparent" by your standards.
|
|
#
?
Nov 11, 2015 04:02
|
|
|
abigserve posted:If you're giving someone access to a RDG and then allowing that box to talk to internal resources then that's literally an SSL VPN that only does port 3389. Any hardware VPN box can do that with the added bonus of it not being transparent to your network and security administrators. That's not what an SSL VPN does. A client VPN connection modifies the client interfaces, route tables and DNS and makes the client appear to be connected to a local, internal subnet. Firewall rules need to be put into place to prevent clients on the VPN from communicating with other services, and that's assuming they haven't just been configured to land on the same subnet as a bunch of other internal devices. Your VPN connected client can propagate malware into the local network if the appropriate firewall rules and NAC rules aren't in place. An RDC connection just provides a tunnel into a specific internal resource. It's far harder for client resident malware to propagate that way since there is no direct route from the client to other internal resources. Wrath of the Bitch King posted:That's going to be a long while considering the cost of desktop storage versus SAN storage. VDI works well for non-persistent instances and terribly for everything else unless you want to spend a fortune. Hybrid and all flash storage have gotten much cheaper and things like inline dedupe, compression, and clone offload have made consolidation of large numbers of desktops on a relatively small amount of storage feasible, bringing the true cost down even more. Add in the operational savings and security benefits and the cost argument starts looking worse and worse.
|
|
#
?
Nov 11, 2015 04:27
|
|
|
NippleFloss posted:That's not what an SSL VPN does. A client VPN connection modifies the client interfaces, route tables and DNS and makes the client appear to be connected to a local, internal subnet. Firewall rules need to be put into place to prevent clients on the VPN from communicating with other services, and that's assuming they haven't just been configured to land on the same subnet as a bunch of other internal devices. Your VPN connected client can propagate malware into the local network if the appropriate firewall rules and NAC rules aren't in place. Of course, but an RDG performs the same function, that is tunneling application traffic inside SSL to get around security policy that would otherwise block it. The difference is installing an actual VPN server usually requires the input of networks and security and can be configured however you want when your clients suddenly also want access to other internal resources instead of just RDP. Your methodology was applied at my last job, a university, where everyone just did whatever they thought worked without considering the wholistic picture. Yeah sweet RDG works for that application, and I guess an SSH gateway can do that as well, but oh now you've got departments running all sorts of servers all around the place instead of someone just consolidating it all into one properly configured system.
|
|
#
?
Nov 11, 2015 07:50
|
|
|
abigserve posted:Your methodology was applied at my last job, a university I didn't state a methodology. I just said that VPN and RDG have different security considerations. This is a conversation about security so it's pretty important to not draw a false equivalence.
|
|
#
?
Nov 11, 2015 07:58
|
|
|
abigserve posted:Of course, but an RDG performs the same function, that is tunneling application traffic inside SSL to get around security policy that would otherwise block it. The difference is installing an actual VPN server usually requires the input of networks and security and can be configured however you want when your clients suddenly also want access to other internal resources instead of just RDP. e: I'm going to set the spread at ten separate Dropbox for Business accounts for different departments/labs. Vulture Culture fucked around with this message at 08:06 on Nov 11, 2015 |
|
#
?
Nov 11, 2015 08:02
|
|
|
Vulture Culture posted:I just want to clarify that when you say "one properly configured system," what you actually mean is "one IT-managed system that a few people actually use, and an entire set of shadow IT infrastructures in the public cloud that IT doesn't know about and will never, ever manage." Are you saying IT departments/IT infrastructure should be abolished or what? If so I think I agree NippleFloss posted:I didn't state a methodology. I just said that VPN and RDG have different security considerations. This is a conversation about security so it's pretty important to not draw a false equivalence. You specified a solution to a problem (RDP remote access) which involves deploying a specific application (RDG) to solve it. I agree that's a perfectly valid solution and I agree it's also a perfectly secure solution, and it's definitely even more secure than an improperly configured VPN setup. However I disagree that it's the right way to approach the problem for reasons I've already outlined. They do have differnet security considerations but it's purely administrative, I.E "Someone could gently caress up the VPN config". An SSL VPN that only permits 3389 access is not inherently less secure than an RDG setup in any way that I can think of off the top of my head.
|
|
#
?
Nov 11, 2015 08:32
|
|
|
I got a random recruiter email for a security position that seems interesting to pull me from my current job. I'm happy enough where I am to stay if it doesn't turn out to be a good move so I'm fine with moving on if there's some catch, but since this is my first time communicating with a recruiter, what should I look out for? All I know at the moment is that it's a 6 month w2 contract to hire.
Drunk Badger fucked around with this message at 08:44 on Nov 11, 2015 |
|
#
?
Nov 11, 2015 08:42
|
|
|
Drunk Badger posted:I got a random recruiter email for a security position that seems interesting to pull me from my current job. I'm happy enough where I am to stay if it doesn't turn out to be a good move so I'm fine with moving on if there's some catch, but since this is my first time communicating with a recruiter, what should I look out for? All I know at the moment is that it's a 6 month w2 contract to hire. Whatever you do, if he asks you what your current salary is, either do or do not tell him.
|
|
#
?
Nov 11, 2015 12:20
|
|
|
NippleFloss posted:Firewall rules need to be put into place to prevent clients on the VPN from communicating with other services, and that's assuming they haven't just been configured to land on the same subnet as a bunch of other internal devices. Your VPN connected client can propagate malware into the local network if the appropriate firewall rules and NAC rules aren't in place. I like this so that people don't have to have a work laptop to remote in. They can use their home PC, they're not going to gently caress anything up by just RDP'ing in. Otherwise you have to get a laptop, VPN client, anti-virus, lock the machine down, make sure it's updated... The bad thing is they have to leave their desktop on 24/7, and have a second machine to remote in (so that fucks people who only use a laptop), or you have to setup a terminal server, Then the question becomes 'how do I get on the network with my iPad', and then you say "what do you need to do with it", then you explain how you can get Outlook without the VPN, get on the ERP system without the VPN, the only thing you can't do is get your 'files' which doesn't matter because you don't have Word/Excel and if you buy them for the iPad you're not going to like them so get the gently caress out of my face random manager dude.
|
|
#
?
Nov 11, 2015 14:03
|
|
|
So our sysadmin put in his two weeks yesterday and then didn't show up today. There's only me and our IT director now and I've only been in IT for just over 6 months. This is going to be a lot of fun.
|
|
#
?
Nov 11, 2015 14:57
|
|
|
Bob Morales posted:Then the question becomes 'how do I get on the network with my iPad', and then you say "what do you need to do with it", then you explain how you can get Outlook without the VPN, get on the ERP system without the VPN, the only thing you can't do is get your 'files' which doesn't matter because you don't have Word/Excel and if you buy them for the iPad you're not going to like them so get the gently caress out of my face random manager dude. Or they can use one of several remote desktop apps on the app store that support a Remote Desktop Gateway, including the one from Microsoft.
|
|
#
?
Nov 11, 2015 15:00
|
|
|
Drunk Badger posted:All I know at the moment is that it's a 6 month w2 contract to hire.
|
|
#
?
Nov 11, 2015 15:16
|
|
|
gently caress client to site VPNs.
|
|
#
?
Nov 11, 2015 15:21
|
|
|
|
| # ? May 12, 2024 16:22 |
|
|
vibur posted:Actually, all you know right now is that it's a 6-month contract. There are no guarantees in these cases. There's also no guarantee that you won't poo poo the bed and be fired during your 90 day probationary period or that your company won't start taking on water and drop you under "last in - first out" circumstances. Don't be a nay-sayer, interview for it and use the conversation with the hiring manager to gauge their intent for permanence. In almost 5 years, I've only had 1 contract to hire go south because the financial situation changed at the company. I've had a LOT more people poo poo the bed by overselling their experience. Also, if it's a contract to hire, you're dealing with an agency recruiter who doesn't care about what your conversion salary is because it doesn't impact him whatsoever. He WANTS to get you what you want, so you'll take the job. Establish the conversion salary expectations first, then discuss your hourly based on that. If I have a conversion salary of $100K, I typically have a bill rate capable of supporting that equivalent, say $50-55/hr.
|
|
#
?
Nov 11, 2015 16:19
|
|
