I'm a long way from being the brightest bulb in the box, so perhaps someone here can stake me to a few lumens.

I've been trying to find an A record and/or canonical address associated with the IP in a spam I got the other day. To whit:

Go to http://who.is and type in the address and get
inetnum: 189.30/15
aut-num: AS8167
abuse-c: BTA17
owner: Brasil Telecom S/A - Filial Distrito Federal
ownerid: 076.535.764/0326-90
responsible: Brasil Telecom S. A. - CNRS
owner-c: BTC14
tech-c: BTC14
inetrev: 189.31.192/18
nserver: ns03-cta.brasiltelecom.net.br
nsstat: 20080508 AA
nslastaa: 20080508
nserver: ns04-bsa.brasiltelecom.net.br
nsstat: 20080508 AA
nslastaa: 20080508
created: 20070402
changed: 20070402

nic-hdl-br: BTA17
person: Brasil Telecom S. A - Abuso
e-mail: abuse@noc.brasiltelecom.net.br
created: 20030624
changed: 20050214

nic-hdl-br: BTC14
person: Brasil Telecom S. A. - CNRS
e-mail: suporte@noc.brasiltelecom.net.br
created: 20031003
changed: 20080229

That is the ISP who owns the IP address, and there is the complain-to address for email.

Strictly speaning there is no such thing as "an A record ..... associated with the IP" since the IP is the A. But I know what you mean. You are looking for a name that resolves to the address.

It's better to report the IP to the owner, with your evidence that it is spewing spam.

tembow;

Thanks, but I think you missed the point; ...probably because I didn't make it very well. My bad.

I'm not interested in reporting at this point ,,, If I was, I wouldn't use the abuse desk unless I wanted more spam. And I don't have much faith in the “whois” records apropos “registration info” where spam is concerned. I'm just trying to gain some understanding as to what is going on with this and similar spam apropos SMTP.

I had always assumed there was a canonical address, you know... a conventional email address character string... in the DNS zone file on any MTA's server to uniquely identify the sender account. Forged spam headers aside for a moment, in legitimate practice, without an MX record to recursively convert the IP to the email addy and back, it wouldn't be possible to reply to an email; e.g. for a sender's MTA to do the necessary rDNS before attempting to deliver email to that account, like a reply. I had assumed maintaining a valid MX record was 'de rigueur' within SMTP and I also assumed these records were accessible to the general public using standard query techniques.

In this instance:...

I belive "most" spam nowadays is sent using open relays, hijacked hosts, or other hackery methods.

SpamCop is suited for reporting unsolicited spam to ISPs, if that is what you are getting at.

Though yes, I'm sure there are some hosting providers (we called them bullet-proof hosting...usually based in Russia, or other countries that simply don't care) who will not clean up their networks despite the reports you send, though your submissions will keep their IP ranges live on SpamCops blocklists.

The host in question has been hijacked and spam is spewing from the IP: 189.31.219.105

The non-resolving reverse DNS entry indicates to me that it could have been an ADSL account in Brazil that is not in current use. 189-31-219.ctame700.dsl.brasiltelecom.net.br This rDNS to me looks like it is incomplete on purpose (missing the last octet in the IP range). For instance, if you google similar subdomains, such as 189-30-141-251.ctame700.dsl.brasiltelecom.net.br, you will find that this one does resolve to: 189.30.141.251 (at the time of this post).

So when you query 189-31-219.ctame700.dsl.brasiltelecom.net.br, it does not resolve to this IP as you already pointed out.

Spammers will infect anything online, they don't care if there are resolvable rDNS entries or not. According to the RBL quieries I did on this IP, [ example: http://www.robtex.com/rbl/189.31.219.105.html ] it tells me it has spewed a lot of spam and therefore is blacklisted by lists which detect compromised spam origins.

This type of activity has been going on quite a while. Back around 2001 or so, more and more ISPs started blocking email from hosts where the IP and the rDNS entries do not resolve, so this spammers' email is not arriving at many locations, except for recipients who are mostly spamtraps waiting to detect such activity.

Maybe I helped explain this for you, I hope so. You brought up some great questions.

