Disabling External Ping, VPN drops.
-
If your VPN requires ping, open up ping between the two sites. Be careful changing the MTU. Nearly every single Ethernet-connected device runs an MTU of 1500, and does so right out of the box.
Remote management shouldn't be external-facing, and if it is necessary, restrict the IP ranges that can connect to it.
-
@JaredBusch said:
@scottalanmiller said:
Login attempts are inevitable. Pings aren't needed to find that opening. If there is a way to log in, attempted will be made.
If you have RDP exposed you are a much bigger target but no matter what you expose this will happen. Attempts are just attempts.
Something's like LogMeIn will help by stopping there being open ports. But then people just attack the LMI site.
This is why the Controller at one client just got Pertino installed on her laptop and desktop. Suddenly RDP is secure as ever again
We do that too. Pertino and LogMeIn everywhere. No open ports exposed for remote access.
-
@scottalanmiller said:
@JaredBusch said:
@scottalanmiller said:
Login attempts are inevitable. Pings aren't needed to find that opening. If there is a way to log in, attempted will be made.
If you have RDP exposed you are a much bigger target but no matter what you expose this will happen. Attempts are just attempts.
Something's like LogMeIn will help by stopping there being open ports. But then people just attack the LMI site.
This is why the Controller at one client just got Pertino installed on her laptop and desktop. Suddenly RDP is secure as ever again
We do that too. Pertino and LogMeIn everywhere. No open ports exposed for remote access.
I wish I could do this for a few clients, but printing from an AS 400 locally won't work over that setup.
-
Hopefully you mean IBM System "i". AS/400 was killed off in the 1990s.
System "i" doesn't have a Pertino agent nor a LogMeIn agent. Being one of those rare systems today that is not UNIX nor Windows, it is really left out there on its own requiring its own special support for absolutely everything.
What application is running on "i"?
-
Hey guys, thanks for the great info! My RDP is locked down and we use remote software instead.
-
Yeah yeah... it's a, nope It's an AS400! The unit is from 1998 I think, but it could be older.
They run backups on it (though I know next to nothing about them so I have no clue how to test or if they are testing those backups themselves). I've suggested that they look into purchasing a newer unit since their whole billing system runs on it. While the person I work with there agreed, management continues to say no. So my contact reached out to their vendor who has supported the system in the past and they still have some old units their backups could be restored on in case theirs fails, so they have a plan. At least there is that.
-
@scottalanmiller said:
Hopefully you mean IBM System "i". AS/400 was killed off in the 1990s.
We still call it an AS/400. That's what happens when you ingrain a name.
System i, AS/400, it's all good when you call Rochester.
-
@Dashrender said:
I wish I could do this for a few clients, but printing from an AS 400 locally won't work over that setup.
Wait, what?
Create spoolers to the local printer, point applications to the spoolers. Then it's just a matter of busting into the network, which can be accomplished via an stunnel.
-
@scottalanmiller said:
Hopefully you mean IBM System "i". AS/400 was killed off in the 1990s.
System "i" doesn't have a Pertino agent nor a LogMeIn agent. Being one of those rare systems today that is not UNIX nor Windows, it is really left out there on its own requiring its own special support for absolutely everything.
What application is running on "i"?
We just replaced a System/36 accounting system at a client. It was still running thinnet to dumb terminals. Said dumb terminals are still in place so verification can be made with the imported data. But, they are using our new accounting package now at least.
Of note, we sold them the System/36 based accounting package back in the 80's.
-
Ha ha. System/36
Wow.
-
-
@PSX_Defector said:
@Dashrender said:
I wish I could do this for a few clients, but printing from an AS 400 locally won't work over that setup.
Wait, what?
Create spoolers to the local printer, point applications to the spoolers. Then it's just a matter of busting into the network, which can be accomplished via an stunnel.
What's a stunnel? If I have a home printer on my home network (let's assume it's an IP printer) how do I give access to my office based AS400 over the Pertino network?
To make this work today, I use VPN to connect to the office network, Client Access allows me to 'create an AS400 printer' from one of my local printer so it looks like an AS400 queue. I then send my print jobs to that queue, which forwards through my VPN connection to my PC and onto my printer.
-
That would be remote printers, printing locally has a completely different connotation.
I never let people create spoolers from the client. Usually because people are duplicating things over and over and over again with their printers and it gets to be a big mess. Cleaning up queues is my least favorite operator duty.
If you absolutely must setup something like that, better to use a PDF writer. Cleaner, less driver kludges, and you can spin up the spoolers to make it into one single queue instead of the goons spinning up 5 or more printers because they have tons of them at home.
Haven't checked yet, but you should be able to encapsulate the traffic over Pertino for that. Then it's just a matter of having something that will play man in the middle. Of course, popping open a telnet proxy would be easier still.
-
stunnel is a form of VPN: https://www.stunnel.org/index.html
-
@PSX_Defector said:
That would be remote printers, printing locally has a completely different connotation.
I never let people create spoolers from the client. Usually because people are duplicating things over and over and over again with their printers and it gets to be a big mess. Cleaning up queues is my least favorite operator duty.
If you absolutely must setup something like that, better to use a PDF writer. Cleaner, less driver kludges, and you can spin up the spoolers to make it into one single queue instead of the goons spinning up 5 or more printers because they have tons of them at home.
Haven't checked yet, but you should be able to encapsulate the traffic over Pertino for that. Then it's just a matter of having something that will play man in the middle. Of course, popping open a telnet proxy would be easier still.
A telnet proxy? since the home user's IP can change, kinda hard to lock it down, unless there is something I'm missing.
This is a tiny company 8 employees, and not a technical pone in the company so they can't create anything that a consultant doesn't for them.. no worries about them creating a bunch of printers. I moved them off the home dial into the 400 about 10 years ago to a VPN connection. it was/is a lot faster.
How would you encapsulate the traffic from the 400 to the home user's computer?
-
@Dashrender said:
How would you encapsulate the traffic from the 400 to the home user's computer?
VPNs encapsulate everything on the network.
-
@scottalanmiller said:
@Dashrender said:
How would you encapsulate the traffic from the 400 to the home user's computer?
VPNs encapsulate everything on the network.
Yeah.. I know that! other than using an onsite device, say a ASA/sonicwall, etc to terminate the tunnel - how are you getting the traffic into the tunnel in the first place?
-
What's wrong with a device? Once you are at the level of an System i, having a VM with pfSense for VPNs is pretty trivial.
-
But why not use the built in VPN capabilities on the System i box? Not like you can't SSH or stunnel natively.
-
@scottalanmiller said:
But why not use the built in VPN capabilities on the System i box? Not like you can't SSH or stunnel natively.
I am already using a device for that customer (ASA). This whole thing came up because you can't use my situation and Pertino together.
