[nos-bbs] Access control lists

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> Greetings to all.
>
> I'm looking over the subject of access control, and I've applied a
> little of it on my site.  So far it seems to be doing what it was
> designed to do.
>
> Here is something I see in how it operates:
> A bogus SMTP SYN packet arrives via my radio port.

In other words, somebody on the radio side of your machine sends
a SYN for an SMTP connection *through* your machine to another
machine off your site somewhere and you don't want to permit that
SYN to travel through your machine, yes?

> My site ACKS it and processes the SYN then frames a response.

What you are saying here is ambiguous.  Is the SYN addressed
to your machine or is it addressed to a machine that is off
your site?  If it is addressed to your machine then yes, your
machine would be expected to frame a "response" to the SYN.
But what I *think* you are talking about here is an SMTP SYN
frame that is traveling toward a destination that is off your
site but has to travel through your machine to get to it.  In
that case, your machine never actually "sees" the SYN because
it is never passed from IP (layer 3) to your TCP input handler
(layer 4).

So, I am therefore extrapolating that you are talking about 'ip
access' here and not 'tcp access' and that the "ACK" to which
you are referring above is being generated by an AX.25 VC
(virtual circuit) that is carrying IP.

> The response is placed on the stack then access silently drops
> it.  The response does not transmit.

Now, about which stack are you talking?  Do you mean the Hopper
(the NOS "Hopper" is the network() process through which *all*
packets, incoming and outgoing are dispatched).  And if you mean
the Hopper, then the frame ends up NOT being transmitted to the
interface for which 'ip access' is filtering "bogus" SMTP connections
in your machine, yes?

> The objective is met -- the bogus record never gets a response.
> That is good.

I presume you mean the bogus packet here.

> I'm comparing iptables from Linux as a model to jnos access controls.
> ONE difference I see is that iptables filters both in and out traffic,
> so *if* iptables technology were applied to jnos the bogus SYN record
> in the above sample would would be dropped during input handling and
> would not cause my site to process.

When you say "to process" I assume you mean the AX.25 "ACK", yes?
The answer to *this* part of your question is, even if 'ip access'
were operating on the input frame, the AX.25 layer would still be
required to "ACK" the incoming frame because it knows nothing at
all about what it is carrying (which in this case happens to be
IP).  The filtering is done *after* the frame is passed from AX.25
(layer 2) to IP (layer 3).

> I wonder if not dropping input opens jnos up to known problem
> attacks because access stops only output?
>
> Thanks for considering this!

The fact that 'ip access' in JNOS does this doesn't particularly open
it up to any more "attacks" than it would normally be under but what
it does do is waste time figuring out if an output frame on *this*
interface should be authorized when checking the interface is actually
superfluous since the IP route to the specific destination IP address
can only be via a single interface.  For that reason alone, yes,
'ip access' can be moved to look at input frames and can check both
the input and output IP address (and ports) at that time.  It will
make the IP layer in NOS perform a little "faster" if it doesn't
have to pass an "unwanted" frame to its IP output handler.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+