I think I need IP Spoofing

Printable View

October 18th, 2006, 03:42 PM
siko9

I think I need IP Spoofing
Hi,
I have been dealing with this for several months now, and I am running out of ideas...
1. Company-A has an internal mailserver working as expected.
2. Company-B has it´s mail service hosted by its ISP (ISP-B).
3. EMails from Company-A can not be delivered to the mailserver of ISP-B .(meaning that I know of at least 3 domains hosted by ISP-B to whom mail can´t be delivered).
4. I can not establish a telnet connection from Company-A to ISP-B´s smtp server, from any of the systems on c-A´s LAN.
  It either times out of stays forever waiting for the connection to initiate.
  I can do it from 3rd party IPs of diff ISPs.
  I can´t find someone else using c-A´s ISP to run a test.
  -
5. No explanation about why I can´t telnet to the smtp is given.
6. ISP-B dismisses the issue by simply claiming there are no blockings in his side that could be causing this.
  -
7. All sorts of tests and verification were made in Company-A, and everything looks good. This includes online tests, RBL checks, rDNS, etc. etc.
8. All I can think of at this stage, is that ISP-B is blocking us, be it by our IP, IP block, or because of some particular hardware/software combination they might have (re: http://support.microsoft.com/kb/895857). No answers received about that either.
  -
9. My very last idea is to spoof the IP address and see what happens if we were on a different IP / IP block ????.
  All I need is to find out if the telnet session is prompted properly or even prompted at all...
Suggestions greatly appreciated!
Thanks in advance.
October 18th, 2006, 03:59 PM
SirDice

You can forget about spoofing a TCP connection across the Internet. Blind spoofing is hard enough to do in a lab environment..

Solve the issue.. Use a sniffer to see what's actually going out and getting back..

Can you connect to any other port besides 25?

One thing I can think of is NAT.. The packets at Company-A aren't NAT'ted and Company-A is using RFC-1918 addresses (private address ranges).. Meaning the packets arive at ISP-B with a non Internet routable source address. Using a sniffer on Company-A's Internet connection will show this..
October 18th, 2006, 04:01 PM
Opus00

I assume since you stated Company-A has an internal email server it means you are behind a firewall and possibley using NAT. Have you tried to change your NAT'd address to another in your netblock range. Maybe they blocked just the IP and not the whole range.

I also recall having a similar issue which turned out to be some sort of DNS conflict(difficult to recall exactly since it was years ago) but it had something to do with the DNS name resolving to a different IP or the IP resolving to a different name and the server rejecting the connection since their was no valid A/MX record. I'll try and go back and see if i can get the exact information and will post if i do fully recall it. Sorry for the ambiguity
October 18th, 2006, 06:34 PM
siko9

Quote:

Can you connect to any other port besides 25?

I had scanned it when the issue began and there were some other ports available I think.

Quote:

Use a sniffer to see what's actually going out and getting back..

If I read this correctly, I get nothing after the third packet, wich should be the server´s response. I DO get a response on packet 4 sniffing from an external location.
I did this from a work station, I would like to avoid messing (even more) with the mailserver because of this.

Quote:

Meaning the packets arive at ISP-B with a non Internet routable source address. Using a sniffer on Company-A's Internet connection will show this..

Company-A has no known issues with any other server. Then again, the same goes for ISP-B.
I sniffed Company-A connection with a non-related mailserver, but don´t know what I whould look at to detect problems with the routable source address??

Quote:

Have you tried to change your NAT'd address to another in your netblock range. Maybe they blocked just the IP and not the whole range.

If you mean the public IP, I haven´t change it, and it would be kinda too disruptive only to find out the problem is at netblock level.
If you mean the internal IP, I have made tests from several systemas in the LAN and they all fail in the same manner.

Quote:

it had something to do with the DNS name resolving to a different IP or the IP resolving to a different name and the server rejecting the connection since their was no valid A/MX record.

We (two ISPs, online tools and me) can´t detect any obvious mis-configurations about DNS, rDNS, etc.
Both ends seem to be resolving fine.

TIA.
October 18th, 2006, 06:43 PM
SirDice

Quote:

Originally Posted by siko9

If I read this correctly, I get nothing after the third packet, wich should be the server´s response. I DO get a response on packet 4 sniffing from an external location.
I did this from a work station, I would like to avoid messing (even more) with the mailserver because of this.

Sniff the traffic at company-A's Internet connection, preferably before and after the firewall.. You need to see the TCP three-way handshake:

A ------SYN-----> B
A <--SYN/ACK-- B
A ------ACK-----> B

Basic TCP/IP stuff.. Forget about DNS etc.. Start troubleshooting the basics. If this works, it means you're able to make a connection and nothing is blocking the traffic at the IP level.
October 18th, 2006, 07:25 PM
siko9

OK, I agree that this is at a more basic level

This is what I got and tried to describe before:

There are only 3 packets being transmitted, after that, the connection usually stays there forever.
In this case I waited 7 minutes before starting to press Ctl+C to cancel it. Those are packets 4 to 10.
Failure:
[img=http://img505.imageshack.us/img505/6531/connectionfailuregp9.th.jpg]

This is what I get telneting from a 2rd party location.
Packet 4 has the expected prompt from the server. I ended the connection in this case, but the exchange is properly captured if I go on.

Success (external)
[img=http://img519.imageshack.us/img519/2917/connectionokyb6.th.jpg]
October 18th, 2006, 10:58 PM
patrande1

Have you tried doing a trace route from the host that isnt able to get to the mail server?

Just type "tracert <mail server IP> in your windows command prompt.

Compare this with a trace from a host that is able to access the server. This should tell you where your packets are getting dropped.
October 19th, 2006, 09:15 AM
SirDice

Siko9, download and install wireshark. Use that to sniff the traffic. It'll show all the packets in detail..
October 19th, 2006, 02:36 PM
siko9

I would say results are similar, from the troubled point (Company-A) I get the 3 way handshake and then nothing, it stalls there and no other packet seems to be passed between them.

OTOH, from an external location the communication carries on as expected.

Now, the traceroute is showing something curious.

I ran a few from Comp-A, home, and some online sites.
* A couple of traces are ending-up in 200.69.129.146
* A couple in 209.99.224.205
* And Comp-A is getting beyond 209.99.224.205 :

Quote:

5 3 ms 3 ms 4 ms 209.99.224.205
6 4 ms 3 ms 4 ms 10.40.11.11
7 7 ms 7 ms 6 ms 10.40.70.1
8 5 ms 5 ms 5 ms 10.40.5.129

:confused:

PS: ISP-B mailserver(s) should be 209.99.224.5 and/or 209.99.224.6

Thanks for the help so far
October 19th, 2006, 04:43 PM
siko9

OK, FWIW,

I changed the DNS server used in Comp-A workstation (from Comp-A´s ISP) for the ones of a different provider and the traceroute´s results are the same.

I did that on-the-fly, no rebooting, cause I am doing that remotely and can´t risk loosing acces to taht terminal. It still seems valid though, since name resolution didn´t work with the "alternative" DNS.

Regards.
October 19th, 2006, 05:00 PM
cheyenne1212

So if you use the domain name for the mail servers your getting the wrong ip now?

If thats the case, you might double check your DNS settings etc...make sure the A records and what not are correct.
October 19th, 2006, 05:20 PM
siko9

thanks for chiping in

no, that is not what´s happening

If I traceroute from Company-A to mailserver-ISP-B, the trace goes beyond the IP where most of the other traces finish (209.99.224.205) and shows back those 3 additional IPs.

This seems to happen only from Company-A, using two DNS settings, the usual Company-A DNS settings and an "alternative" one from another provider.

AFAIK, 209.99.224.5 / 6 are ISP-B´s DNSs that have their MX record pointing to them, and I assume connections are forwarded to their mailserver´s IP. But this is grasped from a non very helpful ISP-B admin.

I never discarded some DNS problem, like DNS posoning, but if I do get to that .205 IP, that is, maybe, a firewall(?) wouldn´t it mean the problem is internal routing at their end?
October 19th, 2006, 06:11 PM
phishphreek

It seems very odd to me that you can see the hops on their private network. Normally private addresses (RFC 1918) aren't able to be traced over the internet. Are you also on a 10.x.x.x subnet?

When I trace that address from where I am, 209.99.224.205 is the last hop.

Like you, I also assume that 209.99.224.205 is the mail server on a public address, or 209.99.224.205 is a router or firewall which NATs/forwards the appropriate ports to the internal mail server.

Seeing that the hop before it times out, I'd assume that the hop before is the router and 209.99.224.205 is actually a public mail server and it is not natted out. This is just a guess.

Have you called ISP-B with the additional info?

Try to escelate it (request to speak with supervisor or manager) or get another tech who is more willing to help you.

Is it possible that your mailserver is on some sort of spam blocklist?

In the meantime, if you have access to some other network, you could always setup a mail relay to get mail to its desitnation until you figure out what the real problem is.
October 19th, 2006, 07:25 PM
siko9

So I guess that being able to reach those IPs is closely related to the problem, wherever it is.
Is there any explanatio for this?? :confused:

We are not using a similar IP range for public nor private addresses, and we are not in any spam database that is commonly known. ISP-B said he had confirmed we weren´t in the one they use.

Unfortuantely, I don´t have the resources to set up a mail relay.

And as to contact a supervisor... well, I´ve resorted to packet sniffing and thought it could be useful to spoof IPs to see if I could at least get an error message or anything, that gives you an idea of how useless contacting ISP-B has been so far :rolleyes:

Maybe I should do it with this 10.x.x.x IPs, but I don´t really have hopes about. Company-B is about to cancel ISP-B´s service because of this and they still don´t care about it...
October 19th, 2006, 08:29 PM
phishphreek

Some places just don't care about loosing customers. A person said before that spoofing IPs would be difficult. That is correct. Spoofing UDP is much easier than TCP because TCP requires constant syn/ack back and forth. You have to predict everything the dest. would be sending back to you.

It sounds like you have a grasp on the basics of TCP/IP. Do some reading on packet crafting and packet spoofing. It is easy to do in theory, but difficult in practice. You can use something like hping to craft packets but you're going to have to predict how the remote machine is going to act/respond to your packet. You'll never see the response. It will be routed to wherever you crafted the src address.

If you are are demanding and persistant you can get someone to help you. I do it all the time. Most of the time, the first reps you get are just there to weed out the basic every day problems. They know next to nothing and they are most likely in their entry level job right out of college or high school. You have to have them pass it on to someone higher up in the chain.

If the ISP is unwilling to work with you on an issue... find a new ISP. There are plenty out there. Speak with your account rep and write a letter of complaint.
October 20th, 2006, 02:08 AM
siko9

phishphreek, thanks for your comments. Packet manipulation seems too complex for the time I have available, most interesting though.

Anyway, I am delving in the trace of the packet and found some very interesting things,
I did about 30 tracerouts from different onlines sites around the globe...

Which IPs and how many times they were reported as last hops:

209.99.224.205 - 7 times - (note that this IP is similar to the aledged mailserver, 209.99.224.6)

200.69.129.146 - 22 times - (resolved as 200.69.129.146.static.techtelnet.net)

And here is turns interesting...

This single site mentioned the "expected" IP as last hop:
http://www.supporttechnique.net/trace.ihtml
200.69.129.146 > 209.99.224.6

These two sites reported private IPs as I am seeing in Company-A´s traceroutes
(last relevant IPs are listed)

http://tools.telpin.com.ar/cgi-bin/traceroute
200.55.13.150 > 10.40.11.11 > 10.40.70.1 > 10.40.5.129
(location: Argentine)

http://www.zilos.com/conozcanos/traceroute.html
209.99.224.205 > 10.40.70.4
(location: Spain)

Additionaly, as I mentioned earlier there are 3 domains hosted by this ISP-B that we have troubles with.acerouting to them from Comp-A shows this:

Quote:

Traza a la direcci¢n mail.domain1.com [209.99.224.6]

5 3 ms 2 ms 3 ms 209.99.224.205
6 3 ms 3 ms 4 ms 10.40.11.11
7 6 ms 6 ms 5 ms 10.40.70.1
8 5 ms 4 ms 4 ms 10.40.5.129

Traza a la direcci¢n mail.domain2.com [209.99.224.6]

5 3 ms 2 ms 3 ms 209.99.224.205
6 3 ms 3 ms 4 ms 10.40.11.11
7 6 ms 6 ms 5 ms 10.40.70.1
8 5 ms 4 ms 4 ms 10.40.5.129

Traza a la direcci¢n mail.ISP-B.com [209.99.224.21]
5 3 ms 2 ms 3 ms 209.99.224.205
6 5 ms 4 ms 4 ms 10.40.11.9
7 5 ms 5 ms 6 ms 10.40.5.129

Notice the patern in the private IPs... I can´t help it but thinking of a internal routing problem at their end... the originating mailserver can´t be making up those addresses for 3 domains just like that... and even if it could, how does it explain the finding on the last online traces I got ????
Spam trap perhaps?

At least now I Know I´m not seeing ghosts in my internal tracerouts. o_O

Regards.

EDIT:
on further thinking, isn´t each IP provided by the previous hop?
Then those private IPs must be being provided by 209.99.224.205 and thus the problem is not at Company-A, since the issue is experienced from 3rd party locations too, but rather at ISP-B given the similar addresses.

Is it right to asume then that the point of failure is probably at that particular IP??
October 23rd, 2006, 07:08 PM
siko9

Quote:

EDIT:
on further thinking, isn´t each IP provided by the previous hop?
Then those private IPs must be being provided by 209.99.224.205 and thus the problem is not at Company-A, since the issue is experienced from 3rd party locations too, but rather at ISP-B given the similar addresses.

Is it right to asume then that the point of failure is probably at that particular IP??

*bump*
Anyone can throw some light in this?

Thanks in advance.
October 24th, 2006, 09:17 AM
SirDice

Read up on how traceroute works..

It basicly means a host sends an ICMP Echo Request with TTL=1, TTL=2, TTL=3 etc..