Capture port 3389 outbound traffic with asa

phoeneousphoeneous Go ping yourself...Member Posts: 2,333 ■■■■■■■□□□
We received a complaint from our isp that a ton of port 3389 traffic is going outbound to the public. We have an asa 5510 at the perimeter. I created an acl and capture to find the problem child but Im not sure which direction/interface to best apply them on. Should I apply the acl and capture on in/in or out/out?

access-list rdpcaptureacl extended permit tcp host x.x.x.x any eq 3389
access-group rdpcapture acl in interface inside
capture rdpcapture rdpcaptureacl interface inside

or


access-list rdpcaptureacl extended permit tcp any host x.x.x.x eq 3389
access-group rdpcapture acl out interface outside
capture rdpcapture rdpcaptureacl interface outside

Comments

  • ZartanasaurusZartanasaurus Member Posts: 2,008 ■■■■■■■■□□
    If you capture it going out of the outbound port, you'll have to translate the external address back to the internal address. So capturing the inbound in traffic saves you a step.

    Might be faster to just do a sh conn port 3389 though if it's constant RDP traffic.
    Currently reading:
    IPSec VPN Design 44%
    Mastering VMWare vSphere 5​ 42.8%
  • Agent6376Agent6376 Member Posts: 201
    sh ip nat trans | i 3389

    ...

    or whatever the ASA syntax for it is.

    edit: sh xlate | grep 3389
  • ZartanasaurusZartanasaurus Member Posts: 2,008 ■■■■■■■■□□
    sh xlate will just show NAT mappings and what ports were assigned to that session, not the actual TCP ports in use.
    Currently reading:
    IPSec VPN Design 44%
    Mastering VMWare vSphere 5​ 42.8%
  • AhriakinAhriakin SupremeNetworkOverlord Member Posts: 1,799 ■■■■■■■■□□
    If you apply that ACL as is to the interfaces then capturing it won't be your biggest worry :)...(remember...implicit deny)
    You don't need to apply it to any interface, just the capture. Also since it looks like you aren't yet think about applying egress filtering. Ideally define what is needed explicitly and deny everything else, at worst compile some service groups of protocols you never want to see leave your network and deny them, permit everything else.
    Also consider getting a good searchable Syslog server (e.g. Splunk) and you can track the connection creation/teardown messages (and any relevant protocols/IPs pretty) easily. If you want to go even further get a Netflow collector that can handle ASA NSel (Netflow 9 based).
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
  • jwasdenjwasden Registered Users Posts: 1 ■□□□□□□□□□
    we are seeing the same issue. Did you track the issue to a viral attack? We have seen 20GB of 3389 outbound traffic today.
Sign In or Register to comment.