Topic: Remote access from hotspots.

[arne]

REMOTE ACCESS FROM HOTSPOTS.

(Why I changed the firewall.)

I was in the need of a gateway server that could give me this:

1. A reliable ip telephone logon server, that works well, from hotspots where SIP clients normally will not work, due to technical limitations.

2. The ability to perform full remote controll og the gateway server itself and lan resources from hotspots where a ordinary SSH port 22 tunnel will not work.

3. The hosting of web applications for private and no public access. They should still be available for private use from restricted wlan zones.

Now everything works like it should in a stable and reliable way.

To do this "mod" I needed a little bit of technical information from this forum. I got a series of negative comments and feedbacks, but some of them also contained the technical information that were needed.

For the iptelephony part of it I did this:

1. I first installed the selintra Asterisk for SME 7.2 contrib.

2. As the SIP protocol has rather poor performance for the use from hotspot's/public wlan's I desided to use a IAX2 telephony client instead.

3. I decided to use zoipier and installed this on my notebook http://www.zoiper.com/

4. I reconfigured the SME 7.2 server to receive IAX2 logon and data transport on udp port 4569 plus UDP 53 plus eventually other UDP ports as required.

For the remote control part I did this:

1. I downloaded and installed putty to my notebook:  http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

2. I also downloaded and installed winscp to my notebook: http://winscp.net/eng/download.php

3. I then reconfigured the SME 7.2 to receive ssh logon and perform ssh tunneling on TCP 22 and TCP 443 plus eventually other TCP ports as needed.

4. Putty can now do remot ssh shell logon to the gateway and the lan resources from almost any hotspot.

5. It can also do ssh tunneling via port 443 to the gateway and to the lan resources.

6. Graphical file management is available on the gateway and the lan resources via winscp that operates via the tcp 443 ssh tunnel set up by putty.

7. The server manager is available from restricted hotspots on the notebook like this: https.//localhost/server-manager/ (And all private web applications is also available the same way.)

The telephony and the remote access/control solution has been tested from diverse hot spots and wlans and also via 3G on mobile telephones. Works. Also expected to work on other kind of radio transmission based internet connections, but has not tested this yet.

For my individual need the project is now ended as everything works like it should.

If any positive interest I could post a detailed procedure for it all, so other people could need to use a few hours less on such a project than I did.

The administrators of the contribs.org might think that it is negative that some people try to do something on their own, but to have the full picture of a modified firewall solution will work as a whole and complete implementation, it is not possible to just do some minor adjustment on the existing templates. First solutions has to be be tested as a working complete solution, to see how things can or can not work, then they can be implemented.

By the way as a spin off of the same project I also tested out with a 3'rd NIC as dmz or secure wlan zone. This also worked quite well, but that's another story.

All of this is actually rather easy to implement if just some smiles and positive attitude about it all.

 

By the way  .. the question of security .. There is now only one externally accessable tcp service and that is the ssh server. The open "port" is filtered against ip spoofing, tcp flag spoofing and overload due to dos attack. All other direct external access to server functions is blocked out.

[Philippe MARTY]

Hi arne,

I'm really interrested by your work, as I'm working far from my SME Server. I can't acces to the server from office because of web proxy limitation, blocking all communication except on ports 80 and 443...

Could you please explain a little bit more your configuration (for the remote control part)

Thanks in advance, and sorry for my poor english from France

[Stefano]

The administrators of the contribs.org might think that it is negative that some people try to do something on their own, but to have the full picture of a modified firewall solution will work as a whole and complete implementation, it is not possible to just do some minor adjustment on the existing templates. First solutions has to be be tested as a working complete solution, to see how things can or can not work, then they can be implemented.

this is not correct, you are wrong

you are been told many, many and maybe too many times that your improvements are welcome but you have to follow the SME's way; you keep saying the same things since your posts about firewall script.

do you really want to improve SME? yes? are you SURE? well, templatize your work, share your work.. not simply say "well, first of all flush iptables.."

I'll try (I'm italian, my english is not the best) to explain how I feel every time you post something: I feel like you coming in my home and putting your shoes on my sofa, saying that's the best way to see the TV.. well, at MY home (and contribs.org is "our" home, is the house of SME's community) you do the things in MY way, not in yours. If you don't feel good, you are free to go away..

ah.. you speak about "administrators" of contribs.org: they are the dev team.. it's a big difference..

Hope you finally understand the right way.

Ciao

Stefano

P.S.: naturally this is my personal opinion

[arne]

