What are the differences between drop , reject , sdrop snort rule actions and react option in the rule header?
The documentation lists the following actions and their effect:
drop block and log the packet
reject block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP.
sdrop block the packet but do not log it.
These can be found on the documentation page Snort Rule Headers
react whose documentation can be found here is a rule option keyword that allows you to first send a html page back before resetting the session.
As per the documentation this must be enabled when building snort with the following option:
./configure --enable-react / -DENABLE_REACT
Related
We are currently using the dispatcher module in kamailio to get the availability of gateways via the dispatch list.
It uses a health check based on if it can talk to the gateway via SIP by default. However, I would like to know if we can make the check better by also checking via a http health check?
The reason for this is because when the gateway on the other end is in courtesy shutdown the dispatcher still sends calls to it even though we would like the box to shutdown. This leads to the gateway always staying up.
Alternatively there might be a better way of handling this by sending a message back in the sip packet to kamailio.
I have read through the documentation but I can't seem to find anything like what I am looking for.
The Dispatcher module has Event Routes that can be called when a SIP destination goes down / up. There are no Event Routes for HTTP as it's not constantly queried in it's own thread by Dispatcher.
Alternatively there might be a better way of handling this by sending a message back in the sip packet to kamailio.
You can however set the dispatcher state using the ds_mark_dst([state]) function. Through this you could add a custom header in any SIP message from your box that's shutting down to tell Kamailio's Dispatcher to not use it as a destination in the future.
If we added an imaginary header called "X-SetState" with the value "Shutdown" and send it from our box that's shutting down to Kamailio in a SIP message we could pick it up with something like this:
is_present_hf("X-SetState"){ //If custom header is present
xlog("Received state change request ($ru) with value $hdr(X-SetState)")
if($hdr(X-SetState) == "Shutdown"){ //If value of header is Shutdown
ds_mark_dst("dp"); //Mark destatination as disabled & probing
}
}
Obviously you'd need to add your own code to select the right dispatcher to mark inactive and ensure that the X-SetState header was only parsed if it came from your internal boxes you want to mark as down but you get the idea.
However, I would like to know if we can make the check better by also checking via a http health check?
Dispatcher at the moment has no support for monitoring HTTP state, but adding it wouldn't be that difficult to implement, if you're handy at C you could add support or add a feature request.
Alternatively you could write an script to monitor HTTP status of each device and the using Kamcmd / Kamctl set the dispatcher group to down if it doesn't get a response.
If I send a request with LWP, there is a convenience function as_string which tells me what request I just sent. Very handy, and in truth I have no problems with it. Except that I just noticed that it is surely lying to me. For instance, this code:
use v5.14.2;
use LWP;
my $response = LWP::UserAgent->new->get('http://user:pswd#example.com/');
say $response->request->as_string;
Gives this output
GET http://user:pswd#example.com/
User-Agent: libwww-perl/6.13
But surely the URL was not sent like that! The library must have parsed out the username and password, and added the appropriate headers, and added a host header, and so on. Is there an easy way to find out what was actually sent?
There's LWP::ConsoleLogger::Everywhere1, which you can just load to get all the details of both the request as well as the response. The request will be taken right before it's sent over the wire, and the response from when it comes back.
All you need to do is use LWP::ConsoleLogger::Everywhere anywhere in your code. If you want more control, the main module LWP::ConsoleLogger in that distribution will let you tweak settings easily.
However, this is not the real data that goes over the wire. If you want to know what it receives, you need to either monitor the connection with something like tcpdump and then take a look at it (which is quite advanced networking stuff), or maybe change the endpoint to your own IP address, or simply 127.0.0.1, and then use netcat to listen on a specific port.
$ nc -l 8080
If you send your request to that port, you'll see it in netcat.
1) Disclaimer: I'm a contributor for that module
Trying to write a snort rule that prevents the system (using its IP) from accessing a specific website, tried this up to now.
alert tcp any any <> 'ipaddress' any (content: "web url"; msg: "Access Denied"; react:block; sid:1000005;)
Any ideas on why this won't work?
Snort has several actions which can be used:
alert generate an alert using the selected alert method, and then log the packet
log log the packet
pass ignore the packet
activate alert and then turn on another dynamic rule
dynamic remain idle until activated by an activate rule , then act as a log rule
drop block and log the packet
reject block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP.
sdrop block the packet but do not log it.
These can be found on the documentation page Snort Rule Headers
In your situation you want either drop, reject or sdrop, depending on whether you want to send a reset, and either log or not.
The reason your current one will not block is that alert will just log the packet.
I'm not totally certain, but it may be that you are using alert which alerts the IDS where you should be using drop which just drops packets going to the specified URL.
I've been following a number of tutorials, the best being Yandex's.
In step 6, it says I need to open the stream again after authorization? Is there any reason why?
Did the stream close automatically? If I just authenticated the stream, why does it need to close and be reopened? Do I need to recursively start from step 1 again or how often do I need to request it to be reopened? Do I need to authenticate this new stream.
As a XMPP beginner, why's the point of: New Stream -> Authorize it -> New Stream -> Not sure now what, maybe authorize again?
As an XMPP beginner, you may just get an XMPP library which done things right :)
When you ready to go deeper, you must read official XMPP specifications: Core, Instant Messaging and Presence and Address Format
Initial stream "negotiation" described here - https://www.rfc-editor.org/rfc/rfc6120#section-4.3
In a short - no, you need authenticate only when your party "advertise" <auth ... /> element in the beginning of new stream (<stream:features>), most of time it is done once.
The stream features change after authorization. Just as they change after the TLS handshake is performed. A change of stream features always means that there is a "new" stream going on. That's why the stream is "reopened".
If you look at RFC 6120 ยง 9.1, you see that a server (could) first announce (only) starttls as stream feature (9.1.1 Step 3):
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
</stream:features>
then after the server and client performed TLS negotiation and the established TLS a new stream is initiated by the client.
Now the server sends different stream features (9.1.2. Step 8):
S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Notice how the starttls stream feature disappeared and now only the SASL mechanisms are reported as stream feature.
After the client is authenticated another new stream is created and again new stream features are send (9.1.3 step 14):
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
In Apache HTTP Client there's the concept of a "wire log" that can be turned on, printing out the actual HTTP text generated by the client code and sent to the server.
How can I do the same using spray-client? I'm of course able to add a RequestTransformer and ResponseTransformer and print them using .toString, but that doesn't show me what's actually being serialized to HTTP at the TCP level.