This format of screen-sharing is soooo much better than other videos. Please maintain this format of showing everything on the screen. So helpful and so much easier to understand
10:54 Unfortunately, this whole section here about TCP over TCP is incorrect in this case. Yes, if you're tunneling raw IP packets over TCP (and there are ways to do this with SSH, for instance using the -w option, running PPP over SSH, or with OpenVPN over TCP, as well as a million other ways), you do end up with the TCP-over-TCP meltdown you are explaining quite correctly. But, if you're using SSH's "dynamic port forwarding" mode which emulates a SOCKS proxy, there is no TCP over TCP at all going on. There's TCP running between your client software and the SSH client's SOCKS proxy emulator, TCP running between your SSH client and the remote SSH server, and also TCP running from the remote SSH server to the tunnel destination. These are all seperate TCP connections, and none of them of them running "over" each other. They're conseptually connected end to end, not over each other. There's no raw IP packets going over the SSH tnnel, and thus no TCP. Only the data beloning inside the stream as multiplexed as multiple channels in SSH. TCP retransmissions will happen on every TCP stream, but there's no redunant layer of TCP happening end-to-end over the actual tunnel, and no duplication of retransmission for that reason. That said, because everything you're doing ends up passing through a single TCP connection, that can definitely be a bottleneck, but for other reasons.
Hmm... The version I show via the proxy is using netcat to transfer data - that certainly is TCP over TCP no? But in the simpler version where do you think the code opening the TCP connection to the final destination runs? At the same side of the firewall as the web browser or at the same side of the firewall as the web server? I can't easily find an answer to that. If that TCP connection originates outside the firewall you are right but I did not think that was how it is working.
I think you may be right here. It shows even when you use tools for many years you can still learn things. When I was reading for this article I came across many pages confidently claiming that ssh -D was TCP over TCP but I think you are correct.
@@richardclegg8027 Hi! Proxy using netcat is also not TCP over TCP. Same as with ssh -D, it's not a TCP session inside a TCP session, it's data exiting from one TCP session and then entering another TCP session. I.e. you're only tunneling the actual data inside the session, you're not tunneling the TCP headers or the retransmssions. The only way you'd get TCP over TCP is if you're running IP over TCP, for example if you're using some kind of VPN software that uses TCP as a transport for IP packets. To be clear, none of the scenarios you've shown in this video will do IP over TCP and thus not TCP over TCP.
You are right. In days past a similar thing was done with ppp or slirp over ssh which did work like that. I guess this is why the TCP over TCP idea propagated for ssh -D (not helped by the sshtunnel docs which while correct don't clarify). When I read about it lots of places made the claim your explanation is correct.
My professor 2 years ago tried to explain ssh tunneling for the same length of time as this video and failed miserably. Dr. Clegg explained in half the time and even talked about other ways of doing this while being easy to comprehend. Great video
The difference was that you wanted this, while you were subjected against your will and professor. Also, you had previous ground-work enabling easier learning. Perhaps?
During high school, it was incredible to see how even the least tech-interested kids figured out network shares and a bunch of other things when it let them play games in class etc lol
"try this at home but not anywhere else at all" ---> "so now let's imagine you're on a train or in an airport where the administrator is not giving you full access..." That escalated quickly.
Same. I actually had to do this to get around some UDP throttling that a hotel in London was doing to prevent people from using their WiFi for VoIP and video chat.
@@Centigradius I also use a site-to-site IPSec VPN between two UDM Pros. No matter where I am, I'm always connected to my home network, which is also connected to the other house network. It's nice to avoid all the guest network monitoring and tracking.
Yes, TCP over TCP is bad. But there is no TCP over TCP in this case. There are just 2 TCP connections in serial. If you use ssh -w, that would create a tunnel where you are doing tcp over tcp.
I remember using proxy tunnels way back in the early 2000s. I found a bank in France that had full internet access and proxied in to that over port 8080.
I used to do the opposite hosting a game server on school machine and tunnel it out with ssh tunneling and my fds and I can all enjoy free game server hosting
We used to do this SSH tunnel way back in 2007 to break out of the NHS network to connect to home. Was a 2nd line engineer and sick of 3rd line monitoring anything you did. Got more work done with that tunnel than without it.
I've used iodine DNS tunnel for years. It's not fast or efficient but it works. Nobody has ever noticed and none of the many environments I am familiar with monitor DNS traffic for stuff like this.
I'm impressed by the fact that his computer is named for a character from Mervyn Peake's Gormenghast novel. Not that your presentation wasn't interesting, Dr Clegg, but my excitement that I'd found another Peake fan eclipsed all else!
19:10 So for the web proxy protection explanation, the workaround where the exit address gets remapped to :22 only works if you have admin control over the web proxy itself right?
Anyone else notice port 456 blocked "related to mail" (at 4:48)? Me neither. :) Almost certaionly meant to be port 465, for SMTP over implicit SSL/TLS.
I traveled around Turkey this month. I had a local sim card for data (Vodafone). There was one region (Antalya) where it wouldn't allow me to connect to my home wireguard peer. Also VPN provider websites had been blocked e.g. Mullvad. This wasn't the case in Istanbul, Mersin or Fethiye regions, very strange. I'm using a non-default port for wireguard, maybe I should try port 443.
So as a network engineer having to defend these issues when setting up networks like such as a "guest" network. For this, I don't use a layer 4 firewall(such as an ASA without firepower) which is what seems to be on the topic for this video. More used in this situ' is a layer 7 Firewall(such as a Palo Alto) where you can allow based on application rather than "Service Port" for "guest" network on a Palo only allow the following applications: dns, web-browsing & ssl. Another option could be adding in decryption for other networks, it doesn't really work for a guest network. Also, I would like to see what you suggest for application(L7) firewalls and to bypass these...
If you have your alerts popping on known TTPs, even on simple things like duration, or constant dns traffic from a single endpoint that deviates from the baseline configuration, you can at least look at it and see if that is explained behavior or not and adjust your alerts accordingly. But to your point, it often takes a mature SOC dedicated to notice these things,
Someone I know did that a century ago. (A bit more sophisticated, it was encapsulating everything in multiple TLS streams.) IT security can break normal work so easily. A few years after he established this, someone contacted me. Asking why there was so much traffic to that address from that machine. I said it was a leftover test that seemed to be still running and I cut it down. Since then our security got much better, much more defined and more relaxed. No need to tunnel, no need to dig holes, everyone is happy and safe. Too much security is as dangerous as too less security.
Many internet service providers here in the United States will reroute any UDP/53 traffic to their preferred nameserver to facilitate user tracking. Other "better" internet service providers will merely monitor UDP/53, but then frequently deny packets that aren't legitimate DNS requests. As nice and decentralized as our modern internet is, there's some of the worst, most power-hungry people in the world acting as gatekeepers to it.
@@Phroggster VPN over DNS uses valid DNS packets (query/answer), so it looks correct on inspection. Except the fields contain some gibberish data (data encoded with uuencode or some similar encoding). The way a next gen firewall can stop it is with "Domain reputation" - your domain may not be known enough, or not part of the allowed categories. Also intermediary servers may cache replies longer than the TTL value, which can cause mayhem.
A few comments on the last part - not entirely true - in modern web traffic, it's extremely difficult to differentiate between a "normal" ssl websocket traffic and a long-living tunnel. It can be done by pattern analysis, but I doubt train ISP providers monitor for that.
I think you're thinking of websites like gmail that keep alive a long-lived connection. The normal case for SSL is that you make a connection download the website and close the connection. Gmail (and a few other sites) keep the connection alive for extended periods in order to avoid the connection overhead of SSL set up -- but they are the exception more than the rule and their traffic pattern is quite distinctive.
@@richardclegg8027 many websites keep long-running connections - for example notifications, event tracking, data streaming, etc. Also, you have to consider the new technologies coming like spdy and http/2 which (very simplistically said) relies on long-lived connections to minimize roundtrips to the server.
@@richardclegg8027 you're right. I've not followed things recently. I see QUIC runs on UDP, which again can be a carrier for a vpn tunnel. In this case too, you need a pretty sophisticated analytics to pick a tunnel from regular traffic. Maybe it'd be even more difficult as everything is split and mangled in a ton of UDP datagrams. The most important thing is practicality :) If a very simple proxy would keep 99.99% of teenagers from watching 4k youtube on the free wifi, I don't think someone would invest in traffic pattern recognition for those cases :) The cost of running this would certainly outweigh simply providing fast free wifi...
Yeaa.. it remember me the day our IT teacher had to explain how to bypass the school proxy server to setup our own proxy lab. Using proxy for home purposes is irrelevant these days in my option. VPN over 443 and remote sessions (can also be 443) are way more secure and reliable.
Ok. I ssh'ed into Dr. Clegg's home server. Who are all the babes you have 1TB of pictures of? BTW: Thank you very much for your time you spent with explaining this Dr.
when i was in college in the mid 2000s they tried banning bit torrent in the dorms, but they weren't very secure back then so I just tunneled out using UDP and was able to access non-throttled internet speeds too (15kbps wired in the dorms for all data, 20mbps after tunneling out) stuff is more complicated now though i think, but i thought i was a badass back then haha XD
Correct me if I am wrong, but I don't think ssh tunnel is TCP over TCP. ssh tunnel acts like a normal TCP proxy, only that the connection in between the ssh client and ssh server is encrypted, it does not preserve the original TCP header.
I would really like to know whether I can reach my server via ssh from inside a network which only lets ports 80 and 443 pass - but without having to change the port my ssh server is listening to. What would be needed for that?
@@luxraider5384 Yes, that was my question: What if port 22 is blocked in a network, and I need to ssh into my server? I did actually configure my NAT in such a way that incoming traffic goes through another port than 22 (because of the massive load of annoying attempts to log in with a password and some random username, which was never active in the first place). So my question is: Is there a way to have a packet go out on port 80 on my machine and arrive on port, let's say 18650 (for example) on my home server? If so, I'd love the syntax for that ssh commnand - I only know the option -P for the general port (outgoing and incoming). But I'm not sure whether TCP is even capable of having a packet go out on port x and arrive on port y?
How will any of this work if you don't have local device admin rights and network authentication prohibits LAN devices that don't match a specific criteria i.e. MAC address?
mac spoofing is trivial, and you could either get that from the original machine or sniff it. you'd probably have to power it off if you wanted a reliable connection though
Reliable protocol doesnt need the loss :) - it only can accomodate to the loss - its not needed - if you have a local 10mbps link in your computer - you can set it up to send with that rate, choose any buffer (at home....ofc :) ) and tcp will be working very much without a loss on a connected switch 1gbps inter-network - local IP stack implementation will not allow that TCP connection to start getting congested at 10mbps (of course if your 1gbps inter-network wont start getting congested, or switch power ASIC capacitors wont stop being congested :)
That takes me back.. used to have quite a bit of fun with that in the XP days. Haven't tried it in a while for anything, but I would imagine it would attract a lot of attention.
I just set my home firewall to listen on 443, and forward via NAT to my ssh server. So in a nutshell, just set your ssh server to listen on port 443 instead of 22. It's not that complicated. Very secure networks will close your connection after about 30 seconds, and you'll have to create a script to re-init the ssh tunnel, and close it, over and over. Also, most networks other than maybe a work network, which still could probably be argued in court, have you agree to not access certain things via their network. If your house isn't one of those things, then technically ssh to your own home server is fair game. Where you go from home isn't technically in their jurisdiction. If their machine is only connecting to yours, then you have ground to stand on. What your machine connects to, is none of their business. But make damn sure your DNS requests are also going to and through your home machine. Most companies now have a catch all policy that includes not using their provided computers to access XYZ sites. So at that point, you may be hosed. In the end, any admin with enough time on their hands to see that you are using port 443 for different amounts of time, or triggering a disconnect time out rule, is going to have such a hard time proving the rest, plus all the extra hassle of doing so. They're probably going to just pull you aside and say, please don't keep doing this, because eventually I'm going to have to explain it to someone and force it to stop.
I would do this almost everywhere but certainly not in a work environment - an encrypted connection to an unknown destination out of a company network is a big no (could be company secrets) - if I REALLY need access to X I will let IT know and escalate it if necessary 😊
There are also solutions like guacamole that you can run on the target machine and just serve it under a simple web service. (VNC/RDP or an ssh console)
I've never had to go much further than SOCKS over an SSH tunnel on a nonstandard port to bypass poorly-monitored outgoing firewalls. Mostly useful for large businesses with many locations, who provide internet access as a perk to their customers, where individual locations rarely have a dedicated IT staff (restaurants, bars, coffee shops, department stores, salons, spas, outpatient clinics, etc.). Use with caution, and only on the isolated guest wifi, if you're stuck in a hospital and have to get actual work done.
2:00 makes me wonder if you could have wired internet to a train. They have mains electricity from the electrified rail. they could have a ethernet rail for the track.
its very nicely presented here.frankly this is something my school mates and I have used to check social media,in school computer lab , since it was heavyly firewalled network.
the only issue here is that you have to have set up your proxies in all configurations ahead of time because you're not going to be able to get out via SSH to configure your hack. Still, interesting. I didn't know about nc!
Depends on what you are dealing with. If you have a server with ssh anyway then the first part of this using tunnels or sshuttle will "just work". Going via a web proxy won't though.
The web proxy thing wasn't explained well. If everything is blocked how do you reach the web proxy? What exactly is it? No explanation was given at all.
It's a bit more than "cheating" in inverted commas. You manipulated the web proxy, something you typically have no access to. Better would have been to run SSH on port 443 on the twisted server.
It has become necessary (in this day and age) to change your exposed ssh port anyway in order to avoid a few thousand attempted malicious logins everyday anyway. Making ssh available on something like port 62244 keeps your auth.log from growing too large.
The best set up is blocking every port by default, & only opening the exact ones you need, & only then when you've done your best to protect those particular ports. Eg; only opening SSH after you've created a white-list of permitted SSH source / destination sites.
One time at work we wanted to access some site to view various things. Turns out their firewall was only plain text, using the IP address directly worked a charm
The last element, that the attackee needs to get lucky every time, is actually a reversal of the better-accepted aphorism: A well motivated attacker will always win, because they only need to succeed once. Defenders must win all the time. Now for egress I can see some of the logi in the statement made by the blue team guy, but the solutions are relatively straightforward for me: hide in plain sight go low & slow live off the land ensure you only depend on things the target can't take away without committing self-harm (Full disclosure: I'm a red teamer, not a criminal 😁)
I'd say it's an app if it has GUI and interactions, but a command line "do a thing and return" like curl is a program. Ssh, ftp and similar programs are still programs even if they have interactions, though. I think.
Now you need a part 2: "How to hack out of a system with no Networking hardware." Skynet would love that. And i know is possible(the spontaneous creation of life kind of possible(we are here so it is possible) or at least half way to that) though highly unlikely, like trough the electrical grid or with flicking the display on and off of the system at a camera connected to the internet.
I'd like to know this mythical machine where I want to do something *and* own it, yet somehow have not gotten permission from the owner. Every cyber security, hacker, technical person talks about either having permission or being the owner of the machines; hinting at this mythical machine or network where you can have the latter, but not the former.
@@sam-n9v Read my comment again, this is not a technical question but an observation about what he's literally saying as a disclaimer at the beginning.
I am saying that to be responsible my advice must be that you only do this to educate yourself about computers and not to circumvent restrictions that security professionals put in.
@@richardclegg8027 @Richard Clegg No no, not why you're saying it. *What* you're saying. In which situation do you _not_ cover _every possible scenario_ when you qualify "only do this on a machine/network that *you have permission for* "? In what possible state are things that you need to add "or own"? Where is this mythical machine that *you own*, that *you wish to do things to*, and yet somehow *don't have your own permission* (not talking about user permissions; again, not a technical question) to do for? Because you're implying the existence of such a machine or network by saying that you need to own *or* have permission. Why are you not done with "have permission"?
@@tiaxanderson9725 Oh sorry, fair enough. I'm not reading from a pre-prepared script here, it's more an interview style format so I hope you can forgive the odd stumble like that. Not as bad as getting the name of ufw wrong. That's a real *blush* moment. :-)
A long time ago, decades in fact, I used PPTP on hotels, because that doesn't use UDP nor TCP but instead an oddity called GRE. And in those hotels that wasn't being paywalled. And a couple times I even used tunneling via ICMP (yeah, ping payloads), there was a little Linux program for doing that. EDIT: lol.. he mentioned ICMP at 21:00
“Only do this at home” 1min later… “imagine you are in a train”…
Imagine you are on a train -- but actually you are at home not violating the terms of service of a train company -- that's my official position. :-)
You don't have trains in your house?
I just use node vpn😅
Yes.. "imagine" is the keyword here
I think he means "Practice that at home"...:-)
This format of screen-sharing is soooo much better than other videos. Please maintain this format of showing everything on the screen. So helpful and so much easier to understand
10:54 Unfortunately, this whole section here about TCP over TCP is incorrect in this case. Yes, if you're tunneling raw IP packets over TCP (and there are ways to do this with SSH, for instance using the -w option, running PPP over SSH, or with OpenVPN over TCP, as well as a million other ways), you do end up with the TCP-over-TCP meltdown you are explaining quite correctly. But, if you're using SSH's "dynamic port forwarding" mode which emulates a SOCKS proxy, there is no TCP over TCP at all going on.
There's TCP running between your client software and the SSH client's SOCKS proxy emulator, TCP running between your SSH client and the remote SSH server, and also TCP running from the remote SSH server to the tunnel destination. These are all seperate TCP connections, and none of them of them running "over" each other. They're conseptually connected end to end, not over each other.
There's no raw IP packets going over the SSH tnnel, and thus no TCP. Only the data beloning inside the stream as multiplexed as multiple channels in SSH. TCP retransmissions will happen on every TCP stream, but there's no redunant layer of TCP happening end-to-end over the actual tunnel, and no duplication of retransmission for that reason.
That said, because everything you're doing ends up passing through a single TCP connection, that can definitely be a bottleneck, but for other reasons.
Hmm... The version I show via the proxy is using netcat to transfer data - that certainly is TCP over TCP no? But in the simpler version where do you think the code opening the TCP connection to the final destination runs? At the same side of the firewall as the web browser or at the same side of the firewall as the web server? I can't easily find an answer to that. If that TCP connection originates outside the firewall you are right but I did not think that was how it is working.
I think you may be right here. It shows even when you use tools for many years you can still learn things. When I was reading for this article I came across many pages confidently claiming that ssh -D was TCP over TCP but I think you are correct.
@@richardclegg8027 Hi! Proxy using netcat is also not TCP over TCP. Same as with ssh -D, it's not a TCP session inside a TCP session, it's data exiting from one TCP session and then entering another TCP session. I.e. you're only tunneling the actual data inside the session, you're not tunneling the TCP headers or the retransmssions. The only way you'd get TCP over TCP is if you're running IP over TCP, for example if you're using some kind of VPN software that uses TCP as a transport for IP packets.
To be clear, none of the scenarios you've shown in this video will do IP over TCP and thus not TCP over TCP.
You are right. In days past a similar thing was done with ppp or slirp over ssh which did work like that. I guess this is why the TCP over TCP idea propagated for ssh -D (not helped by the sshtunnel docs which while correct don't clarify). When I read about it lots of places made the claim your explanation is correct.
Ah yes, spent a while troubleshooting that ovpn over tcp a few weeks ago...
Thanks for the knowledge!
"do not try this at home" "no, only try this at home", lmao, I am somewhat conflicted on this
Try at home in you home lab. Lol
Here I will simplify it.
Rule 1: Don’t try this at home
Rule 2: Try this at home
But its back to "Do not try this at home if your parents have put locks in place for a reason" :)
Arent we working from home?
Only try This at home =/= Try this Only at home
Didn't he say the second(as in, not on the net)?
We need more technical content like this! Great job!
04:35 UFW is actually _Uncomplicated Firewall_ . It's "only" a Python "wrapper" for iptables.
Tnx, I was scrolling to see if anyone else had noted this.
@@kevinjones5001 Same! Glad someone(s) was on it haha
@@kevinjones5001 there are 17 people who noted this in the comments :)
Students are the best people to ask about how to bypass networks.
My professor 2 years ago tried to explain ssh tunneling for the same length of time as this video and failed miserably. Dr. Clegg explained in half the time and even talked about other ways of doing this while being easy to comprehend. Great video
Or maybe between the two your brain put it together?
The difference was that you wanted this, while you were subjected against your will and professor. Also, you had previous ground-work enabling easier learning. Perhaps?
I feel like this is how many kids get interested in computers.
Just for educational purposes only... ;-)
During high school, it was incredible to see how even the least tech-interested kids figured out network shares and a bunch of other things when it let them play games in class etc lol
"Let's get the OHP up."
Smacked me right back to elementary school.
I didn't understand could you explain?
@@violet_flower And private schools
OHP isn't hacked since 1920
"try this at home but not anywhere else at all" ---> "so now let's imagine you're on a train or in an airport where the administrator is not giving you full access..."
That escalated quickly.
I just run a VPN server at home, and anywhere I've been (including China) I can just VPN back home and get full normal access to everything.
Haven’t been to China … but yes, I do the same and it works quite nicely :)
Same. I actually had to do this to get around some UDP throttling that a hotel in London was doing to prevent people from using their WiFi for VoIP and video chat.
Wireguard FTW
It even works on airline wifi.
@@Centigradius I also use a site-to-site IPSec VPN between two UDM Pros. No matter where I am, I'm always connected to my home network, which is also connected to the other house network. It's nice to avoid all the guest network monitoring and tracking.
that's how network engineers are born.... trying to bypass censorship
"The Net interprets censorship as damage and routes around it" - John Gilmore
@@jursamaj when do we bypass musk's twitter?
@@thewhitefalcon8539 Whenever you decide to quit using Twitter.
4:32 Nope, it's "Uncomplicated FireWall"
Ultimate firewall seems pretty cool though
My apologies for this! You are of course correct.
Yes, TCP over TCP is bad. But there is no TCP over TCP in this case. There are just 2 TCP connections in serial. If you use ssh -w, that would create a tunnel where you are doing tcp over tcp.
Right on, this part is just completely wrong.
I remember using proxy tunnels way back in the early 2000s. I found a bank in France that had full internet access and proxied in to that over port 8080.
One of the very few videos I have watched more than once. Please do more high quality content.
transmitting data as a subdomain to bypass a firewall is the most hacky janky thing I've ever heard of and I love it.
I did this years ago to get around my University's firewalls to play games online... :D
Ah back in the days of Flash games...
I used to do the opposite
hosting a game server on school machine
and tunnel it out with ssh tunneling
and my fds and I can all enjoy free game server hosting
hehehe
So did I, back in 2005.
Why were they blocking online games?
We used to do this SSH tunnel way back in 2007 to break out of the NHS network to connect to home. Was a 2nd line engineer and sick of 3rd line monitoring anything you did. Got more work done with that tunnel than without it.
I've used iodine DNS tunnel for years. It's not fast or efficient but it works. Nobody has ever noticed and none of the many environments I am familiar with monitor DNS traffic for stuff like this.
I'm impressed by the fact that his computer is named for a character from Mervyn Peake's Gormenghast novel. Not that your presentation wasn't interesting, Dr Clegg, but my excitement that I'd found another Peake fan eclipsed all else!
I generally call the largest machine I own gormenghast, the cutest fuschia and the smallest barquentine. :-)
Really nice video. This is what inspires people.
And then you introduce a NGFW with SSL and SSH decryption and loose all the magic.
19:10 So for the web proxy protection explanation, the workaround where the exit address gets remapped to :22 only works if you have admin control over the web proxy itself right?
Anyone else notice port 456 blocked "related to mail" (at 4:48)? Me neither. :)
Almost certaionly meant to be port 465, for SMTP over implicit SSL/TLS.
Is smtp not related to mail?
@@teh_jibbler Very, but port 456 is (commonly) not. Looks like Richard needs to change that to 465 to refer to the common SMTPS port.
I traveled around Turkey this month. I had a local sim card for data (Vodafone). There was one region (Antalya) where it wouldn't allow me to connect to my home wireguard peer. Also VPN provider websites had been blocked e.g. Mullvad. This wasn't the case in Istanbul, Mersin or Fethiye regions, very strange.
I'm using a non-default port for wireguard, maybe I should try port 443.
So as a network engineer having to defend these issues when setting up networks like such as a "guest" network. For this, I don't use a layer 4 firewall(such as an ASA without firepower) which is what seems to be on the topic for this video. More used in this situ' is a layer 7 Firewall(such as a Palo Alto) where you can allow based on application rather than "Service Port" for "guest" network on a Palo only allow the following applications: dns, web-browsing & ssl. Another option could be adding in decryption for other networks, it doesn't really work for a guest network. Also, I would like to see what you suggest for application(L7) firewalls and to bypass these...
DNS tunneling was used in the SUNBURST (Solarwinds) attack last year, so not sure a normal admin would have detected that method.
If you have your alerts popping on known TTPs, even on simple things like duration, or constant dns traffic from a single endpoint that deviates from the baseline configuration, you can at least look at it and see if that is explained behavior or not and adjust your alerts accordingly. But to your point, it often takes a mature SOC dedicated to notice these things,
Someone I know did that a century ago. (A bit more sophisticated, it was encapsulating everything in multiple TLS streams.) IT security can break normal work so easily. A few years after he established this, someone contacted me. Asking why there was so much traffic to that address from that machine. I said it was a leftover test that seemed to be still running and I cut it down. Since then our security got much better, much more defined and more relaxed. No need to tunnel, no need to dig holes, everyone is happy and safe. Too much security is as dangerous as too less security.
Wow, this video really highlights the high quality of comp. sci. coming out of Nottingham University compared to others!
Dr Clegg is from Queen Mary University, London
@@johnvonhorn2942 my point exactly 😉
Vpn over port 53. Can even bypass a lot of wifi paywalls iirc because they still allow DNS requests
Many internet service providers here in the United States will reroute any UDP/53 traffic to their preferred nameserver to facilitate user tracking. Other "better" internet service providers will merely monitor UDP/53, but then frequently deny packets that aren't legitimate DNS requests.
As nice and decentralized as our modern internet is, there's some of the worst, most power-hungry people in the world acting as gatekeepers to it.
@@Phroggster So if you want to use Google DNS for example, they will send requests to their private DNS Server? is that even legal?
@@Phroggster VPN over DNS uses valid DNS packets (query/answer), so it looks correct on inspection. Except the fields contain some gibberish data (data encoded with uuencode or some similar encoding). The way a next gen firewall can stop it is with "Domain reputation" - your domain may not be known enough, or not part of the allowed categories. Also intermediary servers may cache replies longer than the TTL value, which can cause mayhem.
The word "Disclamer" made me enthusiastic.
Just a quick note.
We are going to try everything you are saying here
A few comments on the last part - not entirely true - in modern web traffic, it's extremely difficult to differentiate between a "normal" ssl websocket traffic and a long-living tunnel. It can be done by pattern analysis, but I doubt train ISP providers monitor for that.
I think you're thinking of websites like gmail that keep alive a long-lived connection. The normal case for SSL is that you make a connection download the website and close the connection. Gmail (and a few other sites) keep the connection alive for extended periods in order to avoid the connection overhead of SSL set up -- but they are the exception more than the rule and their traffic pattern is quite distinctive.
@@richardclegg8027 many websites keep long-running connections - for example notifications, event tracking, data streaming, etc. Also, you have to consider the new technologies coming like spdy and http/2 which (very simplistically said) relies on long-lived connections to minimize roundtrips to the server.
These days though I think most traffic to Google (certainly from Chrome) is actually over QUIC and they deprecate SPDY.
@@richardclegg8027 you're right. I've not followed things recently. I see QUIC runs on UDP, which again can be a carrier for a vpn tunnel. In this case too, you need a pretty sophisticated analytics to pick a tunnel from regular traffic. Maybe it'd be even more difficult as everything is split and mangled in a ton of UDP datagrams. The most important thing is practicality :) If a very simple proxy would keep 99.99% of teenagers from watching 4k youtube on the free wifi, I don't think someone would invest in traffic pattern recognition for those cases :) The cost of running this would certainly outweigh simply providing fast free wifi...
Yeaa.. it remember me the day our IT teacher had to explain how to bypass the school proxy server to setup our own proxy lab. Using proxy for home purposes is irrelevant these days in my option. VPN over 443 and remote sessions (can also be 443) are way more secure and reliable.
Ok. I ssh'ed into Dr. Clegg's home server. Who are all the babes you have 1TB of pictures of?
BTW: Thank you very much for your time you spent with explaining this Dr.
when i was in college in the mid 2000s they tried banning bit torrent in the dorms, but they weren't very secure back then so I just tunneled out using UDP and was able to access non-throttled internet speeds too (15kbps wired in the dorms for all data, 20mbps after tunneling out) stuff is more complicated now though i think, but i thought i was a badass back then haha XD
Him: Hey, Internet, don't use this exciting information in any way.
Internet: 👍🤔😏
hes talking about very basic things you learn on day 1 networking.
First!
No UA-cam? I'm definitely doing this... just to watch Computerphile. Just that. Honestly.
The U in UFW stands for Uncomplicated, not Ultimate.
Yes apologies for the mistake. I am blushing. Should have checked even though it is a tool I use all the time
Besides the interesting topic, i like the sound effect used for the firewall at 1:53 xD
“lets get the ohp up”
something i haven’t heard in a loooong time
for those who don’t know, ohp: over head projector (made with lights, magnifying lenses and mirrors)
Yes -- showing my age a bit.
Correct me if I am wrong, but I don't think ssh tunnel is TCP over TCP. ssh tunnel acts like a normal TCP proxy, only that the connection in between the ssh client and ssh server is encrypted, it does not preserve the original TCP header.
You are not wrong. You are in fact absolutely correct.
I really enjoy the networking Videos! Hoping for more :)
I would really like to know whether I can reach my server via ssh from inside a network which only lets ports 80 and 443 pass - but without having to change the port my ssh server is listening to. What would be needed for that?
in the video he only router a port to point to the port 22, he didn t change the port of his ssh
@@luxraider5384 Yes, that was my question: What if port 22 is blocked in a network, and I need to ssh into my server? I did actually configure my NAT in such a way that incoming traffic goes through another port than 22 (because of the massive load of annoying attempts to log in with a password and some random username, which was never active in the first place). So my question is: Is there a way to have a packet go out on port 80 on my machine and arrive on port, let's say 18650 (for example) on my home server? If so, I'd love the syntax for that ssh commnand - I only know the option -P for the general port (outgoing and incoming). But I'm not sure whether TCP is even capable of having a packet go out on port x and arrive on port y?
I’m sure students do this a lot. What are the consequences? At uni for example, would they be in trouble? I noticed libraries lock well
Dr Richard Clegg looks like a magician
I love this video. Though he left out the part about the best tool for tunneling out of a network: GCC and a copy of Stevens.
Hah... that is the advanced edition ofthis video.
How will any of this work if you don't have local device admin rights and network authentication prohibits LAN devices that don't match a specific criteria i.e. MAC address?
mac spoofing is trivial, and you could either get that from the original machine or sniff it. you'd probably have to power it off if you wanted a reliable connection though
4:40 UFW is Uncomplicated Fire Wall or at least that’s how I’ve seen it
If they are using a firewall with a whitelist, doesn't that mean that you need to have your proxy whitelisted?
You must have missed him waving his hands.
Reliable protocol doesnt need the loss :) - it only can accomodate to the loss - its not needed - if you have a local 10mbps link in your computer - you can set it up to send with that rate, choose any buffer (at home....ofc :) ) and tcp will be working very much without a loss on a connected switch 1gbps inter-network - local IP stack implementation will not allow that TCP connection to start getting congested at 10mbps (of course if your 1gbps inter-network wont start getting congested, or switch power ASIC capacitors wont stop being congested :)
"Don't try this at home"
*teenagers with school computers* okay lol
Is the computer connected to internet and firewall not allowing you to go anywhere ? Can you advise please
Is it possible to block the application/ssh communication based on what ssh is sending rather than simply blocking a port?
There are firewalls that examine the packets and block based on the type of communication it matches.
I don't think that SSH+SOCKS run TCP inside TCP. The TCP is unpacked on your own computer and the actual data is sent directly over SSH.
What about arp cache poisoning? Does that still work as a man-in-the-middle route traffic bypass?
That takes me back.. used to have quite a bit of fun with that in the XP days. Haven't tried it in a while for anything, but I would imagine it would attract a lot of attention.
Great Resource 🙌🏻🙌🏻
In China, we call it 翻牆 and almost every coder must learn to use it before start coding.
Because of the govt firewall?
I just set my home firewall to listen on 443, and forward via NAT to my ssh server. So in a nutshell, just set your ssh server to listen on port 443 instead of 22. It's not that complicated.
Very secure networks will close your connection after about 30 seconds, and you'll have to create a script to re-init the ssh tunnel, and close it, over and over.
Also, most networks other than maybe a work network, which still could probably be argued in court, have you agree to not access certain things via their network. If your house isn't one of those things, then technically ssh to your own home server is fair game. Where you go from home isn't technically in their jurisdiction. If their machine is only connecting to yours, then you have ground to stand on. What your machine connects to, is none of their business. But make damn sure your DNS requests are also going to and through your home machine.
Most companies now have a catch all policy that includes not using their provided computers to access XYZ sites. So at that point, you may be hosed. In the end, any admin with enough time on their hands to see that you are using port 443 for different amounts of time, or triggering a disconnect time out rule, is going to have such a hard time proving the rest, plus all the extra hassle of doing so. They're probably going to just pull you aside and say, please don't keep doing this, because eventually I'm going to have to explain it to someone and force it to stop.
I would do this almost everywhere but certainly not in a work environment - an encrypted connection to an unknown destination out of a company network is a big no (could be company secrets) - if I REALLY need access to X I will let IT know and escalate it if necessary 😊
There are also solutions like guacamole that you can run on the target machine and just serve it under a simple web service. (VNC/RDP or an ssh console)
I hadn't come across guacamole -- thanks for the recommend.
I've never had to go much further than SOCKS over an SSH tunnel on a nonstandard port to bypass poorly-monitored outgoing firewalls. Mostly useful for large businesses with many locations, who provide internet access as a perk to their customers, where individual locations rarely have a dedicated IT staff (restaurants, bars, coffee shops, department stores, salons, spas, outpatient clinics, etc.). Use with caution, and only on the isolated guest wifi, if you're stuck in a hospital and have to get actual work done.
4:34 UFW = Uncomplicated Firewall :)
Yup -- sorry for that. You are correct.
2:00 makes me wonder if you could have wired internet to a train. They have mains electricity from the electrified rail. they could have a ethernet rail for the track.
Lel
Yes, but have you got fork handles?
Great explanations. Also a light noise reduction would be amazing.
this is better than most network course labs
I guess blocking port 456 is a typo. SMTPs is on port 465 instead
Man, this seems so clever and scary to me at the same time.
its very nicely presented here.frankly this is something my school mates and I have used to check social media,in school computer lab , since it was heavyly firewalled network.
Isn't ufw "uncomplicated firewall"?
ufw is "uncomplicated firewall" not "ultimate"
Yes -- sorry. Don't know how I messed that up.
@@richardclegg8027 ultimate is kind of nice too. Thanks for the interesting video.
really liked this video, also i like richards way of explaining this stuff. :)
This gave me flashbacks to using 'cu' to hop around different machines on our LAN. ~.
the only issue here is that you have to have set up your proxies in all configurations ahead of time because you're not going to be able to get out via SSH to configure your hack. Still, interesting. I didn't know about nc!
Depends on what you are dealing with. If you have a server with ssh anyway then the first part of this using tunnels or sshuttle will "just work". Going via a web proxy won't though.
The web proxy thing wasn't explained well. If everything is blocked how do you reach the web proxy? What exactly is it? No explanation was given at all.
so where is the part that you mention VPN
It's a bit more than "cheating" in inverted commas. You manipulated the web proxy, something you typically have no access to. Better would have been to run SSH on port 443 on the twisted server.
It has become necessary (in this day and age) to change your exposed ssh port anyway in order to avoid a few thousand attempted malicious logins everyday anyway. Making ssh available on something like port 62244 keeps your auth.log from growing too large.
Actually, "Uncomplicated FireWall" - not as exciting
Closing port 22 is one of the first things I do when setting up a new install :)
It doesn't make your Security better at all... Eventually you face Problems one by one
@@president8 Certainly, but it will remain on my checklist of things to do.
The best set up is blocking every port by default, & only opening the exact ones you need, & only then when you've done your best to protect those particular ports. Eg; only opening SSH after you've created a white-list of permitted SSH source / destination sites.
@@bjarkih1977 but why at all?
@@president8 It's the most obvious place to attack for unsophisticated attacks. Also, why not?
Did anyone get the part where he talked about how to tunnel your way out of a network that only allows you to go through a proxy?
One time at work we wanted to access some site to view various things. Turns out their firewall was only plain text, using the IP address directly worked a charm
Ok mad points for the old school dot matrix printer paper.
The last element, that the attackee needs to get lucky every time, is actually a reversal of the better-accepted aphorism:
A well motivated attacker will always win, because they only need to succeed once. Defenders must win all the time.
Now for egress I can see some of the logi in the statement made by the blue team guy, but the solutions are relatively straightforward for me:
hide in plain sight
go low & slow
live off the land
ensure you only depend on things the target can't take away without committing self-harm
(Full disclosure: I'm a red teamer, not a criminal 😁)
Would not work against any next gen firewall that does application traffic matching
This was fascinating.
I'm glad he says "program" and not App...
Why? Why does it matter?
I'd say it's an app if it has GUI and interactions, but a command line "do a thing and return" like curl is a program. Ssh, ftp and similar programs are still programs even if they have interactions, though. I think.
@@mgeorgescu Maybe because nowadays everything needs to be called an App.
As a sys admin at a school I'm incredibly entertained by this.
Wish I could draw that fast in Visio.... Also sudo assumes the right access, ssh assumes the right RBAC in that environment
6:58 should have edited out that “uuum” … that would have been funny 😂
dns tunnel pretty simple to setup , I find the ssh tunnelling frys my brain half the time
The SSHawshank Redemption
Now you need a part 2: "How to hack out of a system with no Networking hardware."
Skynet would love that. And i know is possible(the spontaneous creation of life kind of possible(we are here so it is possible) or at least half way to that) though highly unlikely, like trough the electrical grid or with flicking the display on and off of the system at a camera connected to the internet.
I'd like to know this mythical machine where I want to do something *and* own it, yet somehow have not gotten permission from the owner. Every cyber security, hacker, technical person talks about either having permission or being the owner of the machines; hinting at this mythical machine or network where you can have the latter, but not the former.
He shows it in this video, block yourself, try and get around it, block yourself again etc etc.
@@sam-n9v Read my comment again, this is not a technical question but an observation about what he's literally saying as a disclaimer at the beginning.
I am saying that to be responsible my advice must be that you only do this to educate yourself about computers and not to circumvent restrictions that security professionals put in.
@@richardclegg8027 @Richard Clegg No no, not why you're saying it. *What* you're saying.
In which situation do you _not_ cover _every possible scenario_ when you qualify "only do this on a machine/network that *you have permission for* "?
In what possible state are things that you need to add "or own"?
Where is this mythical machine that *you own*, that *you wish to do things to*, and yet somehow *don't have your own permission* (not talking about user permissions; again, not a technical question) to do for?
Because you're implying the existence of such a machine or network by saying that you need to own *or* have permission. Why are you not done with "have permission"?
@@tiaxanderson9725 Oh sorry, fair enough. I'm not reading from a pre-prepared script here, it's more an interview style format so I hope you can forgive the odd stumble like that. Not as bad as getting the name of ufw wrong. That's a real *blush* moment. :-)
Netcat is not working any more in Linux.
Depends on your flavour. I think the machines here are using the latest ubuntu LTS and it is in there.
I am gonna make my school my home so I can try this.
Ah, one of the rare times someone actually learns something in school ^^
A long time ago, decades in fact, I used PPTP on hotels, because that doesn't use UDP nor TCP but instead an oddity called GRE. And in those hotels that wasn't being paywalled. And a couple times I even used tunneling via ICMP (yeah, ping payloads), there was a little Linux program for doing that.
EDIT: lol.. he mentioned ICMP at 21:00
Thank you 🙏
Cheers... off to try this on my mates computer now
Back at school we used to rdp to a home computer to get where we wanted