You are on page 1of 3

1 Overview

One way to secure a web-based application is to restrict access based on the IP address. You can
block access to a specific address or range of addresses that you suspect belong to malicious
individuals. ServiceNow allows you to control access to your instance by IP address.

2 Access Control

Navigate to System Security > IP Address Access Control to see a list of your IP access controls.
You may need to activate this module. By default the list is empty, meaning that there are no
particular restrictions on access to your instance. You can add these types of rules:

Allow: any IP address in this range is allowed to connect to this instance.

Deny: any IP address in this range is not allowed to connect to this instance unless it is listed in
an allow rule.

Note: These rules also affect transferring update sets. To ensure that IP Address Access
Control does not cause update sets to fail, add the target instance as an exception on the
source instance. See Transferring Update Sets with Access Control.

2.1 Example 1: Block a particular range

Let's say we want to block a particular range of IPs, say -> Click on
"new" to add a new rule. Then fill it in as follows. Range Start and Range End must be specific IP
addresses as seen in the examples, without asterisks or CIDR blocks.

2.2 Example 2: Block everyone except a particular range

Let's turn the problem around. So if an address is between -> we want to
allow it connect, but we want to deny everybody else. To do this we're going to need two rules, one
to allow that range, and a second to deny everybody else.

Click New and add a new rule. Then fill it in as follows.

Now let's add the deny rule.

3 Finding Denied IP Addresses in the Logs

Denied IP addresses are by default not viewable from the system logs. However, you can still find
them in the instance's node log files.

To find the IP addresses that have been denied access to your instance:

1. Navigate to System Logs > Utilities > Node Log File Browser.
2. Browse the logs by criteria, such as time period and message.

You can also download log files when you know which log you are looking for.

Log entries for blocked IP address appear as follows:

2015-10-21 18:37:43 (175) http-30 WARNING *** WARNING *** Security
restricted: Access restricted ( not authorized)

4 Notes/Limitations

The system won't let you lock yourself out, so if you try to add a rule such that your current
address would be locked out, the system will warn you and refuse your insert.
If you're inside of a corporate intranet, be very careful about setting up your IP rules. The IP
address you see on your own computer (like generally bears no relationship to
the IP address you'll actually appear as out on the internet. Your company will likely proxy
and/or NAT your address into a predictable set of outbound addresses which you'll likely
need to ask your network team about.
A user whose access is restricted based on an access rule will get a 403 error on their
Restricted users don't use transactions, semaphores or count towards any server resource
This feature doesn't supersede or override your existing access control rules if, for example,
you're running a VPN to our data center. It's an additional check that must be met in addition
to any access controls we may have set up on your PIX.
Allow rules always supersede deny rules. So if my address is both allowed (by one rule) and
denied (by a second rule) it is, in fact, allowed.
Asterisks and CIDR blocks are not currently supported.
Regarding forwarded proxy addresses, the allow rules are applied to each address in the
chain and then the deny rules are applied to each address in the chain if none of the allow
rules matched.