> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:redhat-list- > [EMAIL PROTECTED] On Behalf Of Jason Dixon > Sent: Saturday, August 23, 2003 1:20 PM > To: Red Hat Mailing List > Subject: Re: Access to the servers from outside > > Hi Arnoldo: > > > I would like to begin by saying that I am a beginner in linux. > > Cool, welcome to the community. We're always happy to help "newbies". > But let me preface the rest of my comments by saying I'm very > concerned > about anybody providing external services (web/ftp/mail/etc) to the > Internet that doesn't have some experience administrating and securing > these services. Obviously, you have to get experience *somewhere*, > but > I'm of the opinion that this is best done in a controlled environment > first, not a hostile one like the Internet. That said... > > > At this time only I have access to my servers (Apache, proftpd, etc) > > inside of my network and I don't get to call them through the > internet. > > It's likely that your firewall is closing them. Whenever > troubleshooting network services, it's best to follow a scientific > method of discovery in determining what's wrong. Start out by seeing > if > the service is already running. Let's use Apache as the example here. > As you probably know by now, Apache listens on port 80 as a TCP > socket. > Let's take a look at our network connections and see if anything > matches > that: > > [EMAIL PROTECTED] ~]$ netstat -vant | grep 80 > tcp 0 0 0.0.0.0:80 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:8880 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:8025 0.0.0.0:* > LISTEN > tcp 0 0 0.0.0.0:8026 0.0.0.0:* > LISTEN > tcp 0 0 192.168.0.42:32800 164.109.8.55:1723 > ESTABLISHED > > As we can see, the first line shows us that port 80 is listening on > all > available IP addresses (0.0.0.0:80). That's good, we can see that > Apache (httpd) is running. You could also do a "ps ax | grep httpd", > but I trust my netstat output more. ;-) > > Well, if we see that Apache is listening on port 80, but we still > can't > connect, our best bet would be to confirm that the request is making > it > from our client to our server. Using a terminal/console/xterm, let's > run the tcpdump command to see if we're actually receiving the TCP > connection. Tcpdump should be installed in /usr/sbin/tcpdump, you > might > have to install it if you don't already have it. In this example, the > client is 192.168.0.10 and the server is 192.168.0.42. We're testing > on > the backend interface (eth1) for now. > > [EMAIL PROTECTED] ~]$ sudo tcpdump -ni eth1 port 80 > > Ok, now while that's waiting, let's go to our client and request the > website. For this exercise, I'm going to use the command line telnet > from another linux system. > > [EMAIL PROTECTED] fuzzy]$ telnet 192.168.0.42 80 > Trying 192.168.0.42... > telnet: connect to address 192.168.0.42: Connection refused > > What I've done is telnet to the server's port 80 in an effort to > connect > to the Apache service. As we can see, the connection received an > immediate refusal. Now, let's see what our tcpdump back on the server > reveals... > > tcpdump: listening on eth1 > 13:32:07.810612 192.168.0.10.33763 > 192.168.0.42.http: S > 3329145642:3329145642(0) win 5840 <mss 1460,sackOK,timestamp 483794384 > 0,nop,wscale 0> [tos 0x10] > > We're definitely seeing the connection from the client, but that's > about > it. The log shows us a SYN ("S") connection, the first part of the > standard TCP "3-way handshake". Since we didn't see any SYN/ACK or > RST > packets returned, we can safely assume that the Apache service did not > actually receive the request. Let's focus on the firewall. > > Looking at my ruleset (/etc/sysconfig/iptables), I determined that I > did > *not* have an entry to allow incoming TCP packets to port 80. By > adding > the following rule (your syntax may differ depending on your setup), > we > should be able to allow HTTP traffic to our server: > > -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT > > This rule has a number of parameters. The first part, "A", tells us > to > append this rule to an existing chain, "RH-Lokkit-0-50-INPUT". This > was > named as such by the lokkit firewall utility that comes with my Red > Hat > system. The 3rd flag ("-p") matches TCP packets, and the 4th flag > ("-m") allows us to load extended modules (options) for TCP, such as > "--dport" (destination port) and "--syn" (SYN packet). The final part > gives us an action ("-j") to perform (ACCEPT). To summarize > linguisticly, this rule says "Append a rule to the existing chain > named > RH-Lokkit-0-50-INPUT. Accept TCP packets with a destination of port > 80 > and the SYN bit turned on". Ok, let's reload our firewall... > > [EMAIL PROTECTED] ~]$ sudo service iptables restart > Flushing all current rules and user defined chains: [ OK ] > Clearing all current rules and user defined chains: [ OK ] > Applying iptables firewall rules: [ OK ] > > Now we'll start tcpdump on our server and try to connect from our > client > again: > > [EMAIL PROTECTED] ~]$ sudo tcpdump -ni eth1 port 80 and host 192.168.0.42 > tcpdump: listening on eth1 > 14:00:25.713342 192.168.0.10.33769 > 192.168.0.42.http: S > 818946521:818946521(0) win 5840 <mss 1460,sackOK,timestamp 483964186 > 0,nop,wscale 0> [tos 0x10] > 14:00:25.713448 192.168.0.42.http > 192.168.0.10.33769: S > 485666566:485666566(0) ack 818946522 win 32416 <mss > 16220,sackOK,timestamp 5835454 483964186,nop,wscale 0> (DF) > 14:00:25.741393 192.168.0.10.33769 > 192.168.0.42.http: . ack 1 win > 5840 > <nop,nop,timestamp 483964188 5835454> [tos 0x10] > > > Now you'll probably notice a few things different. First and > foremost, > our client connected successfully! Yeehaw! Ok, now let's analyze the > tcpdump output. You might have noticed that I added a few extra words > to my tcpdump command this time ("and host 192.168.0.42"). This > allows > me to filter on the client's IP address, in addition to the port. > This > is very helpful when you need to troubleshoot connections on an > interface that might have other traffic connecting, and you want to > see > only that specific traffic from that specific client. > > Ok, when we look at our tcpdump capture, we see a series of entries. > The first is the same we saw before, a SYN ("S") packet. Next, we see > a > SYN/ACK ("S", "ack"). Third, we see the third part of the 3-way > handshake, the final acknowledgement ACK ("ack"). From this point on, > the TCP connection with Apache is established, and we the remaining > packets would be part of the webpage transmission. > > I know this explanation has been lengthy, but hopefully this will lead > you on your way to troubleshooting basic- and advanced network > problems > on Linux. > > > Is it possible two firewalls exist in my system? How can I verify > that? > > Anything is possible. George W. Bush is the President of the United > States, after all. :( Nevertheless, it's unlikely that you have two > firewalls running. More likely is that you a) simply haven't allowed > access through your firewall for the services in question, or b) you > did, but a 2nd configuration utility (firestarter?) overwrote part of > your running configuration. > > Hope this helps. > > -- > Jason Dixon, RHCE > DixonGroup Consulting > http://www.dixongroup.net > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://www.redhat.com/mailman/listinfo/redhat-list
You are a good guy after all!!!!!!! Otto -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
