{"id":314,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:19","modified_gmt":"2020-08-22T20:26:19","slug":"this-is-the-page-title-toplevel-149","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=314","title":{"rendered":"Securing the Server"},"content":{"rendered":"\nSecuring the Server<\/title>\n<p>\nA key aspect of a firewall is the <glossary>security<\/glossary>\nof the firewall itself. If it is not secure, it is comparable to locking all the doors to your\nhouse, but leaving the key under the mat. Therefore, taking the key with you, or for that matter throwing it away is a much safer alternative.\n<\/p>\n<p>\nSo what do I mean when I say “throwing away the key”? Well, what I mean is that you eliminate all\npotential routes that an intruder can use to get through the firewall or from the firewall to the\ninternal <glossary>network<\/glossary>. Granted, your <glossary>security<\/glossary> <em>should<\/em> be sufficient enough that the intruder cannot get into the firewall in the first place. However, you need to plan for that possibility.\n<\/p>\n<p>\nThe question is not whether I am too paranoid, but rather whether I am paranoid enough. To me,\nnot making the firewall machine secure is comparable to locking all the doors and writing your safe\ncombination on the wall next to it. Okay, the house is secure, but <i>should<\/i> someone break in,\nthey have free run of all your valuables.\n<\/p>\n<p>\nSo, let’s first talk about locking the doors.\n<\/p>\n<p>\nThe purpose of your Internet <glossary>gateway<\/glossary>\nis to provide a gateway to the Internet. Sounds simple enough, but what that means is not always\nclear. The question you need to answer is “What is the purpose of the Internet connection?” The\nanswer to which will define what steps you take to secure the firewall.\n<\/p>\n<p>\nFor example, let’s assume that you have a Internet connection so that your employees can connect\nto the Internet, but do not provide any services yourself. In this case, you do not need to enable\nservices <i>on the firewall<\/i> such as <glossary>FTP<\/glossary> or <glossary>HTTP<\/glossary>. All that happens is\npackets are routed through the firewall. Therefore, you can remove the <glossary term=\"daemon\">daemons<\/glossary> themselves (i.e.\n<command>telnetd<\/command>, <command>ftpd<\/command>, <command>httpd<\/command>, etc) and the programs (<command>telnet<\/command>, <command>ftp<\/command>, etc.). To simply disable them, place a\npound sign in front of the appropriate entry in <file type=\"\">\/etc\/services<\/file>.\n<\/p>\n<p>\nThis is where a lot of controversy occurs. In a article I wrote for a number of years ago, I describe the\nprocedures as “throwing away the key”, in that the programs and daemons were physically removed\nfrom the machine. Some people disagree and say to move them to a place that the normal user would\nnot have access to. The reason being the difficultly in administering the system should these\nprograms be needed.\n<\/p>\n<p>\nDespite the respect I have for their technical capabilities, I have to disagree with him on this\npoint. Although he is correct that it does make the administration more difficult, there are two\nimportant <glossary>security<\/glossary> issues involved. First it makes hacking more difficult. If\nthese programs are not on the machine, they <i>cannot<\/i> be compromised. You have, in essence, thrown away the key.\n<\/p>\n<concept id=\"\" description=\"Simply renaming 'dangerous' programs like telnet does not fool an attacker.\" \/>\n<p>\nThe other issue is that hackers are <i>not<\/i> normal users. They are sneaky, plodding and\npatient. Maybe you have hidden the file on the system, but a good hacker isn’t thwarted by such\nsimple tricks. I wouldn’t be and I am not even a good one. If a program was not in it’s original\nlocation, the first thing I would do is to see if it was anywhere on the system. I have seen\nadministrators simple rename the file to something like telnet.orig so simply starting <command>telnet<\/command>, does nothing. However, if the machine is compromised, an attacker would not be fooled.\n<\/p>\n<concept id=\"\" description=\"It is better to err on the side of inconvenience than on the side of security.\" \/>\n<p>\nMy attitude is that it is better to err on the side of inconvenience than on <glossary>security<\/glossary>.\nIf you discover that access is too inconvenient, you can always change it. However, if you discover that the security is too relaxed, it’s too late.\n<\/p>\n<p>\nI apply this same attitude when it comes to the services that I make available. If you remember\nfor the networking chapter, the available services are defined in <file type=\"\">\/etc\/services<\/file>. My suggestion is\nto first comment out <i>every<\/i> service. Then, one-by-one, uncomment those that you want. Yes, you\nmay forget one and cause a certain amount of inconvenience. However, doing it this way you know\nexactly what services you are enabling. If your forget to enable one, you have inconvenienced\nsomeone. If you do it the other way, by disabling the ones you do not want, if forget to disable\none, you may have let the would-be hacker into your system.\n<\/p>\n<p>\nI believe that which <glossary term=\"port\">ports<\/glossary> are opened should not necessarily simply the whim of the network administrator. Instead, it should be part of the company’s official policy.\n<\/p>\n<concept id=\"\" description=\"It is a good security practice to first disable all services than add the ones you absolutely need.\" \/>\n<p>\nAnother means of securing your system is to limit access to the machine. There is, of course, the\nissue of the physical <glossary>security<\/glossary> of the machine. If someone has physical access\nto your firewall all the <glossary>network<\/glossary> security in the world is of little value.\n<\/p>\n<p>\nWhat you turn on depends on what your needs are. For example, if you ware providing <glossary>FTP<\/glossary> and\n<glossary>HTTP<\/glossary> services these two entries should be uncommented. (Note this assumes that\n<command>httpd<\/command> is running from <command>inetd<\/command> and is not stand-alone). I would definitely say that on the firewall,\nyou should <i>not<\/i> uncomment <command>netstat<\/command>, <command>systat<\/command>, <command>tftp<\/command>, <command>bootp<\/command>, <command>finger<\/command>, and <command>ntp<\/command>. There is no reason\nthat I have ever heard of to make these services available across the Internet. Personally, I think\nyou should also leave out telnet and <glossary>login<\/glossary> (for rlogin). The key is to only give what you <i>have<\/i> to. If you are going to provide remote login access to your system <command>ssh<\/command> is a much better idea.\n<\/p>\n<p>\nTo set this all up there needs to be a couple of changes in the <glossary>kernel<\/glossary>. Obviously, the basic networking functionality needs to be turned on, but there are two other\noptions that you will find useful. The first is IP_FORWARDING. This needs to be turned <i>off<\/i> so that packets are not passed through the firewall.\n<\/p>\n<p>\nThe next is IP_FIREWALLING. This is necessary for the basic firewall functionality. If you want\nto keep track of the <glossary>IP<\/glossary> packets, then you need to turn on IP accounting. I\nrecommend doing this because it allows you to keep track of from where the packets are coming and\nwhere they are going.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What is 'IP masquerading'?\" \/>\n<p>\nAnother concept is the idea of <glossary>IP masquerading<\/glossary> . With this enabled, the internal <glossary>network<\/glossary>\nis “invisible” to the rest of the world. What happens is the firewall server converts the IP\naddresses so that machines on the Internet think they are communicating with the firewall and not\nan internal machine. You can then assign IP <glossary>address<\/glossary> to your internal network\nthat reside with the private ranges as defined by <glossary>RFC<\/glossary> 1918. IP_FIREWALLING must\nbe enabled for this to work.\n<\/p>\n<p>\nIf you plan to use your firewall as springboard, then the configuration is basically complete.\nHowever, if you are planning to go from your workstations through the firewall, then there is more\nthat you need to do do. This is where the concept of a <glossary>proxy<\/glossary> comes in.\n<\/p>\n<p>\nThere are currently two well known proxy packages available for Linux. The first is “socks”,\nwhich operates as a full proxy and can work with any program. There is a single configuration file\nand a single <glossary>daemon<\/glossary> that need to be configured.\n<\/p>\n<p>\nThe other is the TIS firewall toolkit, which requires a new version of each <glossary>daemon<\/glossary>\nthat will be going through the firewall. If you do not want users to have access to a particular\nservice, then you just don’t provide them with the necessary programs. However, with socks, it is easier to unintentionally allow access.\n<\/p>\n<p>\nAlthough not really a firewall, the <glossary>TCP<\/glossary>\nWrapper program can be used to control access to and from a <i>specific<\/i> machine. That is, it\nmust be installed on each machine individually. In contrast, a firewall works for all machines that are trying to get passed it to the Internet.\n<\/p>\n<p>\nThe socks proxy server is available on many of the newer distributions. If you don’t have it you\ncan get as a gzipped tar archive from\n<a href=\"ftp:\/\/sunsite.unc.edu\/pub\/Linux\/system\/Network\/misc\/socks-linux-src.tgz\">ftp:\/\/sunsite.unc.edu\/pub\/Linux\/system\/Network\/misc\/socks-linux-src.tgz.<\/a>\n<\/p>\n<p>\nIt is here that we have come to the point where we have locked the door and put “The Club” into\nour steering wheel. The Firewall <glossary>HOWTO<\/glossary> goes into details of the actual\nconfiguration of the proxy server and the associated files.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Securing the Server A key aspect of a firewall is the security of the firewall itself. If it is not secure, it is comparable to locking all the doors to your house, but leaving the key under the mat. Therefore, … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=314\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-314","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/314","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=314"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/314\/revisions"}],"predecessor-version":[{"id":691,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/314\/revisions\/691"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}