today categories: slam in salon security scripting gnu/linux os x win32 activeRenderer groupware
radioScan
or search:
© copyright 2002 by Marc Barrot
|
|
|
|
Tuesday, June 11, 2002 |
Monitoring Security
Here our some ground rules when using SNMP and client server tools to monitor systems and network devices
- Do not trust your firewall when using SNMP
SNMP version 1 transfers all data, including passwords, in the clear. There are a bunch of worms and trojans these days which sole purpose is to penetrate your firewall, then start network sniffers. SNMP monitoring data will be music to crackers ears when it finally reaches them.
So any SNMP data that travels your firewall protected internal LAN should be encrypted, which is why everyone should be using SNMP version 3 when possible. - Beware of client/server schemes
Most centralized monitors rely on agent modules on on monitored hosts to listen to their requests and respond with relevant information.
Which means that on every host, the agent will very likely open a TCP or UDP port to listen to requests. This may sound paranoïd again, but every open port is a door a potential cracker might use to access the system. It really depends on the quality of the code that opened the port.
A more secure way of monitoring a host is having the host send information by itself, on a time or event (trap) driven basis. This avoids the always-open-port potential vulnerability issue.
Even with SNMP, it is possible to restrict access to the SNMP database to the localhost only, and then have some monitoring code on the host itself send reports and alerts after querying the local MIB.
11:02:38 AM Google It!
|
|
|
|
June 2002 |
Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
|
|
|
|
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
|
|
|
|
|
|
Apr Aug |
|