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.
Hi, i was looking for a way to log all incoming rules that are not part of an established connection, or are not in the INPUT ACCEPT policy. ie, if they are unsolicited connections only.
I was under the assumption that policies are 'parsed' down the table and will stop at a policy that matches. Hence why i put my logging policy at the bottom of the input chain. where am i going wrong? can someone please clarify my error?
Thank you.
Code:
# router addresses
router_mac="68:7f:74:01:dc:fe"
router_ip="192.168.2.2"
gateway_ip="192.168.2.1"
# mldonkey ports
mldonkey_tcp="27045"
mldonkey_udp="27049"
# bittorrent ports
btport_client="27051"
btport_tracker="27052"
# devices
vpndev="tun0"
ethdev="eth0"
# Flush all current rules from iptables
iptables -F
# Set default policies for INPUT, FORWARD and OUTPUT chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
# Set access for localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Accept packets belonging to established and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# START ALL RULES FROM HERE
# INPUT ACCEPT RULES
iptables -A INPUT -i "$ethdev" -s "$router_ip" -m mac --mac-source "$router_mac" -m state --state NEW -j ACCEPT
# mldonkey
iptables -A INPUT -p tcp --dport "$mldonkey_tcp" -j ACCEPT
iptables -A INPUT -p udp --dport "$mldonkey_udp" -j ACCEPT
# bittorrent
iptables -A INPUT -p tcp --dport "$btport_client" -j ACCEPT
iptables -A INPUT -p tcp --dport "$btport_tracker" -j ACCEPT
# INPUT BLOCK LOG RULES
iptables -A INPUT -j LOG --log-level 7 --log-prefix "IPTABLES: "
# OUTPUT ACCEPT RULES
iptables -A OUTPUT -d "$router_ip" -o "$ethdev" -j ACCEPT
iptables -A OUTPUT -o ! "$vpndev" -m owner --uid-owner mldonkeyjail -j REJECT
iptables -A OUTPUT -o "$vpndev" -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -d "$gateway_ip" -o "$ethdev" -j DROP
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#OUTPUT DROP RULES
#iptables -A OUTPUT -o "$ethdev" -j DROP
# OUTPUT DROP LOG RULES
#iptables -A OUTPUT -o eth0 -j LOG --log-level 7 --log-prefix "IPTABLES: "
# Save settings
iptables-save
Thanks for the reply, maybe my inquiry wasn't clear enough, my bad. It does log for me too, but it logs established connections and ports that i have specified to allow traffic. i just want to log unsolicited traffic.
This may or may not help (and I'm not really strong in dealing with FW configs), but when whenever I want to log something, I always have a logging line that precedes the drop/reject line (log & drop). The same applies with traffic that is accepted that you want to log (log & accept). The same would apply at the clean-up (catch-all) rule. While it may seem repetitive to do this (it actually isn't as each rule will be unique), it helps with organization.
He want to log everything what will not match any rule in iptables (what will be dropped by policy rules).
exactly, anything dropped should be logged.
i would post my syslog, but for some reason the daemon stopped logging a while ago. i just deleted my old logs last night. it's late right now and i am busy tommorow, but if i have time i'll post it asap.
you could take my word for it, that it is logging all traffic, inbound/outbound, dropped or accepted. I am no expert on iptables, so i wouldn't know, but shouldn't it be apparent from my rules alone?
Thanks.
$ iptables -S
( there are some rules added by blockcontrol, you can ignore them for the time being. )
Code:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-N blockcontrol_fw
-N blockcontrol_in
-N blockcontrol_out
-A INPUT -m state --state NEW -m mark ! --mark 0x14 -j blockcontrol_in
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.2.2/32 -i eth0 -m mac --mac-source 68:7F:74:01:DC:FE -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27045 -j ACCEPT
-A INPUT -p udp -m udp --dport 27049 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27051 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27052 -j ACCEPT
-A INPUT -j LOG --log-prefix "IPTABLES: " --log-level 7
-A FORWARD -m state --state NEW -m mark ! --mark 0x14 -j blockcontrol_fw
-A OUTPUT -m state --state NEW -m mark ! --mark 0x14 -j blockcontrol_out
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -d 192.168.2.2/32 -o eth0 -j ACCEPT
-A OUTPUT ! -o tun0 -m owner --uid-owner mldonkeyjail -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -d 192.168.2.1/32 -o eth0 -p tcp -m tcp --dport 80 -j DROP
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A blockcontrol_fw -m mark --mark 0xa -j DROP
-A blockcontrol_fw -d 208.67.220.220/32 -j RETURN
-A blockcontrol_fw -d 208.67.222.222/32 -j RETURN
-A blockcontrol_fw -s 192.168.2.0/24 -d 192.168.2.0/24 -j RETURN
-A blockcontrol_fw -j NFQUEUE --queue-num 92
-A blockcontrol_in -m mark --mark 0xa -j DROP
-A blockcontrol_in -i lo -j RETURN
-A blockcontrol_in -s 192.168.2.0/24 -j RETURN
-A blockcontrol_in -s 192.168.2.2/32 -j RETURN
-A blockcontrol_in -j NFQUEUE --queue-num 92
-A blockcontrol_out -m mark --mark 0xa -j REJECT --reject-with icmp-port-unreachable
-A blockcontrol_out -o lo -j RETURN
-A blockcontrol_out -d 208.67.220.220/32 -j RETURN
-A blockcontrol_out -d 208.67.222.222/32 -j RETURN
-A blockcontrol_out -d 192.168.2.0/24 -j RETURN
-A blockcontrol_out -d 192.168.2.2/32 -j RETURN
-A blockcontrol_out -p tcp -m tcp --dport 5557 -j RETURN
-A blockcontrol_out -p tcp -m tcp --dport 5556 -j RETURN
-A blockcontrol_out -p tcp -m tcp --dport 5555 -j RETURN
-A blockcontrol_out -p tcp -m tcp --dport 443 -j RETURN
-A blockcontrol_out -p tcp -m tcp --dport 80 -j RETURN
-A blockcontrol_out -j NFQUEUE --queue-num 92
He want to log everything what will not match any rule in iptables (what will be dropped by policy rules).
That doesn't change anything from what I posted above. If you want to log everything that the catch-all rule is dropping, you'll have to add a log rule before that drop rule.
I implicitly allow what traffic that needs to be allowed...everything else is blocked automatically (by the clean-up rule). In most cases, you wouldn't want to log the default drops. Best practice is to drop but not log (unless you're willing to pay the price in disk space usage). I do it because I donate my logs to SANS.
My last rules within my policy are as follows:
Code:
-A INPUT -p tcp -m tcp -i eth0 --dport 1:65535 -j LOG --log-prefix "Clean-up Rule - BLOCKED: "
-A INPUT -p tcp -m tcp -i eth0 --dport 1:65535 -j DROP
I think I see the major difference between your policy and mine. I've INPUT and OUTPUT set to ACCEPT. You've them set to DENY. I know the reasons for dropping but I also know that ACCEPT works better for me with my current understanding of things (rest assured that the policy is sufficient, though).
I think the best approach in firewall is to drop well known bad packets, allow only needed packets and drop or reject every other. Your rule:
Quote:
-A INPUT -p tcp -m tcp -i eth0 --dport 1:65535 -j DROP
will not handle every unknown packet, for example: what about udp, icmp and other, dport 1:65535 is unnecesary, and what about port 0, what if we one day install new network card and it will be eth1. This is security hole. The default policy (-P) is just for handling these packets which we known nothing.
I think the best approach in firewall is to drop well known bad packets, allow only needed packets and drop or reject every other. Your rule:
will not handle every unknown packet, for example: what about udp, icmp and other, dport 1:65535 is unnecesary, and what about port 0, what if we one day install new network card and it will be eth1. This is security hole. The default policy (-P) is just for handling these packets which we known nothing.
I've italicized the important aspects of my comments.
I don't want to hijack this post, but I'm well aware (I explained already) of what the defaults allow and deny entail. Note that a default of accept isn't necessarily bad, as long as you shore up the risks. There are reasons why I set things up the way they are. I've been doing this quite a while as a profession. Managing FWs isn't my strongest skill but far from my weakest. I've been tested and tempered within the security arena...I'm not bragging. I'm just mentioning this so that you know that I'm not a neophyte at managing a firewall.
You also only saw a piece of my policy...that's not nearly enough to determine whether I'm doing right/wrong. I'm supremely comfortable with what I currently have in place. And, as you can see from the logs I provided, my logging works. I posted them as an example to the OP.
The focus should be to assist the OP's logging issue. If the default of his policy is to drop, then there's no need for a clean-up rule...I know this. The problem is that he wants logging of whatever's being dropped that there isn't an actual FW rule for. He's still going to have to place a logging rule at the very end of his input and output chains...correct me if I'm wrong in this (I didn't see anything of that in his config).
Note that a default of accept isn't necessarily bad, as long as you shore up the risks.
Of course, I agree with this.
Quote:
The problem is that he wants logging of whatever's being dropped that there isn't an actual FW rule for. He's still going to have to place a logging rule at the very end of his input and output chains...correct me if I'm wrong in this (I didn't see anything of that in his config).
Maybe I do not understand correctly, my native language is not an English. He has logging rules here:
He has it at the end of the input chain...one would think that would be enough. Something isn't right with his policy...it's usually pretty simple and basic. He still hasn't observed win32sux's (or your) request to post logs.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
