I think I need IP Spoofing
Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: I think I need IP Spoofing

Hybrid View

  1. #1
    Junior Member
    Join Date
    Oct 2006
    Posts
    9

    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.

  2. #2
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    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..
    Last edited by SirDice; October 18th, 2006 at 04:03 PM.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  3. #3
    Senior Member Opus00's Avatar
    Join Date
    May 2005
    Posts
    144
    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
    There are two rules for success in life:
    Rule 1: Don't tell people everything you know.

  4. #4
    Junior Member
    Join Date
    Oct 2006
    Posts
    9
    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.

    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.

    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??

    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.

    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.

  5. #5
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    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.
    Last edited by SirDice; October 18th, 2006 at 06:46 PM.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  6. #6
    Junior Member
    Join Date
    Oct 2006
    Posts
    9
    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]

  7. #7
    Junior Member
    Join Date
    Feb 2006
    Posts
    12
    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.

  8. #8
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Siko9, download and install wireshark. Use that to sniff the traffic. It'll show all the packets in detail..
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  9. #9
    Junior Member
    Join Date
    Oct 2006
    Posts
    9
    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 :
    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


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

    Thanks for the help so far

  10. #10
    Junior Member
    Join Date
    Oct 2006
    Posts
    9
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides