Enterprise Firewall
 

If any one can help me get an IPTABLES file for securing the server and the network from the LAN and the Internet.

My present fire wall iptables is as follows:

# (1) Policies
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# (2) USER DEFINED RULES
iptables -N okay
iptables -A okay -p TCP --syn -j ACCEPT
iptables -A okay -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A okay -p TCP -j DROP

# (3) INPUT CHAIN RULES
iptables -A INPUT -p ALL -i eth1 -s xxx.xxx.xxx.xxx -j ACCEPT
iptables -A INPUT -p ALL -i eth0 -s 10.0.0.0/255.0.0.0 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s 10.1.2.96 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s xxx.xxx.xxx.xxx -j ACCEPT
iptables -A INPUT -p ALL -i eth0 -s 10.0.0.255 -j ACCEPT

# Rules for incoming packets from the Internet
iptables -A INPUT -p ALL -d 202.41.71.226 -m state --state ESTABLISHED,RELATED -j ACCEPT

# TCP Rules
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 20 -j okay
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 21 -j okay
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 22 -j okay
#iptables -A INPUT -p TCP -i eth1 -s 0/0 --destination-port 80 -j okay
#iptables -A INPUT -p TCP -i eth1 -s 0/0 --destination-port 113 -j okay


# UDP Rules
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 20 -j okay
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 21 -j okay
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 22 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 53 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 2074 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 4000 -j okay

#ICMP RULES

iptables -A INPUT -p ICMP -i eth1 -s 0/0 --icmp-type 8 -j okay
iptables -A INPUT -p ICMP -i eth1 -s 0/0 --icmp-type 11 -j okay

# (4) FORWARD RULES
# accept the packets we want to forward
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# (5) OUTPUT RULES
# ONLU OUT PACKETS WITH LOCAL ADDRESSESS ARE FORWARDED
iptables -A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p ALL -s xxx.xxx.xxx.xxx -j ACCEPT
iptables -A OUTPUT -p ALL -s xxx.xxx.xxx.xxx -j ACCEPT

# (6) POST ROUTING RULES
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xxx.xxx.xxx.xxx


Please let me know what must be changed in this to make it most secure.


Thanks

Ratan

DO I Need to submit to another forum if I don't get response from Linux-Enterprise form

Well, this thread could go in either Enterprise or Security forums. Please don't start more than one thread for the same issue, so if you would rather have this in Security let me know and I'll move it.

The other thing is that these posts are often difficult to answer, because no one knows what your needs are so no one quite knows how to answer it. We have no way of knowing what services you need to allow access to inbound or outbound.

Dear Chort
Thanks a lot for the reply. what i want is that the there should be full restriction for any new inbound packet only packets in response to the http request made by the server or lan users through this proxy may be allowed to come in. The out bound trafficto be allowed is HTTP requests to web sites.

I will be thankfull to you if I can get some feedback on the IPTABLES listed above from you or Security forum.
I can answer any point niot clear to the expert.

Thanks again

Ratan

Dear Chort
I came back to the forum after a weak and did not find any response to my problem or its transfer to security section

Can u help me by looking at the problem or forwarding it to right person.

Thanks

Ratan

Might be better in security ...
I think your needs are simple
and I've replied by e-mail to your e-mail
hope that helps
as I said
If you're not comfortable building your own
a distro like Smoothwall, IP Cop or similar is probably what you are looking for
however there are plenty of clued up people here who can help you "roll your own"
just clearly state what you are after
floppy

I have given my specific requirement and the iptables file above. Pl. suggest any change to aqchive the objective mentioned above.

I moved this thread to the Security forum for you to get more exposure.

What is xxx.xxx.xxx.xxx? It's a bit confusing cause you're using it as a source address in both INPUT and OUTPUT and then SNATing with it. If that is only your external IP address, then you're allowing some odd traffic. Specifically these rules:

