Internet Security Concerns and Securing Telnet, etc by uxu13127


									Internet Security Concerns
and Securing Telnet, etc.

      Setting your paranoia level and
      what to do about it(?)
 Old and New threats
 Sensible Security Precautions
 Protecting your password
 Secure communications (client/server)
Fundamental Tenet of Security

 Trust No One
  Security is everyone’s responsibility. The easiest way into any
          computer system is by tricking a nice person.
Good Password Habits
 Change password periodically
 Choose a good password
    – No easily guessable words, phrases or dates
    – Use a phrase plus a number
    – Use a different password on different systems
 Don‟t write important passwords down
 Report potential password violations
    – “failures since last successful login”
Good Password Habits (Cont’d)
   Only you should know your password
    – This is why passwords are “pre-expired”
    – Even the “administrator” should not know our
   Don‟t give you password to ANYONE!
    – DAS Staff should never need your password
    – If you do give your password to someone change it
   If you think someone got your password:
    – Change it immediately
    – Report to DAS for investigation
Saving Passwords is Evil!
   Don‟t let mail clients or browsers “save”
    your important passwords
    – It may be convenient, but it means your
      password is stored in local workstation and is
    – Anyone with physical (or network) access to
      your computer may be able to acquire or use
      your password
Not just your DAS password
   Don‟t just be paranoid about your DAS
    –   STRS reporting
    –   On-line banking
    –   Local file/print sharing network
    –   Other mail systems
   Many sites or services can have financial
    impact or threats of impersonation
Don’t be annoyed by your DAS when:

 They log you out automatically
 They pre-expire your password
 Your password expires
 They don‟t believe you are who you claim
  to be
Technical Threats to your password and
 Most Internet connections to computers are
  “unsecured” (unencrypted or “plain text”)
 It is possible for „eavesdroppers” to pluck
  your password from the wire
 Physical security of wire is important
    – As networks grow and become more complex
      physical security is less certain
    – “Access from Home” becomes dangerous
Network security
   From inside the DAS
    – Networks are “switched” and relatively secure
    – But still a reason for concern
   Access from dialup modem (ISP)
    – Packets travel directly to ISP, then across global
   Access from DSL or Cable modem
    – Packets visit all your neighbors as well as ISP
    – The neighbor kid could snag your password
Solutions for Unsecured Networks
   Encrypting data between computers
    – Only cooperating machines can read the data
    – Eavesdroppers see only gibberish
   Two broad solutions:
    – VPNs (Virtual Private Networks)
          Client connects to known network with authentication
          All communication with that network becomes encrypted
          Requires software/configuration in both networks
    – SSL for each application
SSL for each application
   TLS (or SSL) is widely adopted for:
    –   HTTPS for web sites
    –   SSL/TLS for email (POP, IMAP, SMTP)
    –   SSH for Telnet (terminal emulators)
    –   SSH for FTP (file transfers)
   Each of these encrypts both the
    username/password and the data
NWOCA Implementation
   NWOCA has implemented SSL for:
    – Email (POP/IMAP)
    – Some web servers
    – Currently optional, but will begin to require
   Will be implementing secure TELNET
    – Will be required for connections from “outside”
   Implementing VPN for some users
   May require new software and/or configuration
What You Can Do
   See what encrypted services are already
    – POP/IMAP mail clients
    – SSH for Telnet
    – HTTPS for web sites
   Encourage DA Site and Tech Coordinator to
    implement SSL or VPNs
   Be cooperative when they do:
    – May cause some pain:
          New software (upgrades or replacement)
          Configuration changes
Services you should be concerned about

   Any place you type your password for
    important and sensitive information:
    –   DA Site account (Telnet for state software)
    –   Email client
    –   FiscWeb
    –   SSWAT or DSL
    –   Et al.
   All computers should have virus scanning
    – To protect both data security and workstation
    – Even if DA Site virus scans email
    – Multiple levels of protection are necessary
   Keep virus scanners up-to-date
    – Scanners only catch virus they know about
   Be suspicious
    – even if it‟s “someone you know”
    – Only open attachments you were expecting
   Hoaxes are human viruses
    – They trick humans into doing something
    – Never forward a “virus warning”, especially if
      it‟s from a “friend”
    – If concerned about a particular warning,
      forward it to DAS or network staff for
Spotting a hoax
 “Send this to everyone you know”
 Doesn‟t say what type of computer it
 Claims to come from a “reputable” person
  at: Microsoft, IBM, some virus company,
  CNN, etc, etc.
 Claims unbelievable catastrophe if you
  don‟t immediately delete some file(s)
Other Miscellaneous Things
   Don‟t use work email address for personal
    – Your personal mail may become public record
   Review District‟s Acceptable Use Policy
    – Consider adding password rules
    – Consider requiring “secure” connections for
      remote or internal access
Related Sites (Virus and Hoax Lists)
Technical Details
   TLS/SSL:
    – Operates at application/socket level
    – Each application must provide support or some knowledge of
           Either provides special port, e.g.:
              – HTTPS = 443, IMAP/TLS = 993, POP/TLS=995
              – Client must connect to correct port
           Or provides mechanism to negotiate TLS over standard port, e.g.:
              – ESMTP port 25: STARTTLS
   If committing to secure connections only then:
    – must block non-secure ports at firewall
    – or disable non-secure ports on server
