[c-nsp] Port 1720 & 1863

Wed Dec 23 20:42:12 EST 2009

On Wed, 23 Dec 2009, abs wrote:

> doesn't look like it's being intercepted... the traffic goes from my host to the router to my ip address...

I'm with Jared on the theory that there is a middlebox somewhere on 
the way being "transparently helpful" - though probably worth clarifying 
that you need to run *two* tcptraceroute sessions  - one to e.g. port 22 
on your router (that you *know* you are talking to the router itself), 
and the other to your suspect port. If the second one gives a different 
path, good chances that there's a middlebox flirting with TCP.

Digression: for both of the cases you will indeed always see your router's 
IP as the final hop, since tcptraceroute would use received SYN-ACK from 
the target IP address to know it is done. And since you are able to 
telnet to that port, we already know before starting the tcptraceroute 
that the source address of the SYN-ACK will be the same as your router's 
IP. That's why you would need to compare the two outputs.

Another "indirect" approach to do is also to capture the traffic on your 
host's end into the PCAP - both the scan and the regular ssh session that you 
would have to the router; and compare the TTL of the IP packets for ssh 
and for the "suspected" ports. Other differences in the things like MSS, 
SACK, window scaling, etc. are worth looking at as well - each of those 
differences is an extra clue about where the SYN-ACK came from. IP ID 
analysis between the two series might work, but can be a bit difficult - 
two streams of random numbers are hard to separate.
other. In any case, generally the helpful middleboxes will out themselves 
this way.

But: both of these approaches do not detect the esoteric case of a 
sufficiently helpful middlebox that would L4-proxy all of your traffic and 
then selectively forward some (though I'd not count this as very likely, 
so still worth suggesting two tcptraceroutes).

Few additional ideas to verify that the suspect traffic is indeed hitting 
the router:

If you are on a recent enough version, you can do embedded packet capture 
on the router side too: 
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_packet_capture_ps6441_TSD_Products_Configuration_Guide_Chapter.html

If not, to verify it is an open port for the to-the-box traffic,
replace "123" below with a number that you do not use for an 
extended ACL currently:

access-list 123 permit tcp any host x.x.x.x eq 1720
access-list 123 permit tcp host x.x.x.x eq 1720 any
access-list 123 permit tcp any host x.x.x.x eq 1863
access-list 123 permit tcp host x.x.x.x eq 1863 any

then run "debug ip packet detail 123" (make sure to have "logging monitor 
debugging" and "terminal monitor"). (IMPORTANT: do not forget the access 
list, and turn off the debug before removing the ACL, else you will print 
debugs for all the  traffic to the box that includes your ssh session to 
it, with obvious painful experience). And see if you have the packets 
reflected in that debug.

If you *do* see the packets from your test host to 1720/1863 either in the 
packet capture on the *router itself* or in the debugs on the router, 
feel free to send me those outputs unicast alongside with the "sh 
ver"/"sh run", please.

cheers,
andrew

>
> --- On Wed, 12/23/09, Jared Mauch <jared at puck.nether.net> wrote:
>
> From: Jared Mauch <jared at puck.nether.net>
> Subject: Re: [c-nsp] Port 1720 & 1863
> To: "abs" <abhishake00 at yahoo.com>
> Cc: "Steve Bertrand" <steve at ibctech.ca>, cisco-nsp at puck.nether.net
> Date: Wednesday, December 23, 2009, 2:38 PM
>
> Have you done a tcptraceroute to see if someone is intercepting your tcp/1720?
>
> - Jared
>
> On Dec 23, 2009, at 2:34 PM, abs wrote:
>
>> that makes a lot more sense now..
>>
>> the box i'm running nmap from is from a remote location.  i am able to telnet into port 1720 and the connection is established (as per netstat -na)
>>
>> i also added deny tcp any any eq 1720 at the top of the acl but that still didn't help.  i'm still able to connect to that port using telnet...
>>
>> i even tried removing the established rule but that didn't change anything as well.
>>
>> --- On Wed, 12/23/09, Steve Bertrand <steve at ibctech.ca> wrote:
>>
>> From: Steve Bertrand <steve at ibctech.ca>
>> Subject: Re: [c-nsp] Port 1720 & 1863
>> To: "abs" <abhishake00 at yahoo.com>
>> Cc: "Adam Strawson" <adam at thepub.cx>, cisco-nsp at puck.nether.net
>> Date: Wednesday, December 23, 2009, 2:20 PM
>>
>> abs wrote:
>>> that is what i was thinking as well so i removed that line but that caused all responses to internal traffic to be blocked.  What do you exactly mean by specific?  Wouldn't I have to put a rule for each type of traffic? 
>>
>> On an inbound ACL, allowing established TCP sessions means that a TCP
>> connection must be made from the 'internal' side of the interface, and
>> only inbound TCP traffic that is associated with that session can
>> ingress the interface.
>>
>> Your 'deny ip any any' at the end would block ALL inbound TCP, other
>> than SSH and pre-established (by an internal device) sessions.
>>
>> Reviewing your other email (that hasn't hit the list yet), do you happen
>> to have an H.323 session established to your nmap box when you see the
>> port as open?
>>
>> What do you see when you (while on your nmap box):
>>
>> % telnet <ip addr> 1720
>> % netstat -na | grep 1720
>> % netstat -na | grep <ip of remote>
>>
>> If you want, provide me with the IP of the box off-list, and I'll scan
>> it from one of my hosts.
>>
>> Steve
>>
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>