> Ansgar, Paolo, and David,
>
> Thanks for the help.
You're welcome.
> I utilized your ideas and ran nmap and nothing comes up (I did this
> from the same host, though).
Please don't go and interpret the results by yourself if you expect
anyone here to help. Just post what exactly you did, and what the exact
output/result was. Or don't bother posting at all.
> My logs dropped to nil activity after implementing a combo of the
> techniques you three mentioned (also, is it a bad thing if my logs
> aren't writing anything now, or is it that my ports can't be "seen"?).
Whether this is good or bad depends on what should or shouldn't be
logged. How would we know? And it has nothing to do with ports that
"can't be seen".
[...]
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> You can omit the last one if you're not forwarding packets.
>
> Only a small minority of people use the forward chain, right?
Wrong.
> I read somewhere that not even ISPs use port forwarding (relaying?).
Everyone running a linux-based firewalling router uses the FORWARD
chain. Which has nothing at all to do with port forwarding, but with IP
forwarding. Those are two entirely different beasts. And relaying is a
horse of yet another different color (the term is frequently used when
referring to accepting and forwarding e-mail).
The FORWARD chain handles packets that are coming from or going to hosts
behind the firewall (e.g. your LAN). The other chains (INPUT, OUTPUT)
handle those packets that are going to or coming from the firewall host
itself (see e.g. [1]). There are quite a few rather good tutorials on
netfilter.org [2] (particularly the packet filtering HOWTO).
>> Why are you ACCEPTing traffic based on the source address? For new
>> outbound connections you should ACCEPT based on destination and state
>> NEW, for everything else, you should use an ESTABLISHED,RELATED rule
>> just like you do in the INPUT chain.
>
> Currently, I have OUTPUT accepting NEW,ESTABLISHED,RELATED. If I'm
> thinking right about what you said Ansgar, the only thing I need to
> worry about in OUTPUT is NEW, so I'm about to change it and see what
> happens.
Wrong. You want to accept everything ESTABLISHED,RELATED in the OUTPUT
chain, so that every traffic corresponding to traffic you accept in the
INPUT chain is allowed as well. If you want to allow NEW outbound
connections you need to allow those in the OUTPUT chain.
Examples (assuming that the policies are set to DROP):
- If you run a webserver on your host and want to accept incoming
connections you need these rules:
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The INPUT rule allows incoming connections to your webserver, the
OUTPUT rule allows your webserver's responses to go back to the hosts
establishing the connection.
- If you want to access websites on other servers you need these rules:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
The OUTPUT rule allows outgoing connections to webservers elsewhere,
the INPUT rule allows those webserver's responses to go back to your
browser.
>> Repeating myself: "stealth" is braindead marketing babble invented by
>> people who failed to understand TCP/IP for people who fail to
>> understand TCP/IP. Your host doesn't magically become "invisible"
>> just because it drops packets. TCP/IP doesn't work that way.
>
> Then why does the site http://www.grc.com keep referring to ports as
> being under stealth? Are they defining "stealth" in a different way?
> What does one have to gain by propogating this "marketing babble"?
No, they're not defining "stealth" differently (they coined the term in
the first place). They just fail to understand TCP/IP. Most of Steve
Gibson's works are at least dubious, if not outright nonsense. There
used to be a site pinpointing that, but it's been down for some time
now. You can, however, still read it on archive.org (e.g. [3]).
What they get out of it? Fame, I suppose. Networking is a complex
matter, so there are a lot of people who are easily deceived by smooth-
talkers like Gibson, because they don't understand the matter well
enough to unmask quacks like him.
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
[2] http://www.netfilter.org/documentation/
[3] http://web.archive.org/web/20060405131413/http://grcsucks.com/
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
No comments:
Post a Comment