Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
# (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.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
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.
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
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:
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
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:
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.
# 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
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?
Originally posted by Krugger # 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.
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...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.