iptables -A INPUT -p ALL -i eth1 -s xxx.xxx.xxx.xxx -j ACCEPT
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 20 -j okay
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 21 -j okay
iptables -A INPUT -p TCP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 22 -j okay
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 20 -j okay
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 21 -j okay
iptables -A INPUT -p UDP -i eth1 -s xxx.xxx.xxx.xxx --destination-port 22 -j okay

Because -i specifies the interface the traffic is entering, it looks like you're allowing traffic coming into the box on the external interface that is addressed from the box itself. So you're basically allowing traffic that is spoofing your IP address. I think maybe you mean to -d (destination) instead or maybe you're just using it in place of multiple addresses?

Also could you explain a bit more what you're using squid for? Since the REDIRECT target drops the traffic into the INPUT queue, you'll need a rule allowing traffic to port 3128.

Since this is for enterprise purposes, I'd collapse some of the redundant rules down to make a more efficient ruleset. The whole user defined chain "okay" isn't really doing much (it basically allows TCP that's in the NEW,ESTABLISHED,RELATED states). I'd just drop traffic that isn't in these states early on and then just use the ACCEPT target instead of jumping to okay and going through more rules there. If you're going to do more complicated things in "okay" but don't want to subject every packet to those rules, then using a user defined is a good idea. Here though you're not getting enough out of it to justify it's use.

Your UDP and ICMP traffic run through the user-defined 'okay' chain for no reason at all. UDP and ICMP are loaded onto "okay" but none of the rules in "okay" match UDP or ICMP traffic, so it just spills back out of "okay" into the INPUT chain again

Thanks for the comments.

1. That's right what you have mentioned xxx is another machine on internet which is allowed access for certain services through eth1.

2. Squid is being used to allow my lan users to access internet using eth0 of the server. 3128 is defined on individual browser on each client machine.

3. This script has been taken from a book on Fedora. so okay chains are just ehhancing the process and is structured for future modifictions / additions.

4. UDP /ICMP are not allowed for security resons and okay chain finally drops all which is not matched.

In case of more clarification, please ask?

In the given situation, how secure is the iptables firewall.

1. That's right what you have mentioned xxx is another machine on internet which is allowed access for certain services through eth1.
Why is outgoing traffic then SNATed to xxx.xxx.xxx.xxx?

2. Squid is being used to allow my lan users to access internet using eth0 of the server. 3128 is defined on individual browser on each client machine.
Limit the REDIRECT rule to only the internal LAN interface. You don't want to be proxying requests from the general internet.

4. UDP /ICMP are not allowed for security resons and okay chain finally drops all which is not matched.
The okay chain does function that way for tcp packets, but from what you've posted there are no rules in 'okay' that match udp or icmp packets, so these packets will move from the udp or icmp INPUT rules and are loaded onto the 'okay' chain. They pass though the 3 rules there and do not match any of the rules. They then go back to the rule in the INPUT directly following the one that loaded them onto 'okay'. They will then move through all the rules in the INPUT chain until they reach the default INPUT policy rule. If you don't want to allow UDP or ICMP, then just drop them early on rather than have them move through every single rule in your firewall (including through the rules in okay where they can never match any of the rules). If you want to prove this to yourself, add a rule logging icmp packets to the very bottom of your firewall, just before they reach the policy rule. So add this to the very end of your firewall script:

iptables -A INPUT -p icmp -j LOG --log-prefix "REACHED END"

Then ping the box and watch the /var/log/messages file and you'll see that the icmp traffic goes all the way through the firewall.

In the given situation, how secure is the iptables firewall.
Not sure yet, it's still not clear whether xxx.xxx.xxx.xxx is the same IP address here:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xxx.xxx.xxx.xxx

and here:

iptables -A INPUT -p ALL -i eth1 -s xxx.xxx.xxx.xxx -j ACCEPT

RatanSA is your systen setup similar to this one ... ( check out the link )

http://www.oreilly.com/catalog/linag2/book/appa.html

Figure A.2

I can reccommend the online book, its a little above my head, but still interesting. Not sure though if its based on IP Tables or IP Chains. If that is what you are after, then I'm sure Capt Caveman or someone will be able to help.

good luck
floppy

maybe this
 

# Policies
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow this specific machine in as well as anyone spoofing this IP
iptables -A INPUT -i eth1 -s xxx.xxx.xxx.xxx -j ACCEPT

#block UDP and ICMP from the internet, still the your users can ping others.
iptables -A INPUT -p UDP -i eth1 -j DROP
iptables -A INPUT -p ICMP -i eth1 -j DROP

# Let me connect to myself. is this really needed?
iptables -A INPUT -i lo -j ACCEPT

# send port 80 to prot 3128 for squid
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3128

#allow everything from the internal network
iptables -A INPUT -i eth0 -j ACCEPT

# ??? --> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xxx.xxx.xxx.xxx
# perhaps this? although you SNAT is the same if you know your own IP and it is static.
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE


Perhaps something like this would run a little faster and cover your need.

Since we are talking iptables. What do you think of this idea:

- We accept all connections we should accept
- We redirect all other connections to echo.

This is very nice, as the attacker just goes "what the hell".

Just imagine a nmap run that returns all ports in state open.

Thanks for the suggestions
dear floppywhopper, Krugger and Capt_Caveman



Here is the latest version of my iptables defining two separate x ips x1 is a machine on internet and x2 is the lan card ip connecting the server to internet.

# (1) Policies
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# (2) USER DEFINED RULES
iptables -N okay
iptables -A okay -p TCP --syn -j ACCEPT
iptables -A okay -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A okay -p TCP -j DROP

# (3) INPUT CHAIN RULES
iptables -A INPUT -p ALL -i eth1 -s x.x.x.x1 -j ACCEPT
iptables -A INPUT -p ALL -i eth0 -s 10.0.0.0/255.0.0.0 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s 10.1.2.96 -j ACCEPT
iptables -A INPUT -p ALL -i lo -s x.x.x.x2 -j ACCEPT
iptables -A INPUT -p ALL -i eth0 -s 10.0.0.255 -j ACCEPT


# Rules for incoming packets from the Internet
iptables -A INPUT -p ALL -d x.x.x.x2 -m state --state ESTABLISHED,RELATED -j ACCEPT

# TCP Rules
iptables -A INPUT -p TCP -i eth1 -s x.x.x.x1 --destination-port 20 -j okay
iptables -A INPUT -p TCP -i eth1 -s x.x.x.x1 --destination-port 21 -j okay
iptables -A INPUT -p TCP -i eth1 -s x.x.x.x1 --destination-port 22 -j okay
iptables -A INPUT -p TCP -i eth1 -s 0/0 --destination-port 0:63553 -j DROP


# UDP Rules
iptables -A INPUT -p UDP -i eth1 -s x.x.x.x1 --destination-port 20 -j okay
iptables -A INPUT -p UDP -i eth1 -s x.x.x.x1 --destination-port 21 -j okay
iptables -A INPUT -p UDP -i eth1 -s x.x.x.x1 --destination-port 22 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 53 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 2074 -j okay
iptables -A INPUT -p UDP -i eth1 -s 0/0 --destination-port 4000 -j okay
iptables -A INPUT -p UDP -i eth1 -j DROP

#ICMP RULES

iptables -A INPUT -p ICMP -i eth1 -s 0/0 --icmp-type 8 -j okay
iptables -A INPUT -p ICMP -i eth1 -s 0/0 --icmp-type 11 -j okay
iptables -A INPUT -p ICMP -i eth1 -j DROP
# (4) FORWARD RULES
# accept the packets we want to forward
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# (5) OUTPUT RULES
# ONLU OUT PACKETS WITH LOCAL ADDRESSESS ARE FORWARDED
iptables -A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p ALL -s 10.1.2.96 -j ACCEPT
iptables -A OUTPUT -p ALL -s x.x.x.x2 -j ACCEPT

# (6) POST ROUTING RULES
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source x.x.x.x2

My question now is
How to avoid spoofing using x1.
Is this firewall secure enought to protect intrusion.

lastly, I have some open ports in my server which i want to close, how to do that?


Thanks again

Ratan

Re: maybe this
 

You improve on a couple of things (handle UDP/ICMP early and fixed the REDIRECT rule), however some other things aren't that great (actually real bad). For example if you ever want to send a packet from this machine or forward any LAN traffic out (you don't have any rules allowing OUTPUT or FORWARD traffic). Also in the original ruleset traffic from xxx.xxx.xxx.xxx was restricted to only a few required ports. No need to give that host un-necessary additional access. Also there still aren't any rules that accept the traffic that's been redirected to the squid ports.

