[unisog] Preventing Dsniff/Arpspoofing
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.
Systems Engineer, NET
George Mason University
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
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
Security Engineer - Technical Services
James Madison University
More information about the unisog