iptables logging on standalone dialup linux box help

ssenuta · 12-19-2006, 08:52 PM

I am trying to use the iptables logging feature to find out why I cannot connect to encrypted sites so as to login and view financial statements. I ran into this problem when I was using the Guarddog firewall but have since switched to this basic iptables firewall.

Everything is fine now (I can now connect to previously unavailable encrypted sites) but I would still like to learn how to troubleshoot a firewall via the netfilters logging feature.

Here is my /etc/sysconfig/iptables file:

# Generated by iptables-save v1.3.3 on Tue Dec 19 20:34:40 2006
*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:LOGDROP - [0:0]
:OUTPUT ACCEPT [3310:398663]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j LOGDROP
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -m state --state NEW -j LOGDROP
-A FORWARD -m state --state INVALID -j DROP
-A LOGDROP -j LOG --log-prefix "iptables logdrop"
-A LOGDROP -j DROP
-A OUTPUT -m state --state INVALID -j DROP
COMMIT

Here is what is displayed by the iptables -L command:

[root@localhost stan]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOGDROP tcp -- anywhere anywhere tcp dpt:https
LOGDROP tcp -- anywhere anywhere tcp dpt:https state NEW

Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID

Chain LOGDROP (2 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning prefix `iptables logdrop'
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID

Here is a snip of the related modules that are loaded:

af_packet 20104 0
ipt_LOG 6208 1
xt_state 2048 5
ip_conntrack 43552 1 xt_state
iptable_filter 2880 1
ip_tables 12568 1 iptable_filter

Do you think this iptable file would put an entry in my /var/log/messages file if I were unable to connect to an encrypted site? I have assumed that an encrypted web sites would use my https port but, since I am new to firewalling, I could be totally wrong.

win32sux · 12-19-2006, 11:43 PM

Quote:

Originally Posted by ssenuta

I am trying to use the iptables logging feature to find out why I cannot connect to encrypted sites so as to login and view financial statements. I ran into this problem when I was using the Guarddog firewall but have since switched to this basic iptables firewall.

Everything is fine now (I can now connect to previously unavailable encrypted sites) but I would still like to learn how to troubleshoot a firewall via the netfilters logging feature.

Here is my /etc/sysconfig/iptables file:

# Generated by iptables-save v1.3.3 on Tue Dec 19 20:34:40 2006
*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:LOGDROP - [0:0]
:OUTPUT ACCEPT [3310:398663]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j LOGDROP
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -m state --state NEW -j LOGDROP
-A FORWARD -m state --state INVALID -j DROP
-A LOGDROP -j LOG --log-prefix "iptables logdrop"
-A LOGDROP -j DROP
-A OUTPUT -m state --state INVALID -j DROP
COMMIT

Here is what is displayed by the iptables -L command:

[root@localhost stan]# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOGDROP tcp -- anywhere anywhere tcp dpt:https
LOGDROP tcp -- anywhere anywhere tcp dpt:https state NEW

Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID

Chain LOGDROP (2 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning prefix `iptables logdrop'
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID

Here is a snip of the related modules that are loaded:

af_packet 20104 0
ipt_LOG 6208 1
xt_state 2048 5
ip_conntrack 43552 1 xt_state
iptable_filter 2880 1
ip_tables 12568 1 iptable_filter

Do you think this iptable file would put an entry in my /var/log/messages file if I were unable to connect to an encrypted site? I have assumed that an encrypted web sites would use my https port but, since I am new to firewalling, I could be totally wrong.

well, there's not much to log as your OUTPUT policy is set to ACCEPT... hence, you are pretty much allowed to connect to anything you want (except packets with an INVALID state)... what exactly is it that you want to log?? the most simple logging method is to append a LOG rule to the end of your chains, with the policies set to DROP... hence, any packet which didn't get sent to ACCEPT by one of your rules gets sent to LOG before it's sent to DROP by the policy...

ssenuta · 12-20-2006, 09:53 AM

Do you mean that my /etc/sysconfig/iptables should look like this if I want to log failed connections:

*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:OUTPUT DROP [3310:398663]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -j log --log-prefix "iptables drop output"
COMMIT

If so, then I was trying to log from the wrong chain (INPUT instead of OUTPUT) & I thank you for helping me learn Linux netfilters ----stan.

amitsharma_26 · 12-20-2006, 10:32 AM

Its not advisable to set OUTPUT policy to DROP as this further bring a bigger headache in creating ruleset.

About logging, i have seen some real neat threads at LQ in past; so searching LQ for "iptables logging" in advanced search with "search within topics" will give you real money for your patience & efforts.

And if you have working knowledge of iptables; then you got to understand the fact that unlike normal block or accept rules, log rules allow packet to be passed onto next rule. So in your case as you want to log OUTGOING or INCOMING requests for 443 -dport; you can create a new rule(working knowledge of iptables) & instead of -j DROP or -j ACCEPT; do a -j LOG --log-prefix ssl-packets & then grep /var/log/messages for ssl-packets to see the logged packets.

Hope this helps.

win32sux · 12-20-2006, 05:39 PM

Quote:

Originally Posted by ssenuta

Do you mean that my /etc/sysconfig/iptables should look like this if I want to log failed connections:

*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:OUTPUT DROP [3310:398663]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -j log --log-prefix "iptables drop output"
COMMIT

If so, then I was trying to log from the wrong chain (INPUT instead of OUTPUT) & I thank you for helping me learn Linux netfilters ----stan.

well, yeah - sort of... basically what i was saying was that with your policies set to DROP, logging becomes much simpler... take this example:

Code:

iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Any attempt to start a connection TO our box will get logged (right
# before it hits our DROP policy), as well as any packet not matching
# any of our criteria:
iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

iptables -P OUTPUT DROP
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -p TCP -o $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -p TCP -o $WAN_IFACE --dport 443 \
-m state --state NEW -j ACCEPT

# Any attempt to start a connection FROM our box to ports other
# than those we've made rules to allow above will get logged (right
# before it hits our DROP policy), as well as any packet not matching
# any of our criteria:
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "

iptables -P FORWARD DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i $LAN_IFACE -o $WAN_IFACE \
-m state --state NEW -j ACCEPT

# Any packet hitting our FORWARD chain and not matching our rule/s
# will get logged:
iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "

iptables -t nat -A POSTROUTING -o $WAN_IFACE -j MASQUERADE

so in this example, if anyone scanned your box, or tried to connect to it, you would know... you would also know if the box itself tries to start a connection to something that is not TCP/80 (HTTP) or TCP/443 (HTTPS) (this example assumes this box is to be used only for Web surfing)... and you also know if something funky was going-on in the FORWARD chain, although the rule i used there as an example is probably way too broad either way...

also keep in mind that to make more specific log entires (for grep-ing later on or whatever) you'd just need to add LOG rules on top of the general ones... kinda like (for example):

Code:

iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p TCP -i $WAN_IFACE --dport 22 \
-m state --state NEW \
-j LOG --log-prefix "INPUT SSH DROP: "

iptables -A INPUT -p TCP -i $WAN_IFACE --dport 80 \
-m state --state NEW \
-j LOG --log-prefix "INPUT HTTP DROP: "

iptables -A INPUT -p TCP -i $WAN_IFACE --dport 443 \
-m state --state NEW \
-j LOG --log-prefix "INPUT HTTPS DROP: "

iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

ssenuta · 12-22-2006, 01:21 PM

I believe I am beginning to understand the netfilters logging proceedure now. To showoff my new found knowledge or to show just how dumb I can be, here are two iptables I put together. I am using iptable# 2 on my standalone dialup system & tested it via www.hackerwatch.org/probe. It passed as "Secure"

Thank you & have a Merry Christmas --stan

1.) I think this iptable will log all incoming & outgoing access requests to port HTTPS & then continue to transverse
the appropriate chain until the packet is terminated by a rule or policy

*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3310:398663]
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j LOG --log-prefix "INPUT HTTPS REQUEST: "
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -o ppp0 -p tcp -m tcp --dport 443 -j LOG --log-prefix "OUTPUT HTTPS REQUEST: "
-A OUTPUT -m state --state INVALID -j DROP
COMMIT

2.) I think this iptable will log all "valid" INPUT & OUTPUT traffic that is dropped. Packets that are "invalid" are
dropped & terminated early in the chains so they never make it to jump LOG.

*filter
:INPUT DROP [1773:206284]
:FORWARD DROP [0:0]
:OUTPUT DROP [99:5976]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j LOG --log-prefix "INPUT-DROP: "
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o ppp0 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A OUTPUT -o ppp0 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j LOG --log-prefix "OUTPUT-DROP: "
COMMIT

win32sux · 12-23-2006, 04:29 AM

Quote:

Originally Posted by ssenuta

I believe I am beginning to understand the netfilters logging proceedure now. To showoff my new found knowledge or to show just how dumb I can be, here are two iptables I put together. I am using iptable# 2 on my standalone dialup system & tested it via www.hackerwatch.org/probe. It passed as "Secure"

Thank you & have a Merry Christmas --stan

hehe, merry christmas to you too!!!

Quote:

1.) I think this iptable will log all incoming & outgoing access requests to port HTTPS & then continue to transverse
the appropriate chain until the packet is terminated by a rule or policy

*filter
:INPUT DROP [255:31881]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3310:398663]
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j LOG --log-prefix "INPUT HTTPS REQUEST: "
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -o ppp0 -p tcp -m tcp --dport 443 -j LOG --log-prefix "OUTPUT HTTPS REQUEST: "
-A OUTPUT -m state --state INVALID -j DROP
COMMIT

actually, that would not only log the "requests", but all packets with that destination port... if you just wanna log requests, then you'd wanna add a state match to the LOG rule for packets of state NEW... like:

Code:

-A INPUT -i ppp0 -p TCP --dport 443 -m state --state NEW \
-j LOG --log-prefix "INPUT HTTPS REQUEST: "

i would also suggest that you remove the rule for INVALID packets, as those packets won't get sent to ACCEPT either way (as long as you're using state matches for NEW,ESTABLISHED,RELATED) and it's good to know when you have packets with INVALID states hitting your box... so looking at it from that prespective, you'd actually be better-off by letting them slide down the chain and hit the DROP policy (or a rule) right after getting logged... then again, i see you removed the generic LOG rule at the end of the chains so you basically won't know what is getting sent to DROP here anyways... =/

Quote:

2.) I think this iptable will log all "valid" INPUT & OUTPUT traffic that is dropped. Packets that are "invalid" are
dropped & terminated early in the chains so they never make it to jump LOG.

*filter
:INPUT DROP [1773:206284]
:FORWARD DROP [0:0]
:OUTPUT DROP [99:5976]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j LOG --log-prefix "INPUT-DROP: "
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o ppp0 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A OUTPUT -o ppp0 -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A OUTPUT -o ppp0 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j LOG --log-prefix "OUTPUT-DROP: "
COMMIT

yes, this would do what you are saying... if you are decided to send INVALID packets to DROP without logging them , i would recommend moving the rule down, so that it is after any NEW/RELATED/ESTABLISHED rules... but like i said, i'm not exactly sure what you are trying to accomplish with the whole INVALID rule extravaganza you have going-on there...

here's how i would do what i think you are trying to accomplish in your first example:

Code:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i ppp0 -p TCP --dport 443 -m state --state NEW \
-j LOG --log-prefix "INPUT HTTPS REQUEST: "

iptables -A INPUT -m state --state INVALID -j LOG \
--log-prefix "INVALID INPUT DROP: "
iptables -A INPUT -m state --state INVALID -j DROP

iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

iptables -A OUTPUT -o ppp0 -p TCP --dport 443 -m state --state NEW \
-j LOG --log-prefix "OUTPUT HTTPS REQUEST: "

iptables -A OUTPUT -m state --state INVALID -j LOG \
--log-prefix "INVALID OUTPUT DROP: "
iptables -A OUTPUT -m state --state INVALID -j DROP

here's how i would do what i think you are trying to accomplish in your second example:

Code:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -m state --state INVALID -j LOG \
--log-prefix "INVALID INPUT DROP: "
iptables -A INPUT -m state --state INVALID -j DROP

iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -o ppp0 -p UDP --dport 53 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -o ppp0 -p TCP --dport 80 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -o ppp0 -p TCP --dport 443 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -o ppp0 -p TCP --dport 110 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -o ppp0 -p TCP --dport 25 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -o ppp0 -p ICMP --icmp-type 8 \
-m state --state NEW -j ACCEPT

iptables -A OUTPUT -m state --state INVALID -j LOG \
--log-prefix "INVALID OUTPUT DROP: "
iptables -A OUTPUT -m state --state INVALID -j DROP

iptables -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "