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.
Now I managed to get iptables to work with my OpenVZ configurations and everything seems to work as it should. However when I run iptables -L I can only see source for the second SSH rule, why isn't the first ones source/IP shown?
Also if you have any comments about the setup feel free :-)
I'm running SSH, Apache and local MySQL
The xxx.xxx is simply to hide my IP's
Code:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t mangle
iptables -X
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -j REJECT
iptables -A INPUT -p tcp --dport 22 -s 77.213.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 62.198.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j REJECT
iptables -A INPUT -j REJECT
iptables -A INPUT -j DROP
Now I managed to get iptables to work with my OpenVZ configurations and everything seems to work as it should. However when I run iptables -L I can only see source for the second SSH rule, why isn't the first ones source/IP shown?
Also if you have any comments about the setup feel free :-)
I'm running SSH, Apache and local MySQL
The xxx.xxx is simply to hide my IP's
Code:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t mangle
iptables -X
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -j REJECT
iptables -A INPUT -p tcp --dport 22 -s 77.213.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 62.198.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j REJECT
iptables -A INPUT -j REJECT
iptables -A INPUT -j DROP
run iptables -L -n -v (do not resolve ips & show packet counters)
why the drop rule after the reject? nothing will reach that rule anyway.
add a chain for logging anything that is dropped if you plan to go with the DROP. that is good for troubleshooting purposes.
Also if you have any comments about the setup feel free :-)
You've got this rule:
Quote:
Code:
iptables -A INPUT -m state --state INVALID -j REJECT
...but some packets in INVALID state would already match the rules above it, so you're essentially filtering packets in state INVALID only if they weren't sent to ACCEPT. If your intention is to keep out all packets in state INVALID, you should move the rule upward. I'd also suggest adding a match for packets in state RELATED (to handle things such as ICMP errors, which can be very useful) and NEW, which would eliminate the need to match for state INVALID since they'll get caught at the end of the chain. BTW, I second centosboy's recommendation of logging everything that is filtered. Example of all of this:
Code:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 22 -s 77.213.xxx.xxx -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 22 -s 62.198.xxx.xxx -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "
iptables -A INPUT -j DROP
add a chain for logging anything that is dropped if you plan to go with the DROP. that is good for troubleshooting purposes.
I'd only do this if you have the resources. I've no idea where this FW is at and how much traffic it is processing, but in the professional world, logging of the catch-all rule is usually disabled to free up drive space and system logging resources (if logging is needed for troubleshooting purposes, it is enabled when needed). This is also sometimes helpful in the case of DoS or large scale events where the firewall is doing fine (acting within parameters) but the OS behind it is barely coping with the load of tracking each hit (logged or not). Sometimes the additional load of logging can negatively impact a FW.
This is more of a personal preference, I guess, but I find that if a FW admin always has 'best practices' as a focus, even with FWs monitoring small network segments, it helps a TON when the job of administrating FWs that track large network segments. Basically, it won't hurt to log on the deny rule, as long as there's proper system resources...just be prepared to be stupified when the system is acting quirky when trying to handle large loads.
Yeah, I'd recommend the use of the limit match module if performance and/or resource issues arise or are expected. Using DROP/REJECT rules within the chain (in order to filter certain packets while keeping them away from the LOG rule) is also an option.
Thanks for all the replies have got a better understanding now and think I've come up with a proper configuration
Code:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t mangle
iptables -X
iptables -A INPUT -m state --state INVALID -j REJECT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -j REJECT
iptables -A INPUT -p tcp --dport 22 -s 77.213.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 62.198.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
.. however log says "No chain/target/match by that name" but that could be because I need to modprobe something on the host node, but if I don't plan to investigate log files that much, is it really something I should do?
Thanks for all the replies have got a better understanding now and think I've come up with a proper configuration
Code:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t mangle
iptables -X
iptables -A INPUT -m state --state INVALID -j REJECT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -j REJECT
iptables -A INPUT -p tcp --dport 22 -s 77.213.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 62.198.xxx.xxx -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
.. however log says "No chain/target/match by that name" but that could be because I need to modprobe something on the host node, but if I don't plan to investigate log files that much, is it really something I should do?
Code:
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix "dropped packet" --limit 5/min
iptables -A LOG_DROP -j DROP
logging 5 entries a minute would not bother your resources too much, but it is not really a requirement, just good for troubleshooting.
[/code]
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
