RH4.2 Linux Intel Last night I got three of these log messages: Two in a row, one a bit later. May 8 00:35:15 osg-gw imapd[4307]: warning: can''t get client address: Connectio n reset by peer May 8 00:35:15 osg-gw imapd[4307]: refused connect from unknown Now, I have imapd blocked to non-local users using tcpd wrappers, so tcpd is trying to find the address of the remote machine (all my wrappers are specified using IP addresses rather than domain names). I assume that some call (getpeername?) is failing on the connect, so it rejects the connection. My question, is the attacker learning anything? Are they able to "time" their connection requests so they know if you are trying to track them? eric -- - Eric Wampner Orlando Software Group, Inc. eww@kataent.com Software Engineer (407) 366-0909 wampner.e.w@orlsoftgrp.com Systems Administrator fax (407) 366-2721 eww@iag.net
Eric Wampner:> May 8 00:35:15 osg-gw imapd[4307]: warning: can''t get client address: > Connection reset by peer > May 8 00:35:15 osg-gw imapd[4307]: refused connect from unknown > > My question, is the attacker learning anything? Are they able to "time" their > connection requests so they know if you are trying to track them?This was most likely part of a network sweep to find machines running an IMAP service. The attacker found out that your machine is running something on the port normally used by de IMAP server, and disconnected even before your server had a chance to respond. It is possible that someone will come back to exploit some vulnerability. But that person won''t be able to do much with the wrapped IMAP server, because they would first have to find out what addresses are authorized. Wietse [mod: I approved Eric''s message because I wanted you all to have a look at these "logs" and tell me and Eric (and learn for yourselves) what probably happened. Wietse is confirming my reading of the log: tcpd is trying to find out who it is talking to, but the remote end already has abandoned the connection. The "legit" explanation is that the a client imap program is crashing the microsecond it has opened the connection to your server. Wether or not it is an approved client cannot be determined: tcpd gets an error return on the getpeername() call, whose result would then be used to determine the authorization of the connecting client. Unless someone can motivate why I''m wrong here, please: discussion closed.... -- REW]
On Sat, 9 May 1998, Wietse Venema wrote:> Eric Wampner: > > May 8 00:35:15 osg-gw imapd[4307]: warning: can''t get client address: > > Connection reset by peer > > May 8 00:35:15 osg-gw imapd[4307]: refused connect from unknown > > > > My question, is the attacker learning anything? Are they able to "time" their > > connection requests so they know if you are trying to track them? > > This was most likely part of a network sweep to find machines > running an IMAP service. > > The attacker found out that your machine is running something on > the port normally used by de IMAP server, and disconnected even > before your server had a chance to respond. > > [mod: I approved Eric''s message because I wanted you all to have a > look at these "logs" and tell me and Eric (and learn for yourselves) > what probably happened. Wietse is confirming my reading of the log: > tcpd is trying to find out who it is talking to, but the remote end > already has abandoned the connection. The "legit" explanation is thatI know you said "discussion closed", but I think I have something useful to contribute. Many months ago, someone was DoS attacking one of our servers by doing the rapid connect/disconnect thing with port 23. Inetd would think something was wrong and shut down telnetd (ok for security...I always use ssh...but annoying to the users who like telnet). Since the attacker was closing his connections before tcpd could tell where they came from, the logs were useless. To catch where the connections are coming from, try using something like: ipfwadm -A in -a -o -y -P tcp -D any/0 13 23 37 143 513 514 This will clutter your logs a bit...depending on how many connections per day you see for each logged service...but it will tell you who''s probing your system. [Mod: Let me also make a statement that completely stealth attacks are impossible. Any attack *will* generate packets on a wire. In order for those packets to be delivered to the target, they must follow IP conventions. Granted, the source address can be spoofed (which should be impossible if ISPs/NSPs start filtering at the customer routers) but apart from that a real, trackable packet will be sent to the target. -- alex] -- alex] ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | http://noagent.com/?jl1 for cheap Network Administrator | life insurance over the net. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
> [Mod: Let me also make a statement that completely stealth attacks are > impossible. Any attack *will* generate packets on a wire. In order for those > packets to be delivered to the target, they must follow IP conventions. > Granted, the source address can be spoofed (which should be impossible if > ISPs/NSPs start filtering at the customer routers) but apart from that a > real, trackable packet will be sent to the target. -- alex]Bwah hah hah! This discussion will *never* be closed! This was discussed on BUGTRAQ under the subject heading: TCPwrappers race condition late last year. The consensus there was much the same as here. One thing I haven''t seen mentioned is the IpLogger package by Mike Edulla <medulla@infosoc.com>. It listens for TCP connects (and ICMP packets) on a raw socket, so it *will* get the IP addresses of these lightning fast scans. (It *won''t* catch the "sleath port scanning" described on BUGTRAQ which takes advantage of responses to a lone FIN packet, but it could easily be modified to do so.) It''ll *also* let you detect scans on ports you don''t even listen to, without booby-trapping them a la tcp_wrappers. For example, I don''t have anything listening to the IMAP port, but I log plenty of tedious imap2 scans, usually from hosts that have been cracked by... imap2 scans! It''s major drawback is that "tcplogd" logs *all* SYN packets, and "icmplogd" logs *all* ICMP packets (except echo replies), so your logs tend to fill up with legitimate connections you have to wade through to find the "bad guys". It''s great for a "client" machine, however, that doesn''t receive connections from many external sources. A word of warning, though: the IpLogger package is far too trusting of DNS lookups. I''ve patched my version to avoid possible buffer overruns and always include the IP address (in case I get a bogus hostname from a cracked DNS server). However, the hostnames aren''t filtered, character-by-character, as in tcp_wrappers, so it''s possible there''s a vulnerability hidden somewhere in there. My patch (against iplogger-1.00) is short, so I''ve included it. Kevin <buhr@stat.wisc.edu> * * * --- icmplog.c 1998/04/23 17:04:16 1.1 +++ icmplog.c 1998/05/12 15:01:23 @@ -170,8 +170,9 @@ i.s_addr=in; he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET); - if(he == NULL) strcpy(blah, inet_ntoa(i)); - else strcpy(blah, he->h_name); + if(he) + sprintf(blah, "%.1000s [%.20s]", he->h_name, inet_ntoa(i)); + else + sprintf(blah, "[%.20s]", inet_ntoa(i)); return blah; } - --- tcplog.c 1998/04/23 16:38:54 1.1 +++ tcplog.c 1998/05/12 15:01:23 @@ -159,8 +159,10 @@ i.s_addr=in; he=gethostbyaddr((char *)&i, sizeof(struct in_addr),AF_INET); - if(he == NULL) strcpy(blah, inet_ntoa(i)); - else strcpy(blah, he->h_name); + if(he) + sprintf(blah, "%.1000s [%.20s]", he->h_name, inet_ntoa(i)); + else + sprintf(blah, "[%.20s]", inet_ntoa(i)); return blah; }
On Tue, May 12, 1998 at 10:39:00AM -0500, Kevin Buhr wrote:>[...] > > It''s major drawback is that "tcplogd" logs *all* SYN packets, and > "icmplogd" logs *all* ICMP packets (except echo replies), so your logs > tend to fill up with legitimate connections you have to wade through > to find the "bad guys". It''s great for a "client" machine, however, > that doesn''t receive connections from many external sources.this is a major problem here indeed... almost everything can be logged, but the more you log, the harder it is to find the valuable informations... For this reasons I have done two scripts, that I include; the first one, called watch_logs, is run nightly: it scans the syslogs and extracts those of certain daemons (like, tcplogd); to do so it uses the second, watch_anomaly, that keeps track of what has happened recently and only shows what has not happened before; after a few days of "learning", the output decreases a lot, and it is easy to see if some kind of strange thing has happened. The scripts need some improvements (if you improve them, please e-mail me the new version), but I have been happily using them for years. a.m.