iptables udp and output

Noi wrote:

> I think I would ACCEPT policy for OUTPUT
> and DROP policy for FORWARD. Of course
> you're dropping all traffic unless you explicitly
> accept it in your rules.

I don't think that's a good idea. First off, the idea of a firewall is
"until I allow it, nothing gets through". Second, output can cause
problems just as much as input, which is why -P DROP for OUTPUT and then
filtering them out using state machine and port selection is the best way.
However, it's preference, and honestly for a home user -P OUTPUT ACCEPT is
probably ok, but I don't like the idea of it.

> I think the 2 multiport commands above will accept $INTERNET_SERVICES
> and $LOCAL_SERVICES of any state from everywhere on any device.
> Wouldn't you want a $LOCAL_NET=192.168.0.0/24 ?
>
>
> Which protocol does DNS come on and from who?
>

DNS is UDP over port 53, and it's best to be VERY specific with that part,
like specifying where the packets are allowed to come from and go to.

>> #Allow incoming NMBD/SMB traffic
>> $IPTABLES -A INPUT -p udp --dport 137 -i eth0 -j ACCEPT
>> $IPTABLES -A INPUT -p udp --dport 138 -i eth0 -j ACCEPT
>>
>
> I thought you dropped port 137,138 from above, not to mention the drop
> policy.

That's what I said ... ;)

>
> Who is charly? What about owners news, smtp, pop3, smbd/nmbd?
> You're not sending port 137,138 due to policy so nmbd/smbd won't work.

Exactly -- he needs to either accept smbd/nmbd (ports 135:139,445) over
local network and stop complaining about "noisy win2k box". If you don't
like the windows computers, don't have them on your net.

>
> ICMP is too important a feature to block.

I said that too...

> Some ISPs use icmp to heartbeat
> the line for connectivity, no icmp then no dhcp or dns. How will you test
> basic (access layer) connectivity? Telnet tests the application
> layers, ie, user program connection.

But I wouldn't use telnet for anything -- to insecure for my tastes...

> Applies to INPUT as well because
> you'd need to accept some ICMP if sending ICMP you can specify types of
> acceptable ICMP.

Which is what I said ... echo request (type 0) and reply (type 8), "network
unreachable" "destination unreachable" etc...

>
> GL
>

--
So... did you ever wonder, do garbagemen take showers before they go to
work?

First of all, I thank the lot of you for helping me design my firewall.

I'm still working on it, and decided to :
- drop the output filtering and do output Accept
- filter the icmp packet as neosadist said
- drop the owner filter for now

I allow chatter between my dns server (which is also my gateway) and my
machine.

As for not having W2K machine, well I cannot force my wife to work with
gimp and there's no equivalent (production-quality) to quark Xpress on
linux yet :)

