As most
security professionals would agree to the fact that there is no easy way to find
what sort of sneaky APTs lingering in the network, it is a mundane task to
monitor either ingress or egress flow day in and out. Since the recent
disclosures of highly sophisticated (hence state sponsored) malwares by the
security vendors were so overwhelming, many of us are left clueless which data
to block or otherwise allow.
While these
attacks are mainly operated ranging from layer 3 to 7, life couldn’t be harder
than just to block just IP and port. For example, SQL injection is the most
widely used attack vector in headline grabbing scenes occurred almost every
month of this year; one can’t simply block all SQL traffic to protect its
network because these type of changes would impact operational use of other
users. Although the best practice for the programming and development of web
applications should not allow SQL injection within web requests and responses,
they can still be seen in well-known websites.
If you give
a glance on any IPS event log, one can see all combination of SQL commands
passed through URL requests inbound or outbound. To be fair, it is regarded as
normal when SQL parameters are detected within outgoing traffic, this becomes
opposite for incoming traffic especially when you know, you are not running any
internet-facing database servers.
So what
should we do to prevent these proactively? Which level of defense you can expect from
an IPS if you are not planning to deploy WAF or NGFW anytime soon? If you fall into those scenarios, read on.
1. Know your requirements
a. Have healthy and supportive
discussion sessions with development team and vendors to create relevant
baselines to uncover any dependency to database access. Sometimes it is a good
practice to include helpdesk or support team to get more details as they are
the frontline people when the actual users have issues.
b. Enable IPS filters that can detect
SQL parameters inside the requests, make sure the filters are not in block mode
since this step is supposed to monitor and verify dependencies from (a)
c. Now it’s time to get your hands
dirty. Sift through the generated logs to identify and classify what are normal
requests and what are hostile ones. Make separate lists for each category.
2. Reduce outside exposure to your
database servers
a. While we are on SQL subject, let’s
assume this is about MS SQL. On most occasions, SQL server management is like
any other server management, all access from outside should be authenticated
via VPN and perform other tasks. Having said that, ‘sa’ login requests should
not be seen in IPS events, which means such logins are to be restricted, i.e.
1433/tcp and 1434/udp should be blocked on external interfaces.
3. Enforce least privilege access
a. Reference from web applications
should be made with least privilege account that could perform sufficient
operations. The account used for such purpose should not be reused in any other
databases at higher permission, to limit damage upon security breaches.
Let’s
conclude part one here and the next part will be uncovering how AET can be
mitigated using an IPS.