SSH, Secure Shell
   Secure replacement for:
    – TELNET
    – Can tunnel for other protocols
   Listens on port 22
   Client and server transfer keys for encryption and
    optionally authentication
   Authentication methods:
    – Password
    – Host Authentication (RHOST with host key)
    – RSA Auentication (user key)
Configuring SSH1/SSH2 on Multinet
   Multinet 4.4 supports both SSH
   Similar configuration for both:
     – Enable SSH service
     – Generate host keys for SSH1 and/or SSH2
   See Multinet “Installation and Administrator Guide” for
     – Read carefully, especially “intrusion detection”
   If using:
     – Password authentication, nothing else to do
     – If using host or user RSA authentication, then must move host
       and/or user keys to remote system
     – See Multinet User Guide
Example: RSA Host authentication with SSH1

 !Host authentication:
  Last interactive login on Tuesday, 17-SEP-2002 12:18:23.15
  Last non-interactive login on Tuesday, 17-SEP-2002 08:19:43.76
 $ type .rhosts smith
 $ type [.SSH]known_hosts. 1024 33
Example: Password authentication with SSH2

 $ MU SSH2

  Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3

 smith's password:
 smith's password:
 Authentication successful.
     Last interactive login on Tuesday, 17-SEP-2002 12:22:53.66
     Last non-interactive login on Tuesday, 17-SEP-2002 12:23:23.28
         1 login failures since last successful login
Example: RSA Authentication with SSH2
Directory NWB:[SMITH.SSH2]
IDENTIFICATION.;2                         1/9       15-SEP-2002 19:21:54.37
ID_DSA_1024_B.;1                          2/9       15-SEP-2002 19:21:13.68
ID_DSA_1024_B.PUB;1                       2/9       15-SEP-2002 19:21:13.77
RANDOM_SEED.;1                            1/9       14-SEP-2002 19:29:45.19
idkey ID_DSA_1024_B
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3
Authentication successful.
   Last interactive login on Tuesday, 17-SEP-2002 12:27:12.47
   Last non-interactive login on Tuesday, 17-SEP-2002 12:23:23.28
$ DIR [.SSH2]
Directory DKC100:[SMITH.SSH2]
AUTHORIZATION.;1             1    15-SEP-2002 19:15:53.69
HOSTKEYS.DIR;1               1    14-SEP-2002 21:54:34.90
ID_DSA_1024_B.PUB;1          2    15-SEP-2002 19:21:13.77
RANDOM_SEED.;1                1   14-SEP-2002 19:15:20.54

Total of 4 files, 5 blocks.
key ID_DSA_1024_B.PUB;
Example: Tunneling with SSH2
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3
Authentication successful.
    Last interactive login on Tuesday, 17-SEP-2002 12:36:28.06
    Last non-interactive login on Tuesday, 17-SEP-2002 12:23:23.28
! From another Session:
2020EB1C            0   0   LOCALHOST(2300)                *(*)

$ telnet localhost /port=2300
Trying... Connected to LOCALHOST.
NWOCA7, Version V7.1
Username: smith
    Welcome to OpenVMS (TM) Alpha Operating System, Version V7.1 on node NWOCA7
    Last interactive login on Tuesday, 16-JUL-2002 13:32:36.78
    Last non-interactive login on Tuesday, 17-SEP-2002 12:40:26.70
$ show users/full smith
        OpenVMS User Processes at 17-SEP-2002 12:43:40.04
    Total number of users = 1,         number of processes = 1
Username Process Name         PID       Terminal
SMITH       SMITH           00000547    NTY16:     (
Example: Tunneling with SSH2 (cont’d)
! Or from another system:
C:\> telnet 2300

NWOCA7, Version V7.1

Username: smith
    Welcome to OpenVMS (TM) Alpha Operating System, Version V7.1 on node NWOCA7
    Last interactive login on Tuesday, 17-SEP-2002 12:43:33.41
    Last non-interactive login on Tuesday, 17-SEP-2002 12:40:26.70
More about VPNs

   Requires:
    – VPN server/concentrator
    – Client software and configuration
   Client software:
    – Makes connection to VPN server
    – Authenticates client (user/password, certificate)
    – Tunnels all or subset of network activity thru VPN
   All communication occurs over secure tunnel
   Client participates in private network, as if it
    were physically connected.
To TLS, VPN or Both
   TLS appropriate for:
    – Outside users who need access to specific services
   VPN appropriate for:
    – Users who need full access to network
    – E.g. DAS staff who need MS Networking or Terminal
    – To protect hosts that have special security
NWOCA is doing both
   TLS enabled on all major services
    – Users encouraged to use now
    – But have not yet blocked unsecure ports from outside
    – Will permit inside use to stay unsecure, for now
   SSH ready, but not in use yet
    – Outside users will eventually be forced to use SSH
      enabled emulator, or Persona
   VPN for staff and specific users

To top