In a previous video I shared some tools that I've found useful as an IT professional, in case
it might be helpful to you as well. You liked it... but you wanted more. Alright. Have some more!
Welcome back to The Pro Tech Show. I will link the original video in the description
in case you haven't seen that one, yet. Please drop your suggestions in the comments as well.
There are definitely a few that you mentioned last time around that are going to feature in this one,
and I'm still liking the idea of a viewers' suggestions video. Without further ado, let's reveal
the first tool; and it's... well it's not actually a specific tool, and more a feature of several tools.
SSH Tunnelling. This lets you redirect network ports securely inside your SSH connection -
making it double a bit as a sort of VPN and allowing you to get around firewalls. Let me show
you a couple of interesting use cases. For this we'll need a lab, so here's one I made earlier. My
computer is here in the blue network. The blue network has IP addresses starting with 172.
I have a Windows server in the green network. The green network has IP addresses starting with 10.
Straddling both networks we have a Linux server. It has network interfaces in both the blue and green
networks, but it's not rooting between them. The IP address of my Windows server is 10.10.10.10 but I
can't ping it or remote desktop to it because there's no connectivity between blue and green.
I can use SSH to connect to Linux server on its blue address starting with 172,
so let's do that. The Linux server also has an interface on the green network so it can ping that
Windows server on 10.10.10.10. When I connect my SSH session you might have noticed it said
something about a web console. I've got Cockpit running on the server, so let's connect to it.
What's this? It doesn't work? No, because the firewall's blocking it. If I show
you the enabled services it isn't there. Let's log out and start again.
I'm going to add another parameter to my SSH command: "-L" followed by a port number, a network
address, and another port number. You can also do this in other SSH clients. In Putty for example
you'd find it in the "SSH" section under "Connection" then "Tunnels". Our first port number is the source
port, and the network address and port number that follows are the destination. For the source port
I'm using 443, which is the standard port for HTTPS. For the destination address I'll use localhost,
and for the destination port I'll use 9090, which is the standard port for Cockpit. Let's
connect our SSH session. Now let's talk about what that additional information I entered about the
network ports did. I told the SSH client to bind to port 443 (that's HTTPS) on my computer. I also
told it to tunnel traffic from that port over my SSH connection to the Linux server and just spit
it out the other end at localhost 9090. Localhost from the context of the Linux server is the Linux
server. 9090 is the port Cockpit is running on. So now if I go to HTTPS localhost on my computer I'm
connected to Cockpit! The firewall isn't getting in the way because I've tunnelled my traffic through
it, and it's actually connecting from the other side of my SSH session inside the Linux server.
It's kind of like magic. Let's do another one; this time from Putty. I'll choose 1234 as
the source port and I'll set the destination to 10.10.10.10. port 3389. 10.10.10.10
you'll recognise is my Windows server in the green network. This time once I've connected my session,
Putty will bind to port 1234 on my computer, redirect it over SSH to the Linux server, and
then fire the traffic from the Linux server at my Windows server on 10.10.10.10, using the
remote desktop port 3389. Temember the traffic is popping out the other end of this tunnel on
the Linux server; and although my computer can't connect to the Windows server the Linux one can.
I will now attempt to open a remote desktop session to localhost on port 1234. Normally this
would be a silly thing to do. It's the wrong port number and why would I want to connect a remote
desktop session to myself? Because of SSH magic this connection not only works but it connects
me to the Windows server in the green network that my computer in the blue network can't actually
talk to itself. This functionality is pretty cool because it lets you tunnel through the firewall
using an encrypted connection similar to a VPN I can access Cockpit without dropping the firewall.
This can be handy to use the tools you have installed on your administrative workstation
to access services on the Linux server that aren't exposed through its firewall.
Like maybe you've installed Elastic Stack and the only thing opened up is Kibana
but you want to send commands to ElasticSearch; or you want to connect a SQL database but SQL isn't
allowed through the firewall. As you've seen, it's not limited to local ports in the Linux server
and can be used as a remote access mechanism to traverse network segments and talk to anything
the Linux server can talk to - making it a very handy trick to have in your arsenal. The next tool
is... well, it's a file. A very specific file called the EICAR anti malware testfile. You can download
it from the EICAR website. That's European Institute for Computer Anti-Virus Research.
It's just made up of plain text characters, though; so you can create it in notepad as well.
It is actually a valid executable file in the 16-bit DOS world from many, many years ago.
It won't run on a modern 64-bit system. Let's create it in Notepad, though; and save it.
Surely a bit of text couldn't do any harm... oh. Windows Defender did not like that. No antivirus will
like it. So how dangerous is it? It's perfectly safe, and that's the point. It's perfectly safe
but every anti-malware program should treat it as a virus. It's an industry standard fake virus
that you can use to test anti-malware products to ensure they're functioning correctly. Without this
you might have to resort to using actual malware, and that would be dangerous. Want to check if your
malware reporting is working? Drop an EICAR testfile on an endpoint and see if your security team
get an alert. Want to check if an email filter is working? Attach an EICAR testfile to an email.
Much safer than emailing someone an actual virus, because if you've worked with users you know that
if that filter isn't working they will definitely open the attachment! Moving on, the next tool I
want to share is WinSCP. This is a remote file management tool that is particularly handy for
managing files on Linux servers from Windows. Linux servers tend to be command-line only
and Windows admins prefer graphical tools, so a graphical tool to manage Linux files from Windows
is a handy little thing to have. Despite the name, it is not just an SCP client. It supports FTP, FTPS,
SCP, SFTP, WebDAV, and Amazon S3 file transfer protocols. In fact it defaults to SFTP, not SCP.
If you can connect using SSH it's a good sign you'll probably be able to use WinSCP to manage
files remotely. So if you need a way to drag and drop between Windows and Linux look no further.
It's also handy for configuration changes because most applications in Linux use text-based config
files, and you can open them in a graphical text editor, change them, save them, and move on with your
life without learning to use VIM or Emacs. I mean you probably should learn to edit text files from
the command line if you're going to be using Linux; but if you're a Windows admin you can stay largely
within your comfort zone with WinSCP. The next tool I want to share is Chrome's dev tools. I say
"Chrome", but this works in other Chromium browsers like Edge as well. You bring this up by hitting F12
and there are a ton of things you can do with it. I'm only going to show you a few but you can get...
creative. Let's try something silly, first. I'm going to go to YouTube and see if Vimeo have
a YouTube channel. That would be kinda weird but also... I bet they do. Yeah, there we go. OK, stop the
trailer because I don't want a copyright strike, hit F12 to open DevTools, use the element selector
to click on the bit we want to change, and you can see the HTML source pops up in the right-hand
with that part selected. Now I'll hit "delete", and it's gone. Let's make another change.
I think it's funny that Vimeo has a YouTube channel, so let's reflect that in the channel name.
Now, I'm just being silly here and just so we're clear I'm not actually defacing YouTube.
I'm defacing the page displayed in my browser, only. If I refresh, all the changes are gone.
The ability to live edit the client-side version of a page in your browser can be useful to get
around issues with badly coded sites, or to get rid of silly pop-ups that block your view, or make
read-only fields editable. You're not hacking, but sometimes you can use this to get around mistakes -
particularly in legacy systems that don't work properly in modern browsers. I've done this several
times with janky old network devices or printers when I needed to make a change but the web UI was
coded for Internet Explorer 6. Open DevTools, edit the page just enough to work, and you can
submit the form. Where I'll more often use DevTools though, is on the network tab to inspect traffic.
Here you can see all the files that my browser has requested, the server's status response, and
the time it took to receive them. This information is useful to troubleshoot web applications
that aren't working properly because you can see which requests failed or were slow to respond.
If you want more detail we can click on them to see actual requests and responses in plain text.
This stuff is encrypted on the network but because we're doing this inside the browser it can show us
the unencrypted data. I can see my browser's request and the server's response headers.
If I click on the response tab I can see the full body of the response, and we can see any errors
that occurred down at the bottom. This is obviously great for troubleshooting a web application but
it's also really handy for pesky authentication problems. Maybe you're using Windows authentication and
it's not working. When you look at the headers you can see that the server is offering Kerberos
but the client will only respond with NTLM. I'm not going to turn this into a DevTools tutorial
but given how many applications are now web-based I think you can probably appreciate how being able
to get detailed information on and tweak the data between client and server could be a really useful
troubleshooting tool. But what if it's not a web browser? Sure, a lot of apps are now web-based; but
web-based are not, absolutely tons are using web APIs to transfer their data. Can you use DevTools
for this? No. It only works in the browser. It can't intercept arbitrary data on the network and if it
could then it wouldn't matter because it would almost certainly be encrypted anyway. For that
you'll need a different tool. For that you'll need Fiddler. Fiddler does a similar job to Chrome's
DevTools in that it lets you inspect and tweak web traffic; but it does it for any application on
your computer. In fact you can even point other devices at it as well, so you can capture the
traffic from something else. The way it works is it registers itself as your system proxy.
Applications will then send their traffic to Fiddler to be forwarded on. If you want
to capture traffic from outside your computer you can configure Fiddler to allow remote computers to
connect to it in the options, then add it as their explicit proxy. This is fine for plain old HTTP but
let's face it these days everything is encrypted. So how can Fiddler actually decrypt the traffic?
Basically... it performs a man-in-the-middle attack. You go to "Tools", "Options" "HTTPS" tab,
and tick the box to "Decrypt HTTPS traffic". Fiddler will prompt you to install a certificate into the
trusted root certification authorities store. It then decrypts your traffic and re-encrypts it using a
spoofed certificate that it signs itself using the root certificate that it asked you to trust. Every
website you visit will appear to your browser to have a certificate signed by Fiddler. If you
want to do this for traffic coming from a device other than your computer you'll need to export
that root certificate and import it as a trusted certificate authority on that device as well. Once
you've done that you can use your applications as normal and all of the web traffic gets logged
in Fiddler. You can see the requests and the responses, timings and delays, headers, full data:
similar to what I showed you with the Chrome DevTools. The key difference being of course that this
works for any application on your computer. A large portion of applications that act as a client to a
server somewhere elsewhere will be using HTTP-based APIs and their traffic will show up in Fiddler -
more often than not as human readable text in JSON or XML form. You might be surprised at
just how many applications are making API calls to services out on the internet. OK, so DevTools: easy
but limited to a browser. Fiddler: a bit more effort but works with anything that accesses a web API.
What about network traffic that isn't HTTP-based, though? You're not going to find the answer here
at layer 7. Instead, you need to take the stairs down to layer 4. For that you can use Wireshark.
Wireshark is a packet analyser. Sometimes called a packet sniffer or a network sniffer.
It captures the raw network traffic and displays it to you. For some protocols you
can actually read the data in plain text but for anything encrypted it's going to be gobbledygook.
The raw data can be intimidating at first but Wireshark does a pretty good job of
laying it out for you and grouping conversations together so you can see what's going on.
With a bit of network knowledge you can start to make sense of it; and even if you can't read the
data you can see who's talking to what, if it's succeeding, where it's breaking down, and so on.
Let's jump back to our lab from before and I'll try to connect to Cockpit from our Windows server
First, though; I'll start Wireshark but filter it so it only captures packets sent to the Cockpit
network port 9090. Nothing here so now let's try to connect to Cockpit. In Wireshark we can
see a couple of packets going out and nothing returning. Then we see some re-transmissions
with the same sequence number, that Wireshark helpfully highlights for us in a different colour.
That's the TCP protocol trying again because it didn't get any acknowledgement back.
Maybe the first packet got lost so it sends another. Incidentally, that's also one of the
major differences between TCP and UDP. UDP is fire and forget. TCP waits for an acknowledgement so it
knows all the data is delivered. The reason this didn't work is because our firewall is blocking it.
Let's allow Cockpit through the firewall and see what happens. This looks a lot different. You can
see that immediately after the packet heading out you can see an acknowledgement coming back.
This time there are no re-transmissions. You can also see it start negotiating an
encrypted connection using TLS 1.3. We're not going to be able to see the data inside this
encrypted connection... well, actually, we can see it but it's not going to make any sense.
We can see that a healthy network conversation is taking place, though;
and both sides are talking to each other using TLS 1.3. If they weren't able to connect to each other,
or weren't able to agree on an encryption protocol or cipher suite, then we'd be able to see that in
Wireshark. As a general rule if I've had to open Wireshark I'm probably not having a good day;
but the number of times I've opened it, stared at it for a minute, and suddenly had that light bulb
moment. Ah! That's what it's doing! Definitely a tool to keep in your virtual bag. It's useful.
You know what else is useful? Clicking the like button; because it tells YouTube this video is
worth showing to someone else, and that means you might just save someone's day by clicking it.
You're a genuine internet superhero! Don't forget to let me know about any tips or useful tools
you recommend, or any creative uses you've found for the ones I've mentioned in this video.
And if you haven't seen the first video in this series then check the description for the link.
Thanks for watching, guys and if you haven't subscribed then remember to click the button,
ring the bell, blah blah blah, all the YouTube things and maybe click on one of these videos
if they look interesting to you. Thanks for stopping by. I'll see you next time!