LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Can't see source on first SSH entry in iptables (https://www.linuxquestions.org/questions/linux-security-4/cant-see-source-on-first-ssh-entry-in-iptables-821664/)

Emil M 07-23-2010 05:31 AM

Can't see source on first SSH entry in iptables
 
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


centosboy 07-23-2010 05:58 AM

Quote:

Originally Posted by Emil M (Post 4042849)
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.

win32sux 07-23-2010 07:25 AM

Quote:

Originally Posted by Emil M (Post 4042849)
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


unixfool 07-23-2010 08:23 AM

Quote:

Originally Posted by centosboy (Post 4042872)
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.

win32sux 07-23-2010 10:39 AM

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.

Emil M 07-23-2010 11:17 AM

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?

centosboy 07-24-2010 05:17 AM

Quote:

Originally Posted by Emil M (Post 4043221)
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]


All times are GMT -5. The time now is 03:30 AM.