Saturday, January 9, 2016

Week 16: Day 045 - TCP/IP Applications #3


Hello everybody, today we're gonna continue Network+. I was never actually able to finish this blog post before Winter Break, but this is what I typed before leaving for break: "Just today and tomorrow until break. My plans are to watch Star Wars: The Force Awakens on the 22nd (big fan of Star Wars) with my friends, and then do the routine Christmas activities. In addition to that, on the 29th, I'm gonna come back here with Marco and learn some Python with Mr. Kevin Cole. Can't wait!, let's get started." We never actually came back to the Career Center during break, since the building's open hours were a bit dodgy I guess. One thing I'll be happy to repeat though is, "let's get started"!

I read the stuff that I didn't go over last class, (Note To Self: it was really useful, so read it again, future version of myself!) so I'm good on that. Now it's time to talk about the TCP/IP Applications themselves. Let's start with the World Wide Web. Many would be inclined to say that the Internet = The Web. However, this is a common fallacy, that is not true at all. The Internet supports the Web but it is not the web. The Web is comprised of servers which store documents using hypertext Markup Language (HTML). HTML has been around for quite a while, but it has been updated several times. The latest version of HTML is HTML 5. What web browsers do is request HTML pages from the Web servers, so when they receive them, they open them. When you enter http:// and the IP address of the Web server, it will access the web page. No one does that though haha. Doing text addresses like "google.com" is much easier. As I already know the default port for HTML is port 80 for TCP. However, it's kind of annoying that it doesn't take into account your previous "commands", although there's several applications that take care of that (Ex: Google Chrome will auto-complete your addresses sometimes, based on previous addresses)

When you've finished designing your HTML document, you can share it with the World Wide Web. You can install a Web server into your computer, my friend Marco has done that. Then you'll need to get a public IP address for the computer, and host the web site yourself. However, you could also pay a company to host your web page. There's free web hosts out there, but there are limitations such as ads, and a domain with their companies in it. However, if you wanna get a domain for your website, you may. They typically charge $10 a month (Google lets you get a domain host for $10 a year :D) Now let's dive into what a Web Server is at its core.

What a Web Server is at its core, is a computer which serves Web pages. They will listen on port 80, and fetch the HTML pages that were given to it, and send them off to browsers asking for it. You can run a Web server on any computer, but you'll need to install server software to connect it to the Internet. Microsoft wants people to use their software "Internet Information Services" (IIS). What IIS does, is that it lets you set a connection limit based on bandwidth and memory. This is meant for protecting your network against a malicious attack like a "Denial of Service" (DoS) attack. On Linux the popular option is "Apache HTTP Server" which my friend Marco is using. It serves over 50% of Web sites on the Internet as of 2012. It's so popular not only cause it runs on several operating systems, but also cause it's free! In comparison, Microsoft's  IIS only has 25% of the market share. Apache isn't much, just an executable program with text files. To make it easier, Web admins get add-on graphical user interfaces (GUIs) to make it easier. In third place there's Google Web Server (GWS) which is only really used by Google servers, and has 5% of the market share of Websites. Then web clients are just the programs used to surf the web, a web browser (Ex: Google Chrome, Internet Explorer, Firefox.)

Now let's be clear here, HTTP is not a secure protocol. Any nosy eavesdropper can plug into the network and read the HTTP packets going around. Fake web sites can be used to trick people and steal user names and passwords. For an internet application to be secure it needs:

- Authentication: Usernames and Passwords
- Encryption: Mixing up data so it's unreadable
- Nonrepudiation: Source cannot deny a sent message

The secure counterpart to HTTP is HTTPS which is already something major. Since so many people use the web, it's important to have security. One safeguard is called Secure Sockets Layer (SSL), which is a protocol by Netscape which transmits private docs over the internet. All popular browsers and web sites support SSL. In recent years, SSL has been slowly replaced by Transport Layer Security (TLS) which keeps the same look on your webpage as if it were SSL, and functions the same way, the only difference is that TLS is more secure.

About 40 years ago, the Internet was full of huge computers known as mainframes which were accessed by a terminal (like in the Fallout series.) Operating systems were made up of a simple command line, as the GUI did not exist then. People became lazy and wanted to access the other terminals from their's, so they figured out how to do it. This gave birth to "Telnet" the first network variation on planet Earth. With telnet you can connect to another system from your own terminal using the command line. This still exists today in the variation of ssh. What is that? Well, I've used it before thanks to Marco, it's called "Secure Shell" (SSH) which is basically modern day Telnet, only major difference being encryption. Routers nevertheless still have the ability of using Telnet. The oldest Telnet servers are from UNIX and Linux systems. However the old "telnetd" isn't as important as the Windows version of Telnet. In Windows, telnet is by default disabled as it is as we established, a security threat. As you can see telnet is pretty much gone because of its security fallacies, so you'll find that SSH is the dominant remote protocol service of today.

The Telnet client is the computer which is logging into the remote server. You'll be able to run telnet from the command prompt or terminal, depending on which OS you're on. To activate Telnet on Ubuntu Linux, open terminal and type "telnet (IP of system you want to access)" and it will work. The command-prompt version lacks features, so you'd be better off using PuTTY. Now in terms of configuring the client, you need to give the host name, the user login name and password of the system you're trying to access. You need to have permission of the server when performing these processes. Usually you'll see Telnet used in libraries, since they don't require much internet security.

The Network+ exam will test you on rlogin, RSH, and RCP. There programs from UNIX. The R stands for "remote", and as you can figure these programs let you access other systems remotely.  However, also expected, they don't encrypt data. Here's a summary given by the book:

- Remote Login (rlogin): Works similarly to Telnet. You run the program with the host name of the server, and you connect and run commands like Telnet. Rlogin has an advantage over Telnet, as it can configure it to log in automatically without entering a username and password. It connectes only to UNIX hosts, unlike Telnet. This works over the TCP port 513.

- Remote Shell (RSH): Enables you to send single commands to remote server. Unlike rlogin, which is designed to be used interactively, RSH can be integrated into a script. RSH runs on TCP port 514.

- Remote Copy Protocol (RCP): Provides capability to copy files from and to remote server without needing FTP or NFS (Network File System, UNIX folder sharing system). RCP can also be used in scripts and shares TCP port 514 with RSH.

In conclusion, Telnet has been used for a long time in the TCP world, but because of its lack of security, it's pretty much died and been replaced with SSH. One thing to remember is that SSH uses TCP port 22 while Telnet's port is TCP 23. Next time we'll finish up the chapter, in standard blog format, and afterwards I'll be only doing Chapter Overviews, and perhaps end of the chapter questions. Thanks for reading and goodbye!

Completion Status: 45%
Pages Left:
- Book: 375 pages
- Chapter: 9 pages


No comments:

Post a Comment