4 ms·

MS has supported event forwarding since 2003. You can set machines to forward events or have them pulled. The events are XML that conform to a published schema.

MS has supported event forwarding since 2003. You can set machines to forward events or have them pulled. The events are XML that conform to a published schema. There is a WMI call that call pull the aggregated events off the collection servers. I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works. Why are they different? The event log has some transactional guarantees that were required for a specific kind of security evaluation...C2? I can't remember the rest. The thing is...you don't have to install a client on the domain controllers. You can setup forwarding to some log hosts and collect them there.

pjc50 11y ago
It's like people don't even try to learn how it works It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.
- sudioStudio64 11y ago
  You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.
  - lygaret 11y ago
    That's a really good point, thank you. I've never really thought about it that way; e.g. the registry is something you should sort of treat as an opaque blob of state (like a smalltalk image?) that you just mutate over time programatically, rather than as a declarative set of configurations to bring the machine to at any time.
  - silon3 11y ago
    > You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).
    - sudioStudio64 11y ago
      After coding for several years, the two aren't all that different. I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX. Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.
      - pjc50 11y ago
        That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :) I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system. With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source (I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)
        sudioStudio64 11y ago
freehunter 11y ago
From what I know, you can use Microsoft RPC to pull event logs or you can install a syslog forwarder, or you can do a combination of these two things (have a Windows syslog forwarder that is not a DC that can pull logs from a DC through RPC). The problem with the last option is, adding another Windows server costs an additional license. Installing a client on the DC doesn't. And there are limitations, so in a huge Windows environment, you're installing several extra Windows servers, each individually licensed, just to forward logs. I've worked in security with several different SIEMs for half a decade and those are the only options I've ever seen. So if there's something else besides this that is easier, it's not just me who is missing it. HP, Dell, Intel and a dozen other companies are missing it as well.
- sudioStudio64 11y ago
  Secureworks was the vendor I was referring to... Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller. Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large footprint and exposure at an organization. For what its worth... most IT people are just as bad. I'm trying to turn that around at my organization. I don't blame people...I get it. It just takes time to disseminate info. Its called event collector. Spread the word. https://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb4...
  - freehunter 11y ago
    >Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller. You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license. There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.

pjc50 11y ago

It's like people don't even try to learn how it works It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.

sudioStudio64 11y ago
You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.
- lygaret 11y ago
  That's a really good point, thank you. I've never really thought about it that way; e.g. the registry is something you should sort of treat as an opaque blob of state (like a smalltalk image?) that you just mutate over time programatically, rather than as a declarative set of configurations to bring the machine to at any time.
- silon3 11y ago
  > You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration. That's an interesting way of putting it. I strongly prefer the Unix way then,(just avoid turing complete config languages).
  - sudioStudio64 11y ago
    After coding for several years, the two aren't all that different. I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX. Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.
    - pjc50 11y ago
      That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :) I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system. With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source (I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)
      - sudioStudio64 11y ago

freehunter 11y ago

From what I know, you can use Microsoft RPC to pull event logs or you can install a syslog forwarder, or you can do a combination of these two things (have a Windows syslog forwarder that is not a DC that can pull logs from a DC through RPC). The problem with the last option is, adding another Windows server costs an additional license. Installing a client on the DC doesn't. And there are limitations, so in a huge Windows environment, you're installing several extra Windows servers, each individually licensed, just to forward logs. I've worked in security with several different SIEMs for half a decade and those are the only options I've ever seen. So if there's something else besides this that is easier, it's not just me who is missing it. HP, Dell, Intel and a dozen other companies are missing it as well.

sudioStudio64 11y ago
Secureworks was the vendor I was referring to... Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller. Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large footprint and exposure at an organization. For what its worth... most IT people are just as bad. I'm trying to turn that around at my organization. I don't blame people...I get it. It just takes time to disseminate info. Its called event collector. Spread the word. https://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb4...
- freehunter 11y ago
  >Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller. You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license. There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.