[NTLUG:Discuss] Recommendation for "Log File Analysis" and firewall updater Software/system/program

[Bryan J. Smith]

[ Collection of responses from LEAP/NTLUG ]

On Sat, 2004-12-11 at 01:38, David Simmons, PE wrote:
> Subject line say's it all...I keep noticing multiple ssh login
failures
> (which are not me) and while I feel good about my passwords - I know
> it's just a matter of time!? Want something that auto-magically
analyzes
> the logs to secure the system.

Response Breakdown:  
- Auditing, IDS, IPS:  Coyle, Henderson, Ross
- SSH Good Practices:  Cox, Snodgrass
-  Malware Reference:  Barnett


On Sat, 2004-12-11 at 02:32, Brian Coyle, GCIA, wrote on LEAP: 
> For all things 'log analysis'....    http://www.loganalysis.org/
> There are several tools to parse syslog and firewall logs, then alert
> on interesting things.  

The most straight-forward way to mitigate this right now is to do as
Mr. Coyle says, start analyzing those logs.

> RE: the ssh probes.   There have been reports since August of malware 
> performing brute force attacks on ssh accounts.  Most are trying 
> simple/common account names and passwords.
> You can find more in recent Dshield and Incidents list archives-
> http://lists.sans.org/pipermail/list/
> http://marc.theaimsgroup.com/?l=incidents&r=1&w=2

You can always count on a GCIA at Disney to "be current" on the latest
advisories.  ;->


On Sat, 2004-12-11 at 06:51, Terry Henderson wrote on NTLUG:  
> snort
> snort.org

Snort is a good network intrusion detection (IDS) platform.  You should
be running it on your firewall appliance, or to a monitor port on the
switch for all relevant subnets (e.g., the Internet in this case),
especially with no TX lines.

Snort will look for patterns in attacks.  I don't know how well it would
defend against the type of attack Mr. Coyle referenced above though.  I
believe SSH client operates by encrypting the clear text passwords with
a random symmetric key which is then encrypted with the public key,
so Snort won't be able to discover a pattern in the password types.

But there might be another pattern, or I may be mistaken on the SSH
type.


On Sat, 2004-12-11 at 01:39, David Ross wrote: 
> PortSentry has a number of options to detect port scans, when it finds
one it
> can react in the following ways:
>        - A log indicating the incident is made via syslog()
>        - The target host is automatically dropped into /etc/hosts.deny
>          for TCP Wrappers
>        - The local host is automatically re-configured to route all
>          traffic to the target to a dead host to make the target
system
>          disappear.
>        - The local host is automatically re-configured to drop all
>          packets from the target via a local packet filter. 

Mr. Ross provides an excellent network Intrusion Prevention (IPS)
approach.  If you know the service(s) being targeted, then IPS is very
doable.  PortSentry is an excellent solution when you have a service
constantly being targeted and you receive constant, incorrect logins.

On UNIX, a very simple but effective IPS approach is to dynamically
append hosts.deny with IPs that have consistently failed to
authenticate.  You can do this on the server providing the service
itself, as well as your firewall (if it is a platform with PortSentry
available for it).


On Sat, 2004-12-11 at 08:44, Jack Snodgrass wrote on NTLUG: 
> I think someone else mentioned it, but I'll re-emphasize it... 
> use /etc/hosts.allow /etc/hosts.deny to limit access to 
> your IP Address or a range of IP Addresses. 

As talked above with regards to PortSentry, if you don't know what
hosts.allow and hosts.deny do, _learn_ them.  Leveraging TCP Wrappers
is one of the "best practices" that you can _always_ do.

Defense-in-depth dictates that you should leverage _every_ available
security layer.  E.g., not only a packet filter at the firewall, but
hardening at the service.

SSH is almost always built with TCP Wrappers which allows you to
define the IPs that should be explicitly allowed/banned.  Especially
if you _do_ know the explicit IP/networks that you will always be
connecting from, or those that you know you will never connect from.

> Also set up your ssh keys between your boxes and 
> turn off ssh passwords in your /etc/ssh config file:
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication no
> this way, the user won't even get a chace to try and 'guess' a 
> password. 

