Phare EIONET Centralised Training Session EIONET node Architecture & Connectivity

Overview of the Presentation EIONET node components Physical architecture Logical architecture Variations IP Addressing issues Additional servers Management of the node Questions & Comments

Eionet node components (standard architecture layout) Internet link Access server (router) EIONET server(s) Firewall node’s LAN

Physical architecture The only requirements from the point of view of physical connections are: EIONET server should be connected to Internet EIONET server should be connected to LAN LAN should be connected to Internet.

Logical architecture “The Internet” is able to access EIONET services LAN should be able to access EIONET services + other services (ex. Mail retrieval) Access to EIONET server(s) should comply to EIONET security policy Access to LAN should comply to local security policy

Logical architecture (cont. …) And that meens… LAN topology and existing wiring style may may impose different solutions than the “standard” EIONET node schematics Local security policy may require ALL computers to be “behind firewall” Internet provider change may also change the interface to an unsupported one ... Etc. ... …we could need variations

Variations Variations in EIONET node’s architecture are possible as long as they implement: Physical connectivity constraints Logical connectivity constraints Compliance to EIONET security policy (applicable to EIONET server(s) Invariance of the way OTHERS see and access your node’s services

Variations (cont. …) In punch-lines: You should ensure the possibility of implementing two (usually) different security policies; eventually on the same machine … You should be able to reliably distinguish between LAN users accessing EIONET server and Internet users AGAIN and AGAIN: your structure should be functionally equal to all other EIONET nodes

Phare EIONET Centralised Training Session Practical issues

large number of workstation in LAN IP addressing scheme When deciding the actual addressing scheme, each EIONET node faces one or more of the following constraints: reduced number of registered IP addresses provided by ISP (a quarter of a C class or less) large number of workstation in LAN foreseeable growth in number of servers/workstations both in LAN and Internet exposed

Terms IP address; dotted decimal notation Network mask Classfull and classless subneting Subnet and Host ID Subnetzero

IP network classes

Divide the available range of addresses

HW &. SW subnetting

Custom Subnetting: the steps

Chart for class C Networks

Determine subnet ID

Last step: Numbering Hosts

Additional servers Physical and logical location of additional servers inside EIONET node structure should be decided studying: Server audience (in terms of: LAN and/or Internet clients) Server capabilities (in terms of protecting itself) Impact to other servers and the node’s structure

Additional servers (cont. …) Open Access Reverse proxy, multi class segment, etc ... EIONET security policy

Management of the node There are several aspects of the node management: System management: servers, routers, firewall(s); includes system backup/restore activity Network management: connectivity, performance, network services Application management: software installation, patches & upgrades; includes applications’ backup, data migration etc. ... System, Network and Applications monitoring: logs, events etc.… Security management: monitoring, updates, alarms, crisis scenarios preparation etc. ...

System management Basic responsibilities for the EIONET node systems manager: SO patches and upgrades: to be performed with balance between fixing bugs, enhancing functionality and keeping full compatibility with installed applications Backup of vital system configuration data before any SO changes and/or reconfigurations are planned Monitors event logs, disk and other resources usage and reacts accordingly to situations that may affect availability and/or quality of services offered by the respective systems Keep users informed of changes, interrupts in operation and client side targeted security threats (I love you message …)

Network management General guidelines: plan carefully structural changes; better still: avoid them monitor network performance at all times, determine the bottleneck before users can feel it if network complexity requires install automated SNMP tools to trap and alert you on unwanted events

Questions & Comments