Re: Looking for a way to deal with unwanted HTTP requests using mod_perl

[Patrick Dohman]

At the risk of sounding last decade…

Sourcing a scanner that attempts to illustrates the goals of an attacker could
make for a worthwhile project.

As an aside a postfix version really ought to exist with it’s myriad of
status codes.

Regards
Patrick


> On Sep 28, 2016, at 9:04 PM, Chris Bennett
 wrote:
>
> On Wed, Sep 28, 2016 at 08:54:14PM -0400, trondd wrote:
>> On Wed, September 28, 2016 1:20 pm, Chris Bennett wrote:
>>>
>>> Right now I am using a simple script from the error log to block
>>> permanently any requests from that IP using OpenBSD pf.
>>>
>>> That simply doesn't work well enough anymore due to the time lag between
>>> 20+ requests at once getting to the log file.
>>
>> I use a combination of overload in pf with a bruteforce table and log
>> parsing.  I don't currently do the log parsing in real time.  You could
>> use your own script or something like fail2ban for that.  The combination
>> will quickly lock out rapid connection attempts, while eventually also
>> getting the slow pokes.
>
> I don't think bruteforce will be helpful in my case. I do occasionally
> get bruteforce attacks, but not very often.
> What I usually get are identical attacks of a certain set of variations
> of URLs from one IP address. A little later the same thing from another
> IP, then another, etc.
>
> One of the reasons I am thinking of a mod_perl solution is that mod_perl
> can step in very early in the Apache process. All kinds of things can be
> done long before normal access is available to other processes.
> But I have no experience using any of these parts of mod_perl. I have
> only used later functions in the cycle.
>
>>
>>> Plus, I
>>> occasionally screw up and block my own IP address so I keep an SSH
>>> session open before experimenting.
>>>
>>
>> Create a "safe" table in pf and put your often used IPs in it (assuming
>> they are static enough for this) and match that before you check the
>> bruteforce table.  Also, your rules and tables for ssh can be different
>> than that of the web server.  No reason for accidentally going to a bad
>> URL to lock you out of ssh.
>>
>
> Thanks, I hadn't thought of that. Some of my IPs are static. But I also
> travel a lot between parts of Mexico and Texas. But I will add to pf for
> that. I can add hotel IPs, when their WiFi signal is actually
> strong enough to connect. That should solve that problem.
>
> For the list, the rest is me rambling on so don't bother reading any
> further, is OT.
>
>
> I can develop on my office/home systems, but some stuff I use requires
> live testing since I don't have another production server. Live testing
> since my software depends on what is sent from another company and then
> processing on my server followed by an email customised for a customer
> to access paid content on my server. I can fake the input to a certain
> degree, but I had one customer a while ago request a refund before
> getting a username/password from my end, so that input was unexpected
> and did not follow the other company's documentation, which is of poor
> quality, so I had to fix a problem that was unexpected and basically
> undocumented.
>
>
> Thanks. Very useful for my SSH problem.
> Chris Bennett

Re: Looking for a way to deal with unwanted HTTP requests using mod_perl

[Chris Bennett]

On Wed, Sep 28, 2016 at 08:54:14PM -0400, trondd wrote:
> On Wed, September 28, 2016 1:20 pm, Chris Bennett wrote:
> >
> > Right now I am using a simple script from the error log to block
> > permanently any requests from that IP using OpenBSD pf.
> >
> > That simply doesn't work well enough anymore due to the time lag between
> > 20+ requests at once getting to the log file.
> 
> I use a combination of overload in pf with a bruteforce table and log
> parsing.  I don't currently do the log parsing in real time.  You could
> use your own script or something like fail2ban for that.  The combination
> will quickly lock out rapid connection attempts, while eventually also
> getting the slow pokes.

I don't think bruteforce will be helpful in my case. I do occasionally
get bruteforce attacks, but not very often.
What I usually get are identical attacks of a certain set of variations
of URLs from one IP address. A little later the same thing from another
IP, then another, etc.

One of the reasons I am thinking of a mod_perl solution is that mod_perl
can step in very early in the Apache process. All kinds of things can be
done long before normal access is available to other processes.
But I have no experience using any of these parts of mod_perl. I have
only used later functions in the cycle.

> 
> > Plus, I
> > occasionally screw up and block my own IP address so I keep an SSH
> > session open before experimenting.
> >
> 
> Create a "safe" table in pf and put your often used IPs in it (assuming
> they are static enough for this) and match that before you check the
> bruteforce table.  Also, your rules and tables for ssh can be different
> than that of the web server.  No reason for accidentally going to a bad
> URL to lock you out of ssh.
> 

Thanks, I hadn't thought of that. Some of my IPs are static. But I also
travel a lot between parts of Mexico and Texas. But I will add to pf for
that. I can add hotel IPs, when their WiFi signal is actually
strong enough to connect. That should solve that problem.

For the list, the rest is me rambling on so don't bother reading any
further, is OT.


I can develop on my office/home systems, but some stuff I use requires
live testing since I don't have another production server. Live testing
since my software depends on what is sent from another company and then
processing on my server followed by an email customised for a customer
to access paid content on my server. I can fake the input to a certain
degree, but I had one customer a while ago request a refund before
getting a username/password from my end, so that input was unexpected
and did not follow the other company's documentation, which is of poor
quality, so I had to fix a problem that was unexpected and basically
undocumented.


Thanks. Very useful for my SSH problem.
Chris Bennett

Re: tfdpd doesn't deliver pxeboot file

[Sean Kamath]

I’ve been working on transitioning to an all Alix 2d13 environment for my
home set up.  Using 6.0 base, I had no problems with PXE (DHCP or tftp) on my
Alix 2d13 machine.  The server in this case is running on a MacBook Pro with
VMware Fusion with a (just freshly built) 6.0 (Stable) install.  Despite the
bizarre setup (using the ethernet port of the Mac as a secondary interface to
the VM and using a primary interface that’s NATed out the wireless port of
the Mac), it Just Worked(tm).

So, i KNOW OBSD6.0 will provide PXE for an Alix 2d13.  The only part I don’t
know is if an Alix 3x can be a server.   But I don’t see why it couldn’t.

Sean