Yes, another good practice.  If you always require public key
authentication for SSH, then you want to disable _all_ other
mechanisms.  Password authentication is typically allowed by default
in SSH.  Disable it and the malware flying around won't be able
to get in at all.


On Sat, 2004-12-11 at 03:10, Chris Cox wrote on NTLUG:  
> Setup a cryptic username as well and restrict logins to only
> that username...

Another _excellent_ SSH practice.

First off, you should _always_ have an _explict_ "AllowUsers" line
in your sshd.conf.  You should only be allowing those users to
connect.  Do _not_ just let all users connect -- _especially_ when
the SSH daemon authenticates against your LAN list.  No matter how
good you beat good password creation and protection into your users,
many just won't do it.

So you need to mitigate against that.  You should have a formal
procedure in your security policy (or some document it references)
regarding the allowance/maintenance of remote access anyway.  So
the "AllowUsers" line should exist, and procedures followed in
allowing people to be added and, more importantly, _removed_ from
it.

> Consider turning off tunneled passwords and just use passphrase...
> Restrict by IP if possible...

Again, re-enforcing the TCP Wrappers and SSH practices Mr. Snodgrass
also mentioned.


On Sat, 2004-12-11 at 01:53, Phil Barnett wrote on LEAP: 
> Look into port knocking.

Yes, be wary of this!

Even if you have a "deny-all" firewall, most exploits come through
requests by the client.  This especially takes advantage of people
how have an "allow all outgoing" firewall.  E.g., MS IE/Outlook
compromises allow the malware to "phone home" right through the
firewall.

There's just one probably with that, the client itself has to
initiate it.  Although the client might do that on a regular basis
-- the "phone home" interval -- the interval for common malware is
eventually discovered, and an IDS/IPS system can identify it.

With "port knocking," combinations of responses can let firewall
traffic through and _incoming_ -- especially to what the firewall
thinks is just normal port 80.  I.e., responses to what it believes
are just port 80 requests.  So the "phone home" interval doesn't
have to happen, except for maybe the initial "outgoing request"
that is expected from the malware.

Port knocking is rather convoluted, and there are different
approaches I'm not even aware of.  How far it can be used in
conjunction with malware that has made onto a client system behind
a firewall is something I'm not familiar with, but the risk does
exist.  So be wary of it.


Risk mitigation summary ...

1.  First and foremost, get formal auditing in place.  It is easy
with some of the basic log tools out there.  In a corporate
environment, this is crucial.  In a more SMB or even SOHO
environment, you may be able limit your log analysis to just when
adverse network/systems conditions occur.

2.  Always implement "defense in-depth" including practices like
hardening SSH and utilizing TCP Wrappers _by_default_, in addition
to the firewall.

3.  In addition to your firewall, basic "defense in-depth" today
dictates a network IDS by default.  I like IPCop because this makes
it straight-forward and easy to not only install, but the all
important issues of updates and regular _viewing_ of the reports.
This also helps _reduce_ the overhead of #1, and better identifies
when you should get deep into auditing than "gut feeling."

4.  If you are allowing in services, something dynamic like IPS
capabilities are ideal.  They can automagically mitigate certain
events, like consistent login/access failures by shutting off
access to those services from IP addresses.  PortSentry does this
with minimal effort once it is setup.

As always, you should _never_ expend more effort on security than
a cost of a compromise would be.  That's the basic cost rule.

For a home user or SOHO, IPCop is cake and regular updates of the
Snort database and views of the logs/snort logs is enough.  When you 
allow in services, secure them best as you can with TCP Wrappers.
Run service logs through log analysis as appropriate.

In a SMB, I would deny outgoing ports by default and open up only
certain access, with a formal proxy server.  I'd be tapping IDS in
a few places, and implementing PortSentry and other IPS on _all_
servers (and additional packet filters) providing services to the
Internet.

For a larger MB, I'd definitely have multiple subnets of multiple
layers of packet filtering inside my LAN for additional protection
of key systems (e.g., KDC, time/DNS, etc...), with more than one
set of IDS taps.  Not just DMZs, but even segmented _wired_ LANs.

-- 
Bryan J. Smith                                 b.j.smith at ieee.org 
----------------------------------------------------------------- 
Assumptions of the Fedora Project based on Red Hat Linux is like
assumptions of the Debian Project based on using old Corel Linux.