Hot answers tagged tunneling
11
The most systematic answer is to implement split horizon DNS in your infrastructure, such that only internal addresses resolve; clients then must use a proxy server to connect out to the internet, and the proxy server resolves external DNS for them. This is particularly effective if your core network doesn't have a default route, so that packets destined ...
9
Tunnelling is useful because it allows you to connect to any other machine on the network. Once you compromise one internal machine, you can use it as a platform for other attacks. Simply installing tools such as nmap on the compromised machine won't allow you much freedom in terms of actually exploring the network, beyond preliminary scans.
Getting a VPN ...
8
You can indeed use tun/tap tunneling. The easiest way I know of to do so is using OpenVPN. There are graphical clients for that for most OSs.
If you use 'tap' tunneling, your laptop will show up on the remote LAN, since layer 2 network traffic is also sent through the tunnel. Using 'tun' tunneling however, which occurs at layer 3, only your IP traffic is ...
7
The implication of X11 forwarding is that it opens a channel from the server back to the client. In a simple SSH session, the client is more trusted than the server: anyone in control of the client can run commands on the server (assuming shell access), but the converse is not true. With X11 forwarding, the server is likely to gain shell access to the ...
7
Can't recall the name, but I know there's been at least one commercial product which used port 53 to phone home (not a full TCP/IP tunnel though).
I would seriously question the (f)utility of trying to prevent this kind of thing by attempting to block specific outbound traffic though. Firewalls were never intended to filter outbound traffic, tunnels, ...
7
What's up? Here's the meat and potatoes:
nurf@sessmacheen $ ssh -f -L localport:localaddress:remoteport \
user@remoteaddress sleep 10; nc localaddress localport
This is assuming that sshd is listening on the remote box, which I think I can infer from your post.
Ok! So ssh is passed -f, which just backgrounds it after the connection is made, and ...
7
Most SSH clients will do that for you. With the ssh client provided with any good Linux system, simply type:
ssh -D 5000 -N theservername
where theservername is the name of the SSH server to which you want to tunnel the requests. Then set your Web browser to use localhost, on port 5000, as SOCKS proxy. And voila! all your HTTP and HTTPS requests will go ...
7
In general, we set the shell to /bin/false and provide the -N option when creating the tunnel, something like;
ssh -D 4444 -N -i ~/keys/user_id_rsa user@remote.com
The -N switch tells ssh not to execute any commands upon connection, without it your connection will immediately close due to the /bin/false shell.
You could use /bin/rbash to provide some ...
6
Tor isn't safe from man-in-the-middle attacks.
The unsafe component are the Tor exit nodes. These make the actual, unencrypted request and therefore can read and modify your traffic. Tor provides anonymity by not letting them know where the request came from, but the actual traffic between the exit node and the Internet is not different from normal traffic, ...
5
I'd say that tunnelling is important due to the freedom that it allows with specific types of testing. This really only applies to external tests as if you start the test on the Internal network tunnelling is less important (although it could be useful for getting data out of the network).
On an external test you might find an issue that allows for command ...
4
I often use Tor for this kind of tunneling. If Tor works in your network environment, set up a hidden service. The directory /var/lib/tor (GNU/Linux) has a subdirectory for your hidden service. Inside is a file called hostname. You add a section in you .ssh/config:
Host *.onion
ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
plus maybe ...
4
To be able to run SSH tunneling, you must have an account on the "edge" machine. It is difficult to permit tunneling without giving a complete shell access on that machine. That's a shell as a generic user. Theoretically, Unix-like systems enforce strict security rules with regards to local users, so that giving a shell access to a user is not a big deal. In ...
4
Before trying to trade performance for security, I suggest actually measuring the performance. The overhead for SSH encryption is slight; it increases data size by less than 1%, and CPU usage is low unless you have a pretty weak CPU or a pretty fast network (a Core2 CPU can keep up with 10 MBytes/s SSH by using less than 15% of a single core). So chances are ...
4
If someone has access to B in the given scenario, they could set up a proxy to perform a man-in-the-middle attack on the connection from A to C. This would allow them to decrypt any traffic between A and C, if it is not otherwise encrypted at a higher level.
The attacker would configure B to present itself to A as C while using the attacker's key pair. ...
4
Actually, Moxie Marlinspike created a tool called SSLStrip. He actually tested it on his TOR-node, and found that a lot of people didn't notice that the encryption was gone.
His talk is worth a watch: Tricks on defeating SSL
//M00kaw
3
Yes, it's possible for the root user on B to snoop your traffic, although you don't say exactly what OS it is. On Linux, that might include the ttysnoop program or using a debugger against sshd.
I've used tunnel-in-a-tunnel a lot (as well as SSH over PPP over SSH, which is yet another layer), and it doesn't necessarily have a serious performance or latency ...
3
Have you considered using a transparent proxy? It can automatically intercept all traffic and feed it to the proxy.
If you're asking about Tor, check out the Tor transparent proxy, which might do exactly what you want. You might also check out Torouter.
3
The most common solution I see is to have the firewalls at each location set up to only allow the tunnel to connect to specified endpoints. This means it can still be used for the purposes intended, but can't be used to access other locations.
A pre-requisite is that you maintain centralised control over firewalls and endpoints, so there is no way to avoid ...
3
I realize this is an old question, but I just ran across it and thought I'd post my perspective for sake of the next guy.
The best answer is caelyx's response: architect the network so only the proxy can resolve external DNS hostnames. As he points out, retrofitting this into a production environment is difficult.
A compromise is to block all udp/53 ...
3
I have seen this happen.
It is mainly used by cheap geeks to avoid having to pay for public wireless. What they do is that they set up a server at home ether a fake DNS or just a random VPN at home. And when they are out and about they might have to connect to the internet so they look for any open wireless and connect and if it wants you to pay then you ...
3
The actual physical layer or data link layer do not present a security concern as long as you force mutual authentication and use a properly secure ciphersuite.
There is no direct risk with physical layer access. There is a future risk with it.
As somebody with access to the physical layer or data link layer has the possibility to store all traffic ...
2
There is an old but still partially relevant document called the firewall piercing howto. It is aimed at students who use Linux and find themselves trapped at some internship places behind a restrictive firewall which prevents them from slacking with the help of their favourite network-enhanced tools. On a general basis, I do not condone circumventing ...
2
It's actually very easy to create a single port tunnel to take advantage of whatever port is open on a router. This happens a lot in security testing - maybe I can take advantage on a vulnerability on a server, but I then want to do something useful with it such as escalate the attack further. What I then usually do is run netcat to create an outgoing ...
2
If your tunnels are forwarding traffic from the internal to the public, then I don't see any additional problems. E.g. forwarding port 8080 on the private side of the edge machine to the intranet webserver on the public side. (Though if all the services you need can be SOCKS proxied, it may be easier to just do ssh -D 8080 user@edge-machine each time you ...
2
This is well covered above, but i'll try to sum it up.
One system cannot directly access all other systems connected to the internet. Internal hosts with RFC1918 addresses are often only accessible via tunneling through a host that bridges the network you're currently on with the target host's network.
Tunneling is a useful technique for several reasons:
...
2
Firewalls are generally classified into three main categories these are
Stateless/StateFul Packet Filters
Application/Proxy Firewall
Web Application Firewall/Reverse Proxy Firewall
Each type of Firewall operates at different layers in a TCP/IP stack and has its own pros and cons. You are actually using an Application/Proxy Firewall which imposes ...
1
Beside the original post, you wrote you don't have root access to the computers, and that there is already a daemon listening on port 22.
In case you are in the sudoers group, nothankyou's solution is the one to go with:
sudo ssh -f -L localport:localaddress:remoteport user@remoteaddress
sleep 10; nc localaddress localport
In case you don't, but ...
1
Not entirely sure why the answer from @balgan had a downvote, but to expand essentially I would recommend the same thing which is to use the windows firewall which ships with Server 2008 to protect that host and block access to services over the IPv6 tunnel interface.
If you've not running the firewall already to block IPv4 connections, you could add a ...
1
Let's say I open a SSH connection to someserver, with X11 forwarding enabled. The primary risk is that if someserver is malicious, then someserver can do all sorts of nasty stuff to the windows/applications I have open on my own computer.
For instance, someserver can open up windows on my computer, can close other windows I have open, can spy on the ...
1
I don't recall the SOCKS protocol encrypting the traffic. SOCKS can authenticate users, to make sure the SOCKS proxy isn't being abused, but the connection and requests should all be in paintext. Assuming things haven't changed, the ISP could have simply implemented a solution to intercept SOCKS traffic and block filtered sites.
Regardless, there are ...
Only top voted, non community-wiki answers of a minimum length are eligible
