On Sun, 9 Apr 1995 21:24:00 -0700 Ivan COUCH said:
>Greetings network security cognoscenti:
>    We have an HP3000 as a node on a local network, along with two
>Novell servers, multiple DTC's and a growing number of PC's.
>Also connected to that LAN is a Cisco 3000 router, supplied by
>Riverside County, which provides our Internet connection.  Riverside
>County refuses to give us (or any of the other school districts connected
>through them to the Internet) any access to their router and its packet
>filtering capabilities.
 
How rude! :-)  I presume you only have one network in your district then,
and no local routing requirement.  We don't allow access to our router
either (not from downstream anyway) but you might be able to persuade them
to install an access list definition for your side.  I can give you a head
start there (ready-to-plug cisco definitions).
 
>    I'm considering putting another Cisco router between our network and
>the Riverside County router to act as a fire wall.  From the little that
>I've read about Cisco routers (we have no manuals, only a few pages of
>general info faxed from Cisco sales folks), I should be able to program
>the router to drop all incoming packets addressed to the HP3000, or drop
>all but the smtp packets to let Internet mail in, and so on.  I'm not
>clear on how ftp inbound/outbound works in this regard.
 
Yes, you can do this.  A small cisco can take your incoming serial link
and filter traffic going to the ethernet interface.  What you want are
called "extended access lists" which can specify:
 
   permit/deny  source-IP/mask destination-IP/mask [protocol] [rel-op] [port]
                                                or "established"
 
The "established" lets open connections go through unscathed and improves
router performance.  Then for each connection attempt, it checks the access
definition.  To allow any SMTP traffic, for example, you would:
 
   permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 tcp eq 25
 
Inbound ftp requires you to permit ports 20 and 21; telnet 23.
 
>    We have ThinLanLink/3000 running on the 3000 to allow virtual terminal
>sessions from our PC's that are running MiniSoft's network software.  This
>means that anyone with an Internet connection and MiniSoft or Reflection
>network software can immediately get to the MPE XL prompt on our system.
 
VT sessions are on ports 1537 and 1570.
 
>  - Is a router (Cisco or other) an adequate solution? (while keeping all
>     the local precautions in place)  Is there a better or more cost
>     effective solution?
 
You might try an option logon UDC to examine incoming VT session origin
addresses.
 
>  - If our local PC's (network connected, with IP addresses) are left
>     unprotected by the fire wall and are acting as stand alone computers
>     running DOS or Windows applications, can they be accessed through
>     the (Internet) network and thence the 3000?
 
They can be accessed if they are running any services (FTP server, etc) but
not otherwise.
 
>  - What if the above networked PC's are attached to a Novell server?
 
An FTP server "could" provide access to the Novell directories.
 
>  - Do Virtual Terminal sessions look at all different at the packet
>     level?  Do all the same filtering techniques work the same way
>     when a connection is requested?
 
Essentially the same, only the ports are different.
 
[\] Jeff "I survived IPROF 95" Kell
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Jeffrey R Kell, Dir Tech Services | Internet:     [log in to unmask]  |
| Admin Computing, 117 Hunter Hall  | or [log in to unmask] |
| Univ of Tennessee at Chattanooga  |    Voice:  (615)-755-4551         |
| Chattanooga, TN  37403-2598       |      FAX:  (615)-755-4025         |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+