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
