Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: sedangbelajar on October 14, 2007, 04:45:59 PM
-
dear sme server 7.2
i'm using sme server in the remote area, then from another city i need to configure my server. When i'm using my https://my-public -ip/server-manager i can not to see my server ?
just like this:
Forbidden
You don't have permission to access /server-manager on this server.
How, if i want to control my remote server from another city with my public ip.
regards
-
dear sme server 7.2
i'm using sme server in the remote area, then from another city i need to configure my server. When i'm using my https://my-public -ip/server-manager i can not to see my server ?
just like this:
Forbidden
You don't have permission to access /server-manager on this server.
How, if i want to control my remote server from another city with my public ip.
Did you read the manual? How about this for starters: http://wiki.contribs.org/SME_Server:Documentation:User_Manual:Chapter1 ?
-
Hi,
I'm not an expert on SME, but I have a few years experience with the system.
There are a couple of ways of doing what you want to do using the SME system -
1. Add your IP address in the remote management panel of the server-manager. Then you can log into the system using the public IP address. For this to work you would need a fixed IP address.
2. Create a user on the system with VPN access. Make a VPN connection to the server. You can then access the server-manager using the private (internal) IP address. You have to make sure that if you are connected to a network at your current location, that your IP range is not the same as the range used at the remote location, otherwise there might be problems.
Of course, you need to have access to the server-manager to set up the above options. Either you have to visit the site to configure this, or maybe you could use a third option -
3. If it is possible you could use a remote desktop connection to either a Windows Server or XP Pro desktop computer (I don't think you can do it with XP Home). You can then start up the Internet Explorer on this PC and connect to the server-manager, again using the internal IP address. You can then do your configuration this way.
I have used all three methods successfully. I'm not really an expert on security, but I guess that the option 1 (adding your IP address in the server-manager for remote access) restricts access to only your IP. But if you have good strong passwords the other options maybe are not too risky?
Hope this helps!
Dave
-
Hi dave simmons
I'm not an expert on SME, but I have a few years experience with the system.
There are a couple of ways of doing what you want to do using the SME system -
1. Add your IP address in the remote management panel of the server-manager. Then you can log into the system using the public IP address. For this to work you would need a fixed IP address.
if i have stattic public-ip, then insert into the server-manager ? i mean my 65.xxx.xxx.xxx
2. Create a user on the system with VPN access. Make a VPN connection to the server. You can then access the server-manager using the private (internal) IP address. You have to make sure that if you are connected to a network at your current location, that your IP range is not the same as the range used at the remote location, otherwise there might be problems.
it's mean my public-ip 65.xxx.xxx.xxx or 192.168.1.1 ? i'm rather confused..sorry
Of course, you need to have access to the server-manager to set up the above options. Either you have to visit the site to configure this, or maybe you could use a third option -
3. If it is possible you could use a remote desktop connection to either a Windows Server or XP Pro desktop computer (I don't think you can do it with XP Home). You can then start up the Internet Explorer on this PC and connect to the server-manager, again using the internal IP address. You can then do your configuration this way.
I have used all three methods successfully. I'm not really an expert on security, but I guess that the option 1 (adding your IP address in the server-manager for remote access) restricts access to only your IP. But if you have good strong passwords the other options maybe are not too risky?
Hope this helps!
Dave
i need your help dave, regards
-
With option 2. If the site you are administrating is using 192.168.1.x and your local lan is using the same range, it can sometimes be difficult to connect to the remote location as you may have two servers with the same address.
-
Hi,
Sorry if my reply is a bit slow - I'm mostly at customer sites during the day.
In answer to your questions -
1. To add an external IP address in the server-manager, you add your public IP address 65.xxx.xxx.xxx (subnet mask 255.255.255.255). Then only you can access the server-manager. You can find this under the Security - Remote Access panel in the Server Manager. The you will be able to access the server-manager via http://65.xxx.xxx.xxx/server-manager.
2. If you use the VPN approach, you need to use the private IP address of the server - e.g. http://192.168.1.115/server-manager. You have to careful using this method. If you have a network in your office which uses the same IP address range, you can have communication problems. What I mean with this is that if you use a network in your office e.g. the range 192.168.1.1 - 192.168.1.254, and your customer uses the same private ip address range, you will get comunication problems. This is because the VPN connection will also assign you an IP address from their private range e.g. 192.168.1.71 - and your own internal network could contain this number also, so your Internet Browser won't know whether to look on your network or your customers' network.
I think you will have to make a site visit to sort this out. If you use option 3 - Windows Remote Desktop - you need to see that port 3389 is opened on the firewall and routed correctly at the external site. If you're using SME as the firewall, this will not be possible, and you'll either have to instruct someone at the customer site how to change the settings (if it's too far away) or visit the site yourself to sort it out.
-
"2. If you use the VPN approach, you need to use the private IP address of the server - e.g. http://192.168.1.115/server-manager."
After you vpn, you can use the server hostname as well: https://serverhostname/server-manager
-
I don't know if it is considered to be safe enough but it is rather easy to get server-manager access from anywhere.
Just fill in values at server-manager panel: Remote Access -> Remote Management -> Network: 0.0.0.0, Subnet mask: 0.0.0.0
I think you will then have server-manager access from everywhere.
I used it like that for a while, as I needed external access to the server-manager panel. I diden't have a real problem with that.
To day I do it slightly differnt as I am using a "no standard firewall arrangemant" where the port 80 and port 443 is normally closed for external access. I then have the option og opening lets say the port 443 for the server-manager for remote access, if and when required.
********
One other not to difficult way that would also work, I beleve is to set up a ssh tunnel (using putty) from localhost and to the internal ip of the server gateway. This should be a rather safe solutuion. To access the server-manager from a remote Win box should be like this: https://localhost/server-manager
-
"I don't know if it is considered to be safe enough but it is rather easy to get server-manager access from anywhere."
No, it isn't considered safe enough. The recommended process would be to:
-connect to the server via a secure connection (ssh or vpn)
-and then come back out of the server through that secure connection
-
I don't know if it is considered to be safe enough but it is rather easy to get server-manager access from anywhere.
Just fill in values at server-manager panel: Remote Access -> Remote Management -> Network: 0.0.0.0, Subnet mask: 0.0.0.0
I think you will then have server-manager access from everywhere.
I used it like that for a while, as I needed external access to the server-manager panel. I diden't have a real problem with that.
To day I do it slightly differnt as I am using a "no standard firewall arrangemant" where the port 80 and port 443 is normally closed for external access. I then have the option og opening lets say the port 443 for the server-manager for remote access, if and when required.
You can do this, but it is a very unsecure option when you do not use strong passwords. Best options are to allow remote access from certain hosts and make use of Public-Private keys (http://wiki.contribs.org/SSH_Public-Private_Keys) or to setup a VPN connection to the server first.
-
Of cource you are right about what you say when you claim that giving public access to the logon page of the server-manager of the SME server and personally I prefer to lock of port 80 and port 443 for all external access.
But there is allways an interesting question: Why is certain configurations considered to be more or less secure ?
If you configure your server for instance to have a ssh logon via user account and password, or a server-manager SSL logon via user account and password, will then the SLL logon neccessarly be less secure than the SSH logon ? (If using logon via user account and password.)
Should the SSL encryption neccessarly be more easy to brake than the SSH encryption ? Isn't the SSL encryprion actually the encryption method used by netbanks and simualar purposes (Ok I know that the SSL encryption is not the only safety bariere.)
When it comes to the open SSH port it is easy to scan thousands of ip adresses in a minor of time to find those who have en open port 22 and a ssh server. From there is is also a easy task to start up the automated ssh server breakein tools to try to get access to the ssh server. If you run with a open port 22 and external access for the ssh server logon you will see a huge amounts of break in attempts in your log after a while.
If you close down your port 22 external access and in sted leaves open your https port 443 server-manager access, will you then see the same mounts of attemts to breake into the server-manager panel ?
Could the situation also be the oposite, if it is a question of logging in via user/password, then the open port 22 and ssh server is more dangerous than the open server-manager login page ?
I think it actually is a interesting question as I am one of those who normally will use a ssh tunnel for the server-manager logon.
(Yes I know that there are bether metods than user/password logon.)
As I see it leaving open for external access a port 22 and a ssh server is much tha same as exposing a hacker magnet against the net. Will an exposd port 443 and the oportunity of making a external server-manager logon work the same way ?
-
But there is allways an interesting question: Why is certain configurations considered to be more or less secure ?
Because of the systems being involved.
If you configure your server for instance to have a ssh logon via user account and password, or a server-manager SSL logon via user account and password, will then the SLL logon neccessarly be less secure than the SSH logon ? (If using logon via user account and password.)
Yes, as it is much harder to issue commands using the POST and GEt protocol used over http or https than it is on a shell. On top of that the unix/linux shells are well documented and very alike opposite to the http interfaces which can differ very much, let alone that all http(s) interfaces are used to administrate servers.
Should the SSL encryption neccessarly be more easy to brake than the SSH encryption ? Isn't the SSL encryprion actually the encryption method used by netbanks and simualar purposes (Ok I know that the SSL encryption is not the only safety bariere.)
You cannot expect banks to use a shell to transfer you money, they made a intreface for it and tried (and are continuously trying) to keep it as secure as possible implementing more than only the SSL encryption.
When it comes to the open SSH port it is easy to scan thousands of ip adresses in a minor of time to find those who have en open port 22 and a ssh server. From there is is also a easy task to start up the automated ssh server breakein tools to try to get access to the ssh server. If you run with a open port 22 and external access for the ssh server logon you will see a huge amounts of break in attempts in your log after a while.
If you close down your port 22 external access and in sted leaves open your https port 443 server-manager access, will you then see the same mounts of attemts to breake into the server-manager panel ?
No off course not, see my reply above.
As I see it leaving open for external access a port 22 and a ssh server is much tha same as exposing a hacker magnet against the net. Will an exposd port 443 and the oportunity of making a external server-manager logon work the same way ?
If you would have read the documentation I provided as a link you could have seen that this is clearly not the case. The method mentioned there makes use of a private/public key combination which ensures that only users with a private key can open a SME Server shell. All their communication is encrypted (using more or less the same strength as used in SSL encryption) but without the public key there is no communication possible and the connection is closed immediately.
As a sidenote I strongly advise you to read up on proper security measurements since closing down port 80 and 443 is not really an option when running a webserver providing (valuable) content and services to the web, nor can it be compared to secure shell access compared to https security wise. Until you have gained some more knowledge keep your answers on the safe side and do not present your self in a matter that might leave others to believe you are an expert, security wise or SME Server wise. TIA
-
Thaks for some good advices :-)
I am certainly not an security expert or a sme server expert. I would rather describe myself as a amateur that might be able to ask some questions about "facts" that that I some times know is considered to be "true".
Actually I am aware of those arguments mentioned above, but fram my amateur way of thinking, some of my point of views are just not exactely the same.
By the way I am using port 443 on internet connection for ssh logon and ssh tunneling and 443 on the lan side for server-manager access, and I think it should not hurt anyone at all. (Exept the hackers :-) )
In my world security is just related to something as easy as statistics, how often does it happen, in which way does it happen, in which situations does it happen. There should be no room for believe or faith in that. If it is a report on a security issue I find it nothing more than interesing.
In my world some of the joy open source is the ability to ask questions, and to rethink it all, if you want to, listening to arguments, and the joy of learning.
-
arne
Opening your server manager to all remote hosts (as you did) is not recommended, as you significantly increase the possibility of hacking. You should only ever specify a single host or use VPN, and it's even recommended to disable that after you have finished using it.
For someone who talks so much about security & the need for a better firewall to manage security (ie limit access etc), your actions seem contradictory to what you have been saying in these forums.
Opening ssh to password login is also not recommended, for the same reasons as above.
Changing ssh to another port does not increase security, although it may reduce the number of hacking attempts being made & the resultant log noise.
A very secure way of opening ssh access is to specify remote hosts (IPs) that can have ssh access, AND to enable public private keys and disable password login.
There are db commands that configure this (search the wiki), and they interact with the firewall to allow traffic on the specified ssh port ONLY for the specified remote host IP.
If you remove the existing firewall structure (as you have suggested elsewhere), then you remove this and many other built in features that directly interact with the firewall.
Please stop promoting your replacment firewall viewpoints here, which are quite contradictory to sme server good usage principles. I suggest to anyone reading this who wants to have a secure sme server, that Arne's current ideas on firewall replacement scripts should be ignored.
It seems you still have a lot of learning to do about sme server.
One day hopefully you will realise why your approach to developing seperate firewall scripts that do not integrate into the existing sme server masq structure, is a waste of time, and certainly of negative benefit to the majority of sme users.
I'm asking you to refocus your development work to use the existing masq structure, and implement new functionality/rules one at a time, on a needs based priority basis.
Please re-read Charlie Brady's requests/suggestions in the bug you posted
http://bugs.contribs.org/show_bug.cgi?id=3468
There are other bugs that also refer to development work to implement "3 port firewalls", to speak rather loosely.
http://bugs.contribs.org/show_bug.cgi?id=2669
http://bugs.contribs.org/show_bug.cgi?id=2670
Charlie has also posted links to various "firewall" related bugs in a previous forum thread to which you were posting.
Put your talents/knowledge to work and pick up on these threads and help further develop integrated functionality that will benefit the wider sme server community, and not just for a few users who are prepared to take on the risks & problems of implementing standalone firewall scripts.
-
Put your talents/knowledge to work and pick up on these threads and help further develop integrated functionality that will benefit the wider sme server community, and not just for a few users who are prepared to take on the risks & problems of implementing standalone firewall scripts.
Oh, how I wish for a (proper) karma system here... :-)
-
Thanks a lot for your comments :-)
There is actually a some kind of karma system. Look at the field "Advice given" and my -3 and yours +4 and +3 :-)
When it comes to my firewall and my risk, then the real situation is that I only expose one open port to the internet, and this is port 443, that is normally the SSL port, but that I use for SSH tunneling. This gives me all the access I need. I also have the option of partly hiding this single port from portscans etc, if I want to. I have to admit I do not understand how the exposure of this single port will increase the overall security risk.
I wil try my best to make a firewall setup, different from what I have been able to google up on the net until now. I will also try to make it work on any Linux gateway or server, including also the SME server, because this is just my fun and enjoyable amateur hobbist project.
But I will not try to discuss it on this forum.
I will be reading the treads and posts on this forum, but I will not be giving any comments, even if there is questions where I think I have an answer that could have worked.
It is the case that most files on the SME server is marked with the GP licence, they can be modified etc.
On the other hand it is also the case that there is some people that runs the Contribs forum that sets the rules for this forum.
Theese rules can be set, and these rules can be respected, without the need of attacking any person.
By the way I think that the SME server really could get some really nice improvements by thinking slightly different about the firewalling part of it, but I understand that, just at the moment, this is not considered to be a good idea.
By the way, thanks a lot for a very relyable and dependable distro, that I have used for years.
-
Thanks a lot for your comments :-)
There is actually a some kind of karma system. Look at the field "Advice given" and my -3 and yours +4 and +3 :-)
I know but I guess it is hard to understand irony... I have no opportunity to vote neither good nor bad karma and therefore have no opportunity to compliment the users with the same train of thoughts as I have concerning your forum remarks, sorry!
On the other hand it is also the case that there is some people that runs the Contribs forum that sets the rules for this forum.
Theese rules can be set, and these rules can be respected, without the need of attacking any person.
Yes indeed, but you must keep in mind that SME Server is designed to be secure and stabil, modifying it the way you do makes it (very) insecure and possibly instable. The goal of this distribution is to be stabil, secure and easy to install and maintain. Not all users know perfectly well about all security implementations, advising to do stuff like you did certainly does not increase security and that is why I and others try to constantly point out to you as well as readers to be conservative with following your advise.
By the way I think that the SME server really could get some really nice improvements by thinking slightly different about the firewalling part of it, but I understand that, just at the moment, this is not considered to be a good idea.
You are more than welcome to suggest stuff, but we need to make the suggested solution as save and thorough as possible, your advises may be nice and sparkling, your implementation lacks a lot on thoughtfulness and respect for the architecture of the system, which is very well designed and though out.