[linux-security] Re: tcpd anomaly

[wietse porcupine org (Wietse Venema)]

Sorry for discussing sysadmin stuff in a security group. Normally
people contact me via direct email when they have a problem.

A new tcpd instance is run for each connection; each tcpd instance
handles its connection independently from other connections.

So, when telnet connections from the same site are given different
treatment, something has changed from one connection to the other,
and it is up to you to figure out what.

Very likely, something has changed locally to your system.

I suggest that you check out the rules with the tcpdchk and tcpdmatch
configuration checking utilities. These programs are part of the
tcp wrappers source distribution; your software vendor may or may
not have bundled them with the system.

	Wietse

P.S. Appending "&" to a "twist" command will screw it up: the shell
will close the standard input of the twisted command, so it can't
read from the network.

Pluto:
>   Salve,
> 
>   I'm protecting hades with the tcpd wrappers and had no problems so far,
> at least none that I noticed.
> 
>   Today happend something strange. An attacker got a connect on a
> protected port from a not allowed IP:
> 
> > Unusual System Events
> > =-=-=-=-=-=-=-=-=-=-=
>   BTW, thanks for that tool.
> 
> > Jul 1 03:34:56 hades in.null[18321]: twist
> > slip139-92-93-124.hol.ch.ibm.net to perl /usr/sbin/get_em.pl
> > 139.92.93.124 unknown slip139-92-93-124.hol.ch.ibm.net in.null 2>>
> > /var/log/get_em_err
> 
>   This is OK and has happend a dozen times a week in the last year. He
> comes from ch.ibm.net where only de.ibm.net is allowed and is routed to a
> little homegrown script that logs some stuff like traceroute and finger.
> 
> > Jul 1 03:35:00 hades in.null[18324]: twist
> > slip139-92-93-124.hol.ch.ibm.net to perl /usr/sbin/get_em.pl
> > 139.92.93.124 unknown slip139-92-93-124.hol.ch.ibm.net in.null 2>>
> > /var/log/get_em_err
> 
>   And again, still OK.
> 
> > Jul 1 03:35:05 hades in.telnetd[18327]: connect from
> > slip139-92-93-124.hol.ch.ibm.net
> 
>   But now that! Hasn't happend before and I think the fast reconnects
> after 4-5 sec. are on purpose, nobody has done this like that before and I
> got a lot more of this in the logfiles.
>   Seems like tcpd is still busy with the last two scripts and doesn't even
> look at the connect. Or do I miss something? Have the scripts have to have
> a '&' at the end of the line to prevent it? Or is it a bug of the tcpd
> wrappers?
> 
>   Yours troubled
> 
>   Pluto  -  SysAdmin of Hades
>   We are NSA, your mail will be scrutinzed, resistance is futile! =:-)
>   Key fingerprint: 1F 3F EA 94 D0 56 A6 86  4D 19 C4 56 6C F9 43 44
> 
> Boren's Laws:
> 	(1) When in charge, ponder.
> 	(2) When in trouble, delegate.
> 	(3) When in doubt, mumble.
> 
> -- 
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
> 
> To unsubscribe:
>   mail -s unsubscribe linux-security-request redhat com < /dev/null
> 
> 
>