My firewall implementation has been working 100 % stable and without a single problem. The number of hacking attemts, recorded in logs, has been reduced from something like a thousand a week to zero. The arrangement with the 3'rd network card and a wireless zone has also worked without a problem. Access from wireless zones only permitting tcp 80 and rcp 443 has worked stable and as a dream. (I do not use 80 now, only TCP 443 for ssh and tunneling and UDP 53 for IAX2/Asterisk iptelephony).

The SME server is a commersial distro and the commersial SME server does not, as far as I know has those same properties : http://www.smeserver.com.au/products/smeserver/

I would normally be happy to explain all details of how to do the firewalling stuff, but unfortunately discussing major improvements on the communication side and the overall "usability" for the SME server will normally result in some heavy flaming.

Typical for this flaming will be that there is a lot of rather unprecise arguments without any clear content, typically that solutions are unsecure or dangerous, but there will be no further technicaly related argumentations why it should unsecure or dangerous.

As I will see it, the SME server gateway I am using today is considerable bether than the standard SME server and I also feel it is safer. If it should not be like that, I would love to go a little bit into the deep on how things really work.  Until now there has not been one single argument releated to how things works from a technically point of view. It is just empty flaming.

It has not been a target for me to change the SME server for the reason of changing it. It has rather been a target to change it as little as possible, and then still to keep the properties that is needed for me to be able to use it.

When it comes to the question of making services avalable on alternative ports, I saw a posting from one of the SME senior developers a few days ago, that claimed it was possible to giving alternative port access by forwarding an external port to localhost or 127.0.0.1 According to basic Linux firewalling thery this should not work, as I would see it, but there could be "something special" with the SME server, and it would be a rather good thing, if I were wrong about my conciderations. I have not tested this, and it would be rather intersting if this would work, and this would also remove some of my basic needs for changing the firewall arrangement.

I had planned to post a howto for the whole fully working and tested firewall solution on my own web page in a not to fare away future. This will not be a dedicated SME solution, but rather a general Linux solution that can be used on any Linux 2.4/2.6 kernel including also the SME server.

The basic problem is actually to obtain enough testing and to detect eventually security issues. If the negative feedback from "the commersials" on the contribs forum had a real and technically pricice content it would be very, very valuable. It it difficult to develop anything further on built on commersially related flaming, free from all technical content.

elfif -> please send me a mail on arne22 at gmail dot com

By the way, my english might now be to good either, but some times people will not tend to understand you any how.

By the way - the problem of accessing all SME services and resources from a hotspot is actually really not a issue at all, it is rather quite easy. (Except for the amount of flaming such a discussion on how to do this will normally involve, unless this can also be obtained using only standard SME server functions, also available on the commersial SME server distro.)

Arne.

[arne]

Look as this replies between F22-Raptor and mmccarn.

http://forums.contribs.org/index.php?topic=39349.0

I have seen these arguments in more than one post, that it is possible to give an alternative port access by forwarding an alternative port to localhost. Without testing it I would initially believe that this information is inncorrect.

Quote from posting:

Here's what I needed to do, I use a mail hope service which redirects mail for my domain to port nnn and I need to open port nnn on my SME.

I've configured the port forward to something like:
Protocol: TCP
Source port: nnn
Destination Host IP Address: localhost
Destination port(s): nnn

So far everthing is OK.

Do you see any problems with my setup, is it OK to use localhost as a parameter?

Thanks.

****Answer:

That's the approved method - redirect port xxxx to localhost port 25 (for inbound SMTP)

****

As I would see it:

From a Linux firewalling point of view, I think that, a port forwarding and a port redirection is two quite different thing that can not be mixed, so that a port forwarding to localhost will normally not work as a port redirection, unless there is something with the SME server that makes things work "unstandard" (and this could perfectly well be the case.)

If this solution works it might be a bether solution for making alternative port access than replacing the whole forewall configuration like I am using it. I have not tested this method myself, and I would se it as something quite interesting it it can be comfimed that it is working. (But whar then about using port 443 for ssh as long as this port is already bussy for ssl ..)

[arne]

http://wiki.contribs.org/PortRedirect


... Just to suggest some alternative to my firewall mod.

***
... I went to port forwarding and set port 2525 to forward to port 25 with the ip set to the word localhost.

It worked perfectly.

***

I would expect this not to work, but it look like it still does work (!!?)

[arne]

To clarify and find out more about how the standard SME firewall works I made a new installation of a SME 7.3 gateway just now.

So I tried to set up the "forwarding" (actually port redirection) from port 80 and port 443 to localhost port 22. Then I also tried to set up ssh tunneling after loging in ssh via tcp port 80 and tcp 443.

