Quote:
Quote:
Quote:
Code:
# SMTP on internal interface: Quote:
|
As you suggested, I played with tcpdump. The odd thing I noticed on the external interface was that inquires were made by machines on the LAN about other machines on the LAN. They received no reply except when it was regarding the machine itself.
Code:
16:57:15.432063 arp who-has 192.168.30.187 tell 192.168.30.186 On the internal interface, things were as I expected Code:
17:04:04.289561 arp who-has 192.168.30.15 tell 192.168.30.160 Code:
Jul 25 18:17:52 newton kernel: martian source 200.17.our.broadcast from 200.17.another.university, on dev eth1 |
Quote:
Quote:
One of the things you can do with itpables is check how many packets have matched a particular rule. (These are cummulative until manually reset.) Give this command with the options "-nvL" and pipe the result to less. The first number in each line is the number of packets that have matched that rule. (The second number is the number of cummulative bytes these packets had.) So you can, for example, check to see if any packets actually matched the SNAT rule. If not, there is either an error in the rule, the packets didn't make it to the server in the first place, they were knocked out by rp_filter, or they were knocked out by another rule in the firewall. The POSTROUTING chain is the last thing that happens before the packet leaves the box. If rp_filter is knocking out all of your packets, your only choices are to wait until you have things coming in on the right interfaces, or turn rp_filter off. (Note to win32sux: I am not suggesting this is a good thing to do. It is a workaround for a bad situation.) However, if things are coming in on the wrong interface, even if you turn off rp_filter, the packets will still get blocked by the firewall rules unless you impliment my suggestions in post #9. Quote:
Also in #15 you said something about "home page." I am not sure what you were talking about, but maybe this is another rule you need to create for your firewall? |
Quote:
It seems that I did something very wrong when I added rules to win32sux's script. When I run the ssh session I had froze and I had to restart the machine to get it working again. I have gone back to the previous situation. I will have to check my modifications carefully. As I said earlier, without my modifications it seemed OK except for some services that I forgot to mention. Although NAT runs (on occasions) I found nothing under the SNAT rule on iptables statistics. Code:
[root@newton ~]# iptables -nvL I noticed there were no rules for udp only for tcp. Why? This machine runs internally NFS and NIS. Which ports are needed? Quote:
Thank you very much for your comments. |
My mistake about listing the packet counts. As you can see, the command I told you to run lists the INPUT, OUTPUT, and FORWARD chains. To view PREROUTING and POSTROUTING you must run
Code:
iptables -t nat -nvL I repeat, if you want to ssh into this box, you must provide a rule for it in win32sux's script. If you need to ssh and access port 80 from your LAN, for right now I would add the following lines to that script. Code:
$IPTABLES -A INPUT -p TCP -s $INTIF_NET --dport 80 \ |
Back Up and Regroup
Hi heberrdacruz,
We've been discussing a lot of details, and I think we have kind of gotten lost in the forrest. So in this post, I would like to back up a little, summarize where we have been, and propose a firewall script for your temporary use. You originally presented a problem where you were successfully SNATing packets from your LAN to the Internet, and receiving and FORWARDing the responses. But after a time this would stop working. You could start it working again by issuing a network restart on your server. It was soon determined that the problem was that packets were coming into the server on wrong interfaces. The exact reason for this, and why it could be straightened out by the network restart, was never determined, but it turned out a contributing factor might be what can most charitably be called an unusual network configuration. This configuration is expected to be corrected in the near future when new switches are purchased. Also, early on I commented that the firewall script you were using was permitting unlimited access to your box on the INPUT chain from both the Internet and your LAN. I suggested a script for tightening this down some. Win32sux joined the conversation and proposed another script which refined and extended the previous scripts. This script was never successfully used, apparently because of the packets coming in on the wrong interfaces and because some needed services had not been provided for. ---- I believe that is where we are now. You can pursue any additional ideas you have about correcting what interfaces the packets are coming in on. But to move this forward, I am listing below yet another script that I hope will work as a stopgap measure. It does not check which interface packets come in on, and it turns off rp_filter. As I note in its comments, you should correct your situation as soon as possible, and when you do, you should go to a more secure script. I have also changed the way the script specifies which ports on your server may be accessed. These ports are now listed in the variables EXT_TCP and INT_TCP to make adding new allowed TCP services as easy as editing these two lines. (As you have specified no udp ports that needed access, I did not bother with that.) If you want a service available both from the Internet and LAN, include it in both lists as I have done with port 80. I have tested portions of this script, but I do not have a convenient way to test it as a whole. If there are errors you can't figure out, let me know. Code:
#!/bin/sh |
Reply to post #20
Never mind about the iptables command. The output I obtained is below
Code:
Chain PREROUTING (policy ACCEPT 59681 packets, 4501K bytes) Quote:
Quote:
The installation default is to set this variable to one. The server with RH 9 (called magnon) also has this setting and NAT always seemed to work. I have now looked more closely at its log and I noticed occasional messages of the same type. Code:
Jul 28 08:46:36 magnon kernel: IN=eth1 OUT=eth1 SRC=212.58.235.174 DST=192.168.30.118 LEN=48 TOS=0x00 PREC=0x00 TTL=44 ID=34643 DF PROTO=TCP SPT=80 DPT=1405 WINDOW=64240 RES=0x00 ACK SYN URGP=0 |
Reply to post #21 (Back Up and Regroup)
I am most grateful for your help.
I think it is great the way you implemented the port addition. As this machine is the internal NIS and NFS I need to know about what ports are needed before installing your script otherwise no one will be able to use our network. The command rpcinfo -p localhost shows lots of ports. Shall add all of them? Searching the internet I found a page saying that NFS uses random ports. Is that so? When looking at /etc/services I noticed that services, like http, use both tcp and upd ports. Should I add both? One recommendation I stumbled upon was to add the following lines to /etc/sysconfig/network: Code:
YPSERV_ARGS="-p 834" Code:
iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP Looking on this page http://wiki.linuxquestions.org/wiki/...f_port_numbers I understood that I will also need Internet access to TCP and UDP port 53 (DNS) and TCP port 443 (HTTPS) and Internal LAN Access to TCP and UDP port 53 (DNS), TCP and UDP port 123 (NTP), TCP and UDP port 2049 (NFS) and TCP and UDP port 6000 (X11). Is that correct? |
I am afraid I made the same mistake I made in post #7! (At least I am consistent!:rolleyes:)
Code:
# -------------- INPUT Chain Firewall Rules --------------- Code:
$IPTABLES -A INPUT -p TCP ! -s $INTIF_NET --dport $port \ As far a the iptables -nvL and iptables -t nat -nvL commands go, I was providing them for your use as diagnostic tools. What you posted showed that there were indeed packets that matched the rule. |
heberrdacruz,
Your server is doing a lot more than I realized. As I alluded to in an early post, your network might have firewalls upstream, in which case your server might not need as stringent of a firewall as we have been talking about. Do you have a local network administrator you can talk to about this? Quote:
Quote:
The iptables lines (above) in the RH article should not be necessary in the firewalls we are talking about because we are restricting access with a (default) policy of DROP anyway. If you do decide to use such rules, you need to remember that the order of rules matter. Check the iptables man pages for details, but roughly speaking, in any given chain "the first match wins." But there can be complications. You would also need to subsitute your LAN network address (INTIF_NET) for 192.168.0.0/24. I assume you are not offering NFS or NIS over the Internet. (I believe that would be quite dangerous.) So even if you allow your firewall to accept all LAN connections, as I discuss below, but block all but certain specified Internet connections, you would still be accomplishing what the above rules do. So the firewall does need to provide for the services listed with rpcinfo to your LAN. Your options are to open up everything to the LAN (as I discuss below), nail down all the RPC ports and enumerate them in the firewall script, or have the script determine the RPC ports each time it starts. I believe once started the RPC services won't change ports. So in the last case, the correct startup sequence would be
Here is an excercise that gives userful information for modifying my last script. Copy and paste the following into a terminal window. Code:
rpc_tcp=$(rpcinfo -p localhost | \ If you want to add onto an existing string variable in a bash script (output highlighted): Code:
[surfcity@Vectra surfcity]$ testme="aa bb cc" Another option is instead of enumerating all of the services for your LAN, you simply allow packets claiming to come from the LAN complete access to this machine. While potentially less secure, you can be certain you won't deny any essential services to machines on your LAN. To do this, replace Code:
for port in $INT_TCP; do Code:
$IPTABLES -A INPUT -p TCP -s $INTIF_NET \ Quote:
The only reason you would need to allow incoming DNS connections is if you are running a DNS server or DNS proxy on this box. If this runs a DNS server for the rest of the Internet to poll, you certainly need to allow Internet access. If you are just running a proxy for your LAN you probably don't want to allow Internet access. In either case you would want to allow LAN access. I am not an expert on these other services. You can find out what programs are actively listening on their respective TCP ports by running netstat -nap as root. This will also show you UDP connections, but UDP is a stateless protocol so it won't tell you "LISTEN." But a process waiting for a connection will show a local address of 0.0.0.0. You can use this to see what services you might have forgotten about and their port numbers. (If netstat shows you a process number (pid) but no name, that process is completely swapped out. You can find out what it is using ps <pid>). You then need to decide which of these service should be available to the Internet and/or your LAN. |
Thank you very much for your reply. I am sorry I didn’t reply earlier. I was with flu and out of action for a few days, but I am fine now.
Yesterday afternoon I installed the much awaited new switch. I have linked to it only the cables from the external network interfaces and the university network cable. So far the network has been working without any problems. It really seems the mixture of traffic on the same switch was the cause of the problems we were having. This morning I reintroduced Code:
net.ipv4.conf.default.rp_filter = 1 Code:
Aug 4 09:41:20 newton kernel: IN=eth0 OUT=eth0 SRC=69.64.44.92 DST=192.168.30.11 LEN=1500 TOS=0x00 PREC=0x00 TTL=48 ID=52622 DF PROTO=TCP SPT=80 DPT=48321 WINDOW=778 RES=0x00 ACK URGP=0 I talked to the university network administrator and he told me that their firewall blocks all ports, except the standard ones, i.e., the ones that are known to be used the university computers. In which way do you believe that blocking ports on the INTERNAL interface would really increase security? Our LAN computers have very limited access: professors and their research students and staff. The option of opening all ports in the LAN interface is surely much simpler. Quote:
Quote:
Quote:
Thank you very much for all the information. |
Quote:
The interface a packet is sent out should be determined by the routing table. (Early on I had you check this table with route -n.) Earlier in this thread I assumed your routing table was static, i.e. that it didn't change after the computer had booted. I am now wondering if you are running a routing daemon such as routed, gated, or Zebra. I am not familiar with these, but my understanding is that they will (potentially) alter routing tables as they run. Maybe another poster can shed some more light on this mystery. Quote:
When I first noted that your machine was wide open I didn't know how many services this computer provided, and was not aware of the complexity of your network. I feared this box might be exposed directly to the Internet. I originally just noted this as an aside that you might want to look at while we tried to solve your original complaint. Instead, it took on a life of its own and became a major focus on this thread. If you do decide to allow LAN users access to everything, I would suggest you review all of the services on newton and turn of any you don't need. (Always a good security practice.) An easy way to see what services you are running is running netstat as root: Code:
netstat -nap | less Quote:
|
Thank you for your reply.
Quote:
Code:
[root@newton ~]# route -n Quote:
Quote:
When customizing your firewall I had a doubt. Which one of the 3 lines below shall I use in the new and improved switch situation? Code:
$IPTABLES -A INPUT -p TCP ! -s $INTIF_NET --dport $port \ |
Quote:
Code:
# Rules which allow new Internet connections |
Thank you very much for the rules which allow new Internet connections.
Please check below the script I used. Code:
#!/bin/sh Code:
C:\Documents and Settings\heber>ping www.xx.yyyy.zz Code:
Aug 8 09:51:44 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:xx:xx:xx:xx:xx:xx:xx SRC=192.168.30.118 DST=192.168.30.15 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=65036 PROTO=UDP SPT=1037 DPT=53 LEN=40 Code:
C:\Documents and Settings\heber>ping 192.168.30.15 Code:
Aug 8 09:56:25 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:xx:xx:xx:xx:xx:xx:xx SRC=192.168.30.118 DST=192.168.30.15 LEN=62 TOS=0x00 PREC=0x00 TTL=128 ID=1451 PROTO=UDP SPT=1037 DPT=53 LEN=42 What did I do wrong? |
All times are GMT -5. The time now is 03:43 AM. |