In this post my intention is just to give some quick points on QRadar High Availability (HA)
1. HA Overview
- Uses Primary and Secondary HA hosts
- Uses Virtual IPs
- Network connectivity is tested via hearbeat (pings) to all managed hosts
- HA Can be configured for either console or managed host
- Both devices must have the same versions of the software
- Both devices must support the same DSM, scanner and protocols RPMs
- Uses data synchronization or shared external storage
- Consistency is maintained locally by using Distributed Replicated Block Device (DRDB)
- If using external storage data consistency is maintained through iSCSI or Fibre Channel
- Data is synchronized in real time
- Note: Asset profiler can impact DRDB speed
- "/store" partition on secondary is automatically replicated to the secondary host
- Ensure min 1 Gbps between primary and secondary HA hosts
- Initial synchronization can take greater than 24 hours
This may be an understatement. I've seen initial synchronization take upwards of 72 hours.
- Secondary host goes into "standby" after synchronization
- Primary HA hosts status becomes "offline" when restored from a failover
- Primary needs to be placed "online" before it becomes active
- Disk replication is enabled while primary is "offline"
- Post disk failover synchronization is faster
- Basically uses deltas
- When the primary host is restored, only the data collected by the secondary during the period the primary was unavailable is synchronized
- Replacing or reformating the disk on the primary can result in longer synchronization time in the event of a failback
IP Considerations
- Uses Virtual IPs
- Needs 3 IP address - VIP, Primary and Secondary
- The IP address initially configured on the primary host is automatically made the cluster VIP
- A new IP will need to be assigned to the primary once HA configuration is started
- Primary host can act as a standby for secondary
- VIP is used by a host that has a status of active
- All IPs must be in the same subnet
- Latency must be less than 2ms for traffic crosing the WAN
HA Wizard
- Used to configure Primary, Secondary and cluster VIP
- Verifies the secondary has a valid HA activation key
- Verifies the secondary is not part of an existing HA cluster
- Verifies software version is the same on both devices
- Verifies external storage (if configured) on primary and then secondary
- Verifies both support the same DSM, scanner and protocol RPMS
Failover scenarios
- Power supply failure
- network failure (detected by connectivity tests)
- OS malfunction that delays or stops hearbeat tests
- RAID failure
- Manual failover
- Management interface failure on primary hosts
- Primary does not take back its role as primary in the case of a failover.
- Secondary stays as primary while primary acts as standy
- Primary must be switched to "active" to take over its role
- No failover for software errors or disk capacity issues
- If both primary and secondary are unable to ping a managed hosts no failover occurs
- If primary cannot but secondary can ping a managed host, failover occurs
HA Failover event sequence
- File systems are mounted
- Management interface alias is created eth0 is eth0:0
- VIP is assigned to the alias
- QRadar services are started
- Secondary connects to console and downloads configuration files
Tips for manual synchronization
- Ensure primary and secondary hosts are sync'd
- Secondary must be in standby
- Secondary to offline and power off the primary
- DO NOT MANUALLY FORCE FAILOVER DURING PATCHES OR SOFTWARE UPGRADES
2. HA Planning
- File systems on both devices much match - ext-3, etc
- Secondary's "/store" partion must be equal to or greater than the primary
- Both devices should have the same number of interfaces
- Both must use the same management interface
- Only 1 VIP
- Port 7789 is needed for Distributed Replicated Block Device (DRDB)
- DRBD traffic is bidirectional
- Disk replication ensures software updates are applied to the secondary
- Ensure the host has a valid activation key
3. HA Management
- Uses System and License management window to:
- monitor HA
- Force failover
- Disconnect cluster
- Modify cluster settings
- Modify heartbeat interval
- Place the device in "offline" mode before maintenance
Further further information, please see the relevant IBM QRadar High Availability Guide available here.
Monday, April 6, 2015
Monday, March 9, 2015
Critical Infrastructures And The Energetic Bear ... Big Picture Implications
Who
are they?
Energetic
Bear is an Advanced Persistent Threat (APT) group whose targets lie mostly
within the energy sector. In addition to targeting the energy sector, they have
also targeted organizations in other verticals such as Aviation and Defense. The
countries targeted by this group were US, Canada, Spain, France, Italy,
Germany, Turkey and Poland. Their attacks are carried out via methods such as
spear phishing, watering hole, remote access tools and trojanized software (Symantec, 2014). While some
researchers state the group operates in Eastern Europe (Symantec, 2014), others have been more confident and specific,
suggesting that this threat actor is directly connected to the Russian Government.
It is believed that the objective of the Russian Government is to promote
Russia’s national economic interest along with helping its industries to
maintain competiveness in key areas of national importance (Finkle, 2014).
The
Big Picture Implication
Groups
like Energetic Bear poses a clear and present threat to our Critical
Infrastructures and hence our National Security. By successfully penetrating organizations
within our Energy Sector this group may be in a position to control the amount
of heat we get in our homes during the winter, blow up a nuclear energy
facility or even flood a hydro dam. While the primary impact may be physical
destruction, the secondary and other consequential damages can be devastating.
For any of the above, there can be significant loss of life, significant
economic loss and or mass hysteria. Communications systems can be affected thus
affecting emergency services personnel from being able to successfully perform
their duties. The Energy Sector is basically the engine that drives the other
15 Critical Infrastructure Sectors and any threat that reduces its
effectiveness and or the quality of its output, immediately affects the input
to the 15 other critical infrastructure sectors. A 30-minute power outage is
said to cost business around US$15,709. For shorter blackouts which occurs
several times a year in the United States (US) it is reported than this results
has an annual economic loss of between US$104 and US$164 billion (agcs.allianz.com, n.d.). The significant of these numbers show that for
any situation of which the real owners and operators of these infrastructures
do not have full control of their systems, the outcomes of someone malicious
gaining control cannot be over stated.
What
should be done about this group?
The
ultimate objective when dealing with groups like Energetic Bear would be to
work with the Governments and owners of Critical Infrastructures along with the
rest of the security community, combining efforts towards dismantling the group
or the creation of initiatives which may reduce its effectiveness. However, one
should be aware that it can be very difficult to attribute attacks in cyber
space (Schneier, 2015). As can be seen above, Symantec suggested that
the group operates out of Eastern Europe (giving Symantec a broad territory)
while CrowdStrike was more specific claiming it was the Russian government.
While dismantling the
group would be very nice to achieve, the reality is we need to make greater effort
at securing our systems and critical infrastructures. The vulnerabilities exploited by Energetic
Bear (CVE-2013-2465, CVE-2013-1347, and CVE-2012-1723 in Java 6, Java 7, IE 7
and IE 8) (kasperskycontenthub.com)were already known
and should have been patched. If for
business reasons these devices were or are unable to be patched, all efforts
should be made to ensure the relevant technical and or administrative controls
are in place to mitigate any attacks destined for these hosts. However, since
Energetic Bear exploits Internet Explorer (IE) and Java, these being known
client side applications, I will conclude that business reasons may not have
been the primary reason why these devices were on patched.
Some of the technical
controls which may work in these situations are reducing and or eliminating the
use of administrative credentials, implementation of Intrusion Prevention
Systems (IPS) which should block this communication from being successful and
or Security Information Event Management (SIEM) solutions which can help to
store logs, correlate data and alert on potential threats if they were
successful. While these solutions may not prevent these attacks, it does help
an organization to understand the scale of the attack if and or when it is has
been successfully targeted and compromise, while also reducing its attack
surface.
Conclusion
Attribution
in cyber space is very difficult, this makes justified retaliation extremely
hard. Similarly defense is harder than offence, thus we need to ensure we are
recording as much relevant information as possible and where possible. From a
big picture perspective, these groups pose a clear and present threat to
Critical Infrastructures and hence National Security. Containing APT Threat
Actors like Energetic Bear may be difficult, thus protecting our infrastructure
and systems through either prevention or detection solutions should be
paramount.
References
(n.d.). Retrieved from kasperskycontenthub.com:
https://kasperskycontenthub.com/securelist/files/2014/07/EB-YetiJuly2014-Public.pdf
(n.d.). Retrieved from agcs.allianz.com:
http://www.agcs.allianz.com/insights/expert-risk-articles/energy-risks/
Finkle, J. (2014, January 22). Retrieved from
reuters.com:
http://www.reuters.com/article/2014/01/22/us-russia-cyberespionage-idUSBREA0L07Q20140122
Schneier, B. (2015, January 8). Retrieved from
schneier.com:
https://www.schneier.com/blog/archives/2015/01/attack_attribut.html
Symantec. (2014, June 30). Retrieved from
symantec.com:
http://www.symantec.com/connect/blogs/emerging-threat-dragonfly-energetic-bear-apt-group
Saturday, March 7, 2015
Tuning Snort - detection_filter with event_filter
Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.
In this post we will combine detection_filter with event_filter.
It is important to note that event_filter is the recommended method of thresholding.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2003
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
For this we will start off with a rule that is only configured for detection_filter. If you missed the previous post on using detection_filter, you can click here to get that info and then come back to this one.
This rule looks for greater than 6 alerts before it starts to fire. Basically, if we do 10 failed logons, it will ignore the first 6 then alert on everything else thereafter.
Let's test that
Let's perform our failed logon
So our logon failed ... let's see what snort sees
Looks like we got 4 alerts.
Let's verify the performance data
Looks good. There were 10 checks, However only 4 were matched and 4 alerts were generated.
Now if we had 100 or more alerts generated after the first 6, this would have been a very noisy deployment. One which would make any Intrusion Analyst cringe.
To reduce this noise let's add the event_filter option.
Remember, event_filter replaces threshold, so to configure this we modify the threshold.conf file which is found in /etc/snort/
Below shows the entry which was echo'd into thresholds.conf file. If you need guidance on on how the threshold command is used click here.
Running snort again and the failed logins we see ....
As seen above, snort generated 1 alert.
Let's see what the performance data shows
...a thing of beauty. So we had 10 packets which were checked. From that 4 matched. However, we only generated 1 alert.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
Tuning Snort - Detection_filter
Snort has a few
options which can be used to tune its performance and or reduce on the
number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.
In this post we will look at tuning via detection_filters in Snort Version 2.9.2.2.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
According to manual.snort.org "detection_filter defines a rate which must be exceeded by a source or destination host before a rule can generate an event". For this we will try to do 10 failed logins within 60 seconds.
As always let's see what the rule looks like. This rule is a basic rule without the detection filter. The idea is to see how the rule operates before we add the detection filter.
Now let's produce our failed logon
Looks good.
Let's see what snort generated
Looks good, we have 10 alerts.
Now let's see what the performance data shows.
Looks good again. We have 10 Checks, 10 Matches and 10 Alerts.
Let's try to reduce some of this noise
This time the rule looks for 6 matches within 60 seconds and then alerts on everything else. So if we have 10 failed logons within 60 seconds, the first 6 would be ignored and the last 4 would be alerted on.
Let's verify this.
Assume that we generated the 10 failed logons again
Looks like we got 4 alerts.
As always let validate this. Looking at the performance data we see ....
From the above we see we had 10 Checks. However, there were only 4 matches and thus 4 alerts.
The above produced 4 alerts, thus we should consider what would happen in the case there were actually more than 10 failed logons.
To address the above concern with too many messages, our last post in this series will be based on using event_filter with detection_filter.
Another important point to note is that unlike, threshold or suppress which are post detection activities, detection_filter is the last step during the detection phase and not a step done in the post detection phase.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
In this post we will look at tuning via detection_filters in Snort Version 2.9.2.2.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
According to manual.snort.org "detection_filter defines a rate which must be exceeded by a source or destination host before a rule can generate an event". For this we will try to do 10 failed logins within 60 seconds.
As always let's see what the rule looks like. This rule is a basic rule without the detection filter. The idea is to see how the rule operates before we add the detection filter.
Now let's produce our failed logon
Looks good.
Let's see what snort generated
Looks good, we have 10 alerts.
Now let's see what the performance data shows.
Looks good again. We have 10 Checks, 10 Matches and 10 Alerts.
Let's try to reduce some of this noise
This time the rule looks for 6 matches within 60 seconds and then alerts on everything else. So if we have 10 failed logons within 60 seconds, the first 6 would be ignored and the last 4 would be alerted on.
Let's verify this.
Assume that we generated the 10 failed logons again
Looks like we got 4 alerts.
As always let validate this. Looking at the performance data we see ....
From the above we see we had 10 Checks. However, there were only 4 matches and thus 4 alerts.
The above produced 4 alerts, thus we should consider what would happen in the case there were actually more than 10 failed logons.
To address the above concern with too many messages, our last post in this series will be based on using event_filter with detection_filter.
Another important point to note is that unlike, threshold or suppress which are post detection activities, detection_filter is the last step during the detection phase and not a step done in the post detection phase.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
Tuning Snort - Suppress
Snort has a few
options which can be used to tune its performance and or reduce on the
number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
In this post we will look at tuning via suppression in Snort Version 2.9.2.2.
Let's start off with our rule
The rule below is just a basic rule looking for the content "Logon failure" coming from host 10.0.0.2:23 going to host 10.0.0.1. No suppression is enabled.
Let's logon via telnet
As seen above my logon failed. Let's assume this happened 6 times.
For every failed logon received from the server there is a Snort alert above.
Looking at the performance statistics. We see 6 Checks, 6 Matches and 6 Alerts
Let's now go ahead and configure suppression.
This is done via the "threshold.conf" which is found in /etc/snort
Once configured let's go ahead and create our failed logon sessions again, similar to above.
When snort is run again, there is no output on the screen.
However, as we check the performance data we see we have Checks 6, Matches 6 and Alerts 0.
What this confirms is that even though we suppress this alert, snort is still processing the packeet. However, no notification is provided to us as to what is going on with the packet.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
In this post we will look at tuning via suppression in Snort Version 2.9.2.2.
Let's start off with our rule
The rule below is just a basic rule looking for the content "Logon failure" coming from host 10.0.0.2:23 going to host 10.0.0.1. No suppression is enabled.
Let's logon via telnetAs seen above my logon failed. Let's assume this happened 6 times.
For every failed logon received from the server there is a Snort alert above.Looking at the performance statistics. We see 6 Checks, 6 Matches and 6 Alerts
Let's now go ahead and configure suppression.
This is done via the "threshold.conf" which is found in /etc/snort
Once configured let's go ahead and create our failed logon sessions again, similar to above.
When snort is run again, there is no output on the screen.
However, as we check the performance data we see we have Checks 6, Matches 6 and Alerts 0.
What this confirms is that even though we suppress this alert, snort is still processing the packeet. However, no notification is provided to us as to what is going on with the packet.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
Tuning Snort - Thresholding
Snort has a few options which can be used to tune its performance and or reduce on the number of alerts generated. Of the methods available, we will look at threshold, suppress, detection_filters and using detection_filter with event_filters.
In this post we will look at tuning via thresholding.
Before we move forward, I must state that the snort documentation states this is a deprecated function and will not be available in future releases. These posts are being used with snort Version 2.9.2.2. Threshold has been replaced with event_filter.
Using the snort documentation as a guide, one of the examples it has is detecting 5 failed logons using the "limit" option. Threshold itself has a few options to be aware of. These are threshold, limit or both. In this post we will look at all 3.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
Let's get started
Let's create rule which looks for failed logons via telnet without any thresholding.
Below shows the snort rule which is looking for the failed logons. It currently has no threshold configurations
From below we see the failed logon. For this I actually did this 5 times, however there is no need to put all of this in the image. Just consider this as 5 failed logons.
The snort rule fired 5 times as can be seen below
When we look at the performance statistics, we verified that this rule was checked 5 times, matched 5 times and alerted 5 times.
Let's now add the threshold option "limit" to the rule and see the results.
Basically, for the limit, it does not matter how many telnet packets are seen between the hosts with "Logon failure" within 60 seconds, it will simply fire on the first 2 and ignore everything else. To actually test and understand this, you should be running snort in one window which is visible and logon to telnet via another window which allows you to see the snort screen while you are logging in. What you should see is snort generating an alert on your first login, then on your second login. For all the others within 60 seconds there should be no results from snort.
Let's test this.
Create a new rule with limit enable
Let's assume I have 5 failed logins as similar to above.
Below we see that the snort rule triggered only 2 times. This would be the first two then everything else was ignored.
Let's see what the performance statistics show.
Above we see that similar to the first rule, there were 5 checks and 5 matches. However, in this case there were only 2 alerts.
Let's move over to the "threshold" option now
The rule below is basically the same rule which was used for "limit". However the threshold type has been changed to threshold.
What this rule will do, is for every 2 packets seen with "Logon failure" between the two hosts, it will create an alert. So basically every second failure an alert would be created.
Once again, let's test that
Let's assume I have 5 failed logons again. Remember, to truly understand this, you should be able to look at your snort window or terminal, while logging to your telnet session.
Below we see the snort rule fire again 2 times.
Let's see what the performance statistics shows
Once again we saw 5 checks, 5 matches but 2 alerts.
I know at this point you may be thinking this seems confusing as you still have 2 alerts generated. However, remember above we had 5 failed logons, so we are unable to get more than 2 snort alerts.
To make it easier I will do one more example.
This time we will use 10 failed logons while keeping the rule the same. So if, this rule looks for every 2 failed logons within 60 seconds then for 10 failed logons we should have 5 alerts.
Let's test this.
Rule below is basically the same as above
Let's see what snort throws our way after the failed logons
As can be seen this time around, snort generated 5 alerts.
As always let validate this against what the performance preprocessor sees.
Ahhhhhhhhhhh!!! A thing of beauty.
The final option for threshold is "both". Both simply alerts once per interval based on the count value.
For the rule below, snort alert would be triggered on the 2nd packet seen with "Logon failure" between the hosts and everything else is ignored within the seconds specified.
Let's see what alerts we get.
As see above the the rule fired once.
Once again, let's check the performance statistics
Looks like we had 10 checks and 10 matches. However, only 1 alert was fired. This obviously matches what we stated earlier.
One of the things we were able to achieve with this post is for every test we were able to successfully validate our findings via various means.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
In this post we will look at tuning via thresholding.
Before we move forward, I must state that the snort documentation states this is a deprecated function and will not be available in future releases. These posts are being used with snort Version 2.9.2.2. Threshold has been replaced with event_filter.
Using the snort documentation as a guide, one of the examples it has is detecting 5 failed logons using the "limit" option. Threshold itself has a few options to be aware of. These are threshold, limit or both. In this post we will look at all 3.
This lab consists of the following:
Windows 2003 - Telnet Server - IP: 10.0.0.2
Kali Linux - Running telnet client and snort, 2.9.2.2 - IP:10.0.0.1
Let's get started
Let's create rule which looks for failed logons via telnet without any thresholding.
Below shows the snort rule which is looking for the failed logons. It currently has no threshold configurations
From below we see the failed logon. For this I actually did this 5 times, however there is no need to put all of this in the image. Just consider this as 5 failed logons.
The snort rule fired 5 times as can be seen below
When we look at the performance statistics, we verified that this rule was checked 5 times, matched 5 times and alerted 5 times.
Let's now add the threshold option "limit" to the rule and see the results.
Basically, for the limit, it does not matter how many telnet packets are seen between the hosts with "Logon failure" within 60 seconds, it will simply fire on the first 2 and ignore everything else. To actually test and understand this, you should be running snort in one window which is visible and logon to telnet via another window which allows you to see the snort screen while you are logging in. What you should see is snort generating an alert on your first login, then on your second login. For all the others within 60 seconds there should be no results from snort.
Let's test this.
Create a new rule with limit enable
Let's assume I have 5 failed logins as similar to above.
Below we see that the snort rule triggered only 2 times. This would be the first two then everything else was ignored.
Let's see what the performance statistics show.
Above we see that similar to the first rule, there were 5 checks and 5 matches. However, in this case there were only 2 alerts.
Let's move over to the "threshold" option now
The rule below is basically the same rule which was used for "limit". However the threshold type has been changed to threshold.
What this rule will do, is for every 2 packets seen with "Logon failure" between the two hosts, it will create an alert. So basically every second failure an alert would be created.
Once again, let's test that
Let's assume I have 5 failed logons again. Remember, to truly understand this, you should be able to look at your snort window or terminal, while logging to your telnet session.
Below we see the snort rule fire again 2 times.
Let's see what the performance statistics shows
Once again we saw 5 checks, 5 matches but 2 alerts.
I know at this point you may be thinking this seems confusing as you still have 2 alerts generated. However, remember above we had 5 failed logons, so we are unable to get more than 2 snort alerts.
To make it easier I will do one more example.
This time we will use 10 failed logons while keeping the rule the same. So if, this rule looks for every 2 failed logons within 60 seconds then for 10 failed logons we should have 5 alerts.
Let's test this.
Rule below is basically the same as above
Let's see what snort throws our way after the failed logons
As can be seen this time around, snort generated 5 alerts.
As always let validate this against what the performance preprocessor sees.
Ahhhhhhhhhhh!!! A thing of beauty.
The final option for threshold is "both". Both simply alerts once per interval based on the count value.
For the rule below, snort alert would be triggered on the 2nd packet seen with "Logon failure" between the hosts and everything else is ignored within the seconds specified.
Let's see what alerts we get.
As see above the the rule fired once.
Once again, let's check the performance statistics
Looks like we had 10 checks and 10 matches. However, only 1 alert was fired. This obviously matches what we stated earlier.
One of the things we were able to achieve with this post is for every test we were able to successfully validate our findings via various means.
Hope you enjoyed this post. See threshold, suppress, detection_filters and using detection_filter with event_filters for further tuning tips.
References:
http://manual.snort.org/node20.html
http://manual.snort.org/node212.html
http://manual.snort.org/node35.html
https://technet.microsoft.com/en-us/library/cc772789%28v=ws.10%29.aspx
Subscribe to:
Posts (Atom)