> On Sep 28, 2016, at 5:29 AM, Peer Janssen  wrote:
>
> Am 28.09.2016 um 13:27 schrieb Solène Rapenne:
>> Le 2016-09-28 12:45, Peer Janssen a écrit :
>>> TFTP pxeboot requests:
>>>
>>> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ
>>> "pxeboot"
>>>  : 4500 0034 0002  1411 24ea c0a8 0051  E..4..$Q
>>>  0010: c0a8 002c 0816 0045 0020 f181 0001 7078  ...,...E. px
>>>  0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a  eboot.octet.tsiz
>>>  0030: 6500 3000e.0.
>>
>> The TFTP request from alix asks for a binary transfer
>>
>>> As a comparison, the reaction against the RRQ from the linux box:
>>>
>>> 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19
>>> RRQ "pxeboot" (DF)
>>>  : 4500 002f eca9 4000 4011 cc78 c0a8 001f  E../..@.@..x
>>>  0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078  ...,.@.E..u...px
>>>  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.
>>>
>>>
>>
>> The TFTP request from your linux box asks for an ascii transfer
>>
>> There is a difference between the 2 tftp transfers that may explain
>> your problem
>>
>> Can you try the cli tftp and type "binary" before "get pxeboot" ?
>>
>> like the following :
>>
>> tftp 192.168.0.44
>> tftp> binary
>> tftp> get pxeboot
>>
>
> Good idea.
> This works fine. As well as with "localhost".
>
> # tftp localhost
> tftp> binary
> tftp> get pxeboot
> Received 81444 bytes in 0.0 seconds
> tftp> ascii
> tftp> get pxeboot
> Received 81965 bytes in 0.1 seconds
> tftp> #
>
> 13:54:47.936070 localhost.23896 > localhost.tftp: [udp sum ok] 16 RRQ
> "pxeboot" (ttl 64, id 51686, len 44)
>  : 4500 002c c9e6  4011 b2d8 7f00 0001  E..,@...
>  0010: 7f00 0001 5d58 0045 0018 9309 0001 7078  ]X.E..px
>  0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet.
>
> 13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ
> "pxeboot" (ttl 64, id 50915, len 47)
>  : 4500 002f c6e3  4011 b5d8 7f00 0001  E../@...
>  0010: 7f00 0001 5d58 0045 001b 2b39 0001 7078  ]X.E..+9..px
>  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.
>
> # tftp 192.168.0.44
> tftp> binary
> tftp> get pxeboot
> Received 81444 bytes in 0.0 seconds
> tftp> ascii
> tftp> get pxeboot
> Received 81965 bytes in 0.1 seconds
> tftp> #
>
> 13:55:11.780098 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok]
> 16 RRQ "pxeboot" (ttl 64, id 50778, len 44)
>  : 4500 002c c65a  4011 32be c0a8 002c  E..,.Z..@.2,
>  0010: c0a8 002c 810e 0045 0018 ebac 0001 7078  ...,...E..px
>  0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet.
>
> 13:55:18.738183 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok]
> 19 RRQ "pxeboot" (ttl 64, id 51568, len 47)
>  : 4500 002f c970  4011 2fa5 c0a8 002c  E../.p..@./,
>  0010: c0a8 002c 810e 0045 001b 83dc 0001 7078  ...,...E..px
>  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.
>
>
> Maybe the additional options which the alix target (at IP .81) sends are
> what the server does not like.There we had:
>
> 12:16:05.039971 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
>
>  : 4500 0034 0006  1411 24e6 c0a8 0051  E..4..$Q
>  0010: c0a8 002c 081a 0045 0020 f17d 0001 7078  ...,...E. .}..px
>  0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a  eboot.octet.tsiz
>  0030: 6500 3000e.0.
>
> 12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
>  : 4500 0039 0007  1411 24e0 c0a8 0051  E..9..$Q
>  0010: c0a8 002c 081b 0045 0025 619c 0001 7078  ...,...E.%a...px
>  0020: 6562 6f6f 7400 6f63 7465 7400 626c 6b73  eboot.octet.blks
>  0030: 697a 6500 3134 3536 00   ize.1456.
>
> =>
>
> Could it be that OpenBSD6.0's tftpd refuses to serve a binary tftp RRQ with
> tsize 0 or blksize 1456?
>
> Is there a way to tell the target how to build it's pxeboot request (maybe
> some dhcpd option which will get sent to it)?
>
> Peer
>
>
> --
> Peer Janssen - p...@pjk.de

Re: Looking for a way to deal with unwanted HTTP requests using mod_perl

[trondd]

On Wed, September 28, 2016 1:20 pm, Chris Bennett wrote:
>
> Right now I am using a simple script from the error log to block
> permanently any requests from that IP using OpenBSD pf.
>
> That simply doesn't work well enough anymore due to the time lag between
> 20+ requests at once getting to the log file.

I use a combination of overload in pf with a bruteforce table and log
parsing.  I don't currently do the log parsing in real time.  You could
use your own script or something like fail2ban for that.  The combination
will quickly lock out rapid connection attempts, while eventually also
getting the slow pokes.

> Plus, I
> occasionally screw up and block my own IP address so I keep an SSH
> session open before experimenting.
>

Create a "safe" table in pf and put your often used IPs in it (assuming
they are static enough for this) and match that before you check the
bruteforce table.  Also, your rules and tables for ssh can be different
than that of the web server.  No reason for accidentally going to a bad
URL to lock you out of ssh.

Tim.

Re: login.conf processing by /etc/rc

[Evgeny Grin]

On 28.09.2016 21:33, Evgeny Grin wrote:
> Hi!
> 
> I configured freshly installed OpenBSD 6.0-release with kern.maxfiles=131072
> in /etc/sysctl.conf
> and
> :openfiles-max=40960:openfiles-cur=40960:
> for daemon in /etc/login.conf
> 
> And each boot I see message
> kern.maxfiles: 7030 -> 1
> /etc/rc: ulimit: bad -n limit: Invalid argument


Hmm.. Only half of message is delivered.
Continuation:

And at each boot I see message:
kern.maxfiles: 7030 -> 131072
/etc/rc: ulimit: bad -n limit: Invalid argument

I looked at /etc/rc and found that script at first step call 'ulimit -S
-n ' for value found for '-cur' and at second step call 'ulimit -H -n '
for value found for '-max'. That is incorrect as soft limit can't be set
to higher value than hard limit. Moreover, I can't just use
":openfiles=40960:" for daemon class because "default" class has both
"-max" and "-cur" values - as result: at first step "40960" used for
both hard and soft limit, but immediately lowered by using "-cur" and
"-max" values from "default" class (getcap return them for "daemon"
class as well).

As current workaround I use

:openfiles=40960:openfiles-max=40960:openfiles-cur=40960:

but it is not really elegant solution.


I this that at least order of suffix checking in /etc/rc must be changed
from
"for _suffix in {,-cur,-max}; do"
to
"for _suffix in {,-max,-cur}; do"


Am I right? Or I missed something?

-
Evgeny

login.conf processing by /etc/rc

[Evgeny Grin]

Hi!

I configured freshly installed OpenBSD 6.0-release with

kern.maxfiles=131072

in /etc/sysctl.conf
and

:openfiles-max=40960:openfiles-cur=40960:

for daemon in /etc/login.conf

And at each boot I see message:
kern.maxfiles: 7030 -> 131072
/etc/rc: ulimit: bad -n limit: Invalid argument

I looked at /etc/rc and found that script at first step call 'ulimit -S
-n ' for value found for '-cur' and at second step call 'ulimit -H -n '
for value found for '-max'. That is incorrect as soft limit can't be set
to higher value than hard limit. Moreover, I can't just use
":openfiles=40960:" for daemon class because "default" class has both
"-max" and "-cur" values - as result: at first step "40960" used for
both hard and soft limit, but immediately lowered by using "-cur" and
"-max" values from "default" class (getcap return them for "daemon"
class as well).

As current workaround I use

:openfiles=40960:openfiles-max=40960:openfiles-cur=40960:

but it is not really elegant solution.


I this that at least order of suffix checking in /etc/rc must be changed
from
"for _suffix in {,-cur,-max}; do"
to
"for _suffix in {,-max,-cur}; do"


Am I right? Or I missed something?

-- 
Best Wishes,
Evgeny Grin

Re: Opinion about pflog

[Peter N. M. Hansteen]

On 09/28/16 22:25, Walter Alejandro Iglesias wrote:
> I'm about to run my own web server using OpenBSD.  I'm giving my first
> steps with pf.  I was very enthusiastic till I got to this point:
> 
> https://www.openbsd.org/faq/pf/logging.html
> 
> It says:
> 
> The log file written by pflogd is in binary format and cannot be
> read using a text editor.
> 
> So, *binary* logs.  Sounds familiar to me.  And then:

I hope this doesn't discourage you too much.

While I don't have the privilege of reading the developers' minds, there
are a few practical considerations that help make the binary logging
understandable as the default configuration.

One is that firewalls are not necessarily the most capable pieces of
hardware you could put your hands on. Decoding every single packet to
text and writing to syslog or even to console could in itself add
significantly to the load on the system.

I hadn't thought of those incidents for several years, but while writing
this I remember some episodes involving Linux-based firewalls that did
log every packet, decoded to readable text, to the system console and to
syslog. In slightly high-traffic situations -- not actual DDOSes by any
measure -- logging on to the system to fix whatever was not really doable.

Be that as it may, one other thing that comes to mind is that frankly,
most of the traffic is likely to be of no interest whatsoever once it's
been successfully handled according to your PF rules.

> I must confess I'm one among those "run to the hills" paranoids.  I'm
> not an expert, perhaps I'm judging pflog wrong but, anyway, I still
> prefer the traditional way, using cat, grep and tail.

