I have the following network:
PC1 --|¯¯¯¯¯¯¯¯¯| |¯¯¯¯¯¯¯¯¯|-- board2
PC2 --| gateway |-- (eth0) [server] (eth1) --| gateway |
PC3 --|_________| |_________|-- board1
As you can see, the server (running Linux) has 2 interfaces so that the PCs and embedded boards are not on the same subnetwork.
I would like to develop a simple application (or use an existing one) that tunnels incomming Telnet connections from eth0 (using a specific port) to boards through eth1.
I don't have root privileges on the server, but I have a regular Unix account. I don't want the PCs to actually "log in" to the server; I just want them to pass through it to connect to the boards. The server has Python, PHP and Perl installed.
I want to support multiple connections. The port number could be used to forward the connection to the right board (say I have 10 boards, then the tunnel listens on ports 3000 to 3009).
I can imagine a simple Web application to do that, but I want a native Telnet connection that will support CTRL+C and all that stuff and allow you to use any terminal emulator on the PCs (i.e. PuTTY or another one), which run Windows.
Any help would be much appreciated.
It sounds like you're looking for a TCP proxy. A proxy accepts connections on one port, connects to another ip/port, and then passes traffic back and forth.
If you have xinetd on your system you already have what you need. The redirect directive for a service causes xinetd to open a connection to another host/port and act as a proxy. See this document for an example.
balance is another very simple proxy tool that will do what you need. This is probably easier to run as a non-root user, especially since it's configured entirely on the command line.
Since you're not root on your server you'll need to run these on ports > 1024, but otherwise you should be all set.
Related
Which is the most correct way to give Nmap my own computer as a target? Example commands:
nmap -T5 -A -v localhost
nmap -T5 -A -v 192.168.0.7
nmap -T5 -A -v (my external ip address)
Can you explain what's the difference in calling one or the other of those?
Thanks
The difference between those would be which interface nmap tries to connect to. If you use localhost, nmap will attempt to establish connections to any application listening on your local computer using a virtual loopback network device. This means that the OS will process the connections, but your network card will likely not be involved.
If you use 192.168.0.7 (I assume this is the address assigned to your ethernet or wifi card), it will attempt to connect to any application listening on your local computer, but (depending on how smart your OS and networking drivers are), it may actually go through your network card, and maybe even out to the first switch that you are connected to and then back. The connections will not be routed on the internet, so your router will not be involved.
Finally, if you use the public IP address of your router, the connections will go through your network card, to your router, and then through any port forwarding or routing rules configured in your router. This may or may not route the connection back to your computer, depending on which rules are set up and the firewall on the router.
Note that for the first two invocations, it is possible for application listening for connections locally to listen on either one or both of the interfaces (loopback or network card), so it is possible for applications to be listening only on the loopback device and not the network interface and vise versa. So they could return different results. However, anyone outside your computer would not be able to establish a connection to anything listening on only the loopback interface. However, experience tells me that most applications listening for connections tend to listen on all available interfaces, so there is not likely to be a difference in the result of the first two invocations.
I'm working on a project where some clients (embedded linux systems) needs to connect to a main server using so far at least two protocols: HTTPS and SSH. One of the requirement is that only one flow is allowed from every client to the server, so I've to found a way to make the two services works on the same port.
One solution that I was thinking about is to use the iptables markers: on the client side mark the packets for SSH with 0x1, the packets for HTTPS with 0x2 and then on the server side, based on the marker, redirect the packets to the right service listening on the local interface. Is it an acceptable solution? Are the markers kept by the network routers or is only something working locally on the same machine for iptables?
And anyway, if you can advice about a different solution, of course it's welcome!
More for other users finding this question in the future:
https://github.com/yrutschle/sslh has what you might need. I haven't used it (yet) but planning on it.
From the Github site:
sslh -- A ssl/ssh multiplexer
sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client.
Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.
Hence sslh acts as a protocol demultiplexer, or a switchboard. Its name comes from its original function to serve SSH and HTTPS on the same port.
I have 2 linux servers with an app that communicate over a simple telnet protocol (unencrypted).
I would like to force the app to run over some form of encrypted tunnel/etc. Is there a simple way to create a point-to-point encrypted tunnel, and force only my apps' traffic over that tunnel (? (eg: create a virtual NIC thats encrypted traffic) I don't want to route all network traffic over this tunnel.
Use SSH port tunneling. You only need to change the connection (IP and port) on your client end once you have the tunnel set up.
Say system 1 listens on a socket on port AAAA and system 2 connects to system 1. Use ssh tunneling from an arbitrary port (say PPPP) on system 2 to port AAAA on system 1. Now direct the 'app' on system 2 to connect to 127.0.0.1:PPPP and the connection will be tunneled to system 1.
If both system listen and accept connections then also setup a tunnel in the opposite direction.
For completeness setup a custom user on both systems for your ssh tunnel. Set the new users login shell on both systems to /sbin/nologin and do not put them in any groups beyond their own. Now use 'sudo - u ' to launch ssh on system 2. Also block traffic from external interfaces to port AAAA on system 1, assuming you no longer need it. Also set ServerAliveInterval and ClientAlivalInterval in your ssh and sshd configurations respectively.
The alternative to this configuration is to set up a VPN between the two boxes.
I want to access my work computer, which is behind a firewall, from my home computer.
As the work firewall blocks unexpected incoming connections, I would have to open a reverse SSH tunnel from my work computer to my home computer like so:
ssh -R 12345:localhost:22 homeuser#homeip
From my home computer, I could then use port 12345 to access the work computer:
ssh -p 12345 workuser#localhost
The problem is that this requires me to open holes in my home firewall and forward ports to my home computer.
This is my question:
Is there any method by which I could have both machines meet each other half way?
Assuming that I am at my home computer and a co-worker is at my work computer, and we both know each other's local IP (that the computer gets from the router) and internet IP (that the router gets from the ISP), is there some way each of us could initiate an outgoing connection to the other?
No. If you don't want to forward ports in routers, then you need some mutually accessible computer in between for both computers to connect to. (This could be a virtual machine such as those offered by Digital Ocean, or a web host that offers shell login, or you could dedicate something like a Raspberry Pi on your home network with SSH forwarded to it so it's always available.)
If you wanted to access port 22 on the remote computer:
ssh -R 12345:localhost:22 user#your.sshgateway.com
Then on the home computer:
ssh -L 2222:localhost:12345 user#your.sshgateway.com
Then you can connect to the remote computer with:
ssh -p 2222 workuser#localhost
We have a local server with SVN installed on it that we are using for development/testing purpouses. We would like to checkout the data from it to the live server that is somewhere out there.
The only way to do that which I thought of was to use "svn checkout" from the live server, right? This way we do not need to FTP the changes to it, that may cause problems is we forget to upload some of the changes. And if we found a problem we can alway go back to previous stable version, right? Correct me if I am wrong about any of these.
The problem is that our local server (Ubuntu) does not have a IP that is reachable from outside. We have a router from out ISP, but we can not use that to access the local server from the live. We are willing to ask the ISP provider to setup a second IP for the local server, but for security sake they want to setup a separate machine with Windows and windows base security software (firewall - http://www.kerio.com/control/ and antivirus) that will cost us a lot. Can we just setup a free firewall on the local server (Ubuntu as I said) and solve the problem without spending additional money?
I hope I was clear.
It's always hard to comment without knowing the exact situation, but this sounds a bit crazy.
What you would usually do is set up port forwarding for one port to the local server. The server would then be reachable (for example) through 123.45.67.89:3690
That's a three-minute task to set up in a normal household router.
As long as the Ubuntu server is closed otherwise, and Subversion or whatever you are using for authentication is properly configured and up to date, this should not create security issues.
In any case, putting a Windows machine in between to act as a firewall sounds really unnecessary. Ubuntu comes with everything necessary to secure the setup properly.
If the remote server has an ssh server, then you can use ssh forwarding.
From the internal svn server:
ssh -R 7711:localhost:3690 {REMOTE_SERVER}
7711 is an arbitrary port (you can use any free port on the remote system) that will be forwarded from the remote system to port 3690 (svn) on the svn server.
3690 is the port on the internal svn server that you want to talk to (via svn://).
If you are using subversion over http:// then use port 80 instead of 3690.
If you are using subversion over https:// then use port 443 instead of 3690.
After setting up the forward, then you can do this on the remote system:
svn checkout {SCHEME}://localhost:7711/{PATH}
{SCHEME} is svn, http, https, etc.
{PATH} is the normal svn path you want to check out.
Notes:
the forwarded traffic is tunneled through the ssh connection (on a different "channel") so it is also encrypted which is a nice benefit.
by default, the remote end of the forward will listen on the loopback interface so only processes on that system will be able to use the port forwarded port.
As soon as you close the ssh session, the forwarded port will also close. It only lasts the duration of the ssh connection.
ssh forwarding is very powerful. If you can ssh between two systems, then you can get around any sort of connection problem like this.
Do man ssh and read about the -L and -R options.
Useful links about ssh forwarding:
http://www.rzg.mpg.de/networkservices/ssh-tunnelling-port-forwarding:
http://www.walkernews.net/2007/07/21/how-to-setup-ssh-port-forwarding-in-3-minutes/
check if your ISP router provide some port forwarding abilities,
You should probably forward the ssh port ( after ensuring that everyone password is secure/or enforcing login with ssh keys file), and use SVN+SSH protocol to access your repository.
You should be able to open up and forward a single port (3690 by default) on your existing IP to the local server, as pointed out by Pekka. This depends on your router, and your ability to access the configuration interface on the router.
Instead of having to deal with SSH and worry about people trying to access your local server from anywhere, you could setup a firewall to only allow incoming traffic from your single remote server. Depending on the router setup, you could simply use the builtin firewall on the local server. It would still be advisable to have some svn authentication, though.
The SSH forwarding method described by kanaka prevents the entire issue about remote access to the local machine, but it requires you to execute the forwarding command from the local server every time you need to access svn on the remote server.