How to Determine Which Service in LSASS.EXE Binds to Port X?
Will
domain controllers, including kerberos, netlogon, etc. In examining the
LSASS process with Process Explorer, I'm seeing many ports other than the
well-known ones being opened for access through RPC. How can I determine
which specific services are binding to each of the ports? Isn't there an
RPC mapping tool I can run on a server that will clearly identify the actual
service that has bound to each of the RPC assigned ports like 1026?
The reason I am asking this is that I have a domain controller that is being
contacted on TCP port 1026 by only one member server in the domain.
Process Explorer establishes that LSASS owns this port, and I assume it is
an RPC assigned port number that could change from one boot to the next.
I want to clearly identify what the service bound to that port is and try to
understand why only one member server is contacting that service.
The activity is currently being blocked by a firewall. We have all of the
critical RPC services (e.g., NETLOGON, AD replication, etc) bound to fixed
ports and those ports are exposed through the firewall.
--
Will
Paul Bergson [MVP-DS]
how to modify the high ports pool for RPC. I have made ours in a much
smaller pool.
http://www.pbbergs.com/windows/articles/FirewallReplication.html
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Will" <weste...@noemail.nospam> wrote in message
news:OuedndYnuZZX9Wbb...@giganews.com...
Will
news:%23F4ITzP...@TK2MSFTNGP03.phx.gbl...
> Check out an article I have on AD and Firewalls. In it is an explanation
> on how to modify the high ports pool for RPC. I have made ours in a much
> smaller pool.
>
> http://www.pbbergs.com/windows/articles/FirewallReplication.html
I'm very familiar with all of the issues on the above page, and I would like
to add a few thoughts:
1) You need to also add the NETLOGON service as a fixed port. This is
perhaps the single most used service among the dynamic range RPC services,
and you do so by creating a DWORD with the port value at the registry
location:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DCTcpipPort
2) In our experience, once you give fixed ports to NTFRS, NTDS and NETLOGON,
you NO LONGER NEED VARIABLE RPC PORTS (what you assign to 10002 to 10200 in
your example). We have small forests, so maybe there are load balancing
considerations I don't know about, but dcdiag /v reports no errors between
controllers with just those three fixed ports and we completely lock out the
variable RPC ports. But we have been running this way for at least a year
now with no errors popping up in dcdiag /v or the eventviewer logs. If we
have overlooked some legitimate RPCs I would very much like to document
those and read further about them.
To wax poetic a bit, any firewall design for a domain controller that uses
dynamic ports is from my point of view not much better than having no
firewall. The rootkit viruses will either modify system directly or
modify behavior of a well-known system service EXE like LSASS. It's
nothing for them to just open up another RPC, and then they have you. By
locking all known services to fixed ports, your system can be compromised,
and it can try to open up additional ports, but no one can contact those
ports, thus greatly limiting one path to gain access to the box from another
computer.
All the above is just response to the URL you provided in your response.
My original question was how to identify (by name and function) the specific
RPC service running under a specific process. The utility in your link
above PortQryUI and PortQry do not do that. Like Process Explorer, PortQry
simply establishes the fact that process X has open port Y. In my case
that process is LSASS and the port is 1026. What I need is a tool like an
"RPC Query" that will actually use port 135 to enumerate all of the active
RPC services on a box and the ports they run on. Then I can cross
reference the RPC service by name to port 1026 and research that service
further. Such a tool must be possible to write because otherwise how could
any EXE contact the RPC mapper port 135 and enumerate services on the box?
--
Will
Andy C
Placing everything behind the firewall.
Is it for security purposes or for logging purposes or some other cool
reason that I dont know?
-Andy
"Will" <weste...@noemail.nospam> wrote in message
news:ncqdndHffdlypmHb...@giganews.com...
Will
news:eyBL2mWA...@TK2MSFTNGP04.phx.gbl...
> Not to go off topic but I am just curious as to the benifit to you of
> Placing everything behind the firewall.
> Is it for security purposes or for logging purposes or some other cool
> reason that I dont know?
It is for security only. Our entire Windows 2000 network was hit by a
rootkit virus, and once you have gone through that kind of nightmare you do
a lot of thinking about what kinds of network designs make it structurally
very difficult for a trojan application to operate or to spread. All of
those Windows 2000 computers were unrecoverable and had to be rebuilt. As
a small company, it took us years to recover from that, and in fact some of
the machines are still being rebuilt as time allows. As part of the
rebuilding effort, I did a lot of thinking about how current network designs
contribute to this awful worldwide epidemic of trojans and rootkits.
Fundamentally, ethernet with TCP was never built from the start for
security. Consider the ARP protocol for example. ARP sits below TCP and
any Microsoft security layers, and it's the basic protocol that allows
computers on the same subnet to find each other. Unfortunately, it also
lets any authorized software running on your computer essentially sit back
and let the network tell it what targets of interest exist on the network.
The Trojan then can start probing each of the IPs that are broadcast to be
of interest.
From the standpoint of Microsoft Networking, consider what the sniffer trace
of a network looks like when you don't turn off NetBIOS over TCP. There
are huge number of broadcasts that identify for any listener on the network
targets of interest. The protocols that use ports 137, 138, and 139 are
all ancient stuff, with huge security holes.
To address those kinds of concerns, we have gotten to the point where we put
every key server on its own dedicated subnet behind a firewall. That
stops the ARP problem dead, because no other machine can see the ARPs since
only the firewall and the server share the same subnet together. While we
turn off NetBIOS over TCP on both clients and servers, having dedicated
subnets lets us enforce that policy strictly and block ports 137, 138, and
139 right at the firewall, so even a misconfigured machine cannot use
unsecure protocols. Every port in and every port out to every server is
controlled. So even if the hacker was root on some of these servers, and
they could infect them with rootkits, there would be little of profit in
doing so. Any ports the rootkit opens up cannot be reached. Any
outgoing connections to unauthorized ports or HTTP sites are blocked.
I'm sure that parts of our network are still hacked. But we are setting
the bar higher and higher, and at some point the controls will be such that
infestations just won't be able to spread, will be detectable quickly, and
will have limited ability to do damage even on the infected machines.
Unfortunately, getting to that nirvana takes a level of knowledge,
experience, experimentation, and just plain time that I don't believe most
users (or management) would tolerate.
A domain controller is the brain of the network, and once it is compromised
the battle is largely over and you can no longer trust authentication or any
of the services the domain controller is delivering. So for us we decided
early on that we were going to go to war with the domain controllers and
understand top to bottom the services they were delivering, and which of
those needed to be presented for an Active Directory network to function
correctly. The advantage to limiting the domain controller to just fixed
ports is that it can then be secured by a firewall. Someone who
compromises the domain controller and runs a service that opens additional
ports on the domain controller won't be able to use them. The ports might
be listening, but the firewall prevents them from being reached. Because
no other computer sits on the domain controller's subnet, there is no path
to the domain controller that does not enforce the security policy
implemented by the firewall.
Having lived with this basic design for about a year, it has proven to not
only be extremely reliable, but has had the added benefit of speeding up the
network considerably. I don't understand why this is yet, but perhaps
putting everything on dedicated subnets just cuts down the level of
broadcast traffic so much that retransmissions and latency on each subnet go
way down. Our internal firewall now has about 30 subnets on it. It was
a huge amount of work to set it up, but it's not very hard to maintain as
long as you document the network with diagrams, and organize the ruleset
correctly.
Will
news:%23F4ITzP...@TK2MSFTNGP03.phx.gbl...
> on how to modify the high ports pool for RPC. I have made ours in a much
> smaller pool.
>
> http://www.pbbergs.com/windows/articles/FirewallReplication.html
The program I needed was RPCINFO. The service that was running on port
1026 was NT Directory NSP Interface. That is apparently some kind of peer
to peer protocol networking service (first time I ever knew about it).
What Windows 2000 application would be trying to use that?
--
Will
Andy C
with the subnetting of servers and clients. I hadn't thought of using a
firewall on an internal domain controller but you definitly make a good
point. Good luck with you lockdown!
-Andy
"Will" <weste...@noemail.nospam> wrote in message
news:ZdWdnURxZYl38WHb...@giganews.com...
S. Pidgorny <MVP>
"Will" <weste...@noemail.nospam> wrote in message
> To wax poetic a bit, any firewall design for a domain controller that uses
> dynamic ports is from my point of view not much better than having no
> firewall. The rootkit viruses will either modify system directly or
> modify behavior of a well-known system service EXE like LSASS. It's
> nothing for them to just open up another RPC, and then they have you. By
> locking all known services to fixed ports, your system can be compromised,
> and it can try to open up additional ports, but no one can contact those
> ports, thus greatly limiting one path to gain access to the box from
> another computer.
Note that whatever the scenario is firewall doesn't add much security
controls - the attack (and compromise) scenarios are the same with or
without a firewall between the elements of AD infrastructure.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
* http://sl.mvps.org * http://msmvps.com/blogs/sp *
S. Pidgorny <MVP>
"Will" <weste...@noemail.nospam> wrote in message
news:ZdWdnURxZYl38WHb...@giganews.com...
> "Andy C" <acrac...@fluidmaster.com> wrote in message
> news:eyBL2mWA...@TK2MSFTNGP04.phx.gbl...
>> Not to go off topic but I am just curious as to the benifit to you of
>> Placing everything behind the firewall.
>> Is it for security purposes or for logging purposes or some other cool
>> reason that I dont know?
>
> It is for security only. Our entire Windows 2000 network was hit by a
> rootkit virus, and once you have gone through that kind of nightmare you
> do a lot of thinking about what kinds of network designs make it
> structurally very difficult for a trojan application to operate or to
> spread. All of those Windows 2000 computers were unrecoverable and had
> to be rebuilt.
And you reckon a firewall would have prevented that?
Will
news:OGY%23LL1AI...@TK2MSFTNGP02.phx.gbl...
> "Will" <weste...@noemail.nospam> wrote in message
> news:ZdWdnURxZYl38WHb...@giganews.com...
> > "Andy C" <acrac...@fluidmaster.com> wrote in message
> > news:eyBL2mWA...@TK2MSFTNGP04.phx.gbl...
> >> Not to go off topic but I am just curious as to the benifit to you of
> >> Placing everything behind the firewall.
> >> Is it for security purposes or for logging purposes or some other cool
> >> reason that I dont know?
> >
> > It is for security only. Our entire Windows 2000 network was hit by a
> > rootkit virus, and once you have gone through that kind of nightmare you
> > do a lot of thinking about what kinds of network designs make it
> > structurally very difficult for a trojan application to operate or to
> > spread. All of those Windows 2000 computers were unrecoverable and had
> > to be rebuilt.
>
> And you reckon a firewall would have prevented that?
Every case is different. This particular trojan spreads by using ports 139
and 445 and trying to do a buffer overland on every host it contact. If
1) You have a network with 20 hosts
2) 18 of those 20 hosts are on different subnets than the affected host
3) The firewall that joins those subnets prevents the affected host from
using port 139 or 445 to any of the 18 hosts
then yes it follows that the 18 hosts are not at risk of exposure to the
trojan from the one host that is infected. They might be exposed by other
methods, but not by direct exposure to the one infected host.
You cannot close every door. But it seems to me that most networks are
more like a home with unlocked doors, and its just way too easy for
infections to spread once they get inside the firewall.
--
Will
Will
> "Will" <weste...@noemail.nospam> wrote in message
>
> > To wax poetic a bit, any firewall design for a domain controller that
uses
> > dynamic ports is from my point of view not much better than having no
> > firewall. The rootkit viruses will either modify system directly or
> > modify behavior of a well-known system service EXE like LSASS. It's
> > nothing for them to just open up another RPC, and then they have you.
By
> > locking all known services to fixed ports, your system can be
compromised,
> > and it can try to open up additional ports, but no one can contact those
> > ports, thus greatly limiting one path to gain access to the box from
> > another computer.
>
> Note that whatever the scenario is firewall doesn't add much security
> controls - the attack (and compromise) scenarios are the same with or
> without a firewall between the elements of AD infrastructure.
The domain controller is a very special case, because it needs to be open to
everyone with File & Printer sharing enabled.
You can limit domain admins to console logins, and you can make sure the
domain controller has no writable shares, but yes it's very difficult to
prevent infection from someone who is determined and knowledgeable. I'm
always trying to learn more about this subject and look for additional ways
to protect the domain controller. I feel this is an area Microsoft needs
to pay a lot more attention to.
Having said that, it's wrong to think a firewall doesn't add much security.
1) For starters, many trojans operate by opening up ports on the infected
machine so that it can be contacted later and information extracted.
Maybe you cannot stop those ports from opening, but what good do they do the
intruder if he cannot contact them through the firewall?
2) A key strategy for trojans is to write an infected payload to some file
system that the domain controller has the ability to read, and then do a
service start command pointing to the infected payload. That gets the code
loaded with SYSTEM privileges. How exactly is the intruder going to do
this if the domain controller has no writeable shares and has no access
through the firewall to any file servers? I'm very interested in learning
what other back doors there are, but even if there are some I see value in
closing the doors I can close.
3) How exactly is the trojan that infects the domain controller going to
exchange information with the outside world when you have the domain
controller blocked from making any outside connections to the Internet?
I don't doubt that a sufficiently knowledgeable intruder can find a way
around anything. But I'm not trying to keep the CIA out of my network. I
have nothing they want anyway. I'm trying to keep teenagers and criminal
syndicates who profit from zombies out, and those kinds of intruders are
going for the low hanging fruit. If you raise the bar high enough, and
make them spend more money to control you than they get from the use of your
hardware, at some point they are going to make an economic decision to go
elsewhere.
--
Will
S. Pidgorny <MVP>
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
"Will" <weste...@noemail.nospam> wrote in message
>> > It is for security only. Our entire Windows 2000 network was hit by a
>> > rootkit virus
>> And you reckon a firewall would have prevented that?
Will
> I'd invest in a patching process and tools instead.
Patching isn't mutually exclusive with firewalling.
In terms of cost benefit, constant patching, purchasing of security
tools,and constant administration is all hugely expensive, and reduces risks
of infection only slightly. All of the McAfee software in the world
doesn't protect you when a junior admin logs in as administrator and browses
an infected site and loads an Active/X.
The reason I like to firewall everything is that even if you do get infected
you can greatly reduce the side effects from that event, and it becomes much
more manageable to replace the affected machine.
--
Will
S. Pidgorny <MVP>
"Will" <weste...@noemail.nospam> wrote in message news:sYGdnZ_kW-
> The reason I like to firewall everything is that even if you do get
> infected
> you can greatly reduce the side effects from that event, and it becomes
> much
> more manageable to replace the affected machine.
The reason I don't like firewalling is that firewalls prevent small - and
falling - percentage of security incidents. Yours already happened. ROI will
be next to 0.
Will
> G'day:
>
> "Will" <weste...@noemail.nospam> wrote in message news:sYGdnZ_kW-
>
>> The reason I like to firewall everything is that even if you do get
>> infected
>> you can greatly reduce the side effects from that event, and it becomes
>> much
>> more manageable to replace the affected machine.
>
> The reason I don't like firewalling is that firewalls prevent small - and
> falling - percentage of security incidents. Yours already happened. ROI
> will be next to 0.
Every day I get ROI when the machines still infected try to connect to port
445 or port 139 on other machines on our network and cannot. And honestly
having the firewall log to help give information about connections between
any two points on the network helps to solve non security related issues as
well. It's like having a router with very sophisticated reporting tools.
In any case, you are stating a conclusion about ROI rather than the premise
and argument that lead to that conclusion. If a machine cannot get back
out after infection, that is ROI. If a machine cannot connect to other
machines after being infected, that is ROI. If a machine cannot be
contacted on ports it opens after infection, that is ROI. I don't think
you can be responsive and ignore those points. Of course you don't want to
be infected in the first place, and you patch and observe good security
practices in how you use the machine to help prevent that. None of those
things are mutually exclusive of firewalling.
I agree that most people take your point of view. And for most people they
just slap on a copy of McAfee and stop worrying about it. I'm willing to
invest more time up front to have more predictability about how I spend my
time later.
--
Will
S. Pidgorny <MVP>
"Will" <weste...@noemail.nospam> wrote in message
> I agree that most people take your point of view. And for most people
> they
just slap on a copy of McAfee and stop worrying about it.
The opposite is true - most organisations continue to waste money on
firewalls. Also common is trying to apply different levels of security to
different parts of infrastructure.
Paul Bergson [MVP-DS]
to DC to DC, I would agree and I will have to review your NetLogon Port. I
appreciate the feedback.
All internal to dmz communication (RPC) is by port and machine. We do shut
down all RPC services DMZ to external for our DC's, so we don't have that
threat. We do have additional port protection, internally but won't
disclose our topology.
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Will" <weste...@noemail.nospam> wrote in message
news:ncqdndHffdlypmHb...@giganews.com...
Paul Bergson [MVP-DS]
security.
http://www.microsoft.com/uk/technet/itsshowtime/result_search.aspx?speaker=20&x=31&y=10
--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT
Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
"Will" <weste...@noemail.nospam> wrote in message
news:TdWdnb_F8tMQ4GHb...@giganews.com...
Will
> RPC can be needed for components such as AV. If you are strictly
referring
> to DC to DC, I would agree and I will have to review your NetLogon Port.
I
> appreciate the feedback.
>
> All internal to dmz communication (RPC) is by port and machine. We do
shut
> down all RPC services DMZ to external for our DC's, so we don't have that
> threat. We do have additional port protection, internally but won't
> disclose our topology.
All I can say is with the three fixed RPC ports (two in the Microsoft DC
firewall document and one that I added below), we have had no problems so
far with client to DZ communications.
Will
> firewall document and one that I added below), we have had no problems so
> far with client to DZ communications.
Make that DC not DZ.
--
Will
"Will" <weste...@noemail.nospam> wrote in message
news:U56dnU6g8O619Jfa...@giganews.com...
> "Paul Bergson [MVP-DS]" <pbergson@allete_nospam.com> wrote in message
> news:OmVqKLaC...@TK2MSFTNGP05.phx.gbl...
> > RPC can be needed for components such as AV. If you are strictly
> referring
> > to DC to DC, I would agree and I will have to review your NetLogon Port.
> I
> > appreciate the feedback.
> >
> > All internal to dmz communication (RPC) is by port and machine. We do
> shut
> > down all RPC services DMZ to external for our DC's, so we don't have
that
> > threat. We do have additional port protection, internally but won't
> > disclose our topology.
>
>