Just imagine a nmap run that returns all ports in state open.
In theory interesting concept. In practice what happens is that you actually attract more traffic from the crappily written scanners and malware that simply look for a certain port or group of ports to be open and then dump exploit code at the system. Also recent releases of nmap have version detection and can determine what service is running on a given port (doesn't just simply compare a port number to /etc/services anymore). Lastly imagine what happens if I send a single packet to your machine with the source IP address forged to that of your own system...

lastly, I have some open ports in my server which i want to close, how to do that?
What linux distribution and version are you using?

Dear Sir,

Thanks for the help
we are using redhat linux enterprise server 3

Ratan

To see what services are turned on at boot:
chkconfig --list | grep on

To keep a service off at boot:
chkconfig service_name off

To turn a currently running service off:
service service_name stop

Wrt you firewall, what are you using port 53 for? Are you actually hosting a DNS server on-site or was that meant to allow communication with a remote DNS server (like at your ISP)?

Dear Sir,

Good to hear from you instantly.

I have some doubts about the text written by you.

**Wrt you firewall, what are you using port 53 for? Are you actually hosting a DNS server on-site or was that meant to allow communication with a remote DNS server (like at your ISP)?

Yes we have dns at isp site, tro be used.

**#^--Basically same as having a default OUTPUT policy of ACCEPT (not real secure)

How i can make it real secure?

Thanks again

Ratan

First of all you need to NOT get your firewall rules from a Red Hat Linux 9 Bible. Second of all you need to read the man pages on iptables. I'm sitting here and reading the exact same thing from the book you have written. I know it's some place to start but honestly read the man pages and do some google searches on it.

**Wrt you firewall, what are you using port 53 for? Are you actually hosting a DNS server on-site or was that meant to allow communication with a remote DNS server (like at your ISP)?
Yes we have dns at isp site, tro be used.
Ok. Since you are a DNS client, you don't want to allow completely open access to DNS (port 53). Limit the source address on incoming packets to your ISP or ideally to your ISPs name servers. Also because incoming traffic to port 53 should only be in response to DNS lookups, it will be using a source port of 53 not the destination port (if you were were running a DNS nameserver it would be the reverse. So the rule you need is:

iptables -A INPUT -p UDP -i eth1 -s <Your_ISP> --source-port 53 -j ACCEPT


**#^--Basically same as having a default OUTPUT policy of ACCEPT (not real secure)
How i can make it real secure?
By limiting outgoing traffic to only those protocols that are necessary. This can be very difficult though. You'll need a list of all the types of traffic that will be leaving the server and write indivdual rules for each one instead of allowing all outgoing packets. I'd highly recommend getting your firewall working properly first and then try locking down outgoing traffic. Based on your current rules you'll need at least:
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 20 -d x.x.x.x1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 21 -d x.x.x.x1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -d x.x.x.x1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 53 -d <Your_ISP> -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 2074 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 4000 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT

*Usually this list can beome much larger depending on your requirements

Lot of thanks to you, Sir Capt_Caveman.
I think I have got the right inputs from you, Mr. InEeDhElPlInUx
and all others who contributed to this thread of mine.
Speciaql Thanks are due to chort of transferred my orignal thread from other forum.
I will come again in case of doubt.

Thanks again to all of you.

Ratan