[nos-bbs] Access control lists

[Barry Siegfried]

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

> On Tue, 2008-06-03 at 20:21 -0400, Barry Siegfried wrote:
>
> > ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

[snip]

> > 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?
>
> Actually NO...  The destination is my host with a 44... IP

Ok.  But that's not quite what you originally said.

> from a 66... IP who I *presume* is a spammmer searching for a patsy.

Maybe, maybe not.  I realize now that the route for the 66... IP
into your machine is over an RF LAN from hamgate.ottawa.  Ok, *now*
I have the picture.

> My access is defined to allow only 44... IP over RF so this packet
> would qualify to be dropped inbound if access worked that way...

Yes it would.  However, dropping *inbound* with 'ip access' still
means that the IP layer *still* has to "read" the packet.

> > 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.
>
> Well -- that is a good point because the specific link IS a vc so
> that ACK is appropriate,

Yes.  The AX.25 VC ACK from your machine back to your gateway over
your RF LAN *is* "appropriate".

> still, my SMTP does respond and the response does get dropped into
> the bit-bucket.

If you are using "classic" JNOS 'ip access' which filters *outbound*
traffic based on interface then, yes, IP will pass the frame to TCP
and TCP will attempt to reply with a SYN ACK.

[snip]

> > When you say "to process" I assume you mean the AX.25 "ACK", yes?
>
> Actually no -- The ACK is low in the model, I mean SMTP in this case
> which is has a client/server relationship with the outside world.  There
> are many servers available in jnos, I'm questioning all of them.  You do
> bring up a good point though, the network layer could generate an ACK in
> the absence of the SMTP response if SMTP were delayed for some reason
> and that would demonstrate presence of my node to a physherman, but at
> this point I *presume* access would drop even the ACK.

The AX.25 VC ACK will *always* be there and happens to occur at the
link layer (2).  You can not prevent your machine ACKing the incoming
(and unwanted) at AX.25.  The network (IP) layer doesn't generate ACKs.

> > 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.
>
> HHMMMM -- "can be moved"?  Without reprogramming?

No, of course not.  To implement 'ip access' on the input you would
have to move the code some within ip_route() and eliminate the check
of output interface because it is not necessary anymore.  This would
also eliminate the need for having an interface pointer variable in
the 'ip access' struct as well.

> I missed how to convince access to look at incoming frames.

Well, in this particular case, you could have 'tcp access' look
at the frame which *will* kill it on the input.

> Would you point me to the document that explains that detail?

We're talking apples and oranges here.  'ip access' filters OUTPUT
frames that are addressed *through* this machine.  Yes, 'ip access'
*will* catch frames addressed *to* this machine, BUT, using "classic"
'ip access' it won't get them until the network (IP) layer sees the
output frame.  You are using the wrong tool for what you are trying
to accomplish, which is to prevent SMTP from ever seeing the original
SYN.  Use 'tcp access' instead.  'tcp access' (and 'udp access' if
JNOS has that) filters INPUT frames which are addressed *to* this
machine.

> I do resist a reprogramming effort, but if it will configure to
> filter input I'd like to know how.

You need to use 'tcp access' instead of 'ip access'.  'ip access'
is really only necessary to run on machines *through* which packets
switch between two networks.  In other words, if your machine were
switching between two (RF) LANs, then *maybe* 'ip access' might be
appropriate for you to run so that frames from the "outside" LAN
don't get through to the "inside" LAN, but that is not the issue
here.  What you really need to do is 'tcp access' instead which
*will* filter on INPUT for the applications running in your own
machine.

My reference to "moving" 'ip access' to look at input frames is
something I did a while ago in the NOS that I use.  In order for
you to have JNOS do that, Maiko would have to port it if he desires
to, and somehow I suspect that this will NOT be high up on his
"to-do" list.  :)

> In reality, the wasted time is little impact in my [most?]
> circumstances, my prime worry is the danger presented by a clever
> cracker who gets the server to do something BAD.  You know -- exploit
> buffer overrun and stuff like that.  If I could apply access rules
> to input, then this worry is off the table.

Use 'tcp access' for what you are trying to do here.

> THANKS for the response Barry.  As a separate subject I'm beginning
> to consider an appeal to my neighbors on this subject that might
> prevent the bogus packet from arriving and that also reduces my risk.
> Still, a hardened site appeals to me for my own use.

As a general rule, do not rely on your "neighbor" upstream to
filter out traffic you don't want.  They will likely tell you that
filtering your own packets and protecting your own machine is your
own responsibility, which technically, it is.  But in the interests
of keeping unwanted non-44 frames off of our RF LANs, then it might
behoove the operator of hamgate.ottawa to put in some 'ip access'
for his gateway so that you never get to see them in the first
place.  :)

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 |
+----------+----------------------------+