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 <[email protected]> wrote:
From: Jared Mauch <[email protected]>
Subject: Re: [c-nsp] Port 1720 & 1863
To: "abs" <[email protected]>
Cc: "Steve Bertrand" <[email protected]>, [email protected]
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 <[email protected]> wrote:
From: Steve Bertrand <[email protected]>
Subject: Re: [c-nsp] Port 1720 & 1863
To: "abs" <[email protected]>
Cc: "Adam Strawson" <[email protected]>, [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