Well, for for generally keeping an eye on things and not putting too
much strain on anything, setting up pflow(4) to export the metadata to
view with something like nfsen is a good option[1].

If you really want to keep a copy of all traffic, well, you need to go
for beefier hardware and set up to keep a copy of your traffic somewhere
and play with whatever combination of snort, bro and friends that fit
your needs. And yes, beefy hardware and sufficient storage will be a
requirement.

Then again, in all likelihood you will not really want to be staring at
all traffic that ever passed through all network interfaces. If and when
your chosen tools show up something you want to look into in more
detail, applying tcpdump to the binary PF logs may very well be
sufficient to find out what happened and make intelligent decisions. If
you want to keep the PF logs around for longer than the defaults, look
into the log rotation settings as your first step.

I remember having a somewhat similar reaction as yours when I first read
about the binary PF logs, but in practical terms the way it's done
actually makes sense.

- P

[1] One such setup is described, with some anecdotes just because, at
http://bsdly.blogspot.com/2014/02/yes-you-too-can-be-evil-network.html

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Opinion about pflog

[John Jasen]

On 09/28/2016 04:25 PM, Walter Alejandro Iglesias wrote:

> And this "uncommon" practice among unix system administrators (sarcasm),
> needs a "workaround".  You end with a file with a curious termination:
>
> Create the file /var/log/pflog.txt ...

You can name it pflog.log versus pflog.txt, if you wish, and the web
page provides a reference implementation to send it to syslog.

I'll note, a decently busy firewall can swamp a remote syslog server.

Re: Opinion about pflog

[Frederick W. Soucy]

On 09/28/2016 03:25 PM, Walter Alejandro Iglesias wrote:

I know complaining is useless.  Forgive me this time.

I'm about to run my own web server using OpenBSD.  I'm giving my first
steps with pf.  I was very enthusiastic till I got to this point:

https://www.openbsd.org/faq/pf/logging.html

It says:

The log file written by pflogd is in binary format and cannot be
read using a text editor.

So, *binary* logs.  Sounds familiar to me.  And then:

   In many situations it is desirable to have the firewall logs available
   in ASCII format

And this "uncommon" practice among unix system administrators (sarcasm),
needs a "workaround".  You end with a file with a curious termination:

Create the file /var/log/pflog.txt ...


I must confess I'm one among those "run to the hills" paranoids.  I'm
not an expert, perhaps I'm judging pflog wrong but, anyway, I still
prefer the traditional way, using cat, grep and tail.

if by *familiar* you are implying systemd than just stop. if you're that 
worried about binary logs you should have jumped ship from unix and 
unix-like systems decades ago. man utmp(5).

Re: Opinion about pflog

[Theo de Raadt]

> I know complaining is useless.  Forgive me this time.
> 
> I'm about to run my own web server using OpenBSD.  I'm giving my first
> steps with pf.  I was very enthusiastic till I got to this point:
> 
> https://www.openbsd.org/faq/pf/logging.html
> 
> It says:
> 
> The log file written by pflogd is in binary format and cannot be
> read using a text editor.
> 
> So, *binary* logs.  Sounds familiar to me.  And then:

Your type of person seems familiar to be me.  Undeducated *check*
opinioned *check*  Contrasting authoritatively without any education
to back it up *check*

pflog generates pcap files.  that is the DEFACTO INDUSTRY format
for packet logs, since they can be generated at extremely high speed
without decomposition, and then can be analysed later, offline, using
the pcap library with a sophisticated grammer and bpf executation
engine.

So now get lost, grow up, go learn something, and stop being a dick
comparing things you don't know anything about to other things you
don't know anything about.

There is no way to forgive people who intentionally step in the shit.

Re: Opinion about pflog

[Martin Brandenburg]

On Wed, 28 Sep 2016, Walter Alejandro Iglesias wrote:

> I know complaining is useless.  Forgive me this time.
> 
> I'm about to run my own web server using OpenBSD.  I'm giving my first
> steps with pf.  I was very enthusiastic till I got to this point:
> 
> https://www.openbsd.org/faq/pf/logging.html
> 
> It says:
> 
> The log file written by pflogd is in binary format and cannot be
> read using a text editor.
> 
> So, *binary* logs.  Sounds familiar to me.  And then:
> 
>In many situations it is desirable to have the firewall logs available
>in ASCII format
> 
> And this "uncommon" practice among unix system administrators (sarcasm),
> needs a "workaround".  You end with a file with a curious termination:
> 
> Create the file /var/log/pflog.txt ...
> 
> 
> I must confess I'm one among those "run to the hills" paranoids.  I'm
> not an expert, perhaps I'm judging pflog wrong but, anyway, I still
> prefer the traditional way, using cat, grep and tail.
> 
> 

# file /var/log/pflog
/var/log/pflog: tcpdump capture file (little-endian) - version 2.4 (OpenBSD 
PFLOG, capture length 160)

