Capture tcp payload on HAProxy
I wanna capture tcp packet and make acl by captured tcp packet but now I'm trying to capture payload it doesn't work. My configuration frontend hts_frontend bind *:8400 mode tcp maxconn 3000 option tcplog log global #log-format "%ci:%cp [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq" log-format "capture0: %[capture.req.hdr(0)]" timeout client 1m tcp-request inspect-delay 1s tcp-request content capture payload(0,192) len 1 I want to capture the 118th character same as screenshot and make acl if the character is 1 going to A backend server other character is going to B backend server Please advice me how to do that...
stable-bot: Bugfixes waiting for a release 2.2 (2), 2.1 (48), 2.0 (9)
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses to this mail must be
sent to the mailing list.
Last release 2.2.1 was issued on 2020-07-23. There are currently 2 patches in
the queue cut down this way:
- 2 MINOR, first one merged on 2020-07-23
Thus the computed ideal release date for 2.2.2 would be 2020-08-20, which is in
three weeks or less.
Last release 2.1.7 was issued on 2020-06-09. There are currently 48 patches in
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-07-23
- 21 MEDIUM, first one merged on 2020-06-12
- 26 MINOR, first one merged on 2020-06-12
Thus the computed ideal release date for 2.1.8 would be 2020-07-10, which was
two weeks ago.
Last release 2.0.16 was issued on 2020-07-17. There are currently 9 patches in
the queue cut down this way:
- 1 MAJOR, first one merged on 2020-07-23
- 5 MEDIUM, first one merged on 2020-07-21
- 3 MINOR, first one merged on 2020-07-21
Thus the computed ideal release date for 2.0.17 would be 2020-08-20, which is
in three weeks or less.
The current list of patches in the queue is:
- 2.0, 2.1 - MAJOR : dns: Make the do-resolve action
thread-safe
- 2.1 - MEDIUM : mux-h1: Subscribe rather than waking
up in h1_rcv_buf()
- 2.0 - MEDIUM : mux-h2: Emit an error if the response
chunk formatting is incomplete
- 2.0, 2.1 - MEDIUM : resolve: fix init resolving for ring
and peers section.
- 2.1 - MEDIUM : server: resolve state file handle leak
on reload
- 2.1 - MEDIUM : mux-h1: Disable splicing for the
conn-stream if read0 is received
- 2.1 - MEDIUM : mux-h1: Continue to process request
when switching in tunnel mode
- 2.1 - MEDIUM : channel: Be aware of SHUTW_NOW flag
when output data are peeked
- 2.0, 2.1 - MEDIUM : mux-h1: Disable the splicing when
nothing is received
- 2.1 - MEDIUM : pattern: Add a trailing \0 to match
strings only if possible
- 2.1 - MEDIUM : ebtree: use a byte-per-byte memcmp()
to compare memory blocks
- 2.0, 2.1 - MEDIUM : dns: Release answer items when a DNS
resolution is freed
- 2.1 - MEDIUM : fcgi-app: fix memory leak in
fcgi_flt_http_headers
- 2.1 - MEDIUM : server: fix possibly uninitialized
state file on close
- 2.1 - MEDIUM : connection: Continue to recv data to a
pipe when the FD is not ready
- 2.1 - MEDIUM : lists: add missing store barrier on
MT_LIST_BEHEAD()
- 2.0, 2.1 - MEDIUM : mux-h1: Wakeup the H1C in h1_rcv_buf()
if more data are expected
- 2.1 - MEDIUM : pattern: fix thread safety of pattern
matching
- 2.1 - MEDIUM : ssl: crt-list must continue parsing on
ERR_WARN
- 2.1 - MEDIUM : fetch: Fix hdr_ip misparsing IPv4
addresses due to missing NUL
- 2.1 - MEDIUM : log: don't hold the log lock during
writev() on a file descriptor
- 2.1 - MEDIUM : lists: add missing store barrier in
MT_LIST_ADD/MT_LIST_ADDQ
- 2.1 - MEDIUM : log: issue mixing sampled to not
sampled log servers.
- 2.1, 2.2 - MINOR : mux-fcgi: Don't url-decode the
QUERY_STRING parameter anymore
- 2.1 - MINOR : http: make smp_fetch_body() report
that the contents may change
- 2.1 - MINOR : http_ana: clarify connection pointer
check on L7 retry
- 2.1 - MINOR : mworker/cli: fix semicolon escaping in
master CLI
- 2.1 - MINOR : ssl: fix ssl-{min,max}-ver with
openssl < 1.1.0
- 2.1 - MINOR : mux-h1: Disable splicing only if input
data was processed
- 2.1 - MINOR : cli: allow space escaping on the CLI
- 2.1 - MINOR : http_act: don't check capture id in
backend (2)
- 2.1 - MINOR : spoe: add missing key length check
before checking key names
- 2.1 - MINOR : spoe: correction of setting bits for
analyzer
- 2.1 - MINOR : systemd: Wait for network to be online
- 2.1 - MINOR : proxy: always initialize the trash in
show servers state
- 2.1 - MINOR : proxy: fix dump_server_state()'s
misuse of the trash
- 2.1 - MINOR : mux-h1: Fix the splicing in TUNNEL mode
- 2.0, 2.1, 2.2 - MINOR :
missing date() fetcher in lua api in haproxy 2.2
In earlier versions of haproxy, the txn.f object had a `date()` method when
called from a fetch context which returned the current unix timestamp. In
HAproxy 2.2, this method is removed.
The `date()` fetch is still documented and works fine from bare haproxy
config, so I'm not sure why Lua can't hit it.
For a minimal reproducer, stick the following in "helpers.lua":
core.register_fetches("date_wrapper", function(txn)
core.Debug("fetching r_u_i\n")
local date = txn.f:date()
core.Debug(string.format("current date is %d", date))
return string.format("%08x", date)
end)
Then run the following haproxy config:
global
maxconn 65536
lua-load "helpers.lua"
hard-stop-after 30m
defaults
timeout server 10s
timeout client 10s
timeout connect 1s
frontend test_fe
mode http
bind 127.0.0.1:9993
http-response add-header Lua-Fetch %[lua.date_wrapper]
http-response add-header Regular-Fetch %[date]
default_backend test_be
backend test_be
mode http
server localhost 127.0.0.1:9992
This will work fine in haproxy 2.0.x (didn't test 2.1.x yet) and will fail
with "Lua sample-fetch 'date_wrapper': runtime error: helpers.lua:3:
attempt to call a nil value (method 'date') from helpers.lua:3 C function
line 1" on haproxy 2.2.x.
My best guess is that this is related to ae6f125c
but
I don't really understand how sample fetchers are mapped into the Lua API,
so this is just a guess. Is it possible that two-optional-argument sample
fetchers just don't work?
I can work around this by doing `os.time()` but I'd just as soon be reusing
haproxy's unix timestamp rather than doing another system call, and afaik
os.time() isn't portably guaranteed to be a unix timestamp or to be in UTC.
Unrelatedly: the "Lua reference manual" linked in the documentation
z` (
http://www.arpalert.org/src/haproxy-lua-api/2.0dev/index.html) is now a
403. I believe the correct URL is
https://www.arpalert.org/src/haproxy-lua-api/2.2dev/index.html.
--
James Brown
Engineer
Re: SRV records resolution failure if Authority section is present
On Tue, Jul 28, 2020 at 2:59 PM Jerome Magnin wrote: > Hi, > > On Sun, Jul 26, 2020 at 10:41:18PM +0200, Willy Tarreau wrote: > > Thanks Jérôme, > > > > CCing Baptiste for approval (in case we've missed anything, I'm clueless > > about DNS). > > > > Baptiste just reviewed my patch, made a couple suggestions, so please > find an update attached to this email. > Hi, Patch approved :) Thx again Jerome ! Baptiste
Re: SRV records resolution failure if Authority section is present
Hi,
On Sun, Jul 26, 2020 at 10:41:18PM +0200, Willy Tarreau wrote:
> Thanks Jérôme,
>
> CCing Baptiste for approval (in case we've missed anything, I'm clueless
> about DNS).
>
Baptiste just reviewed my patch, made a couple suggestions, so please
find an update attached to this email.
>From db0198a29ab493796414033b8fb11661e91d0bee Mon Sep 17 00:00:00 2001
From: Jerome Magnin
Date: Sun, 26 Jul 2020 12:13:12 +0200
Subject: [PATCH] BUG/MAJOR: dns: don't treat Authority records as an error
Support for DNS Service Discovery by means of SRV records was enhanced with
commit 13a9232eb ("MEDIUM: dns: use Additional records from SRV responses")
to use the content of the answers Additional records when present.
If there are Authority records before the Additional records we mistakenly
treat that as an invalid response. To fix this, just ignore the Authority
section if it exist and skip to the Additional records.
As 13a9232eb was introduced during 2.2-dev, it must be backported to 2.2.
This is a fix for issue #778
---
src/dns.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/dns.c b/src/dns.c
index 6a8ab831c..613d7308f 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -1043,6 +1043,35 @@ static int dns_validate_dns_response(unsigned char
*resp, unsigned char *bufend,
/* now parsing additional records for SRV queries only */
if (dns_query->type != DNS_RTYPE_SRV)
goto skip_parsing_additional_records;
+
+ /* if we find Authority records, just skip them */
+ for (i = 0; i < dns_p->header.nscount; i++) {
+ offset = 0;
+ len = dns_read_name(resp, bufend, reader, tmpname,
DNS_MAX_NAME_SIZE,
+ , 0);
+ if (len == 0)
+ continue;
+
+
+ if (reader + offset + 10 >= bufend)
+ goto invalid_resp;
+
+ reader += offset;
+ /* skip 2 bytes for class */
+ reader += 2;
+ /* skip 2 bytes for type */
+ reader += 2;
+ /* skip 4 bytes for ttl */
+ reader += 4;
+ /* read data len */
+ len = reader[0] * 256 + reader[1];
+ reader += 2;
+
+ if (reader + len >= bufend)
+ goto invalid_resp;
+
+ reader += len;
+ }
nb_saved_records = 0;
for (i = 0; i < dns_p->header.arcount; i++) {
--
2.27.0
Re: [PATCH] BUG/MAJOR: dns: fix null pointer dereference in snr_update_srv_status
Hi Jerome, Thanks a lot for the debugging and the fix. This is all good and can be applied. Baptiste On Tue, Jul 28, 2020 at 2:09 PM Jerome Magnin wrote: > Hi, > > this is a patch for issue #775. > > -- > Jérôme >
[PATCH] BUG/MAJOR: dns: fix null pointer dereference in snr_update_srv_status
Hi,
this is a patch for issue #775.
--
Jérôme
>From 68e8b71c50d0805faf5facba587f1c8c3f1760b7 Mon Sep 17 00:00:00 2001
From: Jerome Magnin
Date: Tue, 28 Jul 2020 13:38:22 +0200
Subject: [PATCH] BUG/MAJOR: dns: fix null pointer dereference in
snr_update_srv_status
Since commit 13a9232eb ("MEDIUM: dns: use Additional records from SRV
responses"), a struct server can have a NULL dns_requester->resolution,
when SRV records are used and DNS answers contain an Additional section.
This is a problem when we call snr_update_srv_status() because it does
not check that resolution is NULL, and dereferences it. This patch
simply adds a test for resolution being NULL. When that happens, it means
we are using SRV records with Additional records, and an entry was removed.
This should fix issue #775.
This should be backported to 2.2.
---
src/server.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/server.c b/src/server.c
index a622e22bd..918294b2f 100644
--- a/src/server.c
+++ b/src/server.c
@@ -3731,6 +3731,15 @@ int snr_update_srv_status(struct server *s, int
has_no_ip)
struct dns_resolution *resolution = s->dns_requester->resolution;
int exp;
+ /* If resolution is NULL we're dealing with SRV records Additional
records */
+ if (resolution == NULL) {
+ if (s->next_admin & SRV_ADMF_RMAINT)
+ return 1;
+
+ srv_set_admin_flag(s, SRV_ADMF_RMAINT, "entry removed from SRV
record");
+ return 0;
+ }
+
switch (resolution->status) {
case RSLV_STATUS_NONE:
/* status when HAProxy has just (re)started.
--
2.27.0
