Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
for my problem I searched a lot but did not find a feasible solution, so I thought to my self to place a question in here.
The problem:
I have a remote server (lets call it A) and a local computer (lets
call it B), both running Ubuntu 14.04. I could establish a reversed
SSH tunnel connecting A and B by doing so At server A: ssh -R
2014:localhost:22 userb#B At the local computer B: ssh -p 2014
usera#localhost
where user-a and user-b are two users at A and B, respectively.
Now, I connect A to a VPN. After the VPN connection is successfully
established, the currently openning ssh session does not respond
anymore. Also, I cannot ssh into A anymore until after I killed the
VPN connection.
Is there a way to let both SSH and VPN be happy? Perhaps to separate the SSH session from VPN ? (I found something called split tunneling but did not really understand it). Could someone enlightens me on this?
This may be a bit late, but ...
The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN.
What follows works for me. It uses iptables and ip (iproute2). Below, it is assumed that the default gateway interface before OpenVPN is started is "eth0". The idea is to ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again.
You could use the same number for the connection mark, firewall mark and routing table. I used distinct numbers to make the diffences between them more apparent.
# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412
# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412
===
UPDATE:
The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry:
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412
There "12.345.67.89" must be the original non-VPN gateway.
VPN screws up your route table by modifying your default gateway toward the new tunnel interface. The funny thing is that you can't initiate a new ssh connection afterward.
So you are saying that ssh -R 2014:localhost:22 userb#B wouldn't connect when going through your VPN?
What is traceroute saying? (Once VPN loaded). Don't you have any kind of port limitation with your vpn provider? If you are using a commercial one I mean.
--- EDIT
Your best try would be, while connected to VPN, from server A :
telnet B 22
To see if you can make a simple TCP SYN to destination. Anyway I'd be surprised hidemyass wouldn't let your ssh traffic going through.
To recap, your VPN is configured on your server?
You are trying to connect from your server B to your client A, through your VPN?
You should be able to traceroute to your VPN public address (which you can get with whatismyip.com for example).
You could check as well on your client for remote packets, coming from your server :
tcpdump -nnXs 0 -i eth0 host ip.of.vpn
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I have a command-line application on linux that uses a specific port to talk to a remote server. Unfortunately, at work, that port is blocked.
I am able to connect my laptop via VNC to the network, and the laptop is on a wifi connection that does have port access to the remote server. I am able to ssh to my laptop from the secure network when it is connected.
Is there a way of using ssh port tunnelling to work around this? Can I port tunnel to my laptop and have my laptop act as a middle-man between the firewalled network and the remote server?
Many thanks.
If I understood you correct you can call ssh from where you are to reach your laptop. Then you should be able to do something like this:
ssh -f -N -L <local port>:<remote server ip or hostname>:<remote server port> <laptop ip or hostname>
This will create start a tcp listening port on the host where ssh originates that forwards to your remote host and port via the machine you ssh to.
Excerpts from https://man.openbsd.org/ssh
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Specifies that connections to the given TCP port or Unix socket on the local
(client) host are to be forwarded to the given host and port, or Unix
socket, on the remote side. This works by allocating a socket to listen to
either a TCP port on the local side, optionally bound to the specified
bind_address, or to a Unix socket. Whenever a connection is made to the
local port or socket, the connection is forwarded over the secure channel,
and a connection is made to either host port hostport, or the Unix socket
remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration file. Only the
superuser can forward privileged ports. IPv6 addresses can be specified by
enclosing the address in square brackets.
By default, the local port is bound in accordance with the GatewayPorts
setting. However, an explicit bind_address may be used to bind the
connection to a specific address. The bind_address of “localhost” indicates
that the listening port be bound for local use only, while an empty address
or ‘*’ indicates that the port should be available from all interfaces.
-f
Requests ssh to go to background just before command execution. This is
useful if ssh is going to ask for passwords or passphrases, but the user
wants it in the background. This implies -n. The recommended way to start
X11 programs at a remote site is with something like ssh -f host xterm.
If the ExitOnForwardFailure configuration option is set to “yes”, then a
client started with -f will wait for all remote port forwards to be
successfully established before placing itself in the background.
-N
Do not execute a remote command. This is useful for just forwarding ports.
Usually I prefer finding a solution on my own, but unfortunately that didn't work out too well this time so I'm asking here.
I'm trying to deal with a server (rather a computer with no screen and debian minimal on it) which is on the usual home network. Problem is the ISP is running out of ipv4 addresses and therefore
decided to use ipv6 instead and dual-stack lite to access the ipv4 side of the internet. This means the computer is not accessible over the ipv4 address from the outside
but is able to connect to a ipv4 computer.
I do have a vserver (debian as well) which still uses only ipv4, so my plan was to use it as some kind of relay or porxy. Problem there is, I am not able to use iptables to configure NAT
since the server provider has removed that module from the kernel.
My first attempt was to use an SSH tunnel like this:
ssh -f user#vserver -R 2222:localhost:22 -N
This allows me to access the CLI over SSH which now listens on port 2222.
Next step was to open a second SSH tunnel and tunnel UDP traffic through that using socat:
homeserver:~# socat tcp4-listen:${tcpport of second tunnel},reuseaddr,fork udp:localhost:${udpport to forward traffic from}
vserver:~# socat -T15 udp4-recvfrom:${udpport to forward traffic to},reuseaddr,fork tcp:localhost:${tcpport of second tunnel}
This does work, however once the client application is trying to connect to the UDP port, the server application is trying to continue the communication on a different new port from the dynamic
port range (Ephemeral Port Range I think). That one random port of course is not being forwarded since socat is not listening to.
The second attempt also involved an SSH tunnel, only a dynamic one this time (basically a socks proxy).
I was trying to setup a virtual network device to route all the traffic through the socks proxy:
(As described in man pages from badvpn-tun2socks)
homeserver:~# openvpn --mktun --dev tun0 --user <someuser> #create tun0 device
homeserver:~# ifconfig tun0 10.0.0.1 netmask 255.255.255.0 #configure it
homeserver:~# route add <IP_vserver> gw <IP_of_original_gateway> metric #Route all traffic through tun0
homeserver:~# route add default gw 10.0.0.2 metric 6 #exept the ones to the vserver
homeserver:~# badvpn-tun2socks --tundev tun0 --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:1080 \
--udpgw-remote-server-addr 127.0.0.1:7300
This needs to SSH socks-proxies since upd needs to be handled seperately.
On the vserver side of things these need to be handled as well:
vserver:~# badvpn-udpgw --listen-addr 127.0.0.1:7300
The connection between both is successful but this time the homeserver is not accessible at all. (seems to me like the vserver has no clue what to do with the packets)
I hope there is a simple fix to either of my attempts. But as it stands now,
I think my whole approach is fundamentally flawed and I'm starting to run out of ideas.
Any help would be appreciated, Thanks in advance!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I am working on a simple Node.js app. This requires a particular port to be open. For example if I want the app to listen to port (say) 5122, I will have to first open the port 5122. For this I have applied the following rule in my iptables
iptables -I INPUT 3 --proto tcp --dport 5122 -j ACCEPT
service iptables save
Initially this worked for me. But suddenly after some it stopped working.
I now, wanted to check whether the port 5122 is really open or not. I issued the command
nmap -sT -O localhost
I don’t see any such ports listed here. But
sudo iptables -L shows it like this -
ACCEPT tcp -- anywhere anywhere tcp dpt:5122
ACCEPT tcp -- anywhere anywhere tcp dpt:5122
I see this line 2 times. Still confused! No idea.
I now opened the following url http://www.yougetsignal.com/tools/open-ports/ and entered my host IP and Port and it says, Port 5122 is closed on 50.56.246.162 (which is my host IP)
My question is how do I permanently keep a particular port open for listening.
Any help would be highly appreciated.
You need to start running your application (using that port number) for the port to appear as open. As soon as it starts running and successfully listening on Port 5122, a local nmap scan will list that port as being open.
You only need to modify firewall rules once your application works to your satisfaction and you want to allow access to it from external host(s).
The output of iptables -L shows that your iptables command has
successfully modified the firewall rules to allowed external access to your application. In fact, it looks like you inserted the rule twice; this doesn’t do any harm as the second rule won’t be processed.
Explanation
By default, all TCP and UDP ports are closed (not in a listening state). Only when a server or similar program opens a network socket and starts “listening” to a port number will that port appear to be open.
E.g., running nmap -sT localhost locally on my server shows that most ports are closed and only lists the ones that are open:
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00019s latency).
rDNS record for 127.0.0.1: localhost.localdomain
Not shown: 995 closed ports
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
3306/tcp open mysql
A firewall such as Netfilter / iptables can be used to selectively block
access to ports whether they’re already open or not. In this case, those ports are considered to be filtered – though confusingly, some people and websites refer to filtered ports as being “closed” and the act of removing the firewall filter as “opening” a port.
E.g. running nmap -sT server.name on the same server from an external host reports different results since now the packets from the remote host are being filtered by the firewall:
Interesting ports on server.name (78.47.203.133):
Not shown: 1679 filtered ports
PORT STATE SERVICE
80/tcp open http
Note that locally, ports 25 and 3306 are open but from an external perspective they are shown as being filtered.
I have a machine with 3 interfaces, two public and one local. They are all from the same IP range. All externally accessible services on the machine use the internal IP.
However, when a process opens a connection to the outside world, the source address in the packets is set to that of the public interface which will be used to sends the packets out.
Is it possible under Linux to force all source addresses to be that of a particular interface, even if the packet then will be routed through an other interface?
Say we have a machine with 3 interfaces, A.B.C.1, A.B.C.2, A.B.C.3. Of these A.B.C.1 and A.B.C.2 are connected to the Internet (and A.B.C.0/24 is routed to them). All services on the machine listen to A.B.C.3. Is it possible to guarantee that all packets originating on the machine will have the source address of A.B.C.3, even if they will leave the machine via A.B.C.1 or A.B.C.2 ?
Specifying the source address when the socket for the outgoing connection is opened is not a solution; we're talking about existing programs which can not be changed. Also, it should work for ICMP as well.
Thanks.
This can be achieved with iptables:
sudo iptables -t nat -A OUTPUT -j SNAT --to A.B.C.3
If the iptables service is not running, it can be activated via the following command:
sudo service iptables restart
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have started sshd in my computer (Ubuntu-12.10) to let other PC (let pc2) connect in my guest account through local port forwarding.
Now how can I monitor the traffic of that pc2 from my PC i.e. which website he/she is opening or what data he/she is downloading and other traffic which is passing through my computer?
You cannot 'see' the traffic arriving from pc2, because ssh encrypts it. However, you will be able to see the outbound portion of any tunnelled traffic when it is being used, because this is generated by the local sshd.
Using the lsof command, look at what happens when the user from pc2 connects to you with ssh. lsof -i TCP|grep pc2 will show you something like this :-
sshd 14466 root 3u IPv4 327724762 0t0 TCP pc1:ssh->pc2:40781 (ESTABLISHED)
sshd 19170 pc2user 3u IPv4 327724762 0t0 TCP pc1:ssh->pc2:40781 (ESTABLISHED)
The first line represents the sshd service itself, and the second line represents the portion of sshd that is running the pc2 user's connection (Privilege Separation is used by default with Ubuntu and hopefully everyone else by now).
From this view, you can't see any port forwarding, because it isn't yet being used. But we can use process ID (PID) of the pc2user's ssh session, which is 19170 here. We can now use lsof again to see what that process is doing. lsof -p 19170 -a -i TCP
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 19170 pc2user 3u IPv4 327724762 0t0 TCP pc1:ssh->pc2:40785 (ESTABLISHED)
That should give you the same output as the second line above; but when the user starts to use the port forwarding tunnel they have declared, you will see it form from this PID ...
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 19170 pc2user 3u IPv4 327724762 0t0 TCP pc1:ssh->pc2:40785 (ESTABLISHED)
sshd 19170 pc2user 10u IPv4 327873368 0t0 TCP localhost:55678->google.com:http (ESTABLISHED)
As soon as you detect this second connection, you are able to start collecting the network traffic for it, by specifying either end of the connection: here, we'll use the localhost end :-
tcpdump -i lo src port 55678
Now that you have seen how traffic tunneled over ssh is visible, you might want a more automatic way to trap it. iptables allows us to match all the traffic that comes from a specific user using the Owner Match facility -- see http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#OWNERMATCH
All the outbound network traffic from pc2user's ssh connection will be owned by pc2user -- you can use iptables to log all of this somewhere, or decide what to allow/reject, or do something else, like push all the HTTP traffic into a specific proxy that you set up.
You might also need to look at the authorized_keys file for ps2user, where you can control what port forwarding the user is allowed to ask for in the first place with permitopen="host:port" statements. man sshd will help you there.
The point of Secure Socket Shell is to encrypt the traffic between connecting entities. It actually implements a protocol level form of encryption. This is one of the benefits to it's utilization.
The thing to note that about your SSH, is how it in itself works.
Though it has a primary goal to secure data, the easiest way to correlate a connection through SSH is like a series of tubes. These tubes contain a start, a end.
When you create this tunnel your specifying an address and port, which will reply once it has properly given a handshake.
If you have a machine behind a firewall you'll need the machine to physically connection to the outside world, by exposing the "Entry" point of the "Remote" side of the connection.
Obviously a benefit for this port being exposed is more items will begin to appear through plain old text, which blatantly exposes any data.
Now there are different tools to monitor such information:
Network and Protocol Analyzers
Proxy Servers
Proxy Servers: This lovely methodology is designed to take any traffic that hits your network; filter, monitor, and then pass it off. So in a sense you'll be able to monitor all incoming and outgoing traffic request.
The connection itself may be secure which will hide transmission, but the Proxy will still expose the destination or incoming request.
Network and Protocol Analyzers: These are designed to be configured to monitor network traffic, so they will target each port and protocol that is geared toward three things:
Server
Client
Router
The goal will be to monitor all Network packets that are sent from the machine, so once that packet is populated it will move down the OSI Model. Now the benefit of these analyzers, is they will expose all the required information from an IP to another. With these Bits exposed partially.
For penetration testing a common tactic is to poison the routers tables, once they are exposed it makes it very easy to intercept these packets then reinject them with different information.
Here are some Network and Protocol Analyzers:
Nagios XI
Wireshark
A Proxy:
Nginx
Security Utilities:
Open Wall, Security site with some security software utilities that may apply.
Antionline, Blackhat - Those forums have a lot of viable information.
Owl Security Software
SSHD
FreeBSD --> Has some built in SSH logging utilities built into it.
There are a lot of information to go about doing this, I took a some what kinder approach then Satish, but you can use different variations of a attacks to obtain information as well. Another thing you may want to try is Penetration Testing. Some of those utilities will also accommodate your request.
Hopefully that helps at least point you in the right direction.
Short answer you cannot. The whole point of ssh is to have a secure (encrypted) connection. The only way is to have the guest account monitored through your root account on pc1. You have do that with having the guest configured to use a proxy for example for internet connection and you have access to the logs of the proxy.
But there are easier ways to do stuff like these.
If you really willing to do that then there is a only way to do is Man-In-The-Middle (MITM) attack. while ssh session is encrypted you can't see the traffic using sniffer so somehow you have to put attacker machine between your computer and PC2 so you can easily sniff traffic. There are some tool available which will help you to implement MITM attack.
MITM SSH
Decrypt SSH2 Session using libssl Vulnerability