Would you rather have something convert packets to ASCII arbitrarily
throwing away `unimportant' fields?

Martin

Opinion about pflog

[Walter Alejandro Iglesias]

I know complaining is useless.  Forgive me this time.

I'm about to run my own web server using OpenBSD.  I'm giving my first
steps with pf.  I was very enthusiastic till I got to this point:

https://www.openbsd.org/faq/pf/logging.html

It says:

The log file written by pflogd is in binary format and cannot be
read using a text editor.

So, *binary* logs.  Sounds familiar to me.  And then:

   In many situations it is desirable to have the firewall logs available
   in ASCII format

And this "uncommon" practice among unix system administrators (sarcasm),
needs a "workaround".  You end with a file with a curious termination:

Create the file /var/log/pflog.txt ...


I must confess I'm one among those "run to the hills" paranoids.  I'm
not an expert, perhaps I'm judging pflog wrong but, anyway, I still
prefer the traditional way, using cat, grep and tail.

Re: What is doas doing??

[Daniel Wilkins]

On Wed, Sep 28, 2016 at 02:45:26PM +0200, Murk Fletcher wrote:
> Hi,
> 
> Anybody ever been in a similar situation?
> 
> % su
> Password:
> you are not in group wheel
> Sorry
> % groups
> wheel
> % cat /etc/doas.conf
> permit nopass keepenv :wheel
> 
> Thanks!
> 
> Murk
> 

You did remember to relog after adding yourself to wheel, right?

Re: Looking for a way to deal with unwanted HTTP requests using mod_perl

[Raul Miller]

In my opinion, the appropriate thing to do here is drop the connection
(so most clients would time out) for bad requests, along with a short
term ip "block" for stuff that becomes real problems. Not a true
block, though, but instead a fixed content "your address is being used
as a part of a hostile action, please try again later" type message in
place of legit content.

In this context, a bad request (enough to drop the connection) is a
request for a url pattern which your site does not host. To trigger
the block you'd need something more obviously malicious.

I don't think modperl is going to be able to help you with that, yet.
You (or someone else) would need to do some significant groundwork,
first.

I hope this helps (but I know it's inadequate),

Thanks,

-- 
Raul


-- 
Raul




On Wed, Sep 28, 2016 at 1:20 PM, Chris Bennett
 wrote:
> I am not sure what is appropriate, given netiqette and practicality for
> my server. I am sick of thousands of identical requests in my error log,
> plus I want to be able to look over my logs easily to find any real
> problems.
>
> Below is a copy of the question I sent to modp...@perl.apache.org
> So far they have never answered any questions I have asked.
>
>
> Right now I am using a simple script from the error log to block
> permanently any requests from that IP using OpenBSD pf.
>
> That simply doesn't work well enough anymore due to the time lag between
> 20+ requests at once getting to the log file.
>
> OpenBSD no longer uses Apache 1 so I am going to move to Apache 2 and
> study how to make the changes, so now is a great time for me to move in
> anything new that I haven't used before.
>
> Right now I have a list of regexes for attack URL's and requests for
> anything with cgi or php in them, which I don't use.
>
> At first glance, it seems to me that setting up a filter to use to block
> anything in my ever growing list seems appropriate. Right or wrong?
>
> If that's right, what should I do to these requests? I would prefer to
> not build up a set of IP addresses to block since they may be forged
> addresses and a real user might get blocked later on. Plus, I
> occasionally screw up and block my own IP address so I keep an SSH
> session open before experimenting.
>
> Or am I looking at this wrong?
> Any help appreciated.
>
> Chris Bennett

Re: PPPoE and VDSL2 with a real /29

[tech-lists]

Hi, thanks for replying

On 28/09/2016 15:20, Stuart Henderson wrote:


No baby jumbos with rl(4) so you are stuck with 1492 MTU, so you need
PF so you can do "scrub (max-mss 1440)" as described in pppoe(4)'s
"MTU/MSS ISSUES" section.


I was mistaken. These are re not rl. How does this alter things? The 
vigor 130 is jumbo-frames-capable and is running the latest uk-firmware.


Thanks again,

--
J.

Looking for a way to deal with unwanted HTTP requests using mod_perl

[Chris Bennett]

I am not sure what is appropriate, given netiqette and practicality for
my server. I am sick of thousands of identical requests in my error log,
plus I want to be able to look over my logs easily to find any real
problems.

Below is a copy of the question I sent to modp...@perl.apache.org
So far they have never answered any questions I have asked.


Right now I am using a simple script from the error log to block
permanently any requests from that IP using OpenBSD pf.

That simply doesn't work well enough anymore due to the time lag between
20+ requests at once getting to the log file.

OpenBSD no longer uses Apache 1 so I am going to move to Apache 2 and
study how to make the changes, so now is a great time for me to move in
anything new that I haven't used before.

Right now I have a list of regexes for attack URL's and requests for
anything with cgi or php in them, which I don't use.

At first glance, it seems to me that setting up a filter to use to block
anything in my ever growing list seems appropriate. Right or wrong?

If that's right, what should I do to these requests? I would prefer to
not build up a set of IP addresses to block since they may be forged
addresses and a real user might get blocked later on. Plus, I
occasionally screw up and block my own IP address so I keep an SSH
session open before experimenting.

Or am I looking at this wrong?
Any help appreciated.

Chris Bennett

Re: FDE on BeagleBone Black

[Benjamin Baier]

On Wed, 28 Sep 2016 06:48:35 +0200
"L.R. D.S."  wrote:

> Also, as a side question, I remember some discussion here on misc or tech, 
> about no 
> support for binary packages on armv7 port. Is it still right, I'll have to 
> compile 
> all by myself? I'm already feeling the pain to compile ffmpeg by myself...
Building packages is only half as bad as it used to be since the pmap and cache
improvements patches got in. I've privately started building packages since 
ports
lock just to see how far I would get with 2 BBB. Pretty far, it turns out.

Re: Route add - too many levels of symbolic links

[Jeremy Evans]

On Wed, Sep 28, 2016 at 2:09 AM, Bryan Linton  wrote:

> On 2016-09-27 20:00:04, Dekker  wrote:
> > I have started encountering a wierd problem with my OpenBSD Laptop
> > Running 6.0 Current (latest snapshot 25.09.2016)
> > I run OpenVPN to connect this laptop to a remote server and I get the
> > following output.
> >
>
> [snip]
>
> > I also receive the 'Too many levels of symbolic links' errors when I
> > connect to alternate (known working) OpenVPN servers.
> > If I connect to these known working servers with my Android phone the
> > route add command succeeds and I can access the interal networks behind
> > the OpenVPN servers
> >
> > If I try to add these routes manually I get the same message: Too many
> > levels of symbolic links.
> >
> > What could be the root cause of this issue?
> >
>
> Please see this thread/post on ports@
> http://marc.info/?l=openbsd-ports=147385901603925=2
>
> Note that sthen@ said he was looking at some other issues as
> well, so this may not be the final patch that gets committed, but
> it fixed OpenVPN for my use case at least.
>
> Your milage may vary.
>

Also, if you want a workaround without waiting for a patch, remove any
route calls from your openvpn configuration, set script-security 2, and use
an up script such as:

#!/bin/sh
/sbin/route add -net 123.45.67.0/24 $4

Thanks,
Jeremy

Re: PPPoE and VDSL2 with a real /29

[Stuart Henderson]

On 2016-09-28, tech-lists  wrote:
> Hello misc@
>
> Hoping someone can help me please. I have a bit of a chicken and egg 
> situation with regard to routing real IPs through a PPPoE connection in 
> that I know some of the terms but my understanding is limited on others. 
> I've read around pppoe on freebsd and openbsd and openbsd seems to me to 
> be the one to go for as it looks simpler and additionally has a 
> reputation for robustness.
>
> The setup that I want goes like this
>
>  internet
>  |
>  |
> draytek vigor 130 in pppoe bridge mode
>  |
>  |rl0 connected to modem
>openbsd 6.0 with two rl interfaces, running pppoe
>  |
>  |rl1 connected to unmanaged switch/LAN
>
> The LAN machines have their own firewalls and will be manually set with 
> real IPs in my /29. I don't need NAT on this machine, though maybe pf is 
> needed for anti-spoof. I'm confident I can set up the actual pppoe 
> connection through use of the online faq.

No baby jumbos with rl(4) so you are stuck with 1492 MTU, so you need
PF so you can do "scrub (max-mss 1440)" as described in pppoe(4)'s
"MTU/MSS ISSUES" section.

> What I'm unsure about is this:
>
> 1. do I need to bridge the rl0 and rl1 interfaces? The way a lot of 

No, and this won't work at all, you're just seeing pppoe frames on rl0.

> fixed IP on *dsl is delivered in the UK is that the connection gets 
> dynamically the same IP each time, because it's tied to the login 
> credentials/radius profile. In my redacted-ip example case I get 
> 82.xx.yy.102 if just one machine with a pppoe client connects to the 
> internet. I have 82.xx.yy.96/29 in CIDR.
>
> 2. how do I make rl1 accept incoming and outgoing traffic from the rest 
> of my /29? Is it as simple as putting the following in hostname.rl0:
>
> inet 82.xx.yy.102 255.255.255.248

The /29 needs to go on the interface facing the LAN, in that case
rl*1*, so this goes in /etc/hostname.rl1.

For hostname.pppoe0 you can do something like this.

inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev rl0 authproto chap authname 
"zen123456@zen" authkey "foo" up

> and then set the sysctl net.inet.ip.forwarding=1 ?

Yes.

Re: What is doas doing??

[Marc Espie]

On Wed, Sep 28, 2016 at 02:45:26PM +0200, Murk Fletcher wrote:
> Hi,
> 
> Anybody ever been in a similar situation?
> 
> % myscript_start
> /etc/rc.d/myscript: need root privileges
> % doas myscript_start
> doas: myscript_start: command not found
> % su
> Password:
> you are not in group wheel
> Sorry
> % groups
> wheel
> % cat /etc/doas.conf
> permit nopass keepenv :wheel
> 
> Thanks!
> 
> Murk

Your prompt being %, I suspect you use csh. and have the path setup somehow
inside csh proper.

Whereas doas is going to run sh, have a different PATH, hence your trouble.

Do yourself a favor, get rid of csh. It's dead, Jim.

PPPoE and VDSL2 with a real /29

[tech-lists]

Hello misc@

Hoping someone can help me please. I have a bit of a chicken and egg 
situation with regard to routing real IPs through a PPPoE connection in 
that I know some of the terms but my understanding is limited on others. 
I've read around pppoe on freebsd and openbsd and openbsd seems to me to 
be the one to go for as it looks simpler and additionally has a 
reputation for robustness.


The setup that I want goes like this

internet
|
|
   draytek vigor 130 in pppoe bridge mode
|
|rl0 connected to modem
  openbsd 6.0 with two rl interfaces, running pppoe
|
|rl1 connected to unmanaged switch/LAN

The LAN machines have their own firewalls and will be manually set with 
real IPs in my /29. I don't need NAT on this machine, though maybe pf is 
needed for anti-spoof. I'm confident I can set up the actual pppoe 
connection through use of the online faq.


What I'm unsure about is this:

1. do I need to bridge the rl0 and rl1 interfaces? The way a lot of 
fixed IP on *dsl is delivered in the UK is that the connection gets 
dynamically the same IP each time, because it's tied to the login 
credentials/radius profile. In my redacted-ip example case I get 
82.xx.yy.102 if just one machine with a pppoe client connects to the 
internet. I have 82.xx.yy.96/29 in CIDR.


2. how do I make rl1 accept incoming and outgoing traffic from the rest 
of my /29? Is it as simple as putting the following in hostname.rl0:


inet 82.xx.yy.102 255.255.255.248

and then set the sysctl net.inet.ip.forwarding=1 ?

many thanks,
--
J.

What is doas doing??

[Murk Fletcher]

Hi,

Anybody ever been in a similar situation?

% myscript_start
/etc/rc.d/myscript: need root privileges
% doas myscript_start
doas: myscript_start: command not found
% su
Password:
you are not in group wheel
Sorry
% groups
wheel
% cat /etc/doas.conf
permit nopass keepenv :wheel

Thanks!

Murk

Re: tfdpd doesn't deliver pxeboot file

[Peer Janssen]

Am 28.09.2016 um 13:27 schrieb Solène Rapenne:
> Le 2016-09-28 12:45, Peer Janssen a écrit :
>> TFTP pxeboot requests:
>>
>> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ
>> "pxeboot"
>>   : 4500 0034 0002  1411 24ea c0a8 0051  E..4..$Q
>>   0010: c0a8 002c 0816 0045 0020 f181 0001 7078  ...,...E. px
>>   0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a  eboot.octet.tsiz
>>   0030: 6500 3000e.0.
>
> The TFTP request from alix asks for a binary transfer
>
>> As a comparison, the reaction against the RRQ from the linux box:
>>
>> 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19
>> RRQ "pxeboot" (DF)
>>   : 4500 002f eca9 4000 4011 cc78 c0a8 001f  E../..@.@..x
>>   0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078  ...,.@.E..u...px
>>   0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.
>>
>>
>
> The TFTP request from your linux box asks for an ascii transfer
>
> There is a difference between the 2 tftp transfers that may explain
> your problem
>
> Can you try the cli tftp and type "binary" before "get pxeboot" ?
>
> like the following :
>
> tftp 192.168.0.44
> tftp> binary
> tftp> get pxeboot
>

Good idea.
This works fine. As well as with "localhost".

# tftp localhost
tftp> binary
tftp> get pxeboot
Received 81444 bytes in 0.0 seconds
tftp> ascii
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp> #

13:54:47.936070 localhost.23896 > localhost.tftp: [udp sum ok] 16 RRQ
"pxeboot" (ttl 64, id 51686, len 44)
  : 4500 002c c9e6  4011 b2d8 7f00 0001  E..,@...
  0010: 7f00 0001 5d58 0045 0018 9309 0001 7078  ]X.E..px
  0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet.

13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ
"pxeboot" (ttl 64, id 50915, len 47)
  : 4500 002f c6e3  4011 b5d8 7f00 0001  E../@...
  0010: 7f00 0001 5d58 0045 001b 2b39 0001 7078  ]X.E..+9..px
  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.

# tftp 192.168.0.44
tftp> binary
tftp> get pxeboot
Received 81444 bytes in 0.0 seconds
tftp> ascii
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp> #

13:55:11.780098 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok]
16 RRQ "pxeboot" (ttl 64, id 50778, len 44)
  : 4500 002c c65a  4011 32be c0a8 002c  E..,.Z..@.2,
  0010: c0a8 002c 810e 0045 0018 ebac 0001 7078  ...,...E..px
  0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet.

13:55:18.738183 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok]
19 RRQ "pxeboot" (ttl 64, id 51568, len 47)
  : 4500 002f c970  4011 2fa5 c0a8 002c  E../.p..@./,
  0010: c0a8 002c 810e 0045 001b 83dc 0001 7078  ...,...E..px
  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.


Maybe the additional options which the alix target (at IP .81) sends are
what the server does not like.There we had:

12:16:05.039971 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot"

  : 4500 0034 0006  1411 24e6 c0a8 0051  E..4..$Q
  0010: c0a8 002c 081a 0045 0020 f17d 0001 7078  ...,...E. .}..px
  0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a  eboot.octet.tsiz
  0030: 6500 3000e.0.

12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
  : 4500 0039 0007  1411 24e0 c0a8 0051  E..9..$Q
  0010: c0a8 002c 081b 0045 0025 619c 0001 7078  ...,...E.%a...px
  0020: 6562 6f6f 7400 6f63 7465 7400 626c 6b73  eboot.octet.blks
  0030: 697a 6500 3134 3536 00   ize.1456.

=>

Could it be that OpenBSD6.0's tftpd refuses to serve a binary tftp RRQ with
tsize 0 or blksize 1456?

Is there a way to tell the target how to build it's pxeboot request (maybe
some dhcpd option which will get sent to it)?

Peer


--
Peer Janssen - p...@pjk.de

Re: traceroute and pf

[Gregory Edigarov]

because it drops privs once initialization done.

On 28.09.16 14:24, johnw wrote:

On 09/28/2016 07:05 PM, Janne Johansson wrote:

Apart from PF failing the syntax, what would one expect to achieve with

=0 ?

That would always cover all users, since its never a negative number.
/usr/include/sys/types.h:typedef__uid_t uid_t;
  /* user id */
/usr/include/sys/_types.h:typedef   __uint32_t  __uid_t;
  /* user id */



No, PF do not failing the syntax, pfctl -f pf.conf without any error and
pfctl can load the rule (pfctl -sr can see it)

I mean is why, below rule do not let traceroute work?

pass out quick on $ext_if inet proto udp from ($ext_if) to any user 0

then run traceroute as root:   traceroute google.com

traceroute to google.com (216.58.221.238), 64 hops max, 40 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote google.com 40 chars, ret=-1

Thanks.

Re: tfdpd doesn't deliver pxeboot file

[Solène Rapenne]

Le 2016-09-28 12:45, Peer Janssen a écrit :

TFTP pxeboot requests:

12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ 
"pxeboot"

  : 4500 0034 0002  1411 24ea c0a8 0051  E..4..$Q
  0010: c0a8 002c 0816 0045 0020 f181 0001 7078  ...,...E. px
  0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a  eboot.octet.tsiz
  0030: 6500 3000e.0.


The TFTP request from alix asks for a binary transfer


As a comparison, the reaction against the RRQ from the linux box:

12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19
RRQ "pxeboot" (DF)
  : 4500 002f eca9 4000 4011 cc78 c0a8 001f  E../..@.@..x
  0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078  ...,.@.E..u...px
  0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii.




The TFTP request from your linux box asks for an ascii transfer

There is a difference between the 2 tftp transfers that may explain your 
problem


Can you try the cli tftp and type "binary" before "get pxeboot" ?

like the following :

tftp 192.168.0.44
tftp> binary
tftp> get pxeboot

Re: traceroute and pf

[johnw]

On 09/28/2016 07:05 PM, Janne Johansson wrote:
> Apart from PF failing the syntax, what would one expect to achieve with
> >=0 ?
>
> That would always cover all users, since its never a negative number.
> /usr/include/sys/types.h:typedef__uid_t uid_t;
>  /* user id */
> /usr/include/sys/_types.h:typedef   __uint32_t  __uid_t;  
>  /* user id */
>
>
No, PF do not failing the syntax, pfctl -f pf.conf without any error and
pfctl can load the rule (pfctl -sr can see it)

I mean is why, below rule do not let traceroute work?

pass out quick on $ext_if inet proto udp from ($ext_if) to any user 0

then run traceroute as root:   traceroute google.com

traceroute to google.com (216.58.221.238), 64 hops max, 40 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote google.com 40 chars, ret=-1

Thanks.

-- 
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC



signature.asc
Description: OpenPGP digital signature

Re: traceroute and pf

[Janne Johansson]

Apart from PF failing the syntax, what would one expect to achieve with
>=0 ?

That would always cover all users, since its never a negative number.
/usr/include/sys/types.h:typedef__uid_t uid_t;  /*
user id */
/usr/include/sys/_types.h:typedef   __uint32_t  __uid_t;/*
user id */


2016-09-28 11:00 GMT+02:00 johnw :

> Hi, I have some problem setup pf, to pass out traceroute with user keyword.
>
>
> below rule do WORK.
>
> pass out quick on $ext_if inet proto udp from ($ext_if) to any
>
> or below one also WORK.
>
> pass out quick on $ext_if inet proto udp from ($ext_if) to any user != 1
>
>
> but below one, do NOT WORK.
>
> pass out quick on $ext_if inet proto udp from ($ext_if) to any user >= 0
>
>
> Is it bug? or normal (if is normal, why the last one will not work)
>
> Thanks.
>
>


-- 
May the most significant bit of your life be positive.

Re: FDE on BeagleBone Black

[Jonathan Gray]

On Wed, Sep 28, 2016 at 10:22:10AM +0200, Stefan Sperling wrote:
> On Wed, Sep 28, 2016 at 06:48:35AM +0200, L.R. D.S. wrote:
> > Hi,
> > I'm thinking of buying a new toy board like BeagleBone Black to test the 
> > armv7 port.
> > It's already possible to do full disk encryption on these boards?
> 
> I don't think the armv7 bootloader has softraid support at present.
> You could use mount_vnd(8) to crypt some partitions. However, I/O
> performance on BBB is so bad that adding crypto on top is rather boring.

Enabling anything more than 1 bit modes on ommmc seems problematic
for reasons I've not been able to figure out.

Especially when writing data to emmc and reading it back which tends
to cause an io error with high modes.  I think 4 bit modes with an sd
card worked on bbb but doesn't on pandaboard.  The bbb emmc should be able
to do up to 8 bit modes if the right combination of clock setup/pin muxing/
whatever other setup is figured out.

There is a standard way of doing sdmmc dma, but the am335x ommmc doesn't
support that, so dma would have to be done by using the edma interface.

> 
> I use a BBB at home. It's a toy which works fine for simple network-bound
> services but you can't make it do wifi or routing due to lack of USB support.
> The USB port on BBB is driven by a non-standard host controller which is not
> supported by OpenBSD yet.
> 
> If you're still figuring out what to buy, also take a look at other
> boards listed on this page: http://www.openbsd.org/armv7.html
> Freescale/NXP i.MX6 devices are currently the best supported ones but
> they are more expensive than BBB.
> 
> If you're using the armv7 port you'll want to run -current in any case.
> 
> > Also, as a side question, I remember some discussion here on misc or tech, 
> > about no 
> > support for binary packages on armv7 port. Is it still right, I'll have to 
> > compile 
> > all by myself? I'm already feeling the pain to compile ffmpeg by myself...
> > Thanks in advance.
> 
> I'm expecting arm packages to re-appear some day soon.
> But I'm not directly involved so I don't have any first-hand info.
> And since I'm not working on it I'll be waiting very patiently.

Re: tfdpd doesn't deliver pxeboot file

[Peer Janssen]

Am 28.09.2016 um 11:33 schrieb Peer Janssen:
> the request seems to be constructed in different ways. This goes
> beyond what tftpd man page says about tftpd's options. Indeed, it
> looks like there aren't any tftpd options for this kind of variation
> at all, so it seems to me at this time that a pxeboot of such an
> alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd.

Here is a complete tcpdump of such an unsuccessful pxeboot session from
an alix.2d13 to the alix.3x server:

# tcpdump -Xi vr0
tcpdump: listening on vr0, link-type EN10MB

Getting an IP:

12:15:43.020040 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
  : 4500 0240   1411 a4ae    E..@
  0010:   0044 0043 022c d577 0101 0600  .D.C.,.w
  0020: ba33 d45c 0004 8000      .3.\
  0030:     000d b933 d45c   ...3.\..
  0040:          
  0050:          
  0060:      ..

12:15:44.031351 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
  : 4510 014b   1011 e8be c0a8 002c  E..K...,
  0010:   0043 0044 0137 cd31 0201 0600  .C.D.7.1
  0020: ba33 d45c 0004 8000   c0a8 0051  .3.\...Q
  0030: c0a8 002c   000d b933 d45c   ...,...3.\..
  0040:     4448 4350 7365 7276  DHCPserv
  0050: 6572         er..
  0060:      ..

12:15:44.031755 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
  : 4510 014b   1011 e8be c0a8 002c  E..K...,
  0010:   0043 0044 0137 afc7 0201 0600  .C.D.7..
  0020: ba33 d45c 0004 8000   c0a8 0051  .3.\...Q
  0030: c0a8 002c   000d b933 d45c   ...,...3.\..
  0040:     4448 4350 7365 7276  DHCPserv
  0050: 6572         er..
  0060:      ..

12:15:44.055566 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
  : 4500 0240 0001  1411 a4ad    E..@
  0010:   0044 0043 022c fc8d 0101 0600  .D.C.,..
  0020: ba33 d45c 0004 8000      .3.\
  0030:     000d b933 d45c   ...3.\..
  0040:          
  0050:          
  0060:      ..

12:15:44.765199 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
  : 4510 014b   1011 e8be c0a8 002c  E..K...,
  0010:   0043 0044 0137 acc7 0201 0600  .C.D.7..
  0020: ba33 d45c 0004 8000   c0a8 0051  .3.\...Q
  0030: c0a8 002c   000d b933 d45c   ...,...3.\..
  0040:     4448 4350 7365 7276  DHCPserv
  0050: 6572         er..
  0060:      ..

12:15:44.766913 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
  : 4510 014b   1011 e8be c0a8 002c  E..K...,
  0010:   0043 0044 0137 ca31 0201 0600  .C.D.7.1
  0020: ba33 d45c 0004 8000   c0a8 0051  .3.\...Q
  0030: c0a8 002c   000d b933 d45c   ...,...3.\..
  0040:     4448 4350 7365 7276  DHCPserv
  0050: 6572         er..
  0060:      ..

ARP request and answer:

12:15:45.063894 arp who-has alix.fritz.box tell 192.168.0.81
  : 0001 0800 0604 0001 000d b933 d45c c0a8  ...3.\..
  0010: 0051    c0a8 002c    .Q.,
  0020:          ..

12:15:45.063957 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30
  : 0001 0800 0604 0002 000d b913 3c30 c0a8  <0..
  0010: 002c 000d b933 d45c c0a8 0051    .,...3.\...Q
  0020:          ..

TFTP pxeboot requests:

12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
  : 4500 0034 0002  1411 24ea c0a8 0051  E..4..$Q
  0010: c0a8 

Re: tfdpd doesn't deliver pxeboot file

[Solène Rapenne]

Le 2016-09-28 11:05, Peer Janssen a écrit :

Am 28.09.2016 um 10:50 schrieb Solène Rapenne:

Le 2016-09-28 10:21, Peer Janssen a écrit :
The target system for an OpenBSD 6.0 install, an alix.2d13, is 
directly

connected to an alix.3x box serving dhcp and tftp.
alix.3x (Server):

# tftp localhost
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp>



Can you try the LAN ip address instead of localhost ?
Maybe it's a firewall issue or tftp not listening on the lan interface




You may want to boot another computer with PXE to see if the problem is 
related to the alix board or a configuration problem maybe ?


From my little experience with PXE and your configs files, everything 
seems fine there for me.

Re: tfdpd doesn't deliver pxeboot file

[Peer Janssen]

Am 28.09.2016 um 11:05 schrieb Peer Janssen:
> Am 28.09.2016 um 10:50 schrieb Solène Rapenne:
>> Le 2016-09-28 10:21, Peer Janssen a écrit :
>>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
>>> connected to an alix.3x box serving dhcp and tftp.
>>> alix.3x (Server):
>>>
>>> # tftp localhost
>>> tftp> get pxeboot
>>> Received 81965 bytes in 0.1 seconds
>>> tftp>
>>>
>> Can you try the LAN ip address instead of localhost ?
>> Maybe it's a firewall issue or tftp not listening on the lan interface
> Works fine:
> $ # on a linux box:
> $ # after switching the cable an vr0 of alix server from alix target to
> network switch where linux box is connected:
>
> $ tftp 192.168.0.44
> tftp> get pxeboot
> Received 81965 bytes in 1.3 seconds
> tftp>
Looking at the tcpdump, I noticed this:

unsuccessful tftp requests from alix target:

09:44:54.290322 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:45:04.454216 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot"

successful tftp request from linux system:

10:54:07.685813 arp who-has alix.fritz.box tell 
10:54:07.685910 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30
10:54:07.686004 .55726 > alix.fritz.box.tftp: 19 RRQ
"pxeboot" (DF)
10:54:07.698624 .55726 > alix.fritz.box.24979: udp 4 (DF)
10:54:07.705934 .55726 > alix.fritz.box.24979: udp 4 (DF)
[...]

So the request seems to be constructed in different ways.

This goes beyond what tftpd man page says about tftpd's options. Indeed,
it looks like there aren't any tftpd options for this kind of variation
at all, so it seems to me at this time that a pxeboot of such an
alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd.
Unless I missed something somewhere, of course.

Peer

--
Peer Janssen - p...@pjk.de

Re: Route add - too many levels of symbolic links

[Bryan Linton]

On 2016-09-27 20:00:04, Dekker  wrote:
> I have started encountering a wierd problem with my OpenBSD Laptop
> Running 6.0 Current (latest snapshot 25.09.2016)
> I run OpenVPN to connect this laptop to a remote server and I get the
> following output.
>

[snip]
 
> I also receive the 'Too many levels of symbolic links' errors when I
> connect to alternate (known working) OpenVPN servers.
> If I connect to these known working servers with my Android phone the
> route add command succeeds and I can access the interal networks behind
> the OpenVPN servers
> 
> If I try to add these routes manually I get the same message: Too many
> levels of symbolic links.
> 
> What could be the root cause of this issue?
> 

Please see this thread/post on ports@
http://marc.info/?l=openbsd-ports=147385901603925=2

Note that sthen@ said he was looking at some other issues as
well, so this may not be the final patch that gets committed, but
it fixed OpenVPN for my use case at least.

Your milage may vary.

-- 
Bryan

State of IPsec, iked (OpenIKED) and redundancy (CARP)

[Jasper Siepkes]

Hi everyone @ misc!

I'm trying to determine what the state is of using iked (OpenIKED) with 
redundancy (with CARP). Should such a setup work in OpenBSD 6.0?

The iked.conf (5) man page implies that using CARP for
redundancy is a supported configuration: "This option is used for 
setups using sasyncd(8) and carp(4) to provide redundancy.".

However after some digging I'm leaning towards it was something that 
used to work but doesn't work anymore (at least not in 6.0).

The issue I bumped into; I'm using OpenBSD 6.0 (fully patched) and CARP 
and iked by themselves work fine. The problems start when trying to 
have iked use the CARP IP address instead of the IP of the host it 
self. iked says in it's logs that it uses the CARP IP as source IP in 
the messages it sends but in reality (checked with tcpdump) it doesn't. 
It uses the IP of the interface with the default route. After some 
digging I found someone on the list who encountered the same 
problem: "IKED/carp/sasyncd: Wrong source ip address/No IKEv2 response" 
[1]. The response is: "iked generates some packets before binding, 
so they have whatever source address is on the interface that holds the 
outgoing route to the destination.". 

I also found a post in the list called "iked+CARP/ active,
passive"[2] which implies that iked + CARP actually does work. But 
since that post is from 2011 I'm guessing it broke somewhere between 
2011 and 2016.

If the current state is indeed that using CARP with iked is not an 
working option perhaps we should modify the iked.conf (5) man page to 
clearly state that?

On a related note; I got bitten by the bug fixed in the patch: 
"Fix an infinite loop in iked"[3]. I manually patched my build with it
but perhaps it's a good candidate for inclusion in the 6.0 patch 
branch?

Regards,

Jasper

[1] https://marc.info/?l=openbsd-misc=145924380931352=2
[2] https://marc.info/?l=openbsd-misc=131850193524708=2
[3] https://marc.info/?l=openbsd-tech=147348976311128=2

Re: tfdpd doesn't deliver pxeboot file

[Peer Janssen]

Am 28.09.2016 um 10:50 schrieb Solène Rapenne:
> Le 2016-09-28 10:21, Peer Janssen a écrit :
>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
>> connected to an alix.3x box serving dhcp and tftp.
>> alix.3x (Server):
>>
>> # tftp localhost
>> tftp> get pxeboot
>> Received 81965 bytes in 0.1 seconds
>> tftp>
>>
>
> Can you try the LAN ip address instead of localhost ?
> Maybe it's a firewall issue or tftp not listening on the lan interface

Works fine:

# ifconfig urtwn0 | grep inet
inet 192.168.0.45 netmask 0xff00 broadcast 192.168.0.255
# ifconfig vr0 | grep inet
inet 192.168.0.44 netmask 0xff00 broadcast 192.168.0.255

$ # on a linux box:
$ # via wifi ssh link to the alix server:

$ tftp alix.fritz.box
tftp> status
Connected to alix.fritz.box.
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> get pxeboot
Received 81965 bytes in 1.9 seconds
tftp>

$ md5sum pxeboot
6d0075598b6672a06dda44498ab7d663  pxeboot

$ # after switching the cable an vr0 of alix server from alix target to
network switch where linux box is connected:

$ tftp 192.168.0.44
tftp> get pxeboot
Received 81965 bytes in 1.3 seconds
tftp>

$ md5sum pxeboot #the second file which has overwritten the one from the
first try
6d0075598b6672a06dda44498ab7d663  pxeboot

# # back on alix server:
# md5
/tftpboot/pxeboot

MD5 (/tftpboot/pxeboot) = 6d0075598b6672a06dda44498ab7d663

# md5
/usr/mdec/pxeboot

MD5 (/usr/mdec/pxeboot) = 6d0075598b6672a06dda44498ab7d663

So everything is in order regarding these connection / firewall /
binding to interface aspects.
There is no firewall between the alix.3x server and the alix.2d13
target, it's just one cable.

--
Peer Janssen - p...@pjk.de

traceroute and pf

[johnw]

Hi, I have some problem setup pf, to pass out traceroute with user keyword.


below rule do WORK.

pass out quick on $ext_if inet proto udp from ($ext_if) to any

or below one also WORK.

pass out quick on $ext_if inet proto udp from ($ext_if) to any user != 1


but below one, do NOT WORK.

pass out quick on $ext_if inet proto udp from ($ext_if) to any user >= 0


Is it bug? or normal (if is normal, why the last one will not work)

Thanks.



0xCF2C80AC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: tfdpd doesn't deliver pxeboot file

[Solène Rapenne]

Le 2016-09-28 10:21, Peer Janssen a écrit :

The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
connected to an alix.3x box serving dhcp and tftp.
alix.3x (Server):

# tftp localhost
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp>



Hello,

Can you try the LAN ip address instead of localhost ?
Maybe it's a firewall issue or tftp not listening on the lan interface

regards

Re: FDE on BeagleBone Black

[Stefan Sperling]

On Wed, Sep 28, 2016 at 06:48:35AM +0200, L.R. D.S. wrote:
> Hi,
> I'm thinking of buying a new toy board like BeagleBone Black to test the 
> armv7 port.
> It's already possible to do full disk encryption on these boards?

I don't think the armv7 bootloader has softraid support at present.
You could use mount_vnd(8) to crypt some partitions. However, I/O
performance on BBB is so bad that adding crypto on top is rather boring.

I use a BBB at home. It's a toy which works fine for simple network-bound
services but you can't make it do wifi or routing due to lack of USB support.
The USB port on BBB is driven by a non-standard host controller which is not
supported by OpenBSD yet.

If you're still figuring out what to buy, also take a look at other
boards listed on this page: http://www.openbsd.org/armv7.html
Freescale/NXP i.MX6 devices are currently the best supported ones but
they are more expensive than BBB.

If you're using the armv7 port you'll want to run -current in any case.

> Also, as a side question, I remember some discussion here on misc or tech, 
> about no 
> support for binary packages on armv7 port. Is it still right, I'll have to 
> compile 
> all by myself? I'm already feeling the pain to compile ffmpeg by myself...
> Thanks in advance.

I'm expecting arm packages to re-appear some day soon.
But I'm not directly involved so I don't have any first-hand info.
And since I'm not working on it I'll be waiting very patiently.

tfdpd doesn't deliver pxeboot file

[Peer Janssen]

The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
connected to an alix.3x box serving dhcp and tftp.
alix.3x (Server):

# dmesg | head -n 1
OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016

# ifconfig vr0
vr0: flags=8b43
mtu 1500
lladdr 00:0d:b9:13:3c:30
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.0.44 netmask 0xff00 broadcast 192.168.0.255

# dhcpd vr0

# cat
/etc/dhcpd.conf

option domain-name "fritz.box";
option domain-name-servers 192.168.0.44;
option routers 192.168.0.44;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
server-name "DHCPserver";
server-identifier 192.168.0.44;
next-server 192.168.0.44;
default-lease-time 600;
max-lease-time 600;

#option bootfile-name "pxeboot";

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.80 192.168.0.254;
  filename "pxeboot";
  #host alix_2d13 { hardware ethernet 00:0d:b9:33:d4:5c; }
}
# ls -lR /tftpboot/
total 14100
-rw-r--r--  1 root  wheel71824 Sep 26 22:40 boot
-rw-r--r--  1 root  wheel  7173390 Sep 26 22:40 bsd.rd
drwxr-xr-x  2 root  wheel  512 Sep 26 22:43 etc
-rw-r--r--  1 root  wheel81444 Sep 28 09:41 pxeboot

/tftpboot/etc:
total 4
-rw-r--r--  1 root  wheel  46 Sep 27 16:03 boot.conf
# cat /tftpboot/etc/boot.conf
stty com0 38400
set tty com0
boot tftp:bsd.rd

# tftp localhost
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp>

# #transferred byte count doesn't match file lenth, but the locally
delivered file is fine:
# diff -s pxeboot
/tftpboot/pxeboot

Files pxeboot and /tftpboot/pxeboot are identical

# tftpd -d /tftpboot

tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out

# #Corresponding tcpdump:
# tcpdump -i vr0
09:44:29.798240 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
09:44:30.805580 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
09:44:33.800273 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
09:44:34.021374 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
09:44:34.320566 arp who-has alix.fritz.box tell 192.168.0.81
09:44:34.320671 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30
09:44:34.320780 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:36.326869 192.168.0.81.2071 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:40.337057 192.168.0.81.2072 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:46.324875 192.168.0.81.2073 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:54.290322 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:45:04.454216 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:45:40.489906 192.168.0.81.2076 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:46:52.508530 192.168.0.81.2077 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:48:40.509010 192.168.0.81.2078 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:51:04.491359 192.168.0.81.2079 > alix.fritz.box.tftp: 29 RRQ "pxeboot"

# # From /var/log/daemon:
Sep 28 09:44:29 alix dhcpd[89986]: DHCPDISCOVER from 00:0d:b9:33:d4:5c
via vr0
Sep 28 09:44:30 alix dhcpd[89986]: DHCPOFFER on 192.168.0.81 to
00:0d:b9:33:d4:5c via vr0
Sep 28 09:44:33 alix dhcpd[89986]: DHCPREQUEST for 192.168.0.81 from
00:0d:b9:33:d4:5c via vr0
Sep 28 09:44:34 alix dhcpd[89986]: DHCPACK on 192.168.0.81 to
00:0d:b9:33:d4:5c via vr0


# # Now what happens on target? => Output on serial console of alix target:

$ cu -l /dev/ttyS0 -s 9600
Connected.
PC Engines ALIX.2 v0.99m
640 KB Base Memory
261120 KB Extended Memory

01F0 Master 848A SDCFHS-008G
Phys C/H/S 15538/16/63 Log C/H/S 974/255/63 LBA

Intel UNDI, PXE-2.0 (build 082)
Copyright (C) 1997,1998,1999  Intel Corporation
VIA Rhine III Management Adapter v2.43 (2005/12/15)

CLIENT MAC ADDR: 00 0D B9 33 D4 5C
CLIENT IP: 

Re: FDE on BeagleBone Black

[ludovic coues]

Simply go to your favorite openbsd mirror and check the packages
directory. You will get up to date information about what packages are
available and which are not.
>From what I've seen, there is no package for armv7 / openbsd6.0. I
haven't checked snapshots.

2016-09-28 6:48 GMT+02:00 L.R. D.S. :
> Hi,
> I'm thinking of buying a new toy board like BeagleBone Black to test the 
> armv7 port.
> It's already possible to do full disk encryption on these boards?
> Also, as a side question, I remember some discussion here on misc or tech, 
> about no
> support for binary packages on armv7 port. Is it still right, I'll have to 
> compile
> all by myself? I'm already feeling the pain to compile ffmpeg by myself...
> Thanks in advance.
>



-- 

Cordialement, Coues Ludovic
+336 148 743 42

Large datasize - how to limit physical memory?

[Raimo Niskanen]

Dear misc@

I have searched the archives and read the documentation of login.conf(5),
ksh(1):ulimit and can not find how to limit the amount of physical memory a
process may use.

I have the following limits where I have set down ulimit -m and ulimit -l
to 1 kbytes in an attempt to limit the process I spawn which is
the Erlang VM.

$ ulimit -a
time(cpu-seconds)unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 33554432
stack(kbytes)8192
lockedmem(kbytes)1
memory(kbytes)   1
nofiles(descriptors) 1024
processes1024

Note that the machine has got 8 GB of physical memory and 8 GB of swap and
that I have set datasize=infinity in /etc/login.conf. I got
datasize=33554432 which seems to be the same as kern.shminfo.shmmax.
The datasize is twice the physical memory + swap.

Then I start the Erlang VM and tell it to allocate an address block of 3
MByte for future use where it will store all literal data in the same block
(this is a garbage collector optimization).  Not much of this data is
actually used.

 68196 beam CALL  
mmap(0,0x75300,0,0x1002,-1,0)
 68196 beam RET   mmap 11871265173504/0xacbfe8b3000

Note the protection flags on the block.  No access is allowed.  This trick
works just fine; here is what top says:

load averages:  0.15,  0.13,  0.09 frerin.otp.ericsson.se 08:49:46
48 processes: 47 idle, 1 on processor up 13:49
CPU0 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU1 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Memory: Real: 43M/636M act/tot Free: 7028M Cache: 508M Swap: 0K/8155M

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
68196 raimo  20   29G   15M sleep poll  0:00  1.42% beam

So I have a process with a data size of 29 GB on a machine with 16 GB
memory + swap.  I have also tried to start an additional Erlang VM that
also allocates 29 GB of virtual memory which also works.

That this is allowed is just fine for me - this trick of allocating a
"large enough" PROT_NONE memory to get one address range for some special
data type is very useful for the Erlang VM.  But I wonder how to limit the
actual memory use?  Setting down ulimit -m and ulimit -l to 1 kbytes
did not prevent this process from getting 15 MByte of "RES" memory...

Is there some way to limit the actual amount of memory for a process when I
need to set up the datasize to allow for large unused virtual memory
blocks?

dmesg | head -4:
OpenBSD 6.0 (GENERIC.MP) #1: Fri Sep 23 08:53:49 CEST 2016

r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8283037696 (7899MB)
avail mem = 8027529216 (7655MB)

Best Regards
-- 
/ Raimo Niskanen, Erlang/OTP, Ericsson AB