Exercise 1: Configuring Telnet and FTP
This lab is to demonstrate how unsecured Telnet and FTP are.
We start this by installing the FTP role on the server and the Telnet Server Feature.
Now we need to start the Telnet Server.
The next step is to copy c:\gtslabs\ftproot to c:\inetpub
Next is to change authentication methods in IIS and add an FTP Site.
After adding the FTP server changes need to be made to the firewall, we need to allow Domain Profile inbound connections.
Exercise 2: Examining Telnet Traffic
Here we monitor the Telnet traffic and look at the packets.
First, we need to turn on the Telnet client so we can actually use the service.
Now we need turn on Wireshark, then run a command
Once in I’ll have to enter my credentials and run the dir command to confirm I have access.
I faced an issue with connecting to telnet but I’ll discuss that at the end of the blog.
No matter what I tried I could not get telnet to connect to my DHCP server, this is what I faced.
I made sure my Client VM’s were getting an IP address.
Then as soon as I went to telnet connect, the IP addresses in the lease went, then so did the DHCP server…
This happens even when my VM’s restart and sit for longer than a couple of minutes.
After a battle, I found out the DHCP was causing issues with the connection between the server and the Client, so I uninstalled it and set the addresses to static but still no luck.
I can only think an issue is occurring because of previous lab configurations and I really need to start a fresh server and client.
After hours of thinking of possible solutions, I took a step back and did the following.
- Shut everything down
- Turn on the server, and a client at the same time
- Ping to Client from Server… Worked
- Pring to Server from Client..
- . Worked
- Waited for 5 minutes and tried again.. Failed
Now this made me think that there is no issue here with my VM configuration but it must have to do with a background process starting up after boot, hence the small gap where everything works.
I went and scanned all my running process, I stopped Certificate Manager… No fix… Then it was at that moment I seen it.. ‘RemoteAccess’ I right clicked and clicked disabled and well look for yourself.
So now time to connect to Telnet and run Wireshark, and capture some information!
We connected like a charm.
Now in Wireshark, I needed to find the packet ending it ‘Login’ and then once I have found that packet I need to note down the end character for the next 26 packets.
This spelled out ‘a a d d m m i i n n i i s s t t r r a a t t o o r r’ this is the Client and Server talking hence the double messages, this obviously spells out administrator, but it seems some letters got a little mixed up.
Now the password packets.
this came across a lot cleaner, which makes sense as it’s a password, this also shows how terrible Telnet is.
Exercise 3: Examining FTP Traffic
In this lab, we now use Wireshark to monitor FTP traffic.
First, we start Wireshark and then connect via FTP to the FTP Server.
Now stopping Wireshark, it’s time to check those packets.
In clear sight, we see this.
Now we need to look at the FTP-data packets, looking at these show all the information I was looking at.
This lab was such a pain in the a**…
Now it was not the lab itself but the previous lab really set me up, and not having the ability to revert changes prior to starting a new lab is a pain.
What would I do differently next time? MAKE RESTORE POINTS BEFORE EACH LAB! i’m not kidding this would save so much hassle.
If I made a restore point right at the very start, I could just keep going back to that after each lab… Why did I not think of that before… You live and learn that’s for sure.
Anyway, this Lab taught me how terrible FTP and Telnet are protecting your data, I love the fact the I.E tried to hide my data and failed so just passed my data over anyway.
Anyway, thankfully this lab is over…