Re: Running multiple instances of pflogd

2022-06-03 Thread Pantelis Roditis
On Fri, Jun 3, 2022 at 12:57 PM Stuart Henderson
 wrote:
>
> On 2022-06-02, Mike Fischer  wrote:
> > I think the issue is more general. It applies whenever multiple
> > instances of any service are needed.
> >
> > I have a similar issue with php_fpm which I am using in multiple PHP
> > versions and with different settings (chroot(2) for httpd(8) or without
> > chroot(2) for Apache httpd).
>
> With php-fpm it's a bit awkward to handle, because it doesn't include
> all the flags in the process name, but just the config filename, so the
> rc.d script would need to parse the flags itself, it's possible but it
> makes things more complex/fragile.

Yes I agree its a bit different than the pflog case mostly because pflogd is on
by default. Also, for packages these complexities can be addressed by their
pkg readmes.

Maybe addressing that on pflogd(8) is also an option?

> ...so I'd prefer to keep php-fpm like it is, unless I'm missing some big
> benefit of running multiple main processes of the same version. (Big benefit
> of running a single version is that you don't need to restart each daemon
> separately after updates).

The only big downside to that is that php-fpm has a really bad history
at handling these
sorts of things and even though it is supported my advice would be if
you can afford
having a separate process you'll be somewhat safer. I think there was
even a recent
bug which was present in this shared setup scenario described. I know
this was also
a case since php5. I have adapted to use separate processes for each of my
chroots as a precaution. It has its administrative overhead, but its a
good tradeoff.

> There's another case, where somebody runs two copies of pflogd, one from
> the default rc.d script, one standalone by running pflogd directly. So,
> it probably would be helpful if the dedault rc.d script was more targetted.

We could use a pkill command similar to the one used in newsyslog.conf
to limit the
extent of that, something like `-u root -U root -t - -x` to address
the direct invocation
cases?



Re: Running multiple instances of pflogd

2022-06-03 Thread Pantelis Roditis
Hi Stuart,

(i was trying to figure out a way to reply without messing up the line
wraps, so sorry in advance if lines get messed by google)

On Fri, Jun 3, 2022 at 1:08 PM Stuart Henderson
 wrote:
>
> On 2022-06-02, Pantelis Roditis  wrote:
> > However, the default pflogd does not start with any flags set, so in
> > order to make this work I had to either set the flags for pflogd
> >
> > rcctl set pflogd flags -s 160 -i pflog0 -f /var/log/pflog
> >
> > or add something like this to /etc/rc.d/pflogd
> >
> >: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
> > pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
>
> hmm, so it constructs the process title based on the variables which are
> set, rather than the actual supplied command line.

Yes, this was the way the process title was constructed for when the
daemon starts without options on rc.conf.local
But its not optimal I admit, tbh I didnt like either of the options.
I was more hoping for a discussion that will lead to a better solution.

>
> $ rcctl get pflogd flags
> -s 256
> $ pgrep -lf pflog
> 40896 pflogd: [running] -s 256 -i pflog0 -f /var/log/pflog
> 46762 pflogd: [priv]
>
> That's a bit annoying and will get in the way of fixing this properly.
> Maybe we need some changes to how pflogd sets the process title as well.

Yes, I noticed that as well, and the order is also important as pflogd
will change it.
foo# pflogd -i pflog0 -s 200
foo# ps -axw|grep pflogd
58030 ??  Spc  0:00.00 pflogd: [running] -s 200 -i pflog0 -f
/var/log/pflog (pflogd)

My initial idea for it was that a pid file could resolve this, but as
it was explained to me, it's something we're trying to move away from,
as this will introduce a different set of problems.
So modifying the rc script seemed a better place to start.
However, if the process title is up for discussion I'll take a look
and see if any ideas come up.



Running multiple instances of pflogd

2022-06-02 Thread Pantelis Roditis
Hi everyone,

I recently started running multiple pflogd instances and noticed that
/etc/rc.d/pflogd killed/restarted every running instance.
The same happened from newsyslog rotations as well.

After suggestions by brynet, sthen and ajacoutot (thank you guys)
I updated pexp to use a combination of `[running]` and `daemon_flags`

pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"

However, the default pflogd does not start with any flags set, so in
order to make this work I had to either set the flags for pflogd

rcctl set pflogd flags -s 160 -i pflog0 -f /var/log/pflog

or add something like this to /etc/rc.d/pflogd

: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"

It was suggested by stehn that a diff may worth submitting, but i dont
know which of the two options is preferred, if any

In the first case we have to set flags for pflogd which no other base
daemon does at the moment, other than maybe amd_master?

In the second case we set default flags inside the rc script and this
introduces an unnecessary dependency to update this script whenever the
default flags or their order changes.

These changes are only needed for when someone needs to run more than
one instance of pflogd, in which case they will have to copy the
default /etc/rc.d/pflogd and/or modify it anyways (e.g. for the interface
name in rc_pre).

The diff for the script follows, suggestions/ideas are more than welcome

diff --git etc/rc.d/pflogd etc/rc.d/pflogd
index 963616775..620d2daef 100644
--- etc/rc.d/pflogd
+++ etc/rc.d/pflogd
@@ -6,7 +6,9 @@ daemon="/sbin/pflogd"

 . /etc/rc.d/rc.subr

-pexp="pflogd: \[priv\]"
+: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
+
+pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"

 rc_pre() {

if pfctl -si | grep -q Enabled; then



Re: Adding zombies to a pf table?

2015-09-24 Thread Pantelis Roditis

On 09/24/2015 11:39 AM, Peter Hessler wrote:

On 2015 Sep 23 (Wed) at 18:14:51 +0100 (+0100), Craig Skinner wrote:
:Hello,
:
:Zombies are often attacking ports which don't have services running,
:such as telnet (most popular indeed), mysql, 3551, 8080, 13272, etc.



Hi,

This is the exact reason why we created bofh-divert[1]. The idea is that 
you pass those packets with PF to a divert socket opened by a daemon. 
The daemon grabs the source IP and adds it to a predefined table.


The rules look something like this

-- pf.conf snip --

table  persist counters

block in log quick from 

pass in log quick on { egress } inet proto tcp from ! to port { 
3389, 5900, 6001, 8080,  } divert-packet port 1100 no state


-- pf.conf snip --

We have used this on some of our firewalls for some time now without 
problems.



I've been playing with this, too.  Overload won't work until the packet
is processed by a userland process.

:Or is there something handy in ports to help?
:

I don't know of any, but I have such a thing on my TODO.



The port[2] is under cleanup/testing and will be submitted for review soon.

I hope this is close to what you guys were looking for.


[1] https://github.com/echothrust/pf-diverters
[2] https://github.com/echothrust/OpenBSD-ports-mystuff



Re: Adding zombies to a pf table?

2015-09-24 Thread Pantelis Roditis

On 09/24/2015 12:48 PM, Peter Hessler wrote:

On 2015 Sep 24 (Thu) at 12:37:03 +0300 (+0300), Pantelis Roditis wrote:
:On 09/24/2015 11:39 AM, Peter Hessler wrote:
:>On 2015 Sep 23 (Wed) at 18:14:51 +0100 (+0100), Craig Skinner wrote:
:>:Hello,
:>:
:>:Zombies are often attacking ports which don't have services running,
:>:such as telnet (most popular indeed), mysql, 3551, 8080, 13272, etc.
:>

[..]

:
:[1] https://github.com/echothrust/pf-diverters
:[2] https://github.com/echothrust/OpenBSD-ports-mystuff
:

Yes, this looks very close to what I had in mind.

Main comment: looks like no IPv6 support.



I know, unfortunately my familiarity with anything IPv6 is close to 0. 
However it shouldn’t be too hard to add the support. If anyone is 
interested in taking the task I am happy to accept pull requests or patches.




Re: bug in rdomain together with kernel pppoe

2015-04-07 Thread Pantelis Roditis

On 29/03/2015 13:56, Holger Glaess wrote:

Am 24.03.2015 um 05:41 schrieb Holger Glaess:

hi

i play a little bit with rdomain

if add my pppoe device to rdomain 1

# cat /etc/hostname.pppoe0
rdomain 1
rtlabel netcologne
inet6 autoconf
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'foo@bar' authkey 'xyz' up
dest 0.0.0.1
!/sbin/route -T 1 add default -ifp pppoe0 0.0.0.1
!/sbin/route -T 1 add -inet6 default -ifp pppoe0 ::0.0.0.1



the pf lines

pass in on $lan_if from any to $myserver rtable 1
pass in on rdomain 1  proto tcp from allow_ssh to ($nc_pppoe:0) 
port 22 rdr-to 192.168.131.250 port 22 rtable 0

match out on $nc_pppoe nat-to ($nc_pppoe:0)



so , all works fine but if i connect to the system by ssh and do , 
for example , an tcpdump -n- r /var/log/pflog

the whole machine crash to an kernel panik.

this is reproducable and , looks like , just when you have an inbound 
connection ( rdr ) .



the kernel-pppoe works well inside the rdomain he discover properly 
the ip4 and the ip6 address.


Holger




# dmesg | more
OpenBSD 5.6-stable (GENERIC.MP) #5: Thu Jan  8 16:16:33 CET 2015
root@DAF.rocki.intern:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 
1.80 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

real mem  = 3208736768 (3060MB)
avail mem = 3143852032 (2998MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/22/10, BIOS32 rev. 0 @ 
0xf0010, SMBIOS rev. 2.6 @ 0xfbe90 (22 entries)
bios0: vendor American Megatrends Inc. version 080016 date 
12/22/2010

bios0: ZOTAC ATOM D525
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI
acpi0: wakeup devices P0P1(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) 
P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) EUSB(S3) 
SLPB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=22785, max=32960
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 
1.80 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 
1.80 GHz
cpu2: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (GenuineIntel 686-class) 
1.80 GHz
cpu3: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF

ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus 3 (P0P6)
acpiprt5 at acpi0: bus 4 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
bios0: ROM list: 0xc/0xda00! 0xce000/0x3000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02
vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x720
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel Pineview Video rev 0x02 at pci0 dev 2 function 1 not 
configured
azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: 
msi

azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 
int 16

pci1 at ppb0 bus 1
jmb0 at pci1 dev 0 function 0 JMicron JMB363 IDE/SATA rev 0x03
ahci0 at jmb0: apic 4 int 16, AHCI 1.0
scsibus1 at ahci0: 32 targets
pciide0 at jmb0: DMA, channel 0 wired to native-PCI, channel 1 wired 
to native-PCI

pciide0: using apic 4 int 16 for native-PCI interrupt
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
ppb1 at pci0