Oh for fuck's it encrypted the onsite backup TIB files. Luckily the offsite backups are good. It's just going to take a while to restore 200gb of file shares. Whoever setup the onsite backups shared the backup folder with everyone. This has been fixed.
I traced the source of the infection back to the remote desktop server. Over the weekend someone logged in and ran a customized VeraCrypt package. It managed to get everything that Domain Users had r/w on. The onsite backups for the file server were encrypted too but the off-site backups were fine. The RDS backup location was fine because I was the one who set it up and only gave the admin account access. Since RDS was where it came from we nuked the VM and restored from backup. After an on-site meeting to discuss the events of the day, I went home. It is as around 6:30 that every finished.
All things considered this was a remarkably fast and smooth disaster recovery. They went from totally fucked to right as rain in less than 12 hours.
IMO remote desktop should be blacklisted unless the connection is originating from inside your network.
That kind of defeats the purpose of a remote desktop server. You might as well just give people thin clients if you're on the same network.
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
Security, convenience, etc etc
We've gone to VPN clients for a lot of users, but some still rely on Terminal Servers. 2FA helps, as does locking down logon rights to only users who need it, and furthermore locking down shares in the same way. If folks only work from satellite offices and not from home, consider whitelisting those IPs only. Blocking IPs from regions where you don't do business eliminates a lot of malicious traffic, though I've grumbled when having to manage requests to whitelist Dubai for a week or whatever when a C-level wants to go on vacation.
+1
Options
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
Personally I hate thin clients, but only because a scant number of our clients use them and they don't have the appropriate management infrastructure, etc.
Yeah, for industrial/medical/research equipment, there is often a very good reason why it needs to stay airgapped
I'm not saying the statement "this laser cutter needs to stay off the network" is absurd or anything, just that it's better to find out for yourself
I did a network assessment for a client last year who use a high pressure water cutter, it runs on Win95. It's airgapped as fuck. Their backup solution is they have an exact clone of the hard drive sitting in a safe, so if the computer takes a shit, they just swap drives and pray.
This is somehow totally normal for lots of niche software. It was written 20 years ago, only works on hardware from that era, and we as a society seem to have accepted that fate.
I'm actually okay with it as long as it stays airgapped.
Or the drive in the safe dies and nobody notices because they don't do recovery test runs.
Ideally you'd also test restoring an image to a fresh HDD as well, though at that point you're also having to consider that your motherboard and other hardware are likely without backups or available parts, etc.
A legitimate disaster recovery plan can include scenarios in which that line of business is done and everyone involved gets reassigned or gets a severance package.
yeah a machine that old it'll be running on an IDE hard drive, long before the times of SATA. finding a working one nowadays gets a lot harder.
I'd probably take a serious run at P to V-ing the Win95 machine.
Oh for fuck's it encrypted the onsite backup TIB files. Luckily the offsite backups are good. It's just going to take a while to restore 200gb of file shares. Whoever setup the onsite backups shared the backup folder with everyone. This has been fixed.
I traced the source of the infection back to the remote desktop server. Over the weekend someone logged in and ran a customized VeraCrypt package. It managed to get everything that Domain Users had r/w on. The onsite backups for the file server were encrypted too but the off-site backups were fine. The RDS backup location was fine because I was the one who set it up and only gave the admin account access. Since RDS was where it came from we nuked the VM and restored from backup. After an on-site meeting to discuss the events of the day, I went home. It is as around 6:30 that every finished.
All things considered this was a remarkably fast and smooth disaster recovery. They went from totally fucked to right as rain in less than 12 hours.
IMO remote desktop should be blacklisted unless the connection is originating from inside your network.
That kind of defeats the purpose of a remote desktop server. You might as well just give people thin clients if you're on the same network.
Users can VPN in with 2fa and group policy restricting which users have vpn access. Remote desktop just isn't a secure protocol and IMO it's too big a risk to leave exposed. It's a very common attack vector for ransomware.
Yeah, for industrial/medical/research equipment, there is often a very good reason why it needs to stay airgapped
I'm not saying the statement "this laser cutter needs to stay off the network" is absurd or anything, just that it's better to find out for yourself
I did a network assessment for a client last year who use a high pressure water cutter, it runs on Win95. It's airgapped as fuck. Their backup solution is they have an exact clone of the hard drive sitting in a safe, so if the computer takes a shit, they just swap drives and pray.
This is somehow totally normal for lots of niche software. It was written 20 years ago, only works on hardware from that era, and we as a society seem to have accepted that fate.
I'm actually okay with it as long as it stays airgapped.
Or the drive in the safe dies and nobody notices because they don't do recovery test runs.
Ideally you'd also test restoring an image to a fresh HDD as well, though at that point you're also having to consider that your motherboard and other hardware are likely without backups or available parts, etc.
A legitimate disaster recovery plan can include scenarios in which that line of business is done and everyone involved gets reassigned or gets a severance package.
yeah a machine that old it'll be running on an IDE hard drive, long before the times of SATA. finding a working one nowadays gets a lot harder.
I'd probably take a serious run at P to V-ing the Win95 machine.
but the whatever hardware the computer needs to talk to the PC probably won't work through a hypervisor.
Oh for fuck's it encrypted the onsite backup TIB files. Luckily the offsite backups are good. It's just going to take a while to restore 200gb of file shares. Whoever setup the onsite backups shared the backup folder with everyone. This has been fixed.
I traced the source of the infection back to the remote desktop server. Over the weekend someone logged in and ran a customized VeraCrypt package. It managed to get everything that Domain Users had r/w on. The onsite backups for the file server were encrypted too but the off-site backups were fine. The RDS backup location was fine because I was the one who set it up and only gave the admin account access. Since RDS was where it came from we nuked the VM and restored from backup. After an on-site meeting to discuss the events of the day, I went home. It is as around 6:30 that every finished.
All things considered this was a remarkably fast and smooth disaster recovery. They went from totally fucked to right as rain in less than 12 hours.
IMO remote desktop should be blacklisted unless the connection is originating from inside your network.
That kind of defeats the purpose of a remote desktop server. You might as well just give people thin clients if you're on the same network.
Ideally, wrap it in a VPN and put two-factor on it.
There are other ways to secure RDP over public Internet (at the very minimum, restrict it to CredSSP, disable clipboard and file system sharing, practice good username/password practices, etc) but those are intrinsically worse and jumping straight to "that defeats the purpose" is pretty inaccurate IMO.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
the "no true scotch man" fallacy.
+1
Options
RandomHajileNot actually a SnatcherThe New KremlinRegistered Userregular
Some of y’all have RDP servers wide open to the internet? Like, important domain-joined servers? I can’t even fathom that. I don’t even like having our website hosted on prem as we do currently. Use VPN with 2FA and then do what you need from there. If someone can’t open up a VPN client and type a number off of an RSA token, I wouldn’t trust them to RDP into a server or have a good password anyway.
Some of y’all have RDP servers wide open to the internet? Like, important domain-joined servers? I can’t even fathom that. I don’t even like having our website hosted on prem as we do currently. Use VPN with 2FA and then do what you need from there. If someone can’t open up a VPN client and type a number off of an RSA token, I wouldn’t trust them to RDP into a server or have a good password anyway.
We have two vendors who offer hosted apps that use RDP, without VPNs. One of them uses Remote Desktop Gateway, the other does not.
I don't currently host a remote desktop server exposed directly to the Internet but I have at prior jobs.
I wouldn't say it's intrinsically insecure, but it isn't implement-and-forget either. You really have to stay on top of patching, vulnerability scans, etc.
Personally, I would hide it behind RDG if not a VPN.
Feral on
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
God, I'm sick of the "what changed?" style of troubleshooting
"The XYZ server stopped doing ABC thing. Did we change anything on it?"
That made sense 20 years ago when software mostly ran locally and systems were less interdependent.
Today, XYZ server might be actively communicating with a dozen other servers every minute; users access it through a browser that has it's own security settings and updates; not to mention the underlying network and virtualization infrastructure it is dependent on; and god forbid there's any cloud or hosted component to it.
Things are always changing every hour of every day.
I've got a better idea. Instead of vaguely reporting a problem to me and ask me "what changed?" how about you do your fucking job and read the goddamn error message, look in fucking Event Viewer or pull up the software's diagnostic logs, and actually do some fucking troubleshooting.
Fuck.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Some of y’all have RDP servers wide open to the internet? Like, important domain-joined servers? I can’t even fathom that. I don’t even like having our website hosted on prem as we do currently. Use VPN with 2FA and then do what you need from there. If someone can’t open up a VPN client and type a number off of an RSA token, I wouldn’t trust them to RDP into a server or have a good password anyway.
We have two vendors who offer hosted apps that use RDP, without VPNs. One of them uses Remote Desktop Gateway, the other does not.
I don't currently host a remote desktop server exposed directly to the Internet but I have at prior jobs.
I wouldn't say it's intrinsically insecure, but it isn't implement-and-forget either. You really have to stay on top of patching, vulnerability scans, etc.
Personally, I would hide it behind RDG if not a VPN.
We’ve always had a VPN and only a VPN, so I’m not super familiar with RDG. Can you give a high level on what makes it marginally safer? Or how it can be made to be?
Some of y’all have RDP servers wide open to the internet? Like, important domain-joined servers? I can’t even fathom that. I don’t even like having our website hosted on prem as we do currently. Use VPN with 2FA and then do what you need from there. If someone can’t open up a VPN client and type a number off of an RSA token, I wouldn’t trust them to RDP into a server or have a good password anyway.
We have two vendors who offer hosted apps that use RDP, without VPNs. One of them uses Remote Desktop Gateway, the other does not.
I don't currently host a remote desktop server exposed directly to the Internet but I have at prior jobs.
I wouldn't say it's intrinsically insecure, but it isn't implement-and-forget either. You really have to stay on top of patching, vulnerability scans, etc.
Personally, I would hide it behind RDG if not a VPN.
We’ve always had a VPN and only a VPN, so I’m not super familiar with RDG. Can you give a high level on what makes it marginally safer? Or how it can be made to be?
I'm not sure if this is the best way to describe it, but I think of it as an HTTPS/SSL reverse proxy for RDP. You log in to the HTTPS site, either through a browser or directly in the RDP client, it checks your credentials against AD and then forwards traffic between your client and the RDP server.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
God, I'm sick of the "what changed?" style of troubleshooting
"The XYZ server stopped doing ABC thing. Did we change anything on it?"
That made sense 20 years ago when software mostly ran locally and systems were less interdependent.
Today, XYZ server might be actively communicating with a dozen other servers every minute; users access it through a browser that has it's own security settings and updates; not to mention the underlying network and virtualization infrastructure it is dependent on; and god forbid there's any cloud or hosted component to it.
Things are always changing every hour of every day.
I've got a better idea. Instead of vaguely reporting a problem to me and ask me "what changed?" how about you do your fucking job and read the goddamn error message, look in fucking Event Viewer or pull up the software's diagnostic logs, and actually do some fucking troubleshooting.
Fuck.
And this is why configuration management is as needed as code version control.
Our RDS server is locked the down for users. If you want to do something out of the ordinary, you'll have to ask me, 'cause only one website and two programs will load on it.
RDS for other servers is restricted to the IT vlan, and domain controller's and hyper v severs are only available from two specific machines.
My last place had a wide open, forward facing RDS server running a cracked version of server 2008. Shut that motherfucker down immediately.
Our RDS server is locked the down for users. If you want to do something out of the ordinary, you'll have to ask me, 'cause only one website and two programs will load on it.
RDS for other servers is restricted to the IT vlan, and domain controller's and hyper v severs are only available from two specific machines.
My last place had a wide open, forward facing RDS server running a cracked version of server 2008. Shut that motherfucker down immediately.
God, I'm sick of the "what changed?" style of troubleshooting
"The XYZ server stopped doing ABC thing. Did we change anything on it?"
That made sense 20 years ago when software mostly ran locally and systems were less interdependent.
Today, XYZ server might be actively communicating with a dozen other servers every minute; users access it through a browser that has it's own security settings and updates; not to mention the underlying network and virtualization infrastructure it is dependent on; and god forbid there's any cloud or hosted component to it.
Things are always changing every hour of every day.
I've got a better idea. Instead of vaguely reporting a problem to me and ask me "what changed?" how about you do your fucking job and read the goddamn error message, look in fucking Event Viewer or pull up the software's diagnostic logs, and actually do some fucking troubleshooting.
Fuck.
And this is why configuration management is as needed as code version control.
I agree, but that enables a similar problem.
"The CM system says something about disabling weak SSL ciphers and now the XYZ server stopped working. Can we roll back that change?"
"What makes you think those two things have anything to do with each other?"
"It was the last thing we changed before the server stopped working."
Fast forward to me going into the damn server and seeing that it's out of HD space.
There's no substitute for having IT staff who can actually do troubleshooting.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Okay so how do you find the DHCP server for a given device if that device is a mac? On windows a simple ipconfig/all makes it pop right up. On mac, ifconfig is giving me a big list of stuff and I'm not seeing it in there. I have another ip conflict coming up and they are both listed on this DHCP server (which is the mac mini running server) so I don't know if it's assigning the same IP for some weird reason or if there's a rogue DHCP server somewhere.
Okay so how do you find the DHCP server for a given device if that device is a mac? On windows a simple ipconfig/all makes it pop right up. On mac, ifconfig is giving me a big list of stuff and I'm not seeing it in there. I have another ip conflict coming up and they are both listed on this DHCP server (which is the mac mini running server) so I don't know if it's assigning the same IP for some weird reason or if there's a rogue DHCP server somewhere.
ipconfig getoption en0 server_identifier
Assuming the connection is en0
+3
Options
FFOnce Upon a TimeIn OaklandRegistered Userregular
Okay so how do you find the DHCP server for a given device if that device is a mac? On windows a simple ipconfig/all makes it pop right up. On mac, ifconfig is giving me a big list of stuff and I'm not seeing it in there. I have another ip conflict coming up and they are both listed on this DHCP server (which is the mac mini running server) so I don't know if it's assigning the same IP for some weird reason or if there's a rogue DHCP server somewhere.
ifconfig will tell you somewhere in that list, which interface is getting an IP address. Usually en0 or en1, depending on the version of the OS (WiFi connections used to be under a different moniker in earlier OS versions).
ipconfig getoption en# server_identifier
en# is whichever interface is being used. That should get you what you want.
So I've got a SonicWall device. If I manually set the IP and connect it to my switch, I can't access or ping it (yes ping is enabled on the interface). If I manually connect that interface to my laptop, I can connect.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
Okay I can see that working on a working device, but when I try it on a conflicted device it gives me back nothing. Hrm. Gonna talk to some external help and see if they can help me pin this down.
Okay I can see that working on a working device, but when I try it on a conflicted device it gives me back nothing. Hrm. Gonna talk to some external help and see if they can help me pin this down.
Do they have a statically assigned IP on that device? That would be why you're having IP conflicts if they do.
Okay I can see that working on a working device, but when I try it on a conflicted device it gives me back nothing. Hrm. Gonna talk to some external help and see if they can help me pin this down.
Do they have a statically assigned IP on that device? That would be why you're having IP conflicts if they do.
They do not. Also one of the devices (I haven't located the other one yet) is showing multiple entries in the clients list of the mac server. All of these entries are the same. Rebooted the server, still happening.
Also searching for information for Mac Server dhcp stuff on google is impossible.
You could also try: temporarily disable DHCP services on the Mac server, then reboot one of the affected devices. See if it grabs an IP from somewhere else.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
the "no true scotch man" fallacy.
+1
Options
RandomHajileNot actually a SnatcherThe New KremlinRegistered Userregular
So I've got a SonicWall device. If I manually set the IP and connect it to my switch, I can't access or ping it (yes ping is enabled on the interface). If I manually connect that interface to my laptop, I can connect.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
My vague recollection is that routing and subnetting on the SonicWall is kind of weird, but it has been a long time since I set up our. Ours has its own /24 subnet/VLAN and it is .1 on that range, and then it gives out DHCP to connected clients on that subnet.
The main thing I remember is that ours had to be behind the firewall to make it work and route internet traffic properly. When we had it acting as it’s own firewall with an external IP address and an internal IP address, the routing never worked right. I had to prove to our networking specialist that she was wrong about that by reading the diagrams in the install guide. Basically for our case, you had to have a SonicWall firewall device in front of your VPN device for it to work, and all we had was the VPN. Like I said, I don’t remember all the details, so that probably isn’t particularly helpful. I ended up NATing it behind our Juniper and it worked how I wanted it to. Unfortunately that made me lose the ability to VPN in when the firewall is down like our old Nortel allowed, but eh the Juniper was pretty solid.
So I've got a SonicWall device. If I manually set the IP and connect it to my switch, I can't access or ping it (yes ping is enabled on the interface). If I manually connect that interface to my laptop, I can connect.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
My vague recollection is that routing and subnetting on the SonicWall is kind of weird, but it has been a long time since I set up our. Ours has its own /24 subnet/VLAN and it is .1 on that range, and then it gives out DHCP to connected clients on that subnet.
The main thing I remember is that ours had to be behind the firewall to make it work and route internet traffic properly. When we had it acting as it’s own firewall with an external IP address and an internal IP address, the routing never worked right. I had to prove to our networking specialist that she was wrong about that by reading the diagrams in the install guide. Basically for our case, you had to have a SonicWall firewall device in front of your VPN device for it to work, and all we had was the VPN. Like I said, I don’t remember all the details, so that probably isn’t particularly helpful. I ended up NATing it behind our Juniper and it worked how I wanted it to. Unfortunately that made me lose the ability to VPN in when the firewall is down like our old Nortel allowed, but eh the Juniper was pretty solid.
Well that is unfortunate. I bought it specifically to be the firewall and filter and VPN.
0
Options
RandomHajileNot actually a SnatcherThe New KremlinRegistered Userregular
So I've got a SonicWall device. If I manually set the IP and connect it to my switch, I can't access or ping it (yes ping is enabled on the interface). If I manually connect that interface to my laptop, I can connect.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
My vague recollection is that routing and subnetting on the SonicWall is kind of weird, but it has been a long time since I set up our. Ours has its own /24 subnet/VLAN and it is .1 on that range, and then it gives out DHCP to connected clients on that subnet.
The main thing I remember is that ours had to be behind the firewall to make it work and route internet traffic properly. When we had it acting as it’s own firewall with an external IP address and an internal IP address, the routing never worked right. I had to prove to our networking specialist that she was wrong about that by reading the diagrams in the install guide. Basically for our case, you had to have a SonicWall firewall device in front of your VPN device for it to work, and all we had was the VPN. Like I said, I don’t remember all the details, so that probably isn’t particularly helpful. I ended up NATing it behind our Juniper and it worked how I wanted it to. Unfortunately that made me lose the ability to VPN in when the firewall is down like our old Nortel allowed, but eh the Juniper was pretty solid.
Well that is unfortunate. I bought it specifically to be the firewall and filter and VPN.
Hang on! To be clear, what we have is specifically just an HTTPS VPN and nothing else. They expected you to already have a SonicWall firewall, but our firewall person at the time (hell, probably 10 years ago at this point) thought she knew what she was doing with this thing. She set it up the broken way and I fought the problem with routing internet traffic for like a year until I just took the reins and fixed it. (She never cared because the people in her department all had access to a secret proxy server, so they could surf...screw the rest of corporate, I guess.)
So! The thing you have may be an all-in-one. I suspect your issue is something you’re overlooking related to routing/default gateway or something. For your setup, it almost certainly needs to be in the routing path with proper NAT stuff set up. I don’t know what your budget is like, but I’d say you may want to have someone come in to help.
So I've got a SonicWall device. If I manually set the IP and connect it to my switch, I can't access or ping it (yes ping is enabled on the interface). If I manually connect that interface to my laptop, I can connect.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
My vague recollection is that routing and subnetting on the SonicWall is kind of weird, but it has been a long time since I set up our. Ours has its own /24 subnet/VLAN and it is .1 on that range, and then it gives out DHCP to connected clients on that subnet.
The main thing I remember is that ours had to be behind the firewall to make it work and route internet traffic properly. When we had it acting as it’s own firewall with an external IP address and an internal IP address, the routing never worked right. I had to prove to our networking specialist that she was wrong about that by reading the diagrams in the install guide. Basically for our case, you had to have a SonicWall firewall device in front of your VPN device for it to work, and all we had was the VPN. Like I said, I don’t remember all the details, so that probably isn’t particularly helpful. I ended up NATing it behind our Juniper and it worked how I wanted it to. Unfortunately that made me lose the ability to VPN in when the firewall is down like our old Nortel allowed, but eh the Juniper was pretty solid.
Well that is unfortunate. I bought it specifically to be the firewall and filter and VPN.
Hang on! To be clear, what we have is specifically just an HTTPS VPN and nothing else. They expected you to already have a SonicWall firewall, but our firewall person at the time (hell, probably 10 years ago at this point) thought she knew what she was doing with this thing. She set it up the broken way and I fought the problem with routing internet traffic for like a year until I just took the reins and fixed it. (She never cared because the people in her department all had access to a secret proxy server, so they could surf...screw the rest of corporate, I guess.)
So! The thing you have may be an all-in-one. I suspect your issue is something you’re overlooking related to routing/default gateway or something. For your setup, it almost certainly needs to be in the routing path with proper NAT stuff set up. I don’t know what your budget is like, but I’d say you may want to have someone come in to help.
Yeah, I called a friend who works with networking stuff and he couldn't determine why it would do that, but he wasn't able to come on site and get hands on.
Budgets are tight, but they need this, so we'll see. I was hoping for something easy, like connecting a router at home. It seemed like just a higher-end one of those, and our needs were fairly simple enough.
I have a Sonicwall SSL-VPN (VPN only, no all-in-one crap) that we use with a third-party firewall
Is that similar to this problem space?
Potentially.
Digging into it a bit today. It looks like it's trying to send my local IP traffic out the WAN. So when I gave it the DC IPs, it's trying to find them out the WAN port. WAN port is working just fine for DNS/Licensing/NTP on the Sonicwall itself.
Found it. Figures.
I have no idea if this is correct or not, but here's what I did. Tell me if this is terrible?
I created a static route that takes Any source, where the Destination is for an IP on our local subnet 192.168.x.x 255.255.0.0, and told it to use the 192.168.30.1 gateway that it has for it's VLAN gateway on the LAN interface.
Now I'm able to ping into and out of the Sonicwall to my local network.
Found it. Figures.
I have no idea if this is correct or not, but here's what I did. Tell me if this is terrible?
I created a static route that takes Any source, where the Destination is for an IP on our local subnet 192.168.x.x 255.255.0.0, and told it to use the 192.168.30.1 gateway that it has for it's VLAN gateway on the LAN interface.
Now I'm able to ping into and out of the Sonicwall to my local network.
I'm not super familiar with SonicWall, but at a high level that sounds like the correct solution for the problem you were experiencing.
Posts
That kind of defeats the purpose of a remote desktop server. You might as well just give people thin clients if you're on the same network.
We've gone to VPN clients for a lot of users, but some still rely on Terminal Servers. 2FA helps, as does locking down logon rights to only users who need it, and furthermore locking down shares in the same way. If folks only work from satellite offices and not from home, consider whitelisting those IPs only. Blocking IPs from regions where you don't do business eliminates a lot of malicious traffic, though I've grumbled when having to manage requests to whitelist Dubai for a week or whatever when a C-level wants to go on vacation.
XBL:Phenyhelm - 3DS:Phenyhelm
I'd probably take a serious run at P to V-ing the Win95 machine.
Users can VPN in with 2fa and group policy restricting which users have vpn access. Remote desktop just isn't a secure protocol and IMO it's too big a risk to leave exposed. It's a very common attack vector for ransomware.
but the whatever hardware the computer needs to talk to the PC probably won't work through a hypervisor.
Ideally, wrap it in a VPN and put two-factor on it.
There are other ways to secure RDP over public Internet (at the very minimum, restrict it to CredSSP, disable clipboard and file system sharing, practice good username/password practices, etc) but those are intrinsically worse and jumping straight to "that defeats the purpose" is pretty inaccurate IMO.
the "no true scotch man" fallacy.
This is a clickable link to my Steam Profile.
We have two vendors who offer hosted apps that use RDP, without VPNs. One of them uses Remote Desktop Gateway, the other does not.
I don't currently host a remote desktop server exposed directly to the Internet but I have at prior jobs.
I wouldn't say it's intrinsically insecure, but it isn't implement-and-forget either. You really have to stay on top of patching, vulnerability scans, etc.
Personally, I would hide it behind RDG if not a VPN.
the "no true scotch man" fallacy.
"The XYZ server stopped doing ABC thing. Did we change anything on it?"
That made sense 20 years ago when software mostly ran locally and systems were less interdependent.
Today, XYZ server might be actively communicating with a dozen other servers every minute; users access it through a browser that has it's own security settings and updates; not to mention the underlying network and virtualization infrastructure it is dependent on; and god forbid there's any cloud or hosted component to it.
Things are always changing every hour of every day.
I've got a better idea. Instead of vaguely reporting a problem to me and ask me "what changed?" how about you do your fucking job and read the goddamn error message, look in fucking Event Viewer or pull up the software's diagnostic logs, and actually do some fucking troubleshooting.
Fuck.
the "no true scotch man" fallacy.
Oh looks like the
MAYBE YOU SHOULD HAVE CHECKED THAT BEFORE ASKING ME "WHAT'S CHANGED?," BRAD
the "no true scotch man" fallacy.
Late night cert install.
XBL:Phenyhelm - 3DS:Phenyhelm
This is a clickable link to my Steam Profile.
I'm not sure if this is the best way to describe it, but I think of it as an HTTPS/SSL reverse proxy for RDP. You log in to the HTTPS site, either through a browser or directly in the RDP client, it checks your credentials against AD and then forwards traffic between your client and the RDP server.
the "no true scotch man" fallacy.
Cool. . .
XBL:Phenyhelm - 3DS:Phenyhelm
And this is why configuration management is as needed as code version control.
RDS for other servers is restricted to the IT vlan, and domain controller's and hyper v severs are only available from two specific machines.
My last place had a wide open, forward facing RDS server running a cracked version of server 2008. Shut that motherfucker down immediately.
Wow. What a bad idea.
I agree, but that enables a similar problem.
"The CM system says something about disabling weak SSL ciphers and now the XYZ server stopped working. Can we roll back that change?"
"What makes you think those two things have anything to do with each other?"
"It was the last thing we changed before the server stopped working."
Fast forward to me going into the damn server and seeing that it's out of HD space.
There's no substitute for having IT staff who can actually do troubleshooting.
the "no true scotch man" fallacy.
Why is Skype for Business such shit?
Assuming the connection is en0
ifconfig will tell you somewhere in that list, which interface is getting an IP address. Usually en0 or en1, depending on the version of the OS (WiFi connections used to be under a different moniker in earlier OS versions).
en# is whichever interface is being used. That should get you what you want.
If I configure my laptop with the same IP, connect it to the same port on the switch, it is seen and I can ping it no problem.
If I connect the SonicWall, and connect my laptop to a different port, but set both to the same VLAN, they can ping each other, but other VLANs can't ping the SonicWall but can ping the laptop.
What am I missing here?
Routing seems fine.
SonicWall seems fine, but I'm new to this?
Switch seems fine.
Oh, and this is to get us from an open RDP server to a VPN connection to secure things. Because the open RDP scares me.
Do they have a statically assigned IP on that device? That would be why you're having IP conflicts if they do.
They do not. Also one of the devices (I haven't located the other one yet) is showing multiple entries in the clients list of the mac server. All of these entries are the same. Rebooted the server, still happening.
Also searching for information for Mac Server dhcp stuff on google is impossible.
the "no true scotch man" fallacy.
The main thing I remember is that ours had to be behind the firewall to make it work and route internet traffic properly. When we had it acting as it’s own firewall with an external IP address and an internal IP address, the routing never worked right. I had to prove to our networking specialist that she was wrong about that by reading the diagrams in the install guide. Basically for our case, you had to have a SonicWall firewall device in front of your VPN device for it to work, and all we had was the VPN. Like I said, I don’t remember all the details, so that probably isn’t particularly helpful. I ended up NATing it behind our Juniper and it worked how I wanted it to. Unfortunately that made me lose the ability to VPN in when the firewall is down like our old Nortel allowed, but eh the Juniper was pretty solid.
This is a clickable link to my Steam Profile.
Well that is unfortunate. I bought it specifically to be the firewall and filter and VPN.
So! The thing you have may be an all-in-one. I suspect your issue is something you’re overlooking related to routing/default gateway or something. For your setup, it almost certainly needs to be in the routing path with proper NAT stuff set up. I don’t know what your budget is like, but I’d say you may want to have someone come in to help.
This is a clickable link to my Steam Profile.
Yeah, I called a friend who works with networking stuff and he couldn't determine why it would do that, but he wasn't able to come on site and get hands on.
Budgets are tight, but they need this, so we'll see. I was hoping for something easy, like connecting a router at home. It seemed like just a higher-end one of those, and our needs were fairly simple enough.
Is that similar to this problem space?
the "no true scotch man" fallacy.
Potentially.
Digging into it a bit today. It looks like it's trying to send my local IP traffic out the WAN. So when I gave it the DC IPs, it's trying to find them out the WAN port. WAN port is working just fine for DNS/Licensing/NTP on the Sonicwall itself.
I have no idea if this is correct or not, but here's what I did. Tell me if this is terrible?
I created a static route that takes Any source, where the Destination is for an IP on our local subnet 192.168.x.x 255.255.0.0, and told it to use the 192.168.30.1 gateway that it has for it's VLAN gateway on the LAN interface.
Now I'm able to ping into and out of the Sonicwall to my local network.
I'm not super familiar with SonicWall, but at a high level that sounds like the correct solution for the problem you were experiencing.