With the output filtering, I cannot reach my machine anymore from the
outside via ssh or ftp (I'll try tomorrow with no output filter)
IPTABLES="/usr/local/iptables-1.2.9/iptables"
INSMOD="/sbin/insmod"
LOCAL_SERVICES="21,22"
GATEWAY="10.0.0.138"

$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP


#-----------------------------
# INPUT RULES
#-----------------------------


# Drop ALL attempted port scans
$IPTABLES -A INPUT -m psd -j DROP
$IPTABLES -A INPUT -f -j DROP

# drop all invalid state packets
$IPTABLES -A INPUT -i eth0 -m state --state INVALID -j DROP

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p tcp --syn --match multiport --dports
$LOCAL_SERVICES -j ACCEPT

# Stop W2K Chatter
$IPTABLES -A INPUT -p tcp --sport 135:139 -j DROP
$IPTABLES -A INPUT -p udp --sport 135:139 -j DROP
$IPTABLES -A INPUT -p tcp --sport 445 -j DROP

#Allow incoming DNS traffic to/from the gateway
$IPTABLES -A INPUT -p udp -s $GATEWAY --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp -d $GATEWAY --dport 53 -j ACCEPT



# Ping must be filtered
$IPTABLES -A INPUT -p icmp -m state --state INVALID -j DROP
$IPTABLES -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT
$IPTABLES -A INPUT -p ! icmp -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT
$IPTABLES -A OUTPUT -p ! icmp -m state --state ESTABLISHED,RELATED -j ACCEPT


#-----------------------------
# OUTPUT RULES REMOVED FOR NOW
#-----------------------------

#$IPTABLES -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
#$IPTABLES -A OUTPUT -m state --state NEW -m owner --uid-owner charly -j
ACCEPT
#$IPTABLES -A OUTPUT -m state --state NEW -m owner --uid-owner root -j
ACCEPT


#-----------------------------
# LOCALHOST IS TRUSTED
#-----------------------------
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

In article <100c618crcejj38@corp.supernews.com>, NeoSadist wrote:
>> basic (access layer) connectivity? Telnet tests the application
>> layers, ie, user program connection.
>
> But I wouldn't use telnet for anything -- to insecure for my tastes...

Rubbish.

I use telnet for a lot of things, and I challenge you to name a single
example of a vulnerability that the use of the telnet client can incur.
There is no better TCP diagnostic tool. How else would one troubleshoot
a SMTP or HTTP or $YOU_NAME_IT server? (But then, I suppose that someone
who would post such an assertion probably would not know how to type raw
SMTP, HTTP or $YOU_NAME_IT commands.)

Your "taste" is nothing more than a kneejerk reaction. The "weakness" of
telnet is the lack of encryption ... well here's a clue: the vast
majority of TCP traffic is unencrypted! You may begin the crusade
against all unencrypted TCP clients now. Start with your news client,
which is infecting unsuspecting readers with uninformed opinions. :)

BTW I also run ihe telnet daemon (through inetd) on all my systems'
internal interfaces. BOO!
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 <rob0@gmx.co.uk> writes:

> In article <100c618crcejj38@corp.supernews.com>, NeoSadist wrote:
>>> basic (access layer) connectivity? Telnet tests the application
>>> layers, ie, user program connection.
>>
>> But I wouldn't use telnet for anything -- to insecure for my tastes...
>
> Rubbish.
>
> I use telnet for a lot of things, and I challenge you to name a single
> example of a vulnerability that the use of the telnet client can incur.

Information-interception on a plate. *That*'s what you're guarding against,
someone getting their paws on your (corporate|personal) info / dealings. I
would go so far as to say this is the most serious computer-related breach.
Utilities can be patched, boxes reinstalled, but folks tend to stay
pissed-off longer.

> There is no better TCP diagnostic tool. How else would one troubleshoot a
> SMTP or HTTP or $YOU_NAME_IT server?

Well, nc does the honours for me, but really it's stuff-all different to
telnet for that kind of purpose apart from doing udp and the `-z' option
thing.

> (But then, I suppose that someone who would post such an assertion
> probably would not know how to type raw SMTP, HTTP or $YOU_NAME_IT
> commands.)
>
> Your "taste" is nothing more than a kneejerk reaction. The "weakness" of
> telnet is the lack of encryption ... well here's a clue: the vast
> majority of TCP traffic is unencrypted! You may begin the crusade against
> all unencrypted TCP clients now. Start with your news client, which is
> infecting unsuspecting readers with uninformed opinions. :)

Well said. I rather wonder what would've happened if the web was run over
SSL primarily. Do we actually need a proliferation of unencrypted protocols
in order for the encrypted ones to stand out somehow?

> BTW I also run ihe telnet daemon (through inetd) on all my systems'
> internal interfaces. BOO!

I was wondering last night, is there any way to exploit an IP stack
implementation so that an external probe could find something lurking on an
internal interface only? Is there any misconfiguration of sysctls possible
that would aid such a thing?

~Tim
--
For a successful technology, |piglet@stirfried.vegetable.org.uk
reality must take precedence over public |http://spodzone.org.uk/cesspit/
relations, for nature cannot be fooled |
- Feynman |

In article <86hdyxb28o.fsf@potato.vegetable.org.uk>, Tim Haynes wrote:
>> I use telnet for a lot of things, and I challenge you to name a single
>> example of a vulnerability that the use of the telnet client can incur.
>
> Information-interception on a plate. *That*'s what you're guarding against,

I understand this. In context: the previous poster (Neosadist) was
responding to Noi's suggestion about the use of telnet as a general
diagnostic tool. There was no mention nor suggestion of using a telnet
daemon as a means of remote login. "telnet mail.some.where 25" is no
more nor less safe from network sniffing than is the use of a MUA or MTA
for SMTP.

The fact, as I'm sure you know, is that using telnet to talk to servers
of plain-text protocols presents no more risk than using a normal client
of that protocol. If anything the risk is probably less, because any
client exploits on that protocol would be expecting a usual client.

>> There is no better TCP diagnostic tool. How else would one troubleshoot a
>> SMTP or HTTP or $YOU_NAME_IT server?
>
> Well, nc does the honours for me, but really it's stuff-all different to
> telnet for that kind of purpose apart from doing udp and the `-z' option

