Keyword filtering for SQLi is not a good technique. There are too many ways to bypass it.
Crazy things like sel/**/ect might work, for instance. Or playing games with substr(). And then there's EXEC('SEL' + 'ECT 1').
There are many guides on how to bypass common filtering techniques.
But then you might ask if there is a superset of things to filter for (...
Since every SQL injection is (by definition) valid SQL and since SQL is a context-free language (source), there is (again, by definition) no regex capable of matching an SQL injection, and trying to do so would probably give result similar to this.
As said by pretty much every comment, use the right tool for the job. In this case it's a prepared statement....
Technically, this is completely possible (though doing so also renders the database useless):
.+ Will indeed detect any possible SQLi.
However, it will also detect any attempt to do normal queries(or any text at all), rendering the database completely useless.
You could equally say that turning the database off protects from SQLi. It's true, but it also ...
The line is definitely blurring somewhat as technological capacity increases, platforms are integrated, and the threat landscape shifts. At their core we have
Firewall - A device or application that analyzes packet headers and enforces policy based on protocol type, source address, destination address, source port, and/or destination port. Packets that do ...
I'm wondering if it is possible to detect 100% of the possible SQLi attacks using a simple regex.
The very fact that you're asking the question this way shows you're thinking about the problem incorrectly.
SQL injection is not a vulnerability in data. It's a vulnerability in application code that handles that data.
For example: right now I'm typing a "SQL ...
IDSs and several deep inspection firewalls (sometimes called NGFW or UTM) can usually detect whether the traffic is HTTP or not. Also a HTTP proxy in front would simply block anything which is not proper HTTP.
But be aware that it is possible to build a reverse shell where the traffic will look like HTTP, so this filtering will only help a bit.
A little background first. As you know, when communicating over a network, programs split raw data into "packets", which as well as this raw data also contain some extra information:
Where does this particular packet fit inside the entire block of data being transmitted?
Who does the packet come from?
To whom does it need to be delivered?
Routers are the ...
You want to increase signal and reduce noise during a pen test?
Great! Here are some things to ponder on:
For answers to the questions you have -- are they already answered somewhere else? For example, does Nmap data from a previous pen test provide an accurate-enough view of the data you would expect today? Would csrecon or similar provide that data? If ...
Update: This article is a nice explanation of auditd rules and gives examples for each event you might want to log:
Check out the bug report here:
They give a very long example file which contains many important changes that might be made to a system. ...
These are scans for proxy servers. The first one tests for a SOCKS4 proxy, the second one for a SOCKS5 proxy, and the third one tests if your server allows forwarding via a CONNECT request to "valuable" ports (SMTP in this case). You don't have to be worried about that, it's what you expect to see on public servers. Your server answers with return code of ...
No, generally not, although of course they say they can.
DDoS is about volume
UTM is almost always at the local end of Internet access
Therefore, DDoS can usually fill the Internet pipe before even reaching a UTM device.
The reasoning -
By definition a DDoS - being Distributed - is taking advantage of multiple attack points to generate a level of traffic ...
It depends on the kind of DPI you are talking about. If it is purely passive DPI (i.e. only looking at the packets) then you will not be able to detect it. If this is instead DPI which can modify the data then you might be able to detect it depending on the kind of access and knowledge you have.
Some typical examples on how active DPI devices change ...
You have to make a choice: are you going for stealth, or for broad coverage and efficiency? Essentially all scanning tools, including nmap -sS, are easily detected by a competent SOC if run at a decent speed. If you want to avoid detection, you must either make fewer requests, or make them more slowly.
Have you tried running tools like Snort, Bro, or ...
The way to look at which is better for you is to work out what your risk appetite is.
If you must have service at all costs then you don't want to fail closed, as any problem with that IPS will cause a Denial of Service. That is a very rare scenario though - the majority of implementations are configured to protect the server and the data on it.
This is ...
Neither of these technologies can prevent a DDoS attack, what they can do is help to prevent a DDoS attack from taking down services. They have completely different functions so you can't say one is better is better than the other.
An Intrusion Prevention System looks for anomalous traffic on a network and can alert operations staff that a DoS attack is ...
Having done tests for multiple clients where they claim "scans won't knock this over, you'll be alright", then an hour later we're having a meeting discussing how they're going to handle a serious downtime incident, I can safely say a few things:
The marketing figures describing performance are at best a peak performance case, produced in a lab situation ...
The attacker can easily mimic HTTP traffic, so I will doubt any IDS/IPS would prevent a well developed shell from mimicking HTTP requests to exfiltrate data. It's very easy to create a fake HTML page, embed the images with <img src="data:image/png;base64,iVBORw0KG…8bg5CYII="> and put the traffic inside.
A lossless compression (like PNG) will allow ...
No. First of all, there are several evil things you can do with SQL injections which don't require the use of the SELECT keyword, like the infamous universal password ' OR '1' = '1 or the common username Robert'); DROP TABLE Students;--. Also, "select" is a very common word in the English language which might appear in completely benign ways in all kinds of ...
You are correct to think that these three technologies are complementary and will often detect the same issues. However, that in itself is no reason not to use them in layers. One may catch things the other may not. Look at virus scanners - here's an example where only 14% of the 37 scanners attempted found the virus! And that's with the same exact type ...
While the other answer focuses on modifying the exploit itself, you can also modify the transport of the exploit, so that the IDS will not detect it (Disclaimer: some of this points to my own research).
Some examples on how to do this on the application layer with HTTP (i.e. for drive-by-downloads while browsing the web etc):
Use a valid but less common ...
There are various ways that comes handy with nmap to evade the basic rules of firewall or Intrusion detection system.
1) Packet Fragmentation:
This option evade pattern matching detection technique. Since packet reassembly can be quite processor intensive, it's common for admin to disable it.
In snort, fragmentation reassembly functionality is disabled ...
Functionally, they are two different applications, but they are often meshed together because the monitoring process tends to be at the edge off the network. Many times you see UTM (Unified Threat Management) which are firewalls with IPS/IDS services integrated as a subscription.
Firewalls serve to control the inbound/outbound connections into an ...
While there are some IDS/IPS devices which are marketed as 'minimal' setup, in reality IDS is one of the most setup-intensive devices in a typical network. In your situation, I would strongly suggest that you avoid this type of device as there is a high likelihood that false positives would further convince your client that he is being targeted.
I would ...
With OSSEC ver. 2.7.1, ossec.conf (by default located in /var/ossec/etc) contains the following active response configuration:
<!-- Active Response Config -->
<!-- This response is going to execute the host-deny
- command for every event that fires a rule with
- level (severity) >= 6.
- The IP is going to ...
Passively listening to network traffic to detecting suspicious behavior is still important. There are only a few obvious attacks which you might detect and block immediately but there is lots of traffic which only looks a bit suspicious or even innocent. But, if you collect traffic information over some time and maybe from multiple places in your network, ...
First, you talk about HIDS and HIPS.
The 'D' stands for "Detection". It means that the protection system will be able to detect and alert upon a possible security event, but it will not attempt to block anything.
The 'P' stands for "Prevention". This means that when the protection system detects a possible security event, it will automatically try to block ...
Regarding Wazuh differences with OSSEC, the Wazuh team is working on updating the documentation to explain those better (and on a new release and installers).
Wazuh new version (2.0, currently found under the master branch) highlights are:
OpenSCAP integrated as part of the agent, allowing users to run OVAL
New WUI on top of Kibana 5, and ...
copy autorun.inf C:\ > NUL
copy file.bat C:\ > NUL
copy autorun.inf D:\ > NUL
copy file.bat D:\ > NUL
Put them together, and you got something that will spread through USB.
On a more serious note, don't expect that someone will ...
I can think of some ways:
Malware connect to C&C server. if you monitor your traffic (as sensitive system should be monitored) - than you find unusual traffic that can be sign (and should be investigated)
If the malware uses USB flash drives to spread itself, and you have different computer platforms in your environment (e,g: windows, mac, linux and BSD ...