What actually apered to be the case is that these functions also can be maintained by the standard SME 7.3 firewall using it's standard methods and standard configuration tools.

So if the target and the need is to gain access to all server resources from hotspots and from elsewere, then there is no need for changing or replacing the standard SME server firewall at all.

This will not give the 3'rd nic or a wlan zone, but using a wireless access point with wpa (and not wep) encryption might give a good enough security for a wlan zone that is technically common with the lan zone. 

I guess I will be doing a howto for how accessing the sme server from hotspots etc via the ordinary firewall and the standard configuration tools as this might be a bit less controversial than replacing the existing firewall with a new one. (Unless there is already a howto for such a hotspot access.)

Arne.

[arne]

How to logon to a sme server (and lan resources) from a hot spot or some other network that allows only tcp 80 and tcp 443 out.


Note1: This method uses the standard SME firewall only, and there will be needed no modifications to be performed on this.

Note2: The method involves new use of the standard ports tcp 80 and/or tcp 443. Because of this the ordinary web server function might not be avaliable for access for external users any more.

Part 1 - Go into the server-manager panel, open up for external access for ssh logon.

Part 2 - redifining the use of port tcp 80 and/or tcp 443.

Go into the admin-panel. Set up a port forwarding from "source port" 80 to "localhost" and destination port 22.
Port 443 can also be used in the same way by forwarding "source port" tcp 443 to "localhost" and destination port 22.
(And if you are using Asterisk you can also forward udp 53 to your IAX2 port on your asterisk server.)

After this change as mentioned under Part 2 you will not any longer have external access to your web server but you will have a ssh server that is available on port 22, port 80 and 443. (I am using port 443 only, blocking the other two.)

Part 3 - the tunnelling.

Download the Putty client to your notebook or "traveling pc".

Make a remote logon to your server gateway for instance on port 443.

Logon will work as normally.

After logging in you can set up ssh tunnels as required.

Example, ssl encryptet protocol via ssh encrypted tunnel:

1. Right click on the blue bar on top of the putty client.
2. Select "change settings".
3. On the bar on the left and at the bottom click  "SSH"
4. Click on "tunnels".
5. Enter source port 443 and destination localhost:443
6. Click "add"


If you now try to use your web browser on the laptop, you can access the server-manager via the tunnel like this:

https://localhost/server-manager

Tunnels can also be set up usin any tcp port to any lan resource.

This last alternative is not tested with the standard SME server firewall but I guess it will work - If you for some reason dislike to run the ssh server with external access on port 22 (that the hackers will be searching for) it can be blocked off by forwarding "source port 22" to localhost and some port that is not in use. I guess it could also work to forwart it to a ip and a port that is not in use.

Hopefully this method will not be cotroversial as it does not modify the existing firewall at all. (But it does modify the function of the SME server as the web server will be only available from lan.)(But of cource one could keep tcp 80 for thsi use.)

Please give some feedback if things should not work as expected.

I tried to post the howto on the wiki, but I did not have a valid account.

[Franco]

HOW-TO

1- Set up a VPN, now you'll have access to all your resources on LAN securelly, that includes voip, SSH, server-panel and so on.

[arne]

Well that where the starting point and the conclusion was that it did not work at all. The reason con be found in the explanation of how a standard pptp vpn connection works:

http://en.wikipedia.org/wiki/Point-to-point_tunneling_protocol

(Rember that the hotspots typically will have only tcp 80/443 and udp 53 as options for the comunication.)

My next move was over to OpenVPN and this worked fare more bether, but it is still a bit "clumsy" to work with. (Put it can do the communicatiuon trough tcp 443 pretty well.)

http://en.wikipedia.org/wiki/Openvpn

After have used the OpenVPN soultuion for a while I moved over to Putty and ssh tunneling. I think this is the most easy and best alternative to deal with.

I have now (today) tested some more with ssh tunneling on SME 7.2 and 7.3 using the standard sme firewall and tcp port 443. Conclusion untlil now is that this works pretty well on SME 7.3 while there is some small strange things with the 7.2 alternative.

When it comes to the iptelephony part of the hotspot solution, it is my experience that solutions based on the SIP protocol does as a general rule not work (due to the complexity of the SIP communication.)

On the other hand one can forward (redirect) the external port udp 53 to the Asterisk IAX2 server (udp 4569) Then one can use a telephony client that is based on the IAX2 protocol and not SIP protocol. I am using Zoiper and it has until now given me a lot of more or less free telephony hours from diverse hotspots.

http://www.zoiper.com/

(I also tried to use SIP and IAX2 via OpenVPN but my general impression is that such a tunneling will work to slowly for iptelephony, so that the iptelephony client has to comunicate directely via udp 53 without the need of passing trough an encrypted tunnel.)

[arne]

Last adjustmets. (Works now pretty well with the unmodified original SME 7.3 firewall.)

1. Installed SME 7.3 in private gateway mode.

2. Went into the server manager-panel and opened ut for ssh, all commands from everywhere.

3. Sat up a forwarding from source port 443 to localhost 22. (So that the ssh deamon will be externally available on port 443.)

4. Sat up a forwarding from source port 22 to 10.0.0.99 port 99. (Forwarding to an non existent ip/port to close down the external port 22 access, to avaoid regulary hacker attacks.)

4. Sat up a forwarding from source port udp 53 to localhost 4569 (To be able to make iax2 telephony client logon on udp port 53, that regularly use to be open.)

Testet then with diverse putty/ssh tunneling from hotstots and telephony logon and everything worked fine.

The pptp vpn port apear to be open by default in the private gateway mode. I would not believe this will be usable for hotspot logon, but I kept it open as a future option.


Note: I am wondering if closing a port by forwarding it to a non existent ip/port could have some unwanted side effects. I believe this will be ok. The reason that the closing has to be done this way is that it has to be open behind the "false forwarding" to make the forwarding from port 443 to port 22 possible. (This is related to how the forwarding and the input chain is working together in the Netfilter firewall.)

Details about setting up the putty/ssh tunnels, etc is mentioned in the posts above.

[slords]

arne,

The forums aren't the place for posting howto's.  Please take your instructions to the wiki or mailing lists as those are the correct places to discuss development.  Forum posts tend to get burried and lost.

-Shad

[thomasch]

Shad,

Sorry off topic : what mailing list?

thomas

[slords]

From http://lists.contribs.org/mailman/listinfo/ that would be the devinfo list.  My suggestion would be to document what has been done on a wiki page and if futher discussion is needed take it to the lists.

[stephen noble]

please add to the wiki
Instead of mailing lists I prefer commenting on the wiki discussion page.
This keeps track of outstanding issues which get lost on forums and lists

[arne]

As I finaly in the end found a way to do the hotspot access (and telephony) without replacing the original firewall and such "ugly things", it was my intention to post a howto in the wiki. I don't know if my account is locked off or restricted in some way, but I were not able to do any posting in the wiki.

I think it would be a good thing to make such a howto, also with some pictures, as the explanations of how to set up the tunnels often is explained as sometning more difficult than it has to be, in the guides found on the net.

Can the wiki be used while logged on as a ordinary user, or will it be required some kind of additional account ?

[stephen noble]

http://wiki.contribs.org/Help:Contents
To help edit this wiki, ...... <Click Link> (and be patient)

[stephen noble]

and if you think you have answered this bug close it, ta
http://bugs.contribs.org/show_bug.cgi?id=3278

[arne]

Yes and no. The problem how to set up a third network adapter has been solved. The soulution ha been tested over some time, it ha been tested with port scanners and diverse hacker tools and there is no problem. On the other hand this third adpapter problem is solved using the only way, I guess it can be solved, by taking a look into the underlaying Netfilter firewall. On the other hand, the only way of solving the 3'rd adapter problem is not considered as a "illegal" way to modify the SME server. When "the only way" is considered to be "the the illegal way", then this problem will remain to be unsolvable, until the method that will solve this problem is accepted.

When it comes to the question of making access from restricted lan and wlan zones, hotspots etc, this is a question that can also be solved quite easy using the UNmodified SME 7.3 firewall.

I will try to make a WIKI Howto for this last variant. (Just found out how to make logon for the WIKI.)   

[slords]

Yes and no. The problem how to set up a third network adapter has been solved. The soulution ha been tested over some time, it ha been tested with port scanners and diverse hacker tools and there is no problem. On the other hand this third adpapter problem is solved using the only way, I guess it can be solved, by taking a look into the underlaying Netfilter firewall. On the other hand, the only way of solving the 3'rd adapter problem is not considered as a "illegal" way to modify the SME server. When "the only way" is considered to be "the the illegal way", then this problem will remain to be unsolvable, until the method that will solve this problem is accepted.

There is more then one way to skin a cat.  I've worked on an updated firewall script for sme and wrote it in a way that not only obeys the rules of sme but also allow unlimited network interfaces.  I've not done much work on it lately because I didn't like the way I was doing some things.

Don't assume that your way is the only way.  Also don't assume that you are the only one that thinks of, or considers the security of the firewall on sme.  There are a number of us that have worked in or done security on linux.  Just because something hasn't changed in a number of years doesn't mean that it is insecure.