Ok.. It looks like we are all confused.
This is why I said mail:

1) He checked his mail logs for connects that were not rfc correct. He found a 
few that did not ident correctly. The assumption now is that a smtp server or a 
telnet to port 25 connected to him. (more then likely to see if his server was 
not setup/patched correctly and would send spam)

So, based on that, one would assume that you would connect back to the ip in 
your log file on port 25 to see who they are. I think the problem is he did not 
say what port he connected on to ident them. Yes, it could be 
ident,netbui,smtp,ftp....ect

2) He did say that he thought there was a backdoor in the mail server. Because 
he is looking for and said mail server, I am assuming he connected on port 25 
to them. Someone said nmap..ect to see a hidden port. Why.. assuming the above, 
we know the port and the assumption is an ftp server on port 25. (very strange, 
but who knows)

Mike,

what port did you connect ot them on?
also...if you connect on 25, what did it ident itself as? (ie: smtp server 
version or ftp server version)

rather then go through all of that...go to arin.net, do a whois on the ip 
address you have and if you have the time, call them.
I would not run nmap against someone else, you could find yourself in legal 
trouble.


-----Original Message-----
From:   Brian Smith-Sweeney [mailto:[EMAIL PROTECTED]
Sent:   Mon 11/14/2005 3:27 PM
To:     Levenglick, Jeff; [email protected]
Cc:     [EMAIL PROTECTED]; Mike Owen; Christopher E. Cramer
Subject:        Re: Odd identd behavior

Everyone I believe did read his message.  Yes, he said mailserver logs,
but that's because the mailservers in question were connecting back to
the ident port which is fairly standard behavior.  What's not standard
is that they were getting a response back from the service listening on
the ident port that was not consistent with an ident server.  While 220
as you noted is a valid mailserver response, it's *not* a valid ident
server response.

The conclusion of "it looks like an FTP server" is based on the fact
that many warez kiddies install FTP servers on non-standard ports, and
that the remainder of the header (..:: ?lit?-Cr?w Rulez ::..) looks like
a warez banner.  The easiest way to verify would be to attempt FTP
protocol negotiation to the port in question to see what happens, but
I'm guessing the majority of folks who posted to the list are correct:
it's FTP.

Also, if you're going to attempt to correct people by citing RFC's, it's
best to use the right RFC. =) RFC 793 is TCP; RFC 2821 (and old 821)
discuss SMTP, which is I assume what you meant to reference.

My guess is the ::.. stuff is just to look cool, but I suppose it's
possible it has a dual purpose.

Cheers,
Brian
Levenglick, Jeff wrote:
> Ok.... It's a good thing we all read his message...
> 
> He said mail server logs....
> 
> 220 is a valid MAIL server response.  
> see http://www.rfc-editor.org/rfc/rfc793.txt   220 <domain> Service
> ready
> 
> Where did ftp come from?
> 
> Now.. Why does it say: 220 ..:: ?lit?-Cr?w Rulez ::....530 Not logged
> in...
> 
> Because that is what they put as the ident of the mail server-  ..::
> ?lit?-Cr?w Rulez ::....530 Not logged in...
> 
> My quick quess is that  ..:: when sent to a daemon could overflow or
> maybe do something it is not supposed to. (ie: a parse bug)
> Or the mail server was hacked and they replaced the ident of the box
> with their name. 
> OR the host was hacked and the host name was changed. Assuming a Unix
> box, did you check your host name?    hostname   or uname -a
> 




-----------------------------------------
This e-mail message is private and may contain confidential or
privileged information.

Reply via email to