BTW, I learned the word wetware from reading your post, I had never heard of that term.

I forgot to add: I scanned a few ports and found: - Other port: (110 - POP3) (active) so this appears to be active on this host, so the IP is definitely open relayed or it is some sort of hijacked host used for mailing spam.

s0tet:

Hi; at last, some traction.

I looked at that dang rDNS for hours thinking “.ctame700” indicated a <.br> network CNAME/alias instead of taking it at face value as you so wisely did;... good eye. My dumb.

I'd polled all the RBLs before I made my OP; ... standard practice on my system. Often SC or Spamhaus publish histories on Open Relays that have been around for a while. It's in the PBL of course [PBL190804]; but even SH didn't seem to have bothered to resolve it.

What I'm trying to understand, specifically and for future reference, is: if the <.br> server has been compromised, which we agree does seem to be the case, wouldn't all the subdomains on that server, in that zone, be “munged” as well; which would (should?) mean we couldn't query them either? Since we've established that they do resolve, I'm puzzled as to just how only one “A” record, or one MX record seems to be affected. I don't think it would be worth while to code the virus for only one account; do you? And if the "worm" has a "spreader", then eventually, all the clients on that <.br> net would get taken down: i.e., become unreachable/unresolvable. That would be counter-productive from a spammer's POV. Whether or not it's a dial-up (as we might infer from the string section <.dsl.brasiltelecom.net.br> shouldn't matter as far as I can tell.

Just to remind you, I'm not the brightest bulb in the box. But I can see how the PC on this <.br> ADSL can be infected, be part of a bot herd and have all manner of misconfigurations in it's mail client; thereby rendering its SMTP stamps suspect. Still; if it exists, there has to be a canonical address to identify it on the internet. So where is it?

If [189.31.219.105] is confirmed to be listening on 110 then we can assume it does exist; i.e., is in current use. Or am I wrong?
I tried Ping and Traceroute a couple of times without success

No worries with all the questions, this port stuff is kinda new for me too.

From what I've understood, these worms/trojans aren't manufactured "per system" - that would be too much work.

The way the systems are set up, is they contain a minimalist SMTP/mail server to allow outgoing mail.

The whole .br top-level domain is not infected, the spam is merely originating from a single address/rDNS within the .br network AFAIK anyways....

Though, who knows, in this day and age of NATs and such, there could possibly BE 10+ machines behind that "IP address"/rDNS. Example: I have a DSL line through HellSouth, I have one IP address, using a wireless router, I have 2 other desktops, one laptop, PLUS the computer directly connected to the router/WAN link, so I have 4 computers totally, running off my IP address.

As far as sending new instructions, I don't think they use mail/smtp to issue new instructions to infected bots, I think most of these bots are sent messages over IRC, or some other protocol, I've read some articles which mention "Freenet" - which is a sort of encrypted Internet...it's a "real" network, not "intended" for use by spammers/criminals, but they have found a use for it...

Freenet http://freenetproject.org/
Freenet on Wikipedia: http://en.wikipedia.org/wiki/Freenet

There are other sites that do extensive research on these botnets too, but that's sorta out of the scope of CastleCops Though, reading into all this is pretty interesting and quite eye-opening/mind-boggling.

Just as you state, this host is offline now, so no more probing can be done.

s0tet

I 'm sure there's a simple answer to all this; I'm just too confused to frame the right question.

My 'provisional' & hypothetical understanding runs something like:
There's a compromised irc server out there that 'controls' (by proxy) a chat client's Windows PC, (hereinafter called “the W-bot”) which runs a client email program that is hosted on servers on the <.br> dial-up network. The W-bot may be infected by a rootkit virus or a worm that either operate directly on the client email app, or independently as a small SMTP mail app that runs in the background. Either way, the W-bot must have a host domain, a FQDN and/or bracketed quad IP, the record of which must exist in an MX recursive file somewhere on a <.br> SOA server.

Given, some Windows rootkits will connect to the IRC server every time the unit is powered up; even without the operator intending to or being aware of it. But for this to happen, the host server on the <.br> net must recognize the W-bot and resolve its domain both as a valid FQDN and IP bracelet 'before' sending the HELO to the IRC server. Otherwise, the IRC server can't return a SMTP greeting and the connection will fail; the 'host' wouldn't be recognized.

I realize that the IRC server can 'recognize' the IP quad and resolve that to the client's IRC account record. But, this still implies a comprehensive host record, including the MX record, be reposed somewhere on a <.br> server.

I base this 'implication' on my understanding of IRC rooms, (e.g., freenode), in that they permit client email exchanges under various protocols... an option not possible unless a canonical address is “active” for both parties, including this W-bot, and unless both parties are, shall I say, “RFC compliant”.

Which brings us back to the question: where is this FQDM to which [189.31.219.105] doesn't seem to want to resolve using rDNS?

s0tet;
Going back to:

+1 on tembow's last message: The PTR record is optional; it exists in this case as 189-31-219.ctame700.dsl.brasiltelecom.net.br . This name is created by the network administrator - which may or may not be the same organization as the owner of a server.

Either way, the W-bot must have a host domain, a FQDN and/or bracketed quad IP, the record of which must exist in an MX recursive file somewhere on a <.br> SOA server.

That is the basic misconception that is causing you such grief. It is simply not true. MX records are involved in the RECEIVING of email by a mail server. SENDING from an IP address does not have to have any name, canonical or otherwise, associated with it.

Your use of the term "canonical" is also not in keeping with the strict definition of the term, thus causing further confusion. A canonical name, also called a CNAME, is an alias for another name.

If there is a name associated with an IP, it is whatever is stored in an Internet database by its owner or delegated owner. It can be as misleading or as accurate as the owner decides it should be.

tembow, s0tet, ahoier, moike;

I can't ell you how much I appreciate all the help. (Genuflects 3 times saying, “I'm not worthy ...”.

tembow wrote;

OK. I retract on the strict definition of canonical name (mea culpa, mea maxima culpa)

When you run a DNS service, you put in to a zone file a number of records pertaining to the domain.

eg
SOA - the start record
A - the address record (translates a name to an address
CNAME - the canonical name or alias - translates a name to a name
TXT - textual information

So I can have an SOA that contains some overall information followed by
example.com. IN A 123.1.2.3
www CNAME example.com.
ftp CNAME example.com.
maila IN A 123.4.4.4
mailb IN A 123.5.5.5
example.com. MX 10 maila
example.com MX 20 mailb

When anyone looks to find www.example.com. the DNS server finds that it can not return the address, just the canonical name example.com. So www.example.com is the alias for the canonical name example.com, as implemented by the CNAME record.

An automated second query on example.com returns the IP address.

That is the strict DNS definition of the terminology that refers to the actual DNS records.

I was confused, and applied the term to the alias, rather than the name the alias resolves to.

Now to the second point

If you want to pursue how an email SENDER can send an email with absolutely any source name, look up how to telnet to port 25 of a mail server. Note how it prompts you for a name. You can key any name.
It is a function of rules within the name server to perform any verification at that point.

Loosely configured servers will take anything. More tightly configured servers may perform a check to see if the sender domain or email address exists before proceeding. More tightly configured will perform a PTR reverse IP lookup. More tightly still will compare the PTR with the user provided, and filter out on bad matches. More tightly again will process SPF checks before allowing a message.

Telnet hostname port.
For the "Host Name", enter the mail server name (for example, "mail.example.com"). For the Port, enter 25. A second or two later you should see a welcome message. Type "HELO" followed by the domain name of the computer you are using. For example, "HELO mail.example.com". Then, after you get a response, type "MAIL FROM: my.email.address@example.com" (using your E-mail address on your mail server), and then "RCPT TO: my.email.address@example.com". Then, type "DATA", "Subject: Test", a blank line, "Test", and then ".". After the response, type QUIT.

If you lie about the domain name, and you lie about the MAIL FROM, you will get different success rates with differently configured mail exchanges.

By the way, if your service provider blocks you from doing a telnet on port 25, you will not be able to conduct that test. Port 25 blocking is becoming a prevalent measure among ISPs to prevent spam from direct mailers.