Before You Begin – See Fastvue TMG Reporter
We have another product dedicated to making reporting on Microsoft Forefront TMG simple and easy. Fastvue TMG Reporter includes live dashboards, alerts, and historical reporting, all preconfigured to show everything you need to know about employee Internet usage, bandwidth and how your network is operating.
Why WebSpy Vantage?
If you need full flexibility over the content of your reports, WebSpy Vantage provides a comprehensive report templating and data aliasing engine that is not available in Fastvue TMG Reporter. WebSpy Vantage also has more flexibility when it comes to distributing reports securely to the right people in your organization.
If you need full control over the report content and/or have specific requirements around report access permissions, then please see the guide below on configuring Microsoft Forefront TMG logging and reporting with WebSpy Vantage.
1. Accessing Forefront TMG’s Log Files
The first step in reporting on your Forefront TMG server is to access the Forefront TMG log files. Forefront TMG has three different logging options. WebSpy Vantage can import all of these formats, but some work may be required to access them from your WebSpy Vantage machine:
By default, Forefront TMG creates log files in it’s own local SQL Express instance. The instance name is MSFW. New databases are created each day, and there is a log table for Firewall and another for Web Proxy data. You can import this log database using the ‘Database Connection’ option in WebSpy Vantage, however, you need to first enable network access and permissions to the databases.
Although not recommended, you can avoid opening the SQL Express logs to network access by installing Vantage on your Forefront TMG Server, and running reports in off-peak times. See our article on how to do this here.
Logging to a remote SQL Server enables you to centralize all your Forefront TMG log files, and has some other great advantages for enterprises. You can import these logs using the ‘Database Connection’ option in WebSpy Vantage and you can select whether to connect with Windows Authentication or SQL Authentication.
If using Windows Authentication, make sure the User Account running WebSpy Vantage has db_reader permission on the SQL databases and tables.
Logging to File (Text log) is by far the easiest method of accessing your log files with WebSpy Vantage. We recommend you use the W3C format due to the standards compliant log structure, however, the native .iis format is supported as well. Simply share the folder that your log files are stored in, and use the ‘Local Networked Files or Folders’ option when importing the logs in WebSpy Vantage.
To find the log format Forefront TMG is currently using:
- Open the Forefront TMG Management Console.
- Select Logs and Reports in the left-hand side.
- Click Configure Web Proxy Logging in the left-hand side. The logging options above are selected in this dialog.
- If you’re logging to Text or Remote SQL, click the Advanced button to see where those log are being created.
The default ‘ISA Logs Folder’ is C:\Program Files\Microsoft Forefront Threat Management Gateway 2010\Logs
About Firewall Logs: You will also notice an option to Configure Firewall Logging in step 3 above. Logging is configured in exactly the same way as the Web Proxy logs and the Firewall logs are fully supported in WebSpy Vantage. However, if you are mainly interested in analyzing web browsing behavior, simply import and analyze the Web Proxy log files into WebSpy Vantage.
Importing Microsoft Forefront TMG SQL Express logs into WebSpy Vantage
Automating the process of importing and reporting on Microsoft Forefront TMG log files as a Daily Task
2. Importing Microsoft Forefront TMG Logs into WebSpy Vantage
WebSpy Vantage imports text log files from over 200 common network devices, into its own database format called a Storage. You can then use this Storage for analysis and reporting, you can regardless of whether the original log file has been moved, archived or deleted.
To import your Microsoft Forefront TMG logs into WebSpy Vantage, go to the Storages tab and click Import logs. The options to select vary slightly depending on your log file type:
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Database connection
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add and select/enter the following:
- MS SQL
- Server: Enter the Forefront TMG’s server name followed by \MSFW. For example 10.0.0.10\MSFW. If Vantage is installed on your TMG Server, you can enter .\MSFW (‘.’ means localhost)
- Port: 1433
- Database Filter: Enter a database filter of *WEB* to only import the web proxy databases, or leave it set to * to import everything including the Firewall databases.
- Table Filter: Leave this set to * to import all tables in the Databases.
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Database connection
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add and select/enter the following:
- MS SQL
- Server: Enter the name or IP address of your SQL Server. For example 10.0.0.10.
- Port: 1433
- Database Filter: Enter the database name, or a suitable database search string (such as *LogDB*) to select the databases that contains the TMG log tables.
- Table Filter: Enter the table name or a suitable search string (such as *WebProxy*), where your TMG logs are being written to. Leave it as * to import all tables in the database.
Click OK and you should see a list of the databases and tables appear in the Import Wizard. Click OK again on the Import Wizard to start importing.
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Local Networked Files or Folders
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add | Folder and select/enter the following:
- Folder: Browse to the folder containing your Forefront TMG log files. Make sure you specify a UNC path such as \\servername\logs rather than a mapped network drive (Vantage cannot import from mapped drives when logged off)
- File Mask: Leave this set to * to import all logs, or enter a suitable search string such as *WEB* to only import web proxy logs, or *FWS* to only import Firewall logs.
- Timezone Offset: Forefront TMG logs in GMT time. Make sure you specify a timezone offset so that your reports show activity in your local timezone rather than in GMT.
- Leave all other options as default
Click OK and you should see a list of TMG log files appear in the Import Wizard. Click OKagain on the Import Wizard to start importing.
Entering Directory Server details
Selecting LDAP Root DN and Search Query.
Using LDAP attributes for username aliasing and Web Module login names.
Grouping users by LDAP attributes and/or OUs.
LDAP import merging options.
A successfully imported Organization tree.
3. Import Your Organization
Microsoft Forefront TMG logs authenticated usernames in the format domain\username. WebSpy Vantage can import information from Active Directory to alias these authenticated users into real names (first name last name), departments, offices and OUs.
To do this, go to the Organization tab and click Import Organization.
On the Directory Server page, select your directory type and server, along with a username (in domain\username format) and password to authenticate with your directory server, and click Test. Click Next after you have successfully connected to your directory server.
Select a Root Distinguished Name to search for users within (for example, ‘dc=mydomain, dc=com’) from the dropdown list. If your users are contained within a specific OU, select the ‘…‘ button to select the OU in your directory.
The LDAP search query defaults to a query that returns ‘user accounts’. It’s important to note that WebSpy Vantage’s licensing is based on ‘number of users’, so if necessary, use the Quick Queries drop-down to change the LDAP search query and import a more specific set of user accounts, such as enabled users with an email address. WebSpy Vantage will import all users up to the license limit, which is unlimited during your trial. Click Next.
The User Details page defines how Vantage maps user objects in your Directory to authenticated usernames in your log files, as well as configuring user login names for the Web Module, the email address to send report notifications to, and the attribute to use to find a user’s manager.
If you are using Active Directory, you choose Use Active Directory Defaults. WebSpy Vantage will attempt to detect the name of your domain, and prefix this to all account names so that your authenticated usernames logged by Microsoft Forefront TMG are correctly aliased to a user object in Active Directory.
If your domain prefix on user accounts is different to your computer network’s domain name, click Custom, then check the Prefix checkbox and enter the required domain prefix.
The Grouping page enables you to configure how you would like users grouped, such as by Departments, Offices, OUs etc. User Objects in Active Directory have a number of attributes, including department, office, description, company, and you can also place user objects in OU containers, and configure attributes on those containers. WebSpy Vantage can hook into any of these attributes to group your users for the purpose of reporting.
By default, there are two groups specified: Offices (using the ‘physicalDeliveryOfficeName’ attribute in Active Directory) and Departments (using the ‘department’ attribute in Active Directory).
If a user does not have one of these values populated in Active Directory, then they will be imported into the ‘Unknown’ department and office respectively. Alternatively, you can uncheck the Import Ungrouped Users option at the bottom of the Grouping page.
You can edit or delete these groups as necessary.
When adding or editing a group:
- First, enter the name of the Group into the Name field. This is up to you and should represent what the group is, such as ‘Departments’, ‘Locations’, ‘Business Centers’ etc. (Note, there are a few default Report Templates that use ‘Departments’ so use the word ‘Departments’ in one of your grouping levels utilize these reports).
- Enter the exact name of the attribute into the Attribute field. For example, enter ‘physicalDeliveryOfficeName’ to import the Office attribute from Active Directory. To import the name of an OU, use the attribute ‘OU’.
By default, Active Directory Users and Computers hides the real attribute names. You can change this by selecting View | Advanced Features to show the Attribute Editor with real attribute names when editing a User or OU.
Tip: Later, you’ll need to configure Web Module access permissions for people and/or groups. To create a default set of permissions that apply to your entire organization, create a top-level group using an attribute that everyone is a member of. For example, call the group ‘Domain’ and use the attribute ‘dc’.
Once you have specified all the Groups you would like to use in your reporting process, click Next.
The Merging page enables you to use the Import Organization wizard multiple times, and merge the results into your existing Organization structure. For example, first import your Organization from one domain (or one Root DN on your domain), with the Overwrite existing organization tree option set to create an initial Organization tree, then run the Import Organization wizard again to import your Organization from another domain (or a different Root DN on your domain) and merge the results into your existing Organization tree.
The Merge options enable to you to keep or remove users that can no longer be found in the directory, as well as keep or update existing user’s details. Use the ‘keep users / keep details’ options if importing from a different domain or root DN.
Note: When merging, only users that have previously been added from your LDAP/LDIF directory will be affected. Users that have been manually added will not be affected.
Click OK to complete the Import Organization wizard and begin the import. Once the import is complete you will see you the Organization tree displayed. You can use the View drop-down list at the top of the Organization tree to display your groups, or your manager/subordinate hierarchy.
sergey vasin
Forefront TMG записывает логи в Local Log Queue (LLQ) – Forefront TMG (ISA Server) Product Team Blog
Одна из причин, по которой TMG может записывать логи в LLQ, вместо базы данных – это наличие неполных баз в локальном экземпляре SQL Server.
Другими словами, у вас могут быть базы данных, зарегистрированные на локальном сервере SQL, но с отсутствующими .mdf и .ldf-файлами. Это может произойти, если файлы были удалены вручную, диск, содержащий эти файлы боле недоступен, либо по другим причинам.
Важно сказать, что подобное может произойти, вне зависимости от того, настроена ли запись логов в локальную или удаленную базу. Происходит это потому, что TMG в любом случае проверяет целостность локальной базы, даже если логи записываются в удаленную.
При возникновении проблемы вы можете обнаружить следующее:
Чтобы определить, действительно ли вы столкнулись с описываемой проблемой, нужно проверить логи локального экземпляра SQL Server, которые по умолчанию находятся в “C:\Program Files\Microsoft SQL Server\MSSQL10.MSFW\MSSQL\Log”.
Сами же базы данных по умолчанию находятся в “C:\Program Files\Microsoft Forefront Threat Management Gateway\Logs\”.
Откройте файл ERRORLOG, находящийся в папке логов и проверьте его на наличие следующих сообщений:
2012-09-05 10:44:52.01 spid54 Starting up database ‘ISALOG_20120831_FWS_000’.
2012-09-05 10:44:52.02 spid54 Error: 17204, Severity: 16, State: 1.
2012-09-05 10:44:52.02 spid54 FCB::Open failed: Could not open file C:\Program Files\Microsoft Forefront Threat Management Gateway\Logs\ISALOG_20120831_FWS_000.mdf for file number 1. OS error: 2(failed to retrieve text for this error. Reason: 15100).
2012-09-05 10:44:52.15 spid54 Error: 17207, Severity: 16, State: 1.
2012-09-05 10:44:52.15 spid54 FileMgr::StartLogFiles: Operating system error 2(failed to retrieve text for this error. Reason: 15105) occurred while creating or opening file ‘C:\Program Files\Microsoft Forefront Threat Management Gateway\Logs\ISALOG_20120831_FWS_000.ldf’. Diagnose and correct the operating system error, and retry the operation.Следующее, что нам нужно выяснить, это что же случилось с пропавшими файлами.
Если вы перенесли логи на другой том и этот том сейчас недоступен, попробуйте вернуть его в рабочее состояние.
Если же вернуть пропавшие файлы не представляется возможным, то нужно будет удалить записи об этих базах из локальной базы master. Вы можете определить имена неполных баз, запустив следующую команду из командной строки с административными полномочиями:
OSQL -E -S .\MSFW -Q “select name from sysdatabases where name like ‘%isalog%’”
Сравните имена баз, указанных в выводе этой команды с файлами баз данных в папке хранения лог-файлов. Определив имена отсутствующих баз, вам нужно будет подготовить файл, содержащий команды для удаления каждой отсутствующей базы. Он должен выглядеть следующим образом:
drop database ISALOG_20120831_FWS_000
go
drop database ISALOG_20120831_WEB_000
go
drop database ISALOG_20120901_FWS_000
go
drop database ISALOG_20120901_WEB_000
goСохраните этот файл под именем, например C:\DropDB.sql.
Далее, из командной строки с административными полномочиями выполните следующую команду:
OSQL -E -S .\MSFW -i c:\DropDB.sql
Перезапустите сервис “Microsoft Forefront TMG Firewall” и откройте окно “Log Status”. Значение “Disconnected” должно измениться на “Queue in use”. Кроме того, нажимая на Refresh вы должны увидеть, что значение “Log Queue (KB)” уменьшается.
В зависимости от того, сколько времени просуществовала проблема, а также от количества данных, сохраненных на сервере, этот процесс может занять от нескольких минут до нескольких дней.
После его завершения вы снова увидите статус “Ready”.
Автор:
Gianni Bragante
Support Engineer — Microsoft CSS Forefront Security Edge TeamРецензент:
Lars Bentzen
Escalation Engineer — Microsoft CSS Forefront Security Edge TeamForefront где хранятся логи
2012-09-05 10:44:52.01 spid54 Starting up database ‘ISALOG_20120831_FWS_000’.
2012-09-05 10:44:52.02 spid54 Error: 17204, Severity: 16, State: 1.
2012-09-05 10:44:52.02 spid54 FCB::Open failed: Could not open file C:\Program Files\Microsoft Forefront Threat Management Gateway\Logs\ISALOG_20120831_FWS_000.mdf for file number 1. OS error: 2(failed to retrieve text for this error. Reason: 15100).
2012-09-05 10:44:52.15 spid54 Error: 17207, Severity: 16, State: 1.
2012-09-05 10:44:52.15 spid54 FileMgr::StartLogFiles: Operating system error 2(failed to retrieve text for this error. Reason: 15105) occurred while creating or opening file ‘C:\Program Files\Microsoft Forefront Threat Management Gateway\Logs\ISALOG_20120831_FWS_000.ldf’. Diagnose and correct the operating system error, and retry the operation.OSQL -E -S .\MSFW -Q “select name from sysdatabases where name like ‘%isalog%’”
drop database ISALOG_20120831_FWS_000
go
drop database ISALOG_20120831_WEB_000
go
drop database ISALOG_20120901_FWS_000
go
drop database ISALOG_20120901_WEB_000
goOSQL -E -S .\MSFW -i c:\DropDB.sql
Gianni Bragante
Support Engineer — Microsoft CSS Forefront Security Edge TeamLars Bentzen
Escalation Engineer — Microsoft CSS Forefront Security Edge TeamBefore You Begin – See Fastvue TMG Reporter
We have another product dedicated to making reporting on Microsoft Forefront TMG simple and easy. Fastvue TMG Reporter includes live dashboards, alerts, and historical reporting, all preconfigured to show everything you need to know about employee Internet usage, bandwidth and how your network is operating.
Why WebSpy Vantage?
If you need full flexibility over the content of your reports, WebSpy Vantage provides a comprehensive report templating and data aliasing engine that is not available in Fastvue TMG Reporter. WebSpy Vantage also has more flexibility when it comes to distributing reports securely to the right people in your organization.
If you need full control over the report content and/or have specific requirements around report access permissions, then please see the guide below on configuring Microsoft Forefront TMG logging and reporting with WebSpy Vantage.
1. Accessing Forefront TMG’s Log Files
The first step in reporting on your Forefront TMG server is to access the Forefront TMG log files. Forefront TMG has three different logging options. WebSpy Vantage can import all of these formats, but some work may be required to access them from your WebSpy Vantage machine:
By default, Forefront TMG creates log files in it’s own local SQL Express instance. The instance name is MSFW. New databases are created each day, and there is a log table for Firewall and another for Web Proxy data. You can import this log database using the ‘Database Connection’ option in WebSpy Vantage, however, you need to first enable network access and permissions to the databases.
Although not recommended, you can avoid opening the SQL Express logs to network access by installing Vantage on your Forefront TMG Server, and running reports in off-peak times. See our article on how to do this here.
Logging to a remote SQL Server enables you to centralize all your Forefront TMG log files, and has some other great advantages for enterprises. You can import these logs using the ‘Database Connection’ option in WebSpy Vantage and you can select whether to connect with Windows Authentication or SQL Authentication.
If using Windows Authentication, make sure the User Account running WebSpy Vantage has db_reader permission on the SQL databases and tables.
Logging to File (Text log) is by far the easiest method of accessing your log files with WebSpy Vantage. We recommend you use the W3C format due to the standards compliant log structure, however, the native .iis format is supported as well. Simply share the folder that your log files are stored in, and use the ‘Local Networked Files or Folders’ option when importing the logs in WebSpy Vantage.
To find the log format Forefront TMG is currently using:
- Open the Forefront TMG Management Console.
- Select Logs and Reports in the left-hand side.
- Click Configure Web Proxy Logging in the left-hand side. The logging options above are selected in this dialog.
- If you’re logging to Text or Remote SQL, click the Advanced button to see where those log are being created.
The default ‘ISA Logs Folder’ is C:\Program Files\Microsoft Forefront Threat Management Gateway 2010\Logs
About Firewall Logs: You will also notice an option to Configure Firewall Logging in step 3 above. Logging is configured in exactly the same way as the Web Proxy logs and the Firewall logs are fully supported in WebSpy Vantage. However, if you are mainly interested in analyzing web browsing behavior, simply import and analyze the Web Proxy log files into WebSpy Vantage.
Importing Microsoft Forefront TMG SQL Express logs into WebSpy Vantage
Automating the process of importing and reporting on Microsoft Forefront TMG log files as a Daily Task
2. Importing Microsoft Forefront TMG Logs into WebSpy Vantage
WebSpy Vantage imports text log files from over 200 common network devices, into its own database format called a Storage. You can then use this Storage for analysis and reporting, you can regardless of whether the original log file has been moved, archived or deleted.
To import your Microsoft Forefront TMG logs into WebSpy Vantage, go to the Storages tab and click Import logs. The options to select vary slightly depending on your log file type:
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Database connection
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add and select/enter the following:
- MS SQL
- Server: Enter the Forefront TMG’s server name followed by \MSFW. For example 10.0.0.10\MSFW. If Vantage is installed on your TMG Server, you can enter .\MSFW (‘.’ means localhost)
- Port: 1433
- Database Filter: Enter a database filter of *WEB* to only import the web proxy databases, or leave it set to * to import everything including the Firewall databases.
- Table Filter: Leave this set to * to import all tables in the Databases.
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Database connection
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add and select/enter the following:
- MS SQL
- Server: Enter the name or IP address of your SQL Server. For example 10.0.0.10.
- Port: 1433
- Database Filter: Enter the database name, or a suitable database search string (such as *LogDB*) to select the databases that contains the TMG log tables.
- Table Filter: Enter the table name or a suitable search string (such as *WebProxy*), where your TMG logs are being written to. Leave it as * to import all tables in the database.
Click OK and you should see a list of the databases and tables appear in the Import Wizard. Click OK again on the Import Wizard to start importing.
- Storage Name: Enter anything you like such as ‘TMG Web Proxy Logs’
- Input Type Page: Select Local Networked Files or Folders
- Loader Selection: Select Microsoft FTMG
- Input Selection: Click Add | Folder and select/enter the following:
- Folder: Browse to the folder containing your Forefront TMG log files. Make sure you specify a UNC path such as \\servername\logs rather than a mapped network drive (Vantage cannot import from mapped drives when logged off)
- File Mask: Leave this set to * to import all logs, or enter a suitable search string such as *WEB* to only import web proxy logs, or *FWS* to only import Firewall logs.
- Timezone Offset: Forefront TMG logs in GMT time. Make sure you specify a timezone offset so that your reports show activity in your local timezone rather than in GMT.
- Leave all other options as default
Click OK and you should see a list of TMG log files appear in the Import Wizard. Click OKagain on the Import Wizard to start importing.
Entering Directory Server details
Selecting LDAP Root DN and Search Query.
Using LDAP attributes for username aliasing and Web Module login names.
Grouping users by LDAP attributes and/or OUs.
LDAP import merging options.
A successfully imported Organization tree.
3. Import Your Organization
Microsoft Forefront TMG logs authenticated usernames in the format domain\username. WebSpy Vantage can import information from Active Directory to alias these authenticated users into real names (first name last name), departments, offices and OUs.
To do this, go to the Organization tab and click Import Organization.
On the Directory Server page, select your directory type and server, along with a username (in domain\username format) and password to authenticate with your directory server, and click Test. Click Next after you have successfully connected to your directory server.
Select a Root Distinguished Name to search for users within (for example, ‘dc=mydomain, dc=com’) from the dropdown list. If your users are contained within a specific OU, select the ‘…‘ button to select the OU in your directory.
The LDAP search query defaults to a query that returns ‘user accounts’. It’s important to note that WebSpy Vantage’s licensing is based on ‘number of users’, so if necessary, use the Quick Queries drop-down to change the LDAP search query and import a more specific set of user accounts, such as enabled users with an email address. WebSpy Vantage will import all users up to the license limit, which is unlimited during your trial. Click Next.
The User Details page defines how Vantage maps user objects in your Directory to authenticated usernames in your log files, as well as configuring user login names for the Web Module, the email address to send report notifications to, and the attribute to use to find a user’s manager.
If you are using Active Directory, you choose Use Active Directory Defaults. WebSpy Vantage will attempt to detect the name of your domain, and prefix this to all account names so that your authenticated usernames logged by Microsoft Forefront TMG are correctly aliased to a user object in Active Directory.
If your domain prefix on user accounts is different to your computer network’s domain name, click Custom, then check the Prefix checkbox and enter the required domain prefix.
The Grouping page enables you to configure how you would like users grouped, such as by Departments, Offices, OUs etc. User Objects in Active Directory have a number of attributes, including department, office, description, company, and you can also place user objects in OU containers, and configure attributes on those containers. WebSpy Vantage can hook into any of these attributes to group your users for the purpose of reporting.
By default, there are two groups specified: Offices (using the ‘physicalDeliveryOfficeName’ attribute in Active Directory) and Departments (using the ‘department’ attribute in Active Directory).
If a user does not have one of these values populated in Active Directory, then they will be imported into the ‘Unknown’ department and office respectively. Alternatively, you can uncheck the Import Ungrouped Users option at the bottom of the Grouping page.
You can edit or delete these groups as necessary.
When adding or editing a group:
- First, enter the name of the Group into the Name field. This is up to you and should represent what the group is, such as ‘Departments’, ‘Locations’, ‘Business Centers’ etc. (Note, there are a few default Report Templates that use ‘Departments’ so use the word ‘Departments’ in one of your grouping levels utilize these reports).
- Enter the exact name of the attribute into the Attribute field. For example, enter ‘physicalDeliveryOfficeName’ to import the Office attribute from Active Directory. To import the name of an OU, use the attribute ‘OU’.
By default, Active Directory Users and Computers hides the real attribute names. You can change this by selecting View | Advanced Features to show the Attribute Editor with real attribute names when editing a User or OU.
Tip: Later, you’ll need to configure Web Module access permissions for people and/or groups. To create a default set of permissions that apply to your entire organization, create a top-level group using an attribute that everyone is a member of. For example, call the group ‘Domain’ and use the attribute ‘dc’.
Once you have specified all the Groups you would like to use in your reporting process, click Next.
The Merging page enables you to use the Import Organization wizard multiple times, and merge the results into your existing Organization structure. For example, first import your Organization from one domain (or one Root DN on your domain), with the Overwrite existing organization tree option set to create an initial Organization tree, then run the Import Organization wizard again to import your Organization from another domain (or a different Root DN on your domain) and merge the results into your existing Organization tree.
The Merge options enable to you to keep or remove users that can no longer be found in the directory, as well as keep or update existing user’s details. Use the ‘keep users / keep details’ options if importing from a different domain or root DN.
Note: When merging, only users that have previously been added from your LDAP/LDIF directory will be affected. Users that have been manually added will not be affected.
Click OK to complete the Import Organization wizard and begin the import. Once the import is complete you will see you the Organization tree displayed. You can use the View drop-down list at the top of the Organization tree to display your groups, or your manager/subordinate hierarchy.
Forefront где хранятся логи
Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о тестировании конфигурации платформы веб-приложения.
Резюме
Правильная конфигурация отдельных компонентов, составляющих архитектуру приложения помогает избежать ошибок, позволяющих скомпрометировать веб-приложение.
Проверка и тестирование конфигурации всех компонентов архитектуры веб-приложения является очень важной задачей. Типовая конфигурация веб-приложения и веб-сервера зачастую содержит не нужные для работы приложения примеры, файлы документации, тестовые страницы, такие данные желательно удалять, так как они могут скомпрометировать целевое приложение.
Как тестировать
Тестирование по методу черного ящика
Примеры и известные файлы и директории
Многие веб-серверы и серверы приложений при установке с параметрами по умолчанию также устанавливают тестовые примеры приложений и файлы, помогающие разработчику проверить функционирование сервера после установки. Многие из таких примеров, устанавливаемых по умолчанию, уязвимы. Например, CVE-1999-0449 (DoS в IIS при установке тестового примера Exair), CAN-2002-1744 (Directory traversal в файле CodeBrws.asp в Microsoft IIS 5.0), CAN-2002-1630 (использование sendmail.jsp в Oracle 9iAS) или CAN-2003-1172 (Directory traversal в View-source примере в Apache’s Cocoon)
CGI сканнеры обычно включают в себя подробный список таких тестовых уязвимых файлов и директорий, поставляемых различным веб-серверами или серверами приложений, использование таких сканнеров, пожалуй, наиболее быстрый способ выявить наличие уязвимых тестовых файлов.
Проверка комментариев
Комментирование исходного кода — часто встречающаяся и даже рекомендуемая практика серди разработчиков. Однако, комментарии добавленные в HTML код, могут раскрывать некоторые аспекты внутренней логики работы приложения, нежелательно, чтобы такая информация была доступна атакующему.
Проверка комментариев необходима чтобы убедиться в отсутствии утечки важной информации о работе веб-приложения, потенциально полезной атакующему. Для осуществления такой проверки необходимо проанализировать статический и динамический контент веб-приложения, для этого необходимо пройтись по контенту веб-приложения, можно в автоматическом режиме (spidering), сохраняя весь полученные данные, а затем осуществить поиск по содержимому файлов на наличие комментариев.Тестирование по методу серого ящика
Проверка конфигурации
Веб-сервер или сервер приложений — важнейшее звено в обеспечении безопасности веб-приложения, эти компоненты должны быть тщательно проверены на предмет наличия типичных ошибок конфигурации. Рекомендации по конфигурации могут варьироваться, в зависимости от назначения и функциональности веб-приложения, однако, в большинстве случаев стоит придерживаться рекомендаций по конфигурации от поставщиков.
В общем случае невозможно дать точных инструкций по конфигурации веб-сервера или сервера приложений, однако существуют общие рекомендации, которые стоит принять во внимание:
- необходимо включать только те модули (расширения ISAPI в случае с IIS), которые необходимы для работы приложения. Это скоратит возможную поверхность атаки, так как уменьшиться размер и сложность сервера.
- обрабатывать ошибки сервера (40x или 50х) с помощью собственных страниц, вместо используемых по умолчанию. Убедитесь, что ошибки приложения при их возникновении не попадают к конечному пользователю и не раскрывают никаких данных о внутренней структуре приложения. Этот пункт особенно важно проверять, так как подобная информация необходима разработчикам на стадии подготовки платформы и часто остается после релиза приложения;
- Убедитесь в том, что серверное программное обеспечение запущено в операционной системе с минимально необходимыми правами доступа, дабы исключить возможность компрометации операционной системы, в случае если атакующий получит возможность исполнять код с правами сервера;
- Убедитесь в том, что сервер логгирует как легитимный доступ к ресурсам приложения, так и ошибки.
- Убедитесь в том, что сервер корректно справляется с перегрузками для предотвращения DoS атак.
- Никогда не разрешайте учетным записям, не входящим в группу Администраторов (за исключением NT SERVICES\WMSvc) доступ к следующим файлам: applicationHost.config, redirection.config adminitration.config (как на чтение, так и на запись). Это относится к учетным записям Network Services, IIS_IUSRS, IUSR или к другим кастомным учетным записям, используемым IIS.
- Никогда не предоставляйте сетевой доступ к файлам applicationHost.config, redirection.config administration.config. При использовании Shared Configuration, предпочтительней экспортировать applicationHost.config в другое место (подробнее см. в [ номер ссылки на конфигурацию IIS])
- Имейте ввиду, что все пользователи могут читать .NET Framework файлы machine.config и root web.config, не рекомендуется хранить важную информацию в этих файлах.
- шифруйте важную информацию, необходимую для работы IIS сервера, которая не нужна другим пользователям и процессам.
- Не предоставляйте права на запись для учетных записей, которые использует веб-сервер для доступа к applicationHost.config файлу, такие учетные записи должны иметь права только на чтение этого файла.
- Используйте разные учетные записи для публикации и конфигурирования applicationHost.config
- используйте стойкие пароли при экспортировании ключей шифрования для использования с shared configuration
- используйте строгие политки безопасности для досутпа к общему хранилищу конфигурации и ключей шифрования.
- рассмотрите возможность защиты общего хранилища файрволом и политиками доступа IPSec, разрешая доступ к хранилищу только для веб-серверов, которым это необходимо.
Логирование
Логирование — важный компонент системы обеспечения безопасности архитектуры веб-приложения, который позволяет регистрировать как ошибки приложения (например, пользователи пытаются обратиться к файлу, который не существует), так и возможные атаки на приложение. Обычно логи генерирует не только веб-приложение, но и серверное программное обеспечение. Также часто в логи приложения пишется дополнительная отладочная информация, используемая программистами для анализа ошибок приложения.
Для тестирования системы логирования, необходимо проанализировать следующую информацию:
- Содержат ли логи важную информацию?
- Где хранятся логи? вынесены ли они на отдельный выделенный сервер?
- Может ли логгирование вызвать отказ в обсуживании?
- Как организована ротация логов? В течение какого времени хранятся логи?
- Как организован просмотр логов? Могут ли администраторы при просмотре логов заметить целенаправленную атаку?
- Как огранизовано резервное копирование логов?
- Проходят ли валидацию данные, перед логированием? (минимальная/максимальная длинна, допустимые символы и т.д.)
Конфиденциальная информация в логах
Некоторые веб-приложения могут использовать GET-запросы для передачи данных форм, и такие данные могут попадать в логи сервера, а значит в логах может содержаться конфиденциальная пользовательская информация (имена пользователей, пароли, информация о банковском счете). Эта информация может попасть к атакующему, например через интерфейс администрирования, использование известных уязвимостей серверного программного обеспечения или изза ошибок конфигурации.
Логи событий обычно содержат полезную для атакующего информацию:
- отладочная информация
- стек-трейсы
- имена пользователей
- имена компонентов системы
- внутренние IP адреса
- менее важные персональные данные(емайл адреса, почтовые адреса, телефонные номера)
- бизнес-данные
Расширенный список конфиденциальной информации информации:
- исходные коды приложения;
- идентификаторы сессий;
- различные токены;
- персональные данные;
- пароли;
- идентификаторы для подключения к базам данных;
- ключи шифрования;
- банковские данные и платежная информация;
- данные, с более высоким уровнем секретности, чем может хранить система логгирования;
- коммерческая конфиденциальная информация;
- данные, сбор и хранение которых запрещено законом;
- данные, на сбор которых пользователь не давал своего согласия или явно указал, что эти данные не должны храниться и использоваться (Do not track).
Расположение логов
Обычно, различные действия, совершаемые серверным ПО, а также их ошибки хранятся локально, используя свободное место сервера на котором и запущено ПО.
Однако, если сервер будет скомпрометирован, логи могут быть удалены злоумышленником для сокрытия своих действий и администраторы системы не смогут получить никакой информации о подробностях атаки.
Поэтому, более мудрым решением будет хранить логи в отдельном, специально отведенном месте, не на сервере веб-приложения. Такое решение также может помочь с агрегацией логов из разных источников, связанных с веб-приложением (веб-серверы, сервер аутентификации, сервер баз данных), также, при таком построении системы, анализ логов не будет влиять на вычислительные мощности веб-серверов.Хранение логов
Система логирования, при неверном подходе к организации хранения, может вызвать отказ в обслуживании. Атакующий, обладающий достаточными ресурсами, может сгенерировать большое количество запросов чтобы заполнить все свободное место, отведенное для хранения логов. При неправильной конфигурации системы хранения логов, например, когда логи хранятся на разделе операционной системы или веб-приложения, это может вызвать сбои в работе операционной системы сервера или самого веб-приложения.
Обычно, в Unix-системах логи хранятся в директории /var (или /opt , /usr/local ), в этом случае необходимо убедиться, что эти директории хранятся на отдельных разделах операционной системы.
Также стоит следить за размером лог-файлов, резкий рост размера лог-файла может быть индикатором проводимой на веб-приложение атаки.
Тестирование вышеописанных возможных проблем, связанных с хранением логов с одной стороны довольно легко осуществимо, с другой стороны — весьма опасно для запущенных в эксплуатацию системах, так как может привести к отказу в обслуживании. В некоторых системах параметры QUERY_STRING логгируются независимо от метода запроса (GET или POST), таким образом для тестирования можно легко симулировать большой объем данных для логирования.Ротация логов
Большинство серверных систем осуществляют ротацию логов, для предотвращения заполнения файловой системы, исходя из того, что информация, хранящаяся в логах, необходима и актуальная в течение определенного времени.
Ротацию логов также необходимо протестировать и проверить следующие моменты:
- логи хранятся установленное в политиках безопасности время, не больше и не меньше;
- логи архивируются и к ним применяют алгоритмы сжатия, для уменьшения занимаемого дискового пространства;
- параметры доступа к архивным лог файлам и к текущим лог файлам такие же или более строгие. Например, веб-серверу необходимы права для записи в лог, но при этом ему не обязательно иметь права на изменение архивных лог файлов.
Контроль доступа к лог-файлам
Конечные пользователи не должны иметь доступа к информации в логах. Даже администраторы веб-приложения не должны иметь прав на просмотр логов, так как это нарушает принцип разграничения обязанностей. Необходимо убедиться, что используемая матрица контроля доступа запрещает прямой доступ к лог файлам, а также убедиться в том, что любая программа, позволяющая просматривать данные лог файлов, предоставляет такой доступ не основываясь на схеме ролей доступа к веб-приложению.
Проверка логов
Проверка лог-файлов может быть использована не только для сбора статистики использования веб-приложения, такая процедура может помочь выявить возможную атаку на веб-сервер.
При таком анализе следует особое внимание уделить следующему:
- ошибки 40х. Наличие большого количества таких сообщений об ошибки может служить индикатором использования CGI сканнеров, используемых для сканирования веб-сервера;
- ошибки 50х. Подобные ошибки могут быть результатом того, что атакующий пытается использовать ошибки приложения. Например, первые фазы при попытке проведения SQL injection атак могут вызывать сбои в приложении, так как sql запрос сконструирован неверно.
Также не следует хранить результаты анализа и проверки лог-файлов на том же сервере, где хранятся непосредственно лог файлы. Иначе, например из-за ошибок конфигурации, злоумышленник может получить доступ к этим данным.