After I posted that I figured someone would mention nc. :) Yes, nc is
better in numerous ways, not the least of which being the UDP matter.
Still, I grab for telnet as a first resort. Even Windows has a
rudimentary telnet client!

> Well said.

Thanks, but it's a bit more harsh than my usual style. :) In this case I
can be blunt with little fear of giving offense, because I believe the
victim has me killfiled. :)

> I rather wonder what would've happened if the web was run over
> SSL primarily.

For one thing, it would impose a MUCH greater burden on servers and
clients in terms of processing requirements. This would increase costs
and dampen the proliferation of information (and misinformation ;) being
published so cheaply now.

> Do we actually need a proliferation of unencrypted protocols
> in order for the encrypted ones to stand out somehow?

Personally I think it would be a Good Thing to see more employment of
encryption in private communications, like email. The knowledge that my
mail is being scanned for crimethink by the likes of Ashcroft does not
sit well with me.

>> BTW I also run ihe telnet daemon (through inetd) on all my systems'
>> internal interfaces. BOO!
>
> I was wondering last night, is there any way to exploit an IP stack
> implementation so that an external probe could find something lurking on an
> internal interface only? Is there any misconfiguration of sysctls possible
> that would aid such a thing?

Whew, if so that would be a biggie. :) in.telnetd would be among the
least of our worries! SMB, NFS ... X11!

When you see xeyes pop up on your screen you will know I succeeded. ;)
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 <rob0@gmx.co.uk> writes:

> In article <86hdyxb28o.fsf@potato.vegetable.org.uk>, Tim Haynes wrote:
>>> I use telnet for a lot of things, and I challenge you to name a single
>>> example of a vulnerability that the use of the telnet client can incur.
>>
>> Information-interception on a plate. *That*'s what you're guarding against,
>
> I understand this. In context: the previous poster (Neosadist) was
> responding to Noi's suggestion about the use of telnet as a general
> diagnostic tool. There was no mention nor suggestion of using a telnet
> daemon as a means of remote login. "telnet mail.some.where 25" is no
> more nor less safe from network sniffing than is the use of a MUA or MTA
> for SMTP.

Oh, agreed. In fact, it does quite often creep evilly onto my machines, in
a stricly client-only sense, for exactly that purpose. Sometimes, you've
just gotta ^]q the blighter, y'know :)

> The fact, as I'm sure you know, is that using telnet to talk to servers
> of plain-text protocols presents no more risk than using a normal client
> of that protocol. If anything the risk is probably less, because any
> client exploits on that protocol would be expecting a usual client.

Indeed.

>>> There is no better TCP diagnostic tool. How else would one troubleshoot a
>>> SMTP or HTTP or $YOU_NAME_IT server?
>>
>> Well, nc does the honours for me, but really it's stuff-all different to
>> telnet for that kind of purpose apart from doing udp and the `-z' option
>
> After I posted that I figured someone would mention nc. :)

:)

[snip]
>> I rather wonder what would've happened if the web was run over SSL
>> primarily.
>
> For one thing, it would impose a MUCH greater burden on servers and
> clients in terms of processing requirements. This would increase costs
> and dampen the proliferation of information (and misinformation ;) being
> published so cheaply now.

Bummer(TM) ;)

>> Do we actually need a proliferation of unencrypted protocols
>> in order for the encrypted ones to stand out somehow?
>
> Personally I think it would be a Good Thing to see more employment of
> encryption in private communications, like email. The knowledge that my
> mail is being scanned for crimethink by the likes of Ashcroft does not
> sit well with me.

Yes, this is true. Balance has to be present, and if everything's encrypted
then it's harder to pick out than if only "interesting" mails get the
treatment, I suppose. Still...

>> I was wondering last night, is there any way to exploit an IP stack
>> implementation so that an external probe could find something lurking on
>> an internal interface only? Is there any misconfiguration of sysctls
>> possible that would aid such a thing?
>
> Whew, if so that would be a biggie. :) in.telnetd would be among the
> least of our worries! SMB, NFS ... X11!

Quite. :)

> When you see xeyes pop up on your screen you will know I succeeded. ;)

OK, I'll be on the lookout - although you'd have to crack my posting-host
first to see where I connect from ;)

~Tim
--
Headlights flash in the darkness |piglet@stirfried.vegetable.org.uk
Memories twist in the rain |http://spodzone.org.uk/cesspit/

charly <spam@yahoo.fr> said:

[... something which I condensed to the essence]

So, here's the ruleset, re-ordered to provide a clearer view to
contents of INPUT and OUTPUT chains. Listing the chain policy as the
last item of the chain may seem counter-intuitive, until you realize
that it is actually just writing out in what order filter applies
the rules.

>$IPTABLES -A INPUT -m psd -j DROP
>$IPTABLES -A INPUT -f -j DROP
>$IPTABLES -A INPUT -i eth0 -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p tcp --syn --match multiport --dports $LOCAL_SERVICES -j ACCEPT
>$IPTABLES -A INPUT -p tcp --sport 135:139 -j DROP
>$IPTABLES -A INPUT -p udp --sport 135:139 -j DROP
>$IPTABLES -A INPUT -p tcp --sport 445 -j DROP
>$IPTABLES -A INPUT -p udp -s $GATEWAY --sport 53 -j ACCEPT
>$IPTABLES -A INPUT -p icmp -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p ! icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -i lo -j ACCEPT
>$IPTABLES -P INPUT DROP

So, you drop all fragments past the first one of each fragmented packet.
Meaning if a packet was fragmented in transit, you'll never going to
receive it.

'state INVALID' messages are in the start dropped only if they arrive from
eth0. I don't see a reason to accept 'state INVALID' traffic from anywhere.

At rather early phase you're accepting all RELATED,ESTABLISHED traffic. This
means that the ICMP-specific RELATED,ESTABLISHED rule later is redundant,
as is the RELATED,ESTABLISHED part of the rule starting with '-p ! icmp'.
Also note that there all 'NEW' non-ICMP traffic is accepted, basically
turning the chain policy into ACCEPT, leaving the INPUT ruleset pretty
much identical to:
-m psd -j DROP
-f -j DROP
-i eth0 -m state --state INVALID -j DROP
-p icmp -m state --state INVALID -j DROP
-p tcp --sport 135:139 -j DROP
-p udp --sport 135:139 -j DROP
-p tcp --sport 445 -j DROP
-j ACCEPT
.... so accepting most of all traffic, only blocking some select things.
This is the typical problem to making too selective matches in iptables
(or other firewalls as well): it makes unexpected holes.

Also, the 'RELATED,ESTABLISHED' rule will make the '--sport 53' ACCEPT
rule redundant. 'RELATED,ESTABLISHED' will allow all return packets
for currently known "sessions" to be passed. At netfileter level, "sessions"
also exist for datagram protocols like UDP (sending out a UDP packet will
open a "reverse channel" for a while (will accept packets originating from
the host and port that were marked as destination in the outgoing UDP packet).

Then after going through that tedious list of checks whether to allow or
deny, all packets from the loopback interface are allowed. This could
well be much earlier in the ruleset.

>$IPTABLES -A OUTPUT -p udp -d $GATEWAY --dport 53 -j ACCEPT
>$IPTABLES -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A OUTPUT -p ! icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A OUTPUT -o lo -j ACCEPT
>$IPTABLES -P OUTPUT ACCEPT

As there are no DENY rules, it doesn't make sense to have any allow rules
here either. You're anyway accepting everything outbound.

>$IPTABLES -P FORWARD DROP

Ok, not forwarding. Might as well turn the IP forwarding support off in
the kernel, then.

Then to propose a fixed ruleset that should be closer to what you attempted:
>$IPTABLES -P FORWARD DROP
>$IPTABLES -P OUTPUT ACCEPT
>$IPTABLES -P INPUT DROP
>$IPTABLES -A INPUT -i lo -j ACCEPT
>$IPTABLES -A INPUT -m psd -j DROP
>$IPTABLES -A INPUT -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p tcp --syn --match multiport --dports $LOCAL_SERVICES -j ACCEPT

Add the fragment-killing rule if you really wish, but I don't see the use
of it. Note, the ESTABLISHED,RELATED rule will allow some ICMP traffic
to your machine, as is necessary to carry the status information of
established TCP and/or UDP sessions. Inbound ICMP ehco (ping) is not
allowed by this ruleset. However, as you've opened two inbound service
ports, you might just as well allow inbound ping - the exitence of services
already gives out the fact that there's a live machine. What you might do
to the pings, though, is to rate-limit the traffic to conserve your uplink
bandwidth.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

On Wed, 14 Jan 2004 21:33:43 -0700, NeoSadist thoughtfully wrote:

> Noi wrote:
>
>> I think I would ACCEPT policy for OUTPUT
>> and DROP policy for FORWARD. Of course
>> you're dropping all traffic unless you explicitly
>> accept it in your rules.
>
> I don't think that's a good idea. First off, the idea of a firewall is
> "until I allow it, nothing gets through". Second, output can cause
> problems just as much as input, which is why -P DROP for OUTPUT and then
> filtering them out using state machine and port selection is the best way.
> However, it's preference, and honestly for a home user -P OUTPUT ACCEPT is
> probably ok, but I don't like the idea of it.
>

I was trying to post back to the original poster but maybe that post
rolled off so I used another. My point about OUTPUT was the original
poster was shutting down all output and allowing 1 or 2 ports. This
shuts down a lot of Linux services http, ntp, rpc, etc or whatever he did
not explicitly include, couldn't initiate connections because everything
had to be related, established.

[snip]
> DNS is UDP over port 53, and it's best to be VERY specific with
that
> part, like specifying where the packets are allowed to come from and go
> to.

That was the point I wanted to make to the OP.

>
[snip]
>> Some ISPs use icmp to heartbeat
>> the line for connectivity, no icmp then no dhcp or dns. How will you
>> test basic (access layer) connectivity? Telnet tests the application
>> layers, ie, user program connection.
>
> But I wouldn't use telnet for anything -- to insecure for my tastes...

Telnet is really useful for testing port connectivity locally, intranet
and internet and is a commonly open port unlike ssh.

>
>> Applies to INPUT as well because
>> you'd need to accept some ICMP if sending ICMP you can specify types of
>> acceptable ICMP.
>
> Which is what I said ... echo request (type 0) and reply (type 8),
> "network unreachable" "destination unreachable" etc...
>
>
>> GL
>>

--
------------------------------------------------------
Linux registered user #302812
using Fedora Core 1 kernel 2.4.22-1.2115.nptl
------------------------------------------------------