Printable View
Hello World, I have a couple of software vendors that would like to support our software remotely using PCAnywhere. They would like me to open a couple of custom ports and forward their connections to the servers. Is this safe? All feedback is appreciated!
In a nutshell, IF you TRUST the vendors then it is safe, IF you DON'T then its not ....
Yes i trust the vendors. But is it safe to open up these ports on the firewall? I mean, can anybody do a port scan and try to pick at the ports?
Sure. Setup rules if you can so that only trusted ips are allowed to access certain ports. Thats a start.
is this usually a typical setup?
Here is another example: Should the mail relay server be internal or in the dmz?
Very typical. If you have specific people or services that you want to access, limiting public access is very essential.
For the mail server, thats up to you, you could put it internal and only allow access to users also on the internel network, or you could port forward so that it is accessible on the internet as well. Lots of ways to do it.
If you are going to make the relay available to the public, I woudl setup some sort of authentication on the mail server itself , so it still only allows certain users to relay messages. This can be done a number of ways depending on what mail server packagae you go with.
thanks!!! all this information is great :0)
By relay I am assuming you mean the server that accepts the mail from the outside and relays it in to the trusted network.... That being the case:-
What is the point of putting it in the trusted network to forward it to the trusted network. Put it in the DMZ and have it forward the mail from the DMZ in to the trusted. That way, if it is compromised it is in the DMZ rather than in the trusted network.
As to PCAnywhere directly... I prefer to make them create a VPN tunnel then fire up their terminal program and connect through the tunnel. That way you are using a double authentication and it prevents an automated work that can exlploit the terminal apps server from direct access to it. If the VPN is vulnerable then the attacker can't be a worm, (well, it could but the tunnel should prevent unneeded traffic anyway), because it would have to know what the internal target is going to be.... Too difficult to predict so it won't be written.
Why do you need e-mail in the internal network at all? I dont see why users cant pop/imap/etc to a server in the DMZ, services on the internal network should establish a connection from the trusted to the DMZ, not vice versa. You should have as little or no connections (if possible, sometimes its a necessary to the business model) allowed to connect back into the internal net from the DMZ. What goes in the DMZ can stay in the DMZ. As for PCAnywhere, I believe it is a fairly secure app (these days) and as someone mentioned, if you only allow connections from specifc addresses it should be fine, but as a matter of good practice I would not leave these open all the time, as in the case with the DMZ, you should not maintain routes that allow incoming connections from the outside world into to your trusted network. Open them when you need them, close them when you are done.
-Maestr0
Typical reasons on that could be that the internal e-mail server is an exchange server, which requires nasty msrcp/dce connections hard to firewall, that you don't want users sending potentially cleartext passwords in the dmz, that if the mail server/relay in the dmz, you don't want the attacker to be able to capture the users passwords...Quote:
Originally posted here by Maestr0
Why do you need e-mail in the internal network at all? I dont see why users cant pop/imap/etc to a server in the DMZ, services on the internal network should establish a connection from the trusted to the DMZ, not vice versa. You should have as little or no connections (if possible, sometimes its a necessary to the business model) allowed to connect back into the internal net from the DMZ. What goes in the DMZ can stay in the DMZ. As for PCAnywhere, I believe it is a fairly secure app (these days) and as someone mentioned, if you only allow connections from specifc addresses it should be fine, but as a matter of good practice I would not leave these open all the time, as in the case with the DMZ, you should not maintain routes that allow incoming connections from the outside world into to your trusted network. Open them when you need them, close them when you are done.
-Maestr0
Ammo
I don't buy it. Those are weak excuses for bad policies. I'm not aware of any problems with Exchange working in a DMZ, as long as the clients inside the trusted network initiate the connection, even so, lets say you dont want Exchange in a DMZ because it sucks, fine. You run a fetchmail from your Exchange to get the mail from the DMZ. As for passwords, DONT USE PLAIN TEXT PROTOCOLS, this isnt 1985, Exchange and everyother groupware solution on the planet supports secure authentication, besides if someone 0wns the relay server in the DMZ, they can read all the mail anyway and dont need any passwords. You should not allow conections from the DMZ to the trusted network, its not secure.
-Maestr0