I'm using HAproxy with a backend of openLDAP servers. I'd like to do the checking of the availability of the backend machines using ldap-check instead of the generic check-tcp (which I'm currently using).
ldap-check binds anonymously with no encryption when performing the check. Looking at the documentation of ldap-check, I see no way of configuring the bind-user and the use of encryption.
So, assuming I can not do a proper check (TLS + binding as specific user), I'm looking for a workaround. I may be able to convince myself to allow anonymous binding, but allowing for unencrypted connections is not something I want to do.
So, is it possible to (somehow) allow unencrypted connections for anonymous binds only? I guess not, since how do you know it's non-anonymous before the binding process has begun?
I currently have olcSecurity: tls=1, and I think I would need something like olcSecurity: tls=1 simple_bind=0, but that would allow any simple bind to be unencrypted (Not something I want to allow).
Maybe I should/could do the check by sending specific packages using ldap-check like shown here? What is the best tool for getting the binary data? Should I just do a session with ldapsearch and tcpdump?
Any thoughts appreciated.
I was able to do the checking from HAproxy using the tcp-check options send-binaryand expect binary without compromising the security of my openLDAP configuration.
In my situation, I expect an attempt to bind anonymously to return the error code 48 (Not allowed). For the bind request, I was able to confirm the data sent in the example I linked to in my question. However, I needed a different response (Not allowed. Error 48)
Using a pcap file captured with tcpdump, I looked at an attempt to bind anonymously with ldapsearch with Wireshark. Doing that, I was able to see the raw data returned by openLDAP telling the client that the anonymous bind is not allowed.
Here is the relevant configuration from the HAproxy backend:
option tcpka
option tcp-check
tcp-check connect port 389
tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple
tcp-check send-binary 01 # message ID
tcp-check send-binary 6007 # protocol Op
tcp-check send-binary 0201 # bind request
tcp-check send-binary 03 # LDAP v3
tcp-check send-binary 04008000 # name, simple authentication
tcp-check expect binary 302502010161200a013004000419616e6f6e796d6f75732062696e6420646973616c6c6f776564 # 48 not allowed
tcp-check send-binary 30050201034200 # unbind request
I don't think tcp-check expect binary can be put in to more than one line like you can with tcp-check send-binary
Related
I have a bit of an unusual question.
I have HAProxy listening on a given port in SSL mode. I can initiate a successful connection to this HAProxy instance using openssl s_client.
However, the usual client that will be connecting to this HAProxy box requires it's own specific packet exchange before it will start the standard SSL negotiation.
In order for this specific client to start a SSL handshake, it attempts to verify with the server first that the server is OK with SSL. To perform this check, this specific client sends the following bytes to the server:
0x00 0x00 0x00 0x08 0x04 0xD2 0x16 0x2F
and then the server is expected to respond with:
0x53
And then the client will do the typical SSL handshake w/ the server (in this case, HAProxy ).
my question:
HAProxy has a variety of functions for injecting things into the response sent to the client; HTTP headers, for example.
Is is possible to inject specific byte(s) to the client based on the client's initial response without involving a special backend?
The approach i was going to try would look something like this:
frontend my_frontend
mode tcp
bind :9999 ssl crt /etc/some/path.crt
acl non_standard_client payload(0,8) -m bin 0000000804D2162F
<snip>
use special_backend if non_standard_client
backend regular_backend
server regular 1.2.3.4:9999
backend special_backend
server special 127.0.0.1:9999
and then have something like this running on the HAProxy box:
#!/bin/bash
# ASCII `S` is 0x53
while true; do echo -e "S" | nc -l localhost 9999; done
Is there a way to mimic that ^ in HAProxy w/o needing a second server just to send the magic byte?
Thanks for your time. It's appreciated!
EDIT: Before anybody asks: HA-Proxy version 1.6.3 2015/12/25
I am new to snort so hope you can help me out. I am trying to create my own rules in snort via the local.rules file. I have snort installed on Windows 7 via Virtual box. My configuration seems to be working fine as I can test it with the string -T and it works fine. Also when I run the first three simple rules in the attached screenshot entitled snort rules they work fine, my problem is when I try to right a specific rule which in this case is to log when bit torrent is download the rule is triggered but I am getting all these http_inspect errors. Not sure what they are and if I am missing something in the snort.conf file. I have not touched the preprocessor settings in snort.conf. The errors I get are also attached in the screenshot Snort Output. The rule syntax I am running is snort -i 1 -c c:\snort\etc\snort.conf -A console. The rule is getting logged in the log folder and also I attach the wireshark output. Any help on this would be much appreciated.
Thanks
Garreth
The messages from http_inspect are not errors with your config or errors at all, they are messages from preprocessor rules that are triggering from the traffic. Specifically rule 120:3:1 (GID = 120, SID = 3, REV = 1). The GID 120 rules are specific to the http server inspection from the http preprocessor. This rule generates an event when the http_inspect preprocessor detects anomalous network traffic. The message for this rule is "NO CONTENT-LENGTH or TRANSFER-ENCODING". What this rule is looking at is the server response headers. It's likely alerting because there was no "Content-Length" header or there was no "Transfer-Encoding" header in the response header.
Here is an example of http server response headers:
accept-ranges:bytes
content-length:67023552
content-type:application/x-apple-diskimage
date:Thu, 10 Mar 2016 05:32:31 GMT
server:downloads
status:200
There should always be a content-length header in the server response because it tells the client how much data there is for this request. When the actual length of the data is different than what is presented in the content-length header the client should discard it and throw an error. If there is no content-length header the client has no idea how much data is about to be sent and there is no way to validate that it got all of the data for this request. If this header is missing from the server response snort will generate the rule you are seeing because this is anomalous traffic. It could also be missing the transfer-encoding header. In the example above you'll notice there is not transfer-encoding, so snort would generate this rule if the server response headers looked like the above. The transfer-encoding header is not in a lot of http responses, and this is normal. I believe that these rules are generated when you have the "extended_response_inspection" and the text rules are set to alert (do you have a preprocessor.rules file snort is picking up, or is this rule in any of your rule files?). This option is explain in the snort manual for the http server configuration options. If you don't care about these alerts you can remove the gid rules from your rules files. If you do not have these rules in your rules files then you can add the "no_alerts" option to the http server config. From the snort manual for this option:
"This option turns off all alerts that are generated by the HTTP Inspect preprocessor module. This has no effect on HTTP rules in the rule set. No argument is specified."
You can also remove the extended_response_inspection options from the http config if the rule is being generated by that option.
looks like your tcp config is missing the client/server/both
keyword between ports and 80. Consequently, 80 is being lost and
reassembly is set to both for 8080 only. Change to this in config file:
preprocessor stream5_tcp: policy first, ports 80 8080
This means that every HTTP port needs to be listed in the stream5_tcp preprocessor and that this is not
enforced.
For more info on setting up snort, please go through the following links:
https://www.talentcookie.com/2015/05/snort-how-does-it-work/
https://www.talentcookie.com/2015/05/snort-an-open-source-ids-in-freebsd-10-or-above/
https://www.talentcookie.com/2015/10/snort-performance-is-your-snort-working-fast-enough/
I configured exim mail server on centos. It is working with no encryption type. But not with SSL and TLS. I din't get correct solution for this type of error. Can anyone tell solution and why this error message in exim main.log file?
The error message is like below in the exim main.log file.
2015-03-17 10:34:16 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=acp-node [10.7.2.137] input="\026\003\001"
(input sent without waiting for greeting) ... input="\026\003\001"
In short: You are trying to use implicit TLS on a port where explicit TLS is needed.
In detail: There are two ways to use TLS with SMTP:
implicit TLS, that is TLS from start. This is used on port 465 (smtps). This mode is in some SMTP stacks simply called "SSL".
explicit TLS, that is start with plain SMTP and upgrade to TLS with the STARTTLS command. This is used on ports 25 (smtp) and 587 (submission). This mode is in some SMTP stacks simply called "TLS".
If you look around at the questions regarding use of SMTP with TLS you will find lots of confusion about how to use these modes with the various setups. And you will find lots of bad code which tries to use implicit TLS where explicit TLS is needed.
What you see is the result of the client trying to use implicit TLS on a port not suitable for this. \026\003\001 (or hex 16 03 01) is the start of a TLS 1.0 handshake and input sent without waiting for greeting refers to the fact, that the client is sending data first without waiting for the server to send the (plain text) SMTP greeting.
Judging from the error log entry, your mail client 10.7.2.137 is trying to establish a secure (TLS) connection but your Exim server is not expecting it.
Most probably, TLS is not configured properly in your Exim configuration file. You can refer to http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html for tutorial.
The solution is, therefore, to edit your Exim configuration file, making sure TLS certificates are defined and tls_advertise_hosts is set; and then restart Exim.
Hi Im writing some custom rules for a university project and I wondered if anyone could check my rule for this vulnerability;
http://www.exploit-db.com/exploits/34517/
here is my rule;
alert tcp any any -> any 5466 \
(msg: "FTP command execution"; content: " / admin lua script html"; content: "POST"; http_method; content: "os execute";)
Revised rule; alert tcp any any -> any 5466\
(msg: "FTP command execution"; content:"/admin_lua_script.html"; content:"POST"; http_method; content: "os execute";)
I would recommend something like the following:
alert tcp any any -> any 5466 /
(msg:"FTP command execution"; flow:to_server,established; /
content: "POST"; http_method; nocase; /
content:"/admin_lua_script.html"; fast_pattern; http_uri;/
content:"command=os.execute"; http_client_body; nocase; /
metadata: service http;)
Explanation:
dest port 5466:
You should always specify a port when possible. When you have rules that are "any/any" for source/destination snort treats them differently than rules with ports defined.
Important: Since this exploit module runs over port 5466 and is http you NEED to make sure that this port is in your http preprocessor configuration for ports. Specifically, your snort.conf should have a configuration line similar to the following:
preprocessor http_inspect_server: server default profile all ports { 80 ... 5466 ...}
(obviously don't put the dots, just representing other ports you should have in there). If you do not have this port in your preprocessor config for http, all of your http content modifiers will NOT match because snort will not treat traffic on this port as http, which is likely the main issue you're having.
flow:to_server,established;
You only want to check established sessions where the flow is going to the server. This will be more efficient as snort won't have to check random traffic for unestablished sessions and it won't have to check traffic going to the client, since you know the direction for this exploit will always be going to the server. The only way the request would be successful would be if the connection was already established between client and server, if it's not the exploit won't succeed and it's pointless to alert on this.
content: "POST"; http_method; nocase;
You want nocase for the post match because it is not required by http for the method to be all capital letters.
content:"/admin_lua_script.html"; fast_pattern; http_uri;
Adding the fast_pattern option will make the rule more efficient as it will put it into the fast pattern matcher in snort. You know this content is static and never changing (case included) so this is eligible for the fast pattern matcher. Since this is the only content match in the rule that is case sensitive snort would put this into the fast pattern matcher on it's own, but if you modify the rule later on with another content match you would want this to be the content match to use for the fast_pattern matcher.
content:"command=os.execute"; http_client_body; nocase;
This is going to be in the client body, so add the http_client_body option.
metadata: service http;
If you are using target based (which now a days you should be), you need to add the service http keyword. Having this in the rule will no prevent the rule from triggering if you aren't using target based, so it's also a good practice to put this in if you know the service this traffic is.
Additional Note:Your custom rule sids should be 1000000 or above, anything below this is reserved for the snort distribution rules. See more on that here
I have few doubts regarding telnet and echo which I haven't got so far lucky with google (also to say I have done my homework)
Does the telnet specification says that there are specific echo port and specific non-echo port?
If yes, Do ports 23 and 10001 differs on that specifically?
If conditional yes, is it some version of telnet protocol specific. In other words were those added after some specific iteration of telnet and/or are their fully compliant telnet clients and partially compliant one (regrading echo)?
also whats the difference if any between localecho and remote echo? I believe I am talking about echo from server side (remote echo?) but in any case which is what?
I am not sure if there is telnet / protocol specific child stackoverflow site? If yes, can somebody point me there?
The IANA Service Name and Transport Protocol Port Number Registry contains all port number registrations and for Telnet it cites RFC 854 as specification which defines
Port Assignment
When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.
For the Echo Protocol the RFC number RFC 862 which similarily defines
TCP Based Echo Service
One echo service is defined as a connection based application on TCP.
A server listens for TCP connections on TCP port 7. Once a
connection is established any data received is sent back. This
continues until the calling user terminates the connection.
The port number 10001 is registered for "SCP Configuration".
When a true Telnet server starts, it sends a number of IAC commands to the client telling it how to behave. The server can tell the client to do its own character echo (IAC DO ECHO) or it can tell the client to act dumb (IAC DONT ECHO). The client then confirms its action (IAC WILL ECHO) or inaction (IAC WONT ECHO). If the client responds the opposite of what the server requests then the server can either adapt or continue to insist (and likely eventually fail).
https://www.rfc-editor.org/rfc/rfc857
So to answer your specific question, no, there are not different echo/noecho ports. It's a result of server configuration and client capability. Though technically it is possible to have the telnet server have different configuration on different ports.
You can find a list of special Telnet codes and available do/dont/will/wont options here:
http://www.laynetworks.com/telnet.htm