Bug 172181 - Log IPv4 adresses as IPv4, not IPv6.
Summary: Log IPv4 adresses as IPv4, not IPv6.
Keywords:
Status: CLOSED DUPLICATE of bug 159268
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openssh
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-01 05:38 UTC by Anchor Systems Managed Hosting
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-01 08:07:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Anchor Systems Managed Hosting 2005-11-01 05:38:32 UTC
By logging ipv4 connections as ipv6 addresses, this breaks tcp_wrappers
functionality and presents a significant security issue. This could hardly be
seen as just an enhancemant.

+++ This bug was initially created as a clone of Bug #159268 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red
Hat/1.7.8-1.1.3.1

Description of problem:
sshd logs all connection attempts as IPv6 addresses, even if they were really
IPv4. Ie:

May 29 18:58:06 homer sshd[5357]: Failed password for root from
::ffff:209.152.166.153 port 49674 ssh2
May 29 18:58:07 homer sshd[5359]: Invalid user admin from ::ffff:209.152.166.153

This clutters up the logs (and hence logwatch mails) and is generally unsightly. 

A workaround is to add

ListenAddress 0.0.0.0

to /etc/ssh/sshd_conf, but that disables listening to ipv6 alltogether,
which isn't really what I want.

Upstream has a patch to fix this. From the 4.1p1 changelog:

20050503
 - (dtucker) [canohost.c] normalise socket addresses returned by
   get_remote_hostname().  This means that IPv4 addresses in log messages
   on IPv6 enabled machines will no longer be prefixed by "::ffff:" and
   AllowUsers, DenyUsers, AllowGroups, DenyGroups will match IPv4-style
   addresses only for 4-in-6 mapped connections, regardless of whether
   or not the machine is IPv6 enabled.  ok djm@

Please backport this.

/August.

Version-Release number of selected component (if applicable):
openssh-3.9p1-8.RHEL4.4

How reproducible:
Always

Steps to Reproduce:
1. install openssh
2. ssh to it (via ipv4)
3. check out the logs.
  

Actual Results:  encapsulated ipv4 addresses.

Expected Results:  proper dotted-quad ipv4 addressses.

Additional info:

-- Additional comment from shillman on 2005-06-01 10:41 EST --
In order to file a RHEL feature request, please either contact Red Hat's
Technical Support line at 888-REDHAT-1 or file a web ticket at
http://www.redhat.com/apps/support/.  Bugzilla is not an official support
channel, has no response guarantees, and may not route your request to the
correct area to assist you.  Using the official support channels above will
guarantee that your issue is handled appropriately and routed to the
individual or group which can best assist you with this issue and will also
allow Red Hat to track the issue, ensuring that any applicable feature
addition is included in all releases and is not dropped from a future update
or major release.

Comment 1 Tomas Mraz 2005-11-01 08:07:57 UTC

*** This bug has been marked as a duplicate of 159268 ***

Comment 2 Tomas Mraz 2005-11-01 08:10:37 UTC
See the comment by Suzanne Hillman how to properly request bug fix or
implementation of feature in existing RHEL release.


Comment 3 Anchor Systems Managed Hosting 2005-11-01 13:19:45 UTC
Tomas,

Read the comment at the top:

"By logging ipv4 connections as ipv6 addresses, this breaks tcp_wrappers
functionality and presents a significant security issue. This could hardly be
seen as just an enhancemant."

This is a significant security problem. TCP wrappers, one of the most basic,
fundamental security measures for the system is BROKEN on RHEL 4.

Comment 4 Tomas Mraz 2005-11-01 13:59:30 UTC
I've read that comment. However this doesn't change anything with the statement
that bugs in RHELs should be reported to Support tracker.



Note You need to log in before you can comment on or make changes to this bug.