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_errThis 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_errAnd again, still OK.> Jul 1 03:35:05 hades in.telnetd[18327]: connect from > slip139-92-93-124.hol.ch.ibm.netBut 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.
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 > > >
Have you looked at xinetd? I have it running on our firewall and it even allows you to bind services to a single interface. This way there is no connect then disconnect as with tcp_wrappers. -Rick -- +-------------------------------------------+ | "No matter where you go...there you are." | | -Buckaroo Banzai | +-------------------------------------------+--------------------- ChapWin Consulting Inc. rick@chapwin.com Red Lake Internet / Ear Falls Internet www.chapwin.net Box 882 (807) 727-2606 Red Lake, ON P0V 2M0 FAX (807) 727-3594 ------------------------------------------------------------------ Member: Northern Ontario Coalition of Internet Providers ------------------------------------------------------------------
On Wed, 1 Jul 1998, Pluto wrote: | 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 well.. I used to use a boobytrap on port 139 for outside IPs with TCPD.. who''s job was to mail me the source IP immediately.. until.. I got hit by this person.. who used 28 diff IPs to hit port 139 repeatedly.. and it was so hard on my machine.. that the HD LED never went out before I power cycled it after like 15 mins of non responsiveness :( I had an "&" at the end this is something you should be aware of when running something like an external shell script or a program from tcpd using twist or without.. --- Annex
On Thu, 2 Jul 1998, Wietse Venema wrote: | 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. just wanted to add: I wasn''t using TWIST when I had "&" at the end. what I had was: smbd: ALL: (/bin/echo "%u at %n (%a) to %d" | \ /bin/mail me) & in /etc/hosts.deny don''t flame me, I don''t use it anymore. --- Annex