[nos-bbs] Access control lists

[(Skip) K8RRA]

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

> 
> 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 from a 66...
IP who I *presume* is a spammmer searching for a patsy.  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...


> 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, still, my SMTP does respond and the response does
get dropped into the bit-bucket.


> 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?
YES -- only the word "hopper" is unfamiliar to me.  As long as "hopper"
and "stack" are interchangeable we are on the same page.


> 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 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?  I missed how to
convince access to look at incoming frames.  Would you point me to the
document that explains that detail?  I do resist a reprogramming effort,
but if it will configure to filter input I'd like to know how.

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.

> 
> 73, de Barry, K2MF >>
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.

73
de [George (Skip) VerDuin] K8RRA k