16
23.7 Legacy Series / Re: /nonexistent
« on: January 04, 2024, 01:44:07 pm »
> actually exist or not?
Not
Not
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
pattern: '%{IP:client_ip}:%{INT:client_port} \[%{HAPROXYDATE:accept_date}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} (\{%{HAPROXYCAPTUREDREQUESTHEADERS}\})?( )?(\{%{HAPROXYCAPTUREDRESPONSEHEADERS}\})?( )?"(<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://)?(?:%{USER:http_user}(?::[^@]*)?@)?(?:%{URIHOST:http_host})?(?:%{URIPATHPARAM:http_request})?( HTTP/%{NUMBER:http_version})?))?"'
pfctl -s rules | grep crowd
block drop in quick inet from <crowdsec_blacklists> to any label "6fc904ee8f33bb90e1c73147d55cd852"
block drop in quick inet6 from <crowdsec6_blacklists> to any label "7de971956cb806447b5f10bdb3d4d9bb"
cscli collections install crowdsecurity/haproxy
filenames:
- /var/log/haproxy/latest.log
force_inotify: true
poll_without_inotify: true
labels:
type: syslog
grep hap /var/log/crowdsec/crowdsec.log
cscli metrics | grep haproxy
pfctl -s rules | grep crowd
block drop in quick inet from <crowdsec_blacklists> to any label "6fc904ee8f33bb90e1c73147d55cd852"
block drop in quick inet6 from <crowdsec6_blacklists> to any label "7de971956cb806447b5f10bdb3d4d9bb"
As of 2.3.1, PTPd still does not support hardware timestamping. This
functionality will appear in the upcoming version 2.4 - potentially an
interim version of 2.3.x may be delivered that will support hardware
clocks and timestamping on Linux. This is very much OS-specific and to
a large extent, hardware-specific. Linux has a PTP kernel API but not
all hardware supports it. Because PTPd supports multiple OS platforms,
where hardware timestamping may use different mechanisms on every plat-
form, it has to be re-written in a modular way to allow this without
unnecessarily increasing code complexity, which already is a problem.
em0: <Intel(R) PRO/1000 Network Connection 7.7.8> port 0xe000-0xe01f mem 0xf7b40000-0xf7b5ffff,0xf7b60000-0xf7b63fff irq 16 at device 0.0 on pci1
em0: Insufficient MSIX vectors, using MSI
em0: Using an MSI interrupt
and yes this is a new block to me.. but obviously used. So no 1723 incoming..
dig +short @36.91.138.130 www.google.com
64.233.170.147
64.233.170.104
64.233.170.99
64.233.170.103
64.233.170.106
64.233.170.105
dig +short @201.184.117.60 www.google.com
142.250.78.164
dig +short @111.70.2.171 www.google.com
142.251.42.228
08:36:35.176707 IP 111.222.333.444 > 36.91.138.130: ICMP 111.222.333.444 udp port 1723 unreachable, length 576
"An attacker wants to know whether the target has an open port, so it sends a spoofed UDP message from the authoritative server to that port. If the port is open, no ICMP reply is sent and the rate counter remains unchanged. If the port is inaccessible, then an ICMP reply is sent (back to the authoritative server, not to the attacker) and the rate is increased by one. Although the attacker doesn’t see the ICMP response, it has influenced the counter. The counter itself isn’t known outside the server, but whether it has hit the rate limit or not can be measured by any outside observer by sending a UDP packet and waiting for a reply. If an ICMP “port unreachable” reply comes back, the rate limit hasn’t been reached. No reply means the rate limit has been met. This leaks one bit of information about the counter to the outside observer, which in the end is enough to reveal the supposedly secret information (whether the spoofed request got through or not)."