[unisog] Preventing Dsniff/Arpspoofing

Steve Bernard sbernard at gmu.edu
Fri Jun 14 15:26:25 GMT 2002


By default Banner uses HTTP and a low-grade encrypted Java channel for
client-server communication. HTTPS can be used by adding SSL certificates to
the Oracle/Apache server. Inter-server communication, primarily
SQL*NET/NET8, is not encrypted by default.

For high-security situations, like HIPAA compliance, which may require
end-to-end encryption of data, devices like F5's or NetScaler's appliances
not only do SSL offload but, can also create a secure channel between two of
the devices. In a web-based ERP environment (such as Banner), one device
would reside in the DMZ, load-balancing traffic and offloading SSL sessions
to the front-end web servers. The other device resides in the
private/internal network, possibly load-balancing and offloading SSL
sessions. After the inter-device SSL channel is setup, all DMZ <-> internal
traffic is encapsulated in an SSL tunnel. Another benefit is that you can
hang an IDS or other device behind the SSL accelerators to monitor the
traffic unencrypted. If you terminate your SSL tunnels at each server then
you would need to use host-based IDS or other monitoring tools separately on
each server and then try to aggregate and correlate logs/events later. Of
course, the firewall now only sees SSL communication between the two
accelerators in the DMZ and internal networks and won't be able to enforce
additional policy on those communications. So if you have machines A,B,C in
the DMZ and X,Y,Z in the private network and only A and B should be able to
talk to X and Z, but not Y (or something like that), then you will have to
rely upon the filtering capabilities of the SSL accelerator/load-balancer or
add additional enforcement devices behind the SSL accelerators.


Regards,

Steve Bernard
Systems Engineer, NET
George Mason University


-----Original Message-----
From: Gary Flynn [mailto:flynngn at jmu.edu]
Sent: Friday, June 14, 2002 9:29 AM
To: 'Mark Brochu'; 'Unisog'
Subject: RE: [unisog] Preventing Dsniff/Arpspoofing




> -----Original Message-----
> From: Mark Brochu [mailto:mbrochu at mail.hartford.edu]
>
> Any random thoughts :)

Heh. Those I have plenty of :)

1) I put up an experimental stunnel box with mixed results. It
   was primarily for email sessions. I tunneled IMAP, SMTP,
   IMSP, and NNTP. Results were mixed.

   a) Netscape 4.x and 6.x clients worked fine for all protocols.
   b) Outlook 2000 and Outlook Express had problems with SMTP and
      sending email. (If this gets through, Outlook XP may have
      resolved the problems. I just got a new computer and I'm
      still using Outlook. :)
   c) My limited testing with Mulberry seemed to work.

   We're going to get a new email server with native SSL support
   so I didn't pursue the tunnel approach.

2) There is a program, I think its called arpwatch, that will monitor
   arp traffic and alert you on storms and other activity which may
   indicate attempted use of arp poisoning tools. I suspect you'd have
   to have it on every segment for it to be useful though which limits
   its practicalities. Similar functionality may be provided through
   monitoring of router and switch arp and MAC tables through SNMP and
   be more scalable.

3) Hard coding of ARP tables in routers and critical hosts and allowed
   MAC addresses in switches where it is maintainable for sensitive
   areas may be another possibility.

4) VPN protection for critical apps may be a possibility too if the
client
   will only talk to servers with certain certificates.

I'm not familiar with Banner as we use PeopleSoft. Depending upon the
particular applications in use, PS sessions are protected by:

1) Oracle encryption
2) Tuxedo encryption
3) SSL web sessions

I'm surprised Banner doesn't have something similar.

If you get static about your push to encrypt applications, load
up ettercap on a segment and show people the passwords flying by.

We had a box compromised and a similar tool was installed. The log
files we found on that box convinced a lot of people of the necessity
of encryption and the lack of protection provided by switched networks.

You also need to include a blurb about not ignoring SSH and Web
certificate warnings in your security awareness program. Ettercap,
for one, will hijack SSH and web sessions although the client will
display a certificate or key mismatch message when the attempt
is made.

Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe





More information about the unisog mailing list