Note for external users: This post relates to a service that OxCERT offers to units within the University in the form of occasional port scans for ports related to particular known threats that we are tracking. This post looks at the various ways that people can use these scans within their units and some of the pitfalls they may experience.
In recent months, we have become aware that there is a great deal of variety in the ways that units within the University are using our occasional port scans. This variety can be very healthy, and allows various units to focus on particular areas that they consider to be a threat. It is worth observing that the various approaches people have used lead to very different results from the scans. It is therefore important that the units in question are fully aware of the impact of their choices when deciding how to approach them, and that all their staff are aware of their decisions. All the approaches we’ve seen have different merits so we see it as worthwhile to look at what these are and what they can tell you. We have also seen a few common pitfalls which we may be able to help avoid people falling into. These hints may also be relevant to anybody considering purchasing any form of network scanning service.
One common approach is to treat our scanning hosts as identical to any other systems located within the University Network, this is useful for the following purposes:
- validation of firewall rules
- identification of potentially vulnerable systems accessible outside of your subnet
However this doesn’t help in:
- identifying vulnerable hosts behind your firewall
- validating any additional firewall rules you may have for hosts outside of the University network
Another thing to think about here is whether your firewall has some form of rate limiting on port scans – these functionalities can be useful in reducing the log noise from brute force attempts, however they are liable to leave a false sense of security when applied to network scans, as large amounts of the subnet may be falsely listed as having nothing listening
Another approach is to treat the scanning range as though it is entirely outside of the University network, this will obviously help in similar ways to the previous case, however it may cause you to miss certain hosts if they are presenting vulnerable services to the Oxford network but not to the outside world. I would suggest that unless your network structure is particularly unusual (for instance a network in which you present far more services to the outside world than to the Oxford network) this approach is unlikely to be beneficial.
The final approach (which we have seen from a few units) is to treat our probe system as though they are internal to their network, this has the following advantages for a unit:
- it may pick up hosts that are only accessible internally and are vulnerable to a particular threat that would otherwise not be detected, this is particularly relevant if the unit has a flat (or nearly flat) internal network structure (i.e. there are few internal to internal firewall rules).
It also has a few disadvantages:
- it doesn’t serve to double check whether firewall rules are correctly being applied
- it may be technically hard and of limited benefit to do this for a network where different classes of system are physically segregated
- it may lead to unexpected panic if other IT Staff with in the unit are not aware that the firewall is exempted for these hosts when results are presented
- we may get in touch about hosts we would not otherwise need to if they are protected by your firewall
In general we do not mind what approach is being taken, and consider that the key requirement is to understand the impact of the decisions you are taking, and what that will mean for the results of the scans we perform.
Additionally we would urge all firewall operators to check what, if any, rate limiting they have in place, as this is a prime candidate for producing false negative scan results when we scan your networks – remember it is not unusual for attackers to use non-systematic scans (from many IP addresses) with the result that they may get around rate limiting even if we cannot. Whilst it might be beneficial to use a whole /24 for our scans thereby avoiding this issue, it is very hard to justify the use of already scarce IPv4 merely for this purpose.