icrosoft operating systems do not provide syslog support; instead, they use a combination of a local log manager and SNMP for remote event reporting. It is possible to get implementations of syslog for such systems.
Attackers will often attempt to flood a site's syslog server in order to cover their tracks, so that the server runs out of disk space and stops logging new messages, or so that the evidence of their activities is lost in the noise. Recent versions of syslog often have the ability to turn off listening from the network, while still keeping the ability to send messages to remote servers; some of them also provide the ability to accept remote messages only from specific source addresses.
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
---|---|---|---|---|---|---|---|
In | Ext | Int | UDP |
>1023[146]
|
514 |
[147]
|
External client contacting internal syslog server |
In | Ext | Int | UDP | 514 | 514 | [147] | External syslog server passing message to internal syslog server |
Out | Int | Ext | UDP | >1023[146] | 514 | [147] | Internal client contacting external syslog server |
Out | Int | Ext | UDP | 514 | 514 | [147] | Internal syslog server passing message to external syslog server |
[146]Some syslog clients sometimes use ports below 1024.
[147]UDP has no ACK equivalent.
Normally, SNMP management stations act as clients, contacting SNMP servers in the various network devices to request information or to issue commands. Sometimes, network devices act as SNMP clients to contact special SNMP servers (known as trap servers) on management stations to report critical information that can't wait until the next time the management station polls the device. SNMP trap servers are separate from regular SNMP servers so that a given machine can run both -- that is, can be both an SNMP server (and thus be manageable via SNMP) and an SNMP trap server (and thus be a management station and receive traps from other devices).
In general, you don't want someone from the outside to be able to manage your network via SNMP. Therefore, you shouldn't allow SNMP to cross your firewall, and you should carefully configure (or disable) SNMP on your systems that are outside your firewall so that attackers can't use it to change that configuration. See Chapter 10, "Bastion Hosts", Chapter 11, "Unix and Linux Bastion Hosts", and Chapter 12, "Windows NT and Windows 2000 Bastion Hosts ", for more information on how to properly configure bastion hosts.
The SNMP version in widest use, which is SNMPv2, does support some rudimentary security; when information is requested, the requester needs to specify a community that it's in. Different communities can be shown different information, and in some implementations, a reusable password can be required for certain communities. At its best, this security is quite primitive; anybody who's doing packet sniffing can easily discover a community name and password. Since relatively few implementations support passwords, and almost all implementations provide a default community called "public", it's very rare to find things at their best. At least one implementation not only comes with the "public" community but does not provide any permanent way to disable access for this community!
SNMP can be an extraordinarily dangerous protocol. The minimal information most devices will give out includes operating system details and precise traffic loads and destinations, which is already information you don't want attackers to have. Many implementations add even more critical information (for instance, icrosoft's SNMP server will list all valid account names on the machine and most of the services running on it). In addition, it is possible for a remote machine not only to request information but to set variables. Since SNMP is intended for network management, and an SNMP client is expected to be a network management console, these variables usually give you full control of at least the machine's network configuration, and often more than that. For instance, you can often reboot a remote machine via SNMP, and icrosoft systematically attempts to make all the functionality of service control panels available over SNMP. Routers can often be completely controlled via SNMP.
In general, the default "public" community is able only to read information, but it is often able to read all the available information, which in several implementations from large router vendors includes a listing of all the communities and their capabilities, so that anybody can read the information about how to get write access.
On machines that are running multiple SNMP-enabled services (for instance, machines that have an operating system SNMP agent and are also running Oracle), SNMP servers may be at unexpected ports. If multiple SNMP agents need to run on the same machine, only one of them can be at SNMP's normal port. One way to deal with it is to have a master agent at that port and move some or all of the other SNMP agents to other ports (normally above 1024, since that's where free ports are likely to be). The master agent then speaks SNMP to the other agents (commonly referred to as sub-agents), which don't have to be aware that there's anything unusual happening. This is a very flexible approach, but it is yet another service that may be vulnerable if you open up connections above 1024.
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
---|---|---|---|---|---|---|---|
In | Ext | Int | UDP | >1023 | 161 |
[148]
|
Query from external management station to internal SNMP device |
Out | Int | Ext | UDP | 161 | >1023 | [148] | Response from internal SNMP device to external management station |
Out | Int | Ext | UDP | >1023 | 161 | [148] | Query from internal management station to external SNMP device |
In | Ext | Int | UDP | 161 | >1023 | [148] | Response from external SNMP device to internal management station |
In | Ext | Int | UDP | >1023 | 162 | [148] | Trap from external SNMP device to internal management station |
Out | Int | Ext | UDP | >1023 | 162 | [148] | Trap from internal SNMP device to external management station |
[148]UDP has no ACK equivalent.
All versions of SNMP use the same port numbers, so you will not be able to tell what version you are allowing through your packet filters. Since different versions have very different levels of security, you will probably want to limit access to those devices that you know are appropriately secure.
Shared application management
Remote control
Database tools to clean databases and produce reports
SMS has very serious security implications. The SMS hardware and software inventory provide detailed information about machines, and the software distribution mechanism allows any command to be executed with full Administrator permissions. All client machines are completely at the mercy of the SMS servers. In addition, an SMS system normally involves multiple server machines (for instance, one running the database server, one running software distribution, and one storing the shared applications), and those servers all trust each other. If any of the machines involved is compromised, the attacker will have control of all of the servers and, through them, of all of the clients.
Several of the utilities included in SMS are useful in a firewall environment; the network monitor, for instance, is an important diagnostic tool, and there is a tool for turning events into SNMP traps. The primary functions of SMS (hardware and software inventory, software distribution, and shared application management) are all risky and should not be run through a firewall or to firewall machines.
Performance Monitor and Network Monitor both provide information that's useful to attackers. Performance Monitor is the less interesting of the two; it provides performance and utilization data that will tell an attacker some useful data about the machine configuration, the amount of work needed to produce a denial of service, and the likelihood that anybody will notice if the attacker starts using the machine, but it doesn't give out anything of immediate use in breaking into the machine.
Network Monitor, on the other hand, comes with an agent that will let an attacker use the machine as a remote network sniffer. The version of Network Monitor that comes with Windows NT shows only packets sent to and from the machine it's running on (including broadcast and multicast packets), but that's plenty of data for an attacker to do damage with. If you have installed the full-featured version that comes with System Management Server, it will show all traffic that comes to the port, regardless of the machine that the traffic was sent to. Depending on your network configuration, this may make no difference (for instance, on a switched network, hosts will normally receive only their own traffic), or it may be all the traffic on the network segment (for instance, if you're using simple hubs or classic Ethernet bus-style cabling).
Because they are based on SMB transactions, Network Monitor and Performance Monitor are difficult to secure through a firewall, and you should not allow them. Because the Network Monitor Agent and Performance Monitor are extremely useful management tools, you may want to allow them on machines that make up your firewall. In this situation, you should be sure that they are not running on interfaces that can be reached from the Internet. It would be better yet to run Network Monitor and Performance Monitor locally on the firewall machine and disable SMB over the network altogether.