On Wednesday 2005-August-10 12:27, Anthony DiSante wrote:
> Jörg Harmuth wrote:
> >>Can anyone offer some pointers here? I imagine more of my
> >> narc.conf and/or iptables' output would be helpful, but rather
> >> than me attaching the whole thing right now, just ask if you want
> >> me to post any of that.
I would point out that this "narc.conf" appears to be controlling a
rather complex script. I cannot answer anything about it. I can look
over your rules ... needlessly complex IMO ... and point out problems.
But for issues with this script, consult its documentation (and source
code) and ask elsewhere.
> # iptables-save
> # Generated by iptables-save v1.3.1 on Wed Aug 10 13:21:27 2005
> *mangle
>
> -A PREROUTING -d 0.0.0.0/255.0.0.0 -i eth0 -m state --state NEW -j
> DROP
Filtering in the nat or mangle tables is not advised. It might not even
work as expected. I have no idea what the script writer is doing here,
nor why s/he is doing it here in particular.
Here are the rules in INPUT:
> -A INPUT -j SPOOF_CHK
> -A INPUT -p tcp -j SANITY_CHK
> -A INPUT -j STATE_CHK
> -A INPUT -s 127.0.0.0/255.255.255.0 -d 127.0.0.0/255.255.255.0 -i lo
> -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -j TCP_CHK
> -A INPUT -p udp -j UDP_CHK
> -A INPUT -p icmp -j ICMP_CHK
We'll consider SSH. That is first examined by SPOOF_CHK, then by
SANITY_CHK, then by STATE_CHK, and finally by TCP_CHK.
> -A STATE_CHK -m state --state RELATED,ESTABLISHED -j ACCEPT
You're probably right that when you manually try in both directions,
you're going to fool connection tracking into thinking that it's
related.
> -A STATE_CHK -p tcp -m state --state NEW -m tcp ! --tcp-flags
> SYN,RST,ACK SYN -j DROP
I'm not sure what this does. It might be dropping your SSH depending on
the TCP flags which are set.
> -A TCP_CHK -s 10.0.0.12 -d 10.0.0.12 -p tcp -m tcp --dport 3029:3038
> -j ACCEPT
These rules are bypassed. The last rule in SPOOF_CHK :
> -A SPOOF_CHK -s 10.0.0.12 -i eth0 -j CUST_LOG
has already dropped anything which would match. I don't understand what
they were supposed to do anyway, both source and destination the local
eth0 IP address?
> -A TCP_CHK -i eth0 -p tcp -m multiport --dports 22,873,80,9618 -m
> state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
This looks like it should be accepting your SSH, but for some reason
it's not. What is the IP you are using, the NAT'ed external IP, or the
direct 10.0.0.12 and .13? If you're using the NAT'ed IP, the problem is
on the router which is doing the NAT. (And I agree, that was a lousy
way to set this up.)
> -A TCP_CHK -i eth0 -p tcp -m multiport --dports 22,80,873,9618 -m
> state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
Same rule twice? That's strange.
Anyway, your solution is quite simple. Put an ACCEPT rule ahead of
anything which would drop or reject the packets you want.
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
