Website hosting mac, affordable, php5, plesk - linux experts blog

Firewalls iptables Important This section is a brief introduction to setting up customized security beyond what is possible with the GUI tools provided by Red Hat. It’s not meant to be comprehensive, as everyone’s needs are different, and it’d be impossible to cater to them all. However, hopefully it’ll give you a taste of the tools available. Blocking and allowing traffic based on direction (i.e. incoming or outgoing) and port number gives some degree of control over network traffic, but there are situations when we need finer control. For example, we may want to run a Web server that can be accessed only from machines within our department, and not from machines elsewhere. Or we may want to prevent users on certain machines from being able to FTP files from our machine while allowing others to do so. The firewalling code in Red Hat Linux 9 is perfectly able to cope with these situations, and far more complex ones, but we have to roll up our sleeves and configure it from the command line. This is where the iptables command comes in. It is used to manipulate the kernel’s packet filtering tables, so we can fine tune the firewall settings to our environment. Let’s see how to implement a concrete example. Imagine our Red Hat machine has two network interfaces: eth0 has the IP address 192.168.1.1 and eth1 has the IP address 192.168.10.1. Both interfaces have netmasks of 255.255.255.0. We’re running a Web server listening on port 80, and an FTP server that uses ports 20 and 21. We need to allow machines with IP addresses starting with 192.168.10 access to the Web server, but nobody else. We also need to allow all machines in the 192.168.1.0 network access to the FTP server, except 192.168.1.57. How do we configure this? The first thing to do is look at the existing firewall configuration. Log on to the machine and switch to the root user. Run the following command to get a verbose listing of the current firewall rules: # iptables -L -v Rules are grouped together into chains. There are three default chains: INPUT, which handles incoming network packets destined for processes on the local machine OUTPUT, which handles outgoing network packets produced by the local machine FORWARD, which handles packets that arrive on one interface and leave on another (i.e. the local machine is forwarding them). There may be other user defined chains too. To set up our machine to meet the above specification, we’ll clear out (or flush) the existing rules with the following command: # iptables -F Note We can use this command to delete the named user-defined chain: # iptables -X name We’re going to be dealing only with packets coming into our machine in this example, so we’ll be configuring rules in the INPUT chain. Our first step is to configure the default behaviors - or Policy - for the INPUT chain so that if it receives a packet that doesn’t match any rules, it drops (discards) it. This is the most security conscious approach, as it means that everything is blocked unless we explicitly allow it. The command to set 429
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services

Firewalls When we press the OK button, the firewall configuration is updated and saved so that the machine will reboot with the new configuration in place. Lokkit There is another tool that we can use to configure the firewall on our Red Hat Linux systems. It’s called Lokkit (installed from the gnome-lokkit RPM). It is a simple to use configuration tool that asks a series of simple questions and configures the firewall according to the answers you supply. It’s not as versatile or powerful as the method we’ve just discussed, so we’ll make no more mention of it here. Note Note that Lokkit is not meant for custom firewall configuration and has fewer options than the Red Hat redhat-config-securitylevel tool. There is one significant drawback with using the Security Level Configuration or Lokkit applications to configure our packet filtering firewall; both configure only rules that selectively block incoming network traffic. Outgoing traffic and traffic that is forwarded (that is received on one network interface and sent out on another) by our Red Hat system are not checked in any way. This means that, should you have a system behind your firewall that has been compromised (hacked or maybe infected by a virus), it is free to transmit whatever it likes through your firewall. It is a good idea to configure your firewall to block selected outgoing and forwarded traffic too. For example, you may want to force all Internet access for machines behind the firewall to be handled by secure proxy servers. This can be done by blocking outgoing Internet access for all machines except the proxy servers. More detailed firewall configuration like this is done with the iptables command, so let’s look at how to do that. 428
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services

Firewalls say, port 8080. If we select No firewall as the security level, then the firewall is disabled. If we find that the default firewall rules do not meet our requirements, then we can select the Customize radio button. This enables the remaining options on the window: If we check the box against a network interface in the Trusted devices section, this configures the firewall to allow all traffic to and from that interface (because we trust all the machines connecting via that interface). However, can we be sure that one of these machines has not been compromised and that the packets coming from it are the work of a hacker? The other options on the dialogue enable us to allow incoming connections on a selection of well-known ports for different services. For example, let’s pretend that our example machine will be running a Web server, and we’ll need remote access via ssh for administration, so the WWW and SSH boxes need to be checked. This ends up looking like this: 427

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Sandzak jsp web hosting provider

Firewalls SYN, SYN+ACK, ACK packets at the start of the connection, but with UDP, there is no connection, so incoming and outgoing simply refer to the direction of the packet. Configuring the Red Hat Linux Firewall Configuring the Red Hat Linux firewall is very straightforward. Start the Security Level Configuration application by choosing Main Menu | System Settings | Security Level, or by typing redhat-config-securitylevel at the command prompt. If you are not logged on as root, and you haven’t recently supplied the root password to enable you to update system wide settings, you’ll be prompted to do that before the Security Level Configuration starts. When it does, you’ll see this window. Under the Security Level: drop-down list, the options are High, Medium, and No firewall: The High setting configures the firewall to reject all incoming TCP connections (by blocking TCP packets that have the SYN flag set, and ACK cleared), and reject all incoming UDP packets, with the exception of replies to DNS queries on port 53 that come from the name servers we told Red Hat Linux about when we configured the network settings. (If the DNS replies were blocked, then we would be unable to resolve any host names that aren’t defined in the local /etc/hosts file, which would make using the Internet very tedious.) Important Note that, since incoming connections are blocked, we can’t run a Web server or any other kind of server behind such a firewall. The Medium setting configures the firewall to reject all incoming TCP connections to ports in the range 0 to 1023, and also incoming UDP packets for these port numbers. NFS and X11 traffic are also blocked. The significance of the ports in the range 0 to 1023 is that these are “privileged” ports, and a program has to be running with root authority in order to open sockets on them. However, this does not mean that ports with numbers 1024 to 65536 can only have unprivileged programs opening sockets on them. It is quite possible to set up a Web server running with root authority listening on, 426

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Sandzak jsp web hosting provider

Firewalls Firewalls Firewalls are another useful tool for improving the security of our system. They come in different flavors, but all do essentially the same thing; network traffic passing through the firewall is analyzed and the decision about what to do with the traffic (let it through, throw it away and tell the sender, throw it away and don’t tell the sender, etc.) is made based on the rules configured by the firewall administrator. Some firewalls analyze network traffic at the packet level; these are called “packet filters”. They can work with any network traffic, but can implement only fairly simple rules based on the contents of the packet header (typically where the packet came from, where it’s going to and what flags are set). Other firewalls understand more about the higher level protocols used for e-mail and web browsing. They can perform more complex tasks such as scanning e-mail attachments for viruses, or requiring users to authenticate themselves before allowing access to certain Web sites. In a typical corporate environment, the protection provided by simple packet filtering firewalls is enhanced with more sophisticated firewalls and proxies that can analyze the contents of the packets as well as their headers. Since the Linux kernel has built in packet filtering capabilities, we’ll look at how we can configure these to enhance the security of our Red Hat Linux system. Network Connections Before we get into the mechanics of configuring the Red Hat Linux built in firewall, we need to understand how network connections work. For TCP/IP connections, there are two basic protocols; TCP (Transmission Control Protocol) and UDP (Universal Datagram Protocol). TCP is a connection-oriented protocol. This means that when two machines wish to communicate via TCP, their TCP stacks negotiate a connection and the application (such as a Web browser talking to Web server using HTTP), and TCP ensures that packets are delivered to the application in the right order, with no duplicates. The mechanism for setting up a connection involves the exchange of TCP packets between the systems that have different flags set in their headers. First, the client (that’s the machine that wants to establish a connection) sends the server (the machine the client wants to connect to) a TCP packet with the SYN flag set. The server replies with a packet whose header has both the SYN and ACK flags set, and when the client receives this packet, it sends one back with just the ACK bit set. From this point on, the connection is established, and the client and server can exchange packets. When the connection is no longer required, either party can request that it is closed by sending the other end a TCP packet with the FIN flag set. The recipient replies with a packet having the ACK flag set, then performs whatever termination steps are required by the application. When this is done, a packet with the FIN flag set is sent back to the end that initially requested the connection to be closed. When this is acknowledged with a packet where the ACK bit is set, the connection is finished. UDP is a much simpler, connection-less protocol. All that happens here is that the originator sends the UDP datagram to the recipient, and the network layer tries its best to deliver it. Unlike TCP, delivery is not guaranteed, and datagrams traveling over long distances may go by different routes and therefore arrive out of order at the other end. All the logic for synchronizing client and server, or re-trying failed packets, has to be handled by the application code. It is important that we understand the differences between TCP and UDP when configuring firewalls. With TCP, the direction of the connection (i.e. incoming, where the client is remote and the server is on our machine, or outgoing where the client is local and the server is remote) is determined by the exchange of 425
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

Network Services With the options chosen in the example capture window, the main display is also updated in real time: This example shows the start of an ssh session between two machines. This time, we won’t be seeing any plain text passwords! The point of showing tcpdump and ethereal is not to encourage you to go sniffing for packets on networks, but rather to illustrate just how easy it is to capture sensitive information such as passwords that are sent across broadcast networks, such as Ethernet. However, if you make sure that you use protocols such as ssh and sftp that encrypt sensitive data, then it won’t matter if someone is capturing the packets you send. 424
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

Network Services 0×0020 5010 16d0 1416 0000 0d0a 0869 6e3a P……….in: 12:12:03.699442 fred.3335 > bob.telnet: tcp 1 (DF) 0×0000 4500 0029 4e7b 4000 8006 1649 0a04 4101 E..)N{@….I..A. 0×0010 0a04 4102 0d07 0017 24e6 7471 f267 5606 ..A…..$.tq.gV. 0×0020 5018 21a8 a534 0000 6420 2020 2020 P.!..4..d….. This is what we mean when we say that the telnet protocol sends passwords in plain text across the network. If that network uses broadcast media, then every machine on the same network segment as the sender receives the unencrypted password on its network interface. Most of the time, the other machines will just ignore this data, but all it takes is one of them to be running a promiscuous mode packet logger like tcpdump and all the passwords sent by telnet can be captured. Ftp suffers from a similar vulnerability. Fortunately, there are secure alternatives to both telnet and ftp (ssh and sftp respectively) that encrypt all data they send over the network using strong encryption techniques so the eavesdropper is not able to glean any useful information from the packets. Another packet analyzer that can be installed from the Red Hat Linux 9 CDs is called Ethereal. This has a graphical front end that makes it much easier to set up filters and interpret the contents of packets. When Ethereal is started (as root, by simply typing ethereal at the command prompt - once the Ethereal RPM has been installed, of course!), the main window opens. The Capture | Start menu option opens another window where capture options can be set: Note the check box to put the interface (eth0) in promiscuous mode, so packets not intended for this machine can be captured. Once capturing is running, another window is updated continuously with packet counts. 423
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

Network Services source or destination port is 23 - the telnet port - (src or dstport 23). We’ll get an acknowledgment: tcpdump: listening on eth0 … and tcpdump will log all telnet packets it sees on the network segment. Now we go to Fred, our Windows machine, and telnet from there to Bob, our Linux server. As soon as we do, we see the packets being logged by tcpdump, even though that’s running on a machine that’s not the destination for the packets! # tcpdump -i eth0 -1 -q -X src or dst port 23 tcpdump: listening on eth0 12:11:51.070377 fred.3335 > bob.telnet: tcp 0 (DF) 0×0000 4500 0030 317b 4000 8006 3342 0a04 4101 E..01{@…3B..A. 0×0010 0a04 4102 0d07 0017 24e6 7419 0000 0000 ..A…..$.t….. 0×0020 7002 2000 26f7 0000 0204 05b4 0101 0402 p…&……….. 12:11:51.070826 bob.telnet > fred.3335: tcp 0 (DF) 0×0000 4500 0030 0000 4000 4006 a4bd 0a04 4102 E..0..@.@…..A. 0×0010 0a04 4101 0017 0d07 f267 5575 24e6 741a ..A……gUu$.t. 0×0020 7012 16d0 e838 0000 0204 05b4 0101 0402 p….8………. If we look carefully at the packet log, we can find the Password prompt and see what the user typed in response. The password has been highlighted to make it easier to see, but hackers don’t need that much help - they’ll probably use an automated password sniffer that’ll decode the packets for them: 12:12:02.265222 bob.telnet > fred.3335: tcp 10 (DF) [tos 0×10] 0×0000 4510 0032 9d51 4000 4006 075a 0a04 4102 E..2.Q@.@..Z..A. 0×0010 0a04 4101 0017 0d07 f267 55fc 24e6 746e ..A……gU.$.tn 0×0020 5018 16d0 2c48 0000 5061 7373 776f 7264 P…,H..Password 0×0030 3a20 12:12:02.465557 fred.3335 > bob.telnet: tcp 0 (DF) 0×0000 4500 0028 4a7b 4000 8006 1a4a 0a04 4101 E..(J{@….J..A. 0×0010 0a04 4102 0d07 0017 24e6 746e f267 5606 ..A…..$.tn.gV. 0×0020 5010 21a8 0941 0000 2020 2020 2020 P.!..A…….. 12:12:03.180919 fred.3335 > bob.telnet: tcp 1 (DF) 0×0000 4500 0029 4b7b 4000 8006 1949 0a04 4101 E..)K{@….I..A. 0×0010 0a04 4102 0d07 0017 24e6 746e f267 5606 ..A….. $.tn.gV. 0×0020 5018 21a8 a337 0000 6620 2020 2020 P.!..7 ..f….. 12:12:03.218203 bob.telnet > fred.3335: tcp 0 (DF) [tos 0×10] 0×0000 4510 0028 9d52 4000 4006 0763 0a04 4102 E..(.R@.@..c..A. 0×0010 0a04 4101 0017 0d07 f267 5606 24e6 746f ..A……gV.$.to 0×0020 5010 16d0 1418 0000 65fd 01ff fb05 P…….e….. 12:12:03.423073 fred.3335 > bob.telnet: tcp 1 (DF) 0×0000 4500 0029 4c7b 4000 8006 1849 0a04 4101 E..)L{@….I..A. 0×0010 0a04 4102 0d07 0017 24e6 746f f267 5606 ..A…..$.to.gV. 0×0020 5018 21a8 9736 0000 7220 2020 2020 P.!..6..r….. 12:12:03.423232 bob.telnet > fred.3335: tcp 0 (DF) [tos 0×10] 0×0000 4510 0028 9d53 4000 4006 0762 0a04 4102 E..(.S@.@..b..A. 0×0010 0a04 4101 0017 0d07 f267 5606 24e6 7470 ..A……gv.$.tp 0×0020 5010 16d0 1417 0000 6465 6420 4861 P…….ded.Ha 12:12:03.555199 fred.3335 > bob.telnet: tcp 1 (DF) 0×0000 4500 0029 4d7b 4000 8006 1749 0a04 4101 E..)M{@….I..A. 0×0010 0a04 4102 0d07 0017 24e6 7470 f267 5606 ..A…..$.tp.gV. 0×0020 5018 21a8 a435 0000 6520 2020 2020 P.!..5..e….. 12:12:03.555354 bob.telnet > fred.3335: tcp 0 (DF) [tos 0×10] 0×0000 4510 0028 9d54 4000 4006 0761 0a04 4102 E..(.T@.@..a..A. 0×0010 0a04 4101 0017 0d07 f267 5606 24e6 7471 ..A……gV.$.tq 422
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

Network Services # nmap -sUT localhost Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on rh9 (127.0.0.1): (The 3064 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 68/udp open dhcpclient 123/udp open ntp 6000/tcp open X11 Nmap run completed — 1 IP address (1 host up) scanned in 3 seconds It has identified the same ports as netstat did, with the exception of xinetd listening on tcp/32769. This is because port 32769 is not in the range 1 to 1023, nor is it listed in /etc/services, so it won’t get scanned by default. If we used the -p flag to specify port numbers (e.g. added “-p 1-65535″ to the command line to have all ports scanned), then the open port is found and listed with “unknown” in the service column. Notice that nmap needs to be told which host to scan the ports on, suggesting that it can be used to scan for open ports on remote machines. Nmap is indeed capable of scanning for open ports on a range of remote machines, even choosing addresses at random. However, it is wise to get written permission from the owners of systems before scanning their ports, since this action may be seen as a prelude to illegal hacking activity. After all, it is just like walking past a row of parked cars and trying the doors on each one to see if they’re locked. If a policeman caught you doing that, you’d have a hard time explaining that if you were only looking for unlocked cars so you could tell the owners to be more careful. IP traffic It is surprisingly easy to capture and analyze network traffic. There are many tools available that enable users with sufficient privileges to record the headers and contents of network packets into files on disk and analyze the contents later. With broadcast network media, such as Ethernet, every machine on a network segment receives all the packets, regardless of who the packet is addressed to. Normally, the receiving network card discards packets not addressed to it, but most network cards can be configured to operate in “promiscuous” mode, which allows them to receive and process packets regardless of their intended destination. (Ethernet switches, as opposed to hubs, have intelligence and effectively create a series of point-to-point Ethernet links, instead of sending all packets to all machines. This not only improves security, it can also improve performance.) We’ll use a utility called tcpdump (from the RPM package of the same name) to demonstrate just how easy it is to capture data not destined for our machine. (As with nmap above, make sure you have permission to do this if you’re going to try it on a network that you don’t own!) Our theoretical test setup is this. There are three machines, all connected to a 10/100 Ethernet hub, and all on a private subnet 192.168.1/24 (that’s shorthand for a subnet 192.168.1.0 with a netmask of 255.255.255.0, i.e. 24 bits). Fred (192.168.1.l) is a Windows machine that we’ll use as a telnet client, Bob (192.168.1.2) is a Linux server we’ll be telnetting in to, and Kate (192.168.1.3) is our Red Hat Linux 9 machine. On Kate, we su to root and type: # tcpdump -i eth0 -l -q -X src or dst port 23 This tells tcpdump to listen to all packets on interface eth0 (-i eth0), buffer the output line-by-line (-1), don’t print lots of header information (-q) but do print the packets in ASCII (-X) and show only packets where the 421
Hint: If you are looking for high quality webhost to host and run your jsp application check Vision web hosting jsp services

Network Services -u UDP -1 Port sockets in state “listening” -n Show numeric values for hosts and ports -P Show process ID that owns sockets # netstat -nutlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 718/xinetd tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 979/X tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 704/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 832/sendmail udp 0 0 0.0.0.0:68 0.0.0.0:* 772/dhclient udp 0 0 10.4.65.253:123 0.0.0.0:* 803/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 803/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 803/ntpd This lists the TCP and UDP sockets that are ready to receive incoming data (connections in the case of TCP and datagrams for UDP). We can see that this machine is listening on four TCP/IP ports which are the numbers after the ‘:’ in the Local Address column (22 for ssh, 25 for incoming mail, 6000 for X11 and 32769 for the xinetd “super” server). It will also accept datagrams on port 68 (DHCP client) and 123 (Network Time Protocol service). Three TCP/IP addresses appear in this local address column: 0.0.0.0 means that the server is listening on all addresses, 127.0.0.1 is the machine’s loopback address, and 10.4.65.253 is the address of the machine’s Ethernet card (leased from a DHCP server). If we leave out the -l flag, netstat will show us all the active connections. If we leave out the -n flag, netstat will look up port names in /etc/services and host names using DNS, giving symbolic output. Try varying the flags to see what information is returned. We can check the output of the netstat command to make sure that we don’t have any programs listening on TCP or UDP ports that we’re not expecting. The -p flag, which gets netstat to print out the PID (Process ID) and name of the process that opened the socket, is very useful for identifying “rogue” programs, perhaps modified by an intruder, that are listening on unexpected ports. (Of course, if we’ve got Tripwire set up and we’re running regular scans, we’ll quickly identify if an intruder has modified a program.) nmap Nmap takes a different approach to the problem of identifying which ports are being listened to (are “open” in nmap parlance) on a machine. It sends special packets to ports on the machine in question, and listens for the response. This enables it to deduce whether the port is open, closed, or even being blocked by a firewall (more on that later). Nmap isn’t installed by default, but is on the Red Hat Linux CD-ROMs, so you may need to install it if you want to try these examples. First, by way of example, let’s get nmap to see what ports are open on our machine. We’ll use the flags -sUT to tell nmap we want it to scan both TCP and UDP ports, and accept the defaults for everything else (including the port range, which is 1 to 1023, since these are the ports that privileged services use, plus others that are mentioned in /etc/services). Here’s the output from a test system: 420
Hint: If you are looking for high quality webhost to host and run your jsp application check Vision web hosting jsp services