Hot answers tagged

168

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 (...


106

NO 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 ...


56

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 ...


50

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 ...


21

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 ...


20

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.


19

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 ...


19

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 ...


18

I think there's something to be said for setting a bar, regardless of how low it is. Can Tripwire be bypassed? Sure. Will it catch things that you wouldn't otherwise? Yes it will. The main problem I've seen in a Tripwire installation is tuning it to where it isn't false-positive laden to the point of ignoring it. If it blows up every time someone ...


14

Update: This article is a nice explanation of auditd rules and gives examples for each event you might want to log: HOWTO_configure_the_auditing_of_the_system_auditd Check out the bug report here: https://github.com/gds-operations/puppet-auditd/pull/1 They give a very long example file which contains many important changes that might be made to a system. ...


13

You will need a wireless nic that permits a 'monitor' mode, and that requires some special drivers and special nics. Kismet's list of cards for Linux tests on different cards pineapple device (special device) airpcap nic (specialized nic for Windows) Once you get a card, you will need software to deal with the data and Kismet is the leader in this area ...


13

There has been an enormous amount of research into using machine learning techniques for anomaly detection, i.e., to scan network traffic and detect intrusions. However, this research has had very little practical impact. These techniques have seen little deployment and are rarely used in practice. Why not? There are a number of reasons. First, these ...


13

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 ...


13

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 ...


13

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 ...


12

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 ...


12

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 ...


12

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 ...


11

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 ...


10

Tripwires are very useful for defending against userland rootkits. Kernelland rookits do not need to replace binaries to subvert the behavior of the system, usually these rootkits are just a Linux Kernel Module (LKM). In fact when you control the kernel like this any executable's behavior can be influenced without needing to modify the binary its self. (...


10

There are two subtly different things you might want to test. Is Snort working in the sense that it's running, able to sniff trafic, testing it against the rules, and alerting you when one is triggered? Is Snort working in the sense that it's current rule set detects a specific intrusion of type X? To test case 1, you make a rule that's easy to fire, like ...


10

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 ...


9

Fail2ban does exactly what you ask. It monitors your log files looking for certain patterns and then executes whatever action you specify. You can block an IP for a length of time. It does require some skill in regex, but it comes packaged with regex testers.


9

It also might be worth taking a look at IDSWakeUp [Apr 2019: link is dead]. IDSwakeup is a collection of tools that allows to test network intrusion detection systems. The main goal of IDSwakeup is to generate false attack that mimic well known ones, in order to see if NIDS detects them and generates false positives. Like nidsbench, IDSwakeup ...


9

That's a very general question. Your concern should not just in relation to Snort, it all depends on the platform that you install it on (o/s - yes it does run on Windows, CPU, memory etc) and what elements (pre-processors for fragmentation or stream reassembly) of Snort that you enable (look in the configuration file, typically /etc/snort.conf, for more ...


9

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 ...


9

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 ...


8

In addition to the answers from Rook and Jeff, Tripwire and similar solutions also have real time alerting value. To subvert a Tripwire system that is also monitoring its own files you need to prevent it alerting during the subversion process. Not as straightforward an attack any more. So in summary - you can get around any controls given enough time/...


8

Web application firewalls like mod_security have the potential to be more effective than network-based IDSs like Snort, because a web firewall can see the request exactly as it will be handled by the web server, and a network-based IDS cannot. Network-based systems, like Snort, can only see the network packets. They have to infer/guess how the web server ...


Only top voted, non community-wiki answers of a minimum length are eligible