archive-nl.com » NL » S » SANE.NL

Total: 288

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Second International SANE Conference
    of opportunities to meet other system administrators and network security professionals with similar interests while attending a program that brings you the latest in tools techniques security and networking A LETTER FROM THE PROGRAM CO CHAIRS Program Registration Hotels reservations Social event Conference dinner Useful to know BoF and WIP sessions Exhibition Sponsoring PGP Keysigning non party Internet Access Facilities The InSANE Quiz How to travel to Maastricht Our co

    Original URL path: http://www.sane.nl/events/sane2000/sane2000-home.html (2016-01-30)
    Open archived version from archive


  • NLUUG SANE 2000 Conference Pictures : index
    5 overview 6 overview 7 overview 8 overview 9 overview 10 overview 11 overview 12 overview 13 overview 14 overview 15 overview 16 overview 17 overview 18 overview 19 overview 20 overview 21 overview 22 overview 23 overview 24 overview

    Original URL path: http://www.sane.nl/gallery/conference/sane2000/index.html (2016-01-30)
    Open archived version from archive

  • First International SANE Conference
    A Letter from the Program Co Chairs Preliminary Conference Time Table with abstracts Wednesday Thursday Friday BoF sessions and PGP key signing party Registration Information Printable Registration Forms and On Line Registration Hotel Information and Printable Hotel Reservation Forms Conference Dinner Social Event Internet Access Facilities Our co sponsors USENIX and NLnet Foundation How to become a sponsor How to join the SANE 98 Trade Show Map of the SANE

    Original URL path: http://www.sane.nl/events/sane98/sane98-home.html (2016-01-30)
    Open archived version from archive

  • NLUUG SANE '98 Conference Pictures : index
    are available overview 0 overview 1 overview 2 overview 3 overview 4 overview 5 overview 6 overview 7 overview 8 overview 9 overview 10 overview 11 overview 12 Last modified

    Original URL path: http://www.sane.nl/gallery/conference/sane98/ (2016-01-30)
    Open archived version from archive

  • Outsourceware, Design and Implementation of a Distributed and Automated Intranet Server
    which links to the GUI parts of the other service modules top frame of Fig 3 Generic bin sh include files and perl libraries The most important configuration file is the master root file It contains all generic parameters like IP addresses netmasks extra DNS servers trusted hosts for the web based GUI and telnet ssh etc It contains variable value pairs and may only be read by two include files one for bin sh scripts one for perl scripts These include files can also be used for all kinds of backward compatibility tricks this will be shown in the section about multi machine IntraConnect later on Another important aspect of the master root file is that items like IP numbers are stored only once Other configuration files needing these parameters must retrieve them from this master root file by scripts In the past moving a machine to another IP addresses caused lots of trouble because of the large number of different configuration files containing one and the same IP address Fig 3 Administrator example of the services overview The three frames showed come from the general module admin The admin module deals with the user and group administration for all services and their accounting A user is a single person who can use the services from one or more IP address and or hostnames A group is either a collection of users belonging to for example the same department or any combination of IP numbers network slices and DNS domains see Fig 4 The group concept avoids the need to register every user and the user s IP address Fig 4 Flexible group definition example Note the various Hosts entries The Services list is automatically expanded when new services become available The admin module on IntraConnect deals with fine grained access control up to services per individual see Fig 5 and Fig 6 The reason for this fine grained access control is that not every company allows all of its employees to access all public Internet services The database of the admin module is used by other services to generate access files for those particular services Fig 5 Flexible user service permissions example Fig 6 Flexible group service permissions example The admin module also provides detailed accounting and reporting information which is very important for an outsourcing company like Origin In the case of Philips Origin deals with lots of different product division and business units each of which get their own bills based on for example megabytes transferred ntp dns smtp These are considered basic services which must be provided on every server machine together with the os and general modules of course The ntp service is implemented using the xntpd distribution The remote configuration consists only of a list of servers and peers Fig 7 shows an example of the NTP service status frame Fig 7 NTP daemon server status example The dns service is implemented using the bind distribution version 8 The configuration part consists of two files primaries and secondaries in very simple formats and DNS zone files without the SOA part in the case of primary zones From these files a named conf file is generated and complete zone files with a correct SOA record containing an automatically maintained serial number are generated The smtp service is currently implemented using sendmail 8 8 8 A script generates an M4 file from master root information and some additional configuration files Then using the normal sendmail M4 tools the real sendmail cf is generated If users are defined in the admin module the script will generate the appropriate aliases virtusertable and userdb files and their db versions The smtp service can handle multiple mail domains per server machine pop ftp http nntp The pop service is implemented using qpopper the ftp service using wu ftpd the http service using Apache and the nntp service using INN The http service is also multidomain capable INN has been extended with a mail to news gateway telnet ftp www and nntp proxies The telnet and ftp proxies are from the TIS firewall toolkit For www proxy we use Squid and for nntp proxy we use nntpcache which is the only news client that is allowed to talk to INN s nnrpd In this way we offer transparent access to company internal and external news servers All these proxies have been socksified to work with the socks based firewalls managed by Origin At Origin we separate machines for network perimeter security and proxy servers to keep the bastion hosts of the firewall as simple as possible no users no accounting etc Access files are generated using the user group database from the admin module Because the admin module allows almost every possible DNS domain and network slice notation some entries like 192 168 2 32 27 get expanded into multiple IP addresses for the telnet ftp and nntp proxies which do not support these notations During development we move scripts or routines from a normal service module to the general module as soon as that script or routine is necessary in other modules too This way a lot of duplicate coding is avoided when adding new services This also matches our store everything once approach for configuration items 3 2 3 Interfacing with a module As said before we have chosen not to store the files from our modules in the usual locations like usr local bin usr local etc etc but each module has its own directory tree under usr dibbs for example usr dibbs general Below such a tree we have the standard bin etc and lib directories furthermore we added config htdocs and cgi bin The reasons to do this are easy upgrades just move a directory and unpack a new module and backouts of upgrades move the old directory back It also avoids the need for a detailed file list per module and makes it possible to have scripts with the same names for each module For a binary module we defined some entry points the most important ones are listed below Filenames are relative to the root of the module for example usr dibbs general VERSION required for every module This is the file containing the version number of the currently installed module bin installer required This script has three possible parameters install install the module uninstall remove the module backout go back to the previous versions During installation of a module the module s tar gz file is extracted in tmp creating a tmp general directory Then cd tmp general bin installer install is run This will stop the current running service create a backout copy of the currently installed module install the new module in the appropriate directory optionally import local configuration files and finally reconfigure and start itself All these actions are done in a non interactive fashion so that they can be done from cron Although all services have their own installer script most of the installer routines are very generic and are defined in a library in the general module which is used by the installer scripts bin service required Each service script accepts four parameters stop start reconfigure regenerate all configuration files and restart the service and check for correct operation A simple way to implement the reconfigure part of the service script is to call the stop routine regenerate all configuration files and call the start routine However for many of the services the reconfigure is done by just regenerating the configuration files and giving the service daemon a signal normally HUP to make it reread the configuration files This leads to less or no service interruption The service script of the general module has two extra options startall and stopall to start and stop all other services bin hourly daily weekly monthly optional These scripts are used for module specific hourly daily weekly and monthly tasks The general module makes sure these scripts are called from root s crontab bin rotate optional This script rotates one or more logfiles It is executed daily at 00 00 cgi bin menu cgi optional This is the CGI script which generates a web page containing the main menu for the service It is called from the main menu in the general module config filter conf This file contains the filter rules regular expressions for monitoring the service The general module creates one single filter conf file from the individual filter conf files to be used by the filter program discussed in chapter 5 4 Automated installation and upgrading Automated installation and upgrading is primarily a method to achieve scalability and to keep the costs down It is also a good method to guarantee global service consistency as every local modification other than those made by the local administrator though the GUI will disappear after the next automated upgrade A first time installation procedure should be a special upgrade procedure upgrade from nothing For the local administrator a service backout option restore the old working situation should be available as a quick fix for any possible undesirable effects experienced by end users after an automated change which is solely under remote control Upgrades must only be performed in the customers change window but in case of problems the local and global service delivery organizations must be informed so they can take the necessary actions needed to solve the problem Only a few minutes of service interruption should arise in a normal change window 4 1 IntraConnect implementation The initial installation is done by a specially prepared boot floppy for the PC based IntraConnect This floppy creates a RAM disk retrieves the necessary modules and runs the installer of the OS module This partitions the hard drives installs the OS and the general module and reboots the system after the local administrator removes the floppy Normally we perform this initial setup ourselves and then ship the box but we have also used email to send an image of this boot floppy to for example Brazil because the hardware was bought locally 4 1 1 Distribution server Because the binary modules are the same for all IntraConnect servers we wanted to store them in no more than one location We created a so called distribution server for this purpose On this distribution server every IntraConnect has a private directory in reverse FQDN notation like e g com philips ms best All remote configuration modules are stored here For the binary modules we use symlinks from these private direcories to a special binary module only directory with a name given by GNU s config guess script for example i386 pc bsdi3 0 In this way a distribution server can support multiple platforms As proof of concept the distribution server has been implemented as a normal FTP server Minimal security is implemented through a tcp wrapper This will be improved and extended in the future as we require more security and a push variant for non intranet servers normally the servers can pull the modules from the distribution server but for servers outside the firewall this might not be allowed because of security reasons 4 1 2 Change window During the change window configured in the master root file all modules are checked against the version on the distribution server This event is initiated by cron on the IntraConnect server itself If there is a newer version available it is fetched unpacked and installed automatically At the end of a change window an overview of the actions performed is sent to the remote administrators A typical change window causes between one second and one minute service interruption per upgraded service 4 1 3 OS upgrade Even the OS itself is a module although the installer differs a lot from the installers in the other modules The IntraConnect server uses two boot hard disks only one of which is used at any time We call this a dual boot setup We took the idea from our Origin firewalls and extended the OS upgrade process to run unattended During an automated upgrade the OS module performs all actions on the other boot disk This provides an easy backout possibility the advantage of being able to backout an upgrade greatly outweighs the cost of an extra disk At the end of the installation of the new OS on the new disk usr dibbs usr config are copied to the new bootdisk and a fresh general b c module is saved on the new disk Only at the end of the OS upgrade are all services stopped by calling service stopall and after changing either the server s boot prom Suns or the boot default configuration file BSD OS to configure the new boot disk the system is rebooted When the system comes up from the new boot disk it detects the first boot after an upgrade installs general b and general c which configures everything needed in etc such as its IP numbers and hostname and boots further starting every service with service startall The var news and cache partitions are located on separate data disks and thus need not be copied during an upgrade The whole OS upgrade can cause up to 4 minutes service disruption this is highly dependent on the amount of RAM in the machine which has to be counted during boot the HP Netservers we use have slow memory tests 5 Automated monitoring Monitoring is crucial in guaranteeing the service level and in communicating the achieved service levels to the customer What needs to be monitored largely depends on the agreed service levels As usual scalability requires that monitoring is an autonomous process Only if something is found to be irrepairably wrong human intervention should be required 5 1 Requirements for monitoring Outsourcing companies must be able to show that an agreed service level is met Therefore every service must be checked for proper functioning at regular time intervals We recommend that this functional checking is performed by the server itself and that event driven alerting is used above the standard SNMP polling based methods This greatly reduces the amount of network communication used by the monitoring process expensive WAN links Furthermore when the network link to the monitoring station fails the service checks also fail with polling based methods This is not the case when the server checks itself Event driven methods scale better than polling based ones A queing mechanism for the alerting messages is strongly advised because of the same network failure reasons Therefore we also advice against the use of SNMP traps The service check should be more than just verifying that a given daemon process exists Proper functioning of a service should also be checked Useful methods include protocol level questions with known answers or the typical welcome to this protocol messages When the server discovers that something is not functioning properly it should notify a central monitoring location Failure in the self checking functionality of the server will result in loss of the notification Therefore the server should send so called heartbeats to the central monitoring location using the same mechanism If the self checking mechanism fails the loss of heartbeats will be detected by the central monitoring location 5 2 IntraConnect implementation The self check mechanism for services is provided by the service check command for each service This command is run every 15 minutes from the cron daemon If the service check notices an error it reports this via syslog Most of the services themselves also use syslog Heartbeat messages are generated from the general module every 15 minutes and are logged via syslog The heartbeat message contains the current UTC date and time in ISO format The syslog file var log messages is tracked in real time by a program called follow and filtered based on regular expressions by a program called filter to service specific log files in var log modulename Every service has at least a messages log file for just informative non priority messages an acct log file for accounting data and daily low high and alert log files for messages of different priority Any message not filtered explicitly by a regular expression is directed to the high priority log file This forces us to classify any unknown messages in an appropriate category daily low high alert The contents of these log files are sent to the central monitoring station every 1440 1 day 60 15 and 1 minutes if there is new data in it of course The heartbeat messages follow exactly the same path through the system as the output of the check scripts and the logged events from the services start from cron log via syslog then filtered via follow and filter and put into specific log files and then processed by a script run from cron We can thus be sure that all critical system processes are operational when we receive heartbeats If a heartbeat is not received within 30 minutes the central monitoring station generates an alert message itself Absence of the heartbeat means that either the self check mechanism is not working or that there is a network outage between the IntraConnect server and the central monitoring location All heartbeats and logging messages are sent using SMTP to preferably the IP address of the central monitoring station We use IP addresses to prevent dependency on other SMTP hubs All we need is a properly functioning network between server and monitoring station We did not want to rely on UDP based services like SNMP traps because of the unreliability of UDP and because of systems outside proxy based firewalls Despite the complexity of two SMTP setups this system has proven to be stable and reliable during the four years that we use it Our experiences show that in general we as a service provider can react quickly to service problems and that we are sometimes even able to solve problems before the customer detected that there

    Original URL path: http://www.sane.nl/events/sane98/aftermath/lambermont/full.html (2016-01-30)
    Open archived version from archive

  • Net Insecurity: Then and Now (1969-1998)
    anonymous way 3 There is lingering affection for the challenge of breaking someone s system This affection lingers despite the fact that everyone knows that it s easy to break systems even easier to crash them All of this would be quite humorous and cause for raucous eye winking and elbow nudging if it weren t for the fact that in recent weeks at least two major serving hosts were crashed under suspicious circumstances by people who knew what they were risking on yet a third system the system wheel password was compromised by two high school students in Los Angeles no less We suspect that the number of dangerous security violations is larger than any of us know is growing You are advised not to sit in hope that Saint Nicholas would soon be there I think that all of us may crack a smile here crackable passwords phone numbers on Stickits and walls breakins by high school students In September 1971 there were 18 hosts on the ARPANET At the time Metcalfe was writing there were 31 host sites In October 1974 there were 49 In January 1976 there were 63 A decade later February 1986 there were 2 308 five years thereafter January 1991 there were 376 000 This number has doubled every year since The number of users is what has made us increasingly insecure The exponential increase over the past few years has made the system increasingly fragile in terms of security or better insecurity 3 More about UNIX Maurice Wilkes had discussed password security in 1968 Time Sharing Computer Systems The FIPS concerning DES appeared in the Federal Register 40FR12134 on March 17 1975 Morris and Thompson published their Password Security A Case History soon thereafter It has appeared in many editions of the BSD documentation It is co AT T 1979 Dennis Ritchie s contribution was a brief article On the Security of UNIX also co 1979 and in the BSD documentation and SUID for which he holds US Patent 4135240 Protection of Data File Contents January 16 1979 Ritchie told me about the patent application The patent was rejected at first because the examiner was unconvinced that the disclosure was complete and explicit enough for a person ordinarily skilled in the art to implement it So I wrote a tiny toy OS framework with Unix protection modes less SUID and we gave it together with the patent to a bright guy new to Unix in the local Comp center He succesfully added SUID to the code and a brief affidavit from him fixed the problem q in 0 SUID and SGID still provide a way to grant users system access to which they are not otherwise entitled This is extremely useful but it also makes us insecure in other ways In 1984 Grampp and Morris wrote a brief article on UNIX Operating System Security It contains four important handles to computer security Physical control of one s premises and computer facilities br

    Original URL path: http://www.sane.nl/events/sane98/aftermath/salus.html (2016-01-30)
    Open archived version from archive

  • SANE 2006
    Go back to home page SANE 2006 Click on a picture to enlarge it Generated by Galerie

    Original URL path: http://www.sane.nl/sane2006/pictures/sane-150506/ (2016-01-30)
    Open archived version from archive

  • SANE 2006
    Go back to home page SANE 2006 Click on a picture to enlarge it Generated by Galerie

    Original URL path: http://www.sane.nl/sane2006/pictures/sane-160506/ (2016-01-30)
    Open archived version from archive



  •