Re: Cannot get httpd block directives to work
Heya
A quick read of the man page shows that the rule is first match for
location stanzas.
So if you want the sub-dirs to not be read, place them above the root
location in the conf file.
Tested on 6.8:
I get 403's for block stanza placed above root location stanza.
I get files served when block stanza placed below root location stanza.
Shane
On Sat, Mar 13, 2021 at 12:49 AM T K wrote:
>
> Hi there,
>
> I am trying to block direct access to given subfolder of
> simple php website hosted on OpenBSD 6.8 amd64.
> Inside webroot folder there are some subfolders
> containing html files I'd like to restrict for direct requests,
> as they are intended for including to php scripts, not
> direct viewing.
>
> What I want to achieve is to get 403 error while
> requesting "http://10.0.1.222/FOLDER/file.html;.
> This is say "development" server, accessible
> through local lan, listening on IP given below.
>
> My very simple config looks like this:
>
> server "10.0.1.222" {
> listen on 10.0.1.222 port 80
> log style combined
>
> location "/*php*"{
> root "/FOLDER"
> fastcgi socket "/run/php-fpm.sock"
> }
>
> directory {
> index "index.php"
> }
>
> location "/*" {
> root "/FOLDER"
> }
>
> location "/SUBFOLDER/*" {block}
> }
>
> Above does not work as I'd expect.
> Requesting "/SUBFOLDER" itself returns
> 403 code but hitting proper html filename
> gets suceeded with 200 code.
> I tried many versions of shell globes
> for "/SUBFOLDER/file" path but nothing changes
> described behaviour. I do not know if tere is
> problem in globe itself or in server config.
> No idea what to do, so any help appreciated.
>
> Tomasz(equi)Krol
>
Re: On blindly running code
Heya My own experience agrees with you with regards to any system in production. However, it is also my experience that nothing demonstrates the difference between what should happen and what actually occurs better than running the code and seeing the aftermath. Thankfully, virtualisation makes things much simpler these days, and running through everything on a clone prior to even considering steps on the production system is consequently highly recommended. Shane On Fri, Oct 18, 2019 at 11:19 PM wrote: > > With regards to recent discussion, here is a little anecdote that came out of > the 6.5 to 6.6 upgrade. > > On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the > ports it left suggestions in the form of copy pasta commands to run to > complete the upgrade process, as it does. One of these was rm -rf > /var/bitlbee/*. > > Had I been so stupid as to just run the command, or if the hyper-complicated > upgrade script required to support every possibility included a single > mistake, all of the settings to connect to my IM accounts (currently > constituting the only place some ancient passwords are guaranteed to be > saved) would have been lost, where in fact what I had to do about those files > was absolutely nothing. > > There is no fault here. The wording is something like 'you should also run', > clearly not 'this is absolutely essential' (because if it was, why wasn't it > done already or documented better?), which couldn't make it any clearer that > you need to think first why you might want to run that command. > > There are good reasons not to delete user accounts when removing the software > that uses them, for example, which is why pkg_delete doesn't but suggests > that you might want to (with copy pasta for your convenience). > > It's my responsibility to understand the software I'm running, how it works > and what effect the things I do will have on it. Nobody would have cried for > me if I'd pasted first and only then realised that I'd lost everything. > > Take responsibility for your own computers or stop using them and buy one of > those Fisher Price remote controlled radio-tracker remote execution vector > iToys that all the kids are playing with these days. > > Matthew > > ps. I do have backups of course. >
Re: auto_upgrade.conf et al man pages or documentation?
Hi Jacob Thanks for that. Shane On Fri, Oct 18, 2019 at 4:28 PM Jacob Adams wrote: > > On 10/17/19 9:49 PM, Theo de Raadt wrote: > > Shane Lazarus wrote: > > > >> I was interested in what it would do by default, and in how I could alter > >> those defaults if I did not like them. > >> > >> The sysupgrade man page informed me of a configuration file. > > > > Your complaint directly referenced the configuration filename > > /auto_upgrade.conf > > > > That filename is not mentioned in the sysupgrade man page, as you just > > claimed. > > > > In fact, it is mentioned nowhere. Your following complaints are that > > it is mentioned nowhere. > > Quoting directly from https://man.openbsd.org/sysupgrade : > "FILES > > /auto_upgrade.conf > Response file for the ramdisk kernel." > > Shane, you appear to be on the right track. From what I can tell it seems to > be > the same thing as install.conf in autoinstall. > > According to autoinstall(8): > > "The response file is a line-oriented ASCII text file. The format of each > line is: > > question = answer > > question is an installer question (not including the question mark) or a > non-ambiguous part of it, consisting of whitespace separated words. answer is > the answer to the question. Passwords may be in plaintext, encrypted with > encrypt(1), or set to ‘*’ (13 '*'s) to disable password logins, > only > permitting alternative access methods (for example, ssh(1) keys)." > > Therefore it seems that to ensure that the sets you do not want installed are > not installed you can use the "Set name(s)" question. > > For example to just install the base system and no other sets, hypothetically > you would put: > "Set name(s) = -all base66.tgz bsd.mp bsd" in /auto_upgrade.conf > > However, looking at the source code this file is created by sysupgrade: > > "cat <<__EOT >/auto_upgrade.conf > Location of sets = disk > Pathname to the sets = /home/_sysupgrade/ > Set name(s) = done > Directory does not contain SHA256.sig. Continue without verification = yes > __EOT" > > Thus you can't really change this unless you want to edit the script directly. > > The easiest method to install a limited number of sets would be to use > sysupgrade -n and then remove the sets you do not want from /home/_sysupgrade > before rebooting. > > Hope this helps, > Jacob >
Re: auto_upgrade.conf et al man pages or documentation?
Heya On Fri, Oct 18, 2019 at 11:25 AM Theo de Raadt wrote: > Shane Lazarus wrote: > > > Hi Folks > > > > With 6.6 being released, I figured to try out sysupgrade. > > > > Checking the man page, I note it uses the file /auto_upgrade.conf > > You checked the manual page for that filename? Why that filename? > How did you decide you need to look up that file? > > I went looking for documentation on how to use the sysupgrade utility. I was interested in what it would do by default, and in how I could alter those defaults if I did not like them. The sysupgrade man page informed me of a configuration file. As other configuration files are documented, I went looking for the documentation for the configuration file. > So, I just ran sysupgrade with no options to see what would happen. > > Very adventurous of you. > > A step I felt was required in order to determine the defaults used. > > Unsurprisingly, it proceeded to install ALL of the sets, without > bothering > > to prompt me, or apparently taking note of what was previously selected > > during the initial install of 6.5. > > Yes that is what it does. > > Was your disk too small, and things didn't fit? > > You haven't explained what problem you ran into. > > My problem is simply a lack of understanding of the utility, and my subsequent inability to find documentation about configuration files. That is my problem, and is the reason I asked for pointers on how to overcome the issue. > > This is an undesirable trait, with neither apparent documentation or > what I > > would consider to be sane defaults. > > In your opinion. > > Yep, in my own opinion, something that states it upgrades should not install sets that were not previously installed. > > If someone would be so kind as to point me in the right direction for how > > to prevent sysupgrade from being unsane, it would be much appreciated. > > Oh, that's easy. If you don't like what it does, don't use it. > Sure. Happy to completely ignore this utility, given I haven't needed it before. > > Very happy I've been able to point you in the right direction! > > Have a nice life. > > Have Fun Shane
auto_upgrade.conf et al man pages or documentation?
Hi Folks With 6.6 being released, I figured to try out sysupgrade. Checking the man page, I note it uses the file /auto_upgrade.conf Sadly, there seems to be no man page or alias for that Checking through the associated autoinstall(8) man page, there is reference to the file /upgrade.conf Which also has no link or alias in the man pages. Then I tried looking for man pages associated with /install.conf but again without success. Lastly, I browsed through the FAQ, without success either, but if someone knows what I missed there, please let me know. So, I just ran sysupgrade with no options to see what would happen. Unsurprisingly, it proceeded to install ALL of the sets, without bothering to prompt me, or apparently taking note of what was previously selected during the initial install of 6.5. This is an undesirable trait, with neither apparent documentation or what I would consider to be sane defaults. If someone would be so kind as to point me in the right direction for how to prevent sysupgrade from being unsane, it would be much appreciated. Thanks Shane
Re: Adding an additional IP on a NIC getting DHCP address
Hi Folks Oddly enough I couldn't figure out a way to do that :) So I just did the following instead with hostname.de1: dhcp inet6 autoconf !ifconfig de1 inet alias 192.168.2.28 255.255.255.0 !route add 128.0.0.0/1 192.168.2.254 up Have Fun Shane On Sat, Mar 23, 2019 at 12:51 PM Stuart Henderson wrote: > On 2019-03-22, Shane Lazarus wrote: > > Hi Folks > > > > Any reason you are not using the append / supercede options in the built > in > > dhclient.conf? > > https://man.openbsd.org/dhclient.conf > > > > Totally curious, as that is what I am using to override / append > > information... > > If you have a working setup with adding an alias IP address to the > interface as well as the address coming from DHCP, please do send it. > > >
Re: Adding an additional IP on a NIC getting DHCP address
Hi Folks Any reason you are not using the append / supercede options in the built in dhclient.conf? https://man.openbsd.org/dhclient.conf Totally curious, as that is what I am using to override / append information... Thanks Shane On Sat, Mar 23, 2019 at 3:55 AM Stuart Henderson wrote: > On 2019-03-22, Theodore Wynnychenko wrote: > > This is the first time I am responding to a post that is not my mine. > > I hope it is not too uninformed. > > > > Anyway, back in about October, 2016, I noticed that the included dhcp > > client would no longer assign an alias address alongside the address > > from the dhcp lease. Before about this time, I seem to recall, it would. > > > > My solution was to use the isc-dhcp-client from ports. But, that also > > had some issues. > > > > My solution (and if it is a poor solution, sorry) is on the mailing list > at: > > > > https://marc.info/?l=openbsd-misc=147638874608453=2 > > > > It is working as expected through my last update of current, which was > about 2 months ago. > > That sounds reasonable. > > > >> -Original Message- > >> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Lars Bonnesen > ... > >> and if so, how do I make sure that mygate does not get overwritten from > >> dhcp? > > So this is a bit different to Theodore's setup as you want a static > gatewy. The simplest method is probably to allow dhclient to set the > 0.0.0.0/0 default route itself, and add lines like these to hostname.if > > !route add 0.0.0.0/1 $gw_address > !route add 128.0.0.0/1 $gw_address > > That way dhclient can add and remove addresses as it wants and it > won't interfere with your real gateway. (Some of the tun-based VPN > clients use the same trick). > > >
Re: how can I get a dmesg (without a floppy or serial console port)?
Heya Any network connectivity at all? Otherwise, mount a USB stick and dmesg file... On Mon, May 27, 2013 at 4:52 PM, Heptas Torres hepta...@gmail.com wrote: Is there any way (physical settings / cables) to get a dmesg from a laptop that has neither a floppy nor a serial console port (no ssh either)? 10x -h
Re: OpenBSD as IPv4+6 gateway
Heya On Fri, Jun 22, 2012 at 2:00 PM, Hugo Osvaldo Barrera h...@osvaldobarrera.com.ar wrote: On 2012-06-21 17:22, Simon Perreault wrote: On 2012-06-21 15:50, Hugo Osvaldo Barrera wrote: I have read a great deal regarding IPv6 and IIRC, if I subnet my network block, my ISP would have to know it has to route traffic to that subnet through the WAN IP address of my router. Yes. If they don't allow that, then they don't know what they are doing. You're not supposed to assign a /48 to a single link. A single link gets a /64. But how would they know though which single IP to route the rest of the subnets? I mean, if I assign: 2800:40:402:::1/64 to my router's WAN interface (2800:40:402::: is it's default gateway) 2800:40:402::1/64 to it's LAN interface 2800:40:402::2/64 to one of my clients Doesn't my ISP need to know that traffic to 2800:40:402::1 should be routed through 2800:40:402:::1? What you have outlined there is that the ISP has configured their upstream device such that it is directly connected to your entire IPv6 allocation. If that is how they want to do things, then your best hope is to define the /64 between their space and yours as being 2800:40:402:::/64, and asking them to configure their upstream device to deliver 2800:40:402::/48 to 2800:40:402:::1 Alternatively, ask them for a linking allocation to remove the block allocated to you from being directly attached to one of their devices. Shane
Re: No way natting-to carp interface
Heya On Wed, Mar 14, 2012 at 5:15 AM, Paquitiu sirr...@arrakis.es wrote: Hi. ... hostname.carp12 inet 81.92.37.12 255.255.255.248 81.92.37.15 balancing ip carpnodes 120:0,121:100 pass PaSSWord12 hostname.carp13 inet 81.92.37.12 255.255.255.248 81.92.37.15 balancing ip carpnodes 130:100,131:0 pass PaSSWord13 ... Any reason those two interfaces have the same IP Address? Shane
Re: Can one interface have an IP address and bridge as well?
Heya On Wed, Jun 22, 2011 at 12:13 PM, Paul Suh pl...@goodeast.com wrote: Folks, Is this possible and/or a good idea? I have a router with three interfaces: sis0: external interface, IPv4 address 1.2.3.4/24 sis1: internal interface, IPv4 address 192.168.1.1/24 sis2 http://192.168.1.1/24sis2: DMZ interface, IPv4 address 192.168.2.1/24 NAT rules pass all traffic from the internal and DMZ zones through the external IP address. I have a couple of servers with IPv4 addresses 192.168.2.2 and 192.168.2.3 in the DMZ, with rdr-to rules that send traffic in to them from 1.2.3.4. I need to place a server at 1.2.3.5, and the software I have to run needs the server itself to have the IPv4 address 1.2.3.5 -- I can't NAT it and give the server the address 192.168.2.4 in the DMZ. (Don't ask. *shudder*) Can I set up a bridge between sis0 and sis2 so that traffic for 1.2.3.5 gets passed through to the server via sis2 as well as having the IPv4 address 1.2.3.4 on sis0? Or is there a better way to do this? --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] I personally would check to see if you could get a /30 routed to 1.2.3.4. 5.6.7.8 - 5.6.7.11 Append one of the /30 to the sis2 interface, and the other to your new server. If 1.2.3.4 1.2.3.5 are part of a bigger block that you own, see if you can't allocate a /30 from that larger pool. ( 1.2.3.8 - 1.2.3.11 ?? ) Shane
Re: Is VPN initiation by traffic possible?
Heya On Fri, Apr 15, 2011 at 10:37 PM, Reyk Floeter r...@openbsd.org wrote: Hi Nemir! Short answer: Yes, it works. ... Regards, reyk The question remains, how does the connection get torn down? Or, in another fashion, how does the OpenBSD IPSEC implementation tell the remote IPSEC implementation that the VPN is not currently required and to de-register the Active SA? Shane
Re: Is VPN initiation by traffic possible?
Heya On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern sc...@blackstaff.cawrote: On 04/13/11 09:38, Randal L. Schwartz wrote: Scott == Scott McEachernsc...@blackstaff.ca writes: Scott It's called port knocking. Google is your friend here. And if you recommend or use port knocking, you're an amateur at crypto. If adding 8 sniffable bits to your effective key length makes you significantly more secure, you've lost the game already. I'm not advocating it, but it is what he's asking about. I should have added This is not a good idea, but I was hoping he'd figure that out by reading about it. Nemir, you might want to go back and find out exactly what problem the bank is trying to solve with their idea. Actually from what I read in his email, it isn't Port knocking he is after. What the Bank likely wants is to not have any n+ client(s) out of however many maintaining a permanent VPN through their infrastructure, thereby leading to a potential DoS for their other clients. ( based on several appliances having hardware / licensing limitations on how many concurrently active VPNs are running at once ) Thus what the Bank would like is for the VPN connection to be torn down after the relevant data is transmitted. And no, I don't see a disconnect option after a brief read of the IPSEC man pages either. Shane
Re: Is VPN initiation by traffic possible?
Heya On Thu, Apr 14, 2011 at 8:05 AM, Matt S maschwa...@yahoo.com wrote: You might consider a creative solution with Dead Peer Detection. Per ipsec.conf(4), you enable Dead Peer Detection by using an ike dynamic statement. One thing that came to mind for manual configuration is an authpf shell or equivalent... On connection by that shell account, manually bring up the IPSEC connection, on disconnect bring it down. That way you have the internal server wanting to communicate have some control over when the VPN is active. But yes, the focus does seem to be on how you can automate an otherwise currently manual function. Shane
CARP Advertisement Issue
Heya In the network: OpenBSD Firewall (x2) -- Metropolitan Layer 2 Network -- ISP(s) CARP advertisements are forming some 7% of the 'noise' traffic across the Metro L2 resulting in complaints from other clients of the Metro L2 provider. All production and testing done with: OpenBSD 4.0 release + errata OpenBSD 4.1 release + errata I have read through the 4.1 to 4.2 changes documentation (http://www.openbsd.org/plus42.html). I can see nothing there that would alter the below results. Thanks in advance for all suggestions and/or recommendations. I have some Feature Requests as a result of this testing, but will hold off on those until feedback is received. :) Upon receiving a request from the L2 provider, we thought of or tried the following: * Unicast CARP advertisements; Unlike pfsync, CARP does not currently have support for Unicast communications. * lladdr filtering by the L2 provider; All of the CARP advertisements are coming from the shared lladdr of the carp interface, not from the lladdr of the carpdev's. (True also on the other carp interfaces.) * netstart + pf + ifstated; Start the external facing carpdev's configured and down and the internal facing carpdev's configured and up on boot. Use pf to explicitly allow CARP advertisements on the internal facing carpdev's and block all others (including the external facing carpdev's). Use ifstated to monitor the state changes on the internal facing carp devices. Run 'ifconfig $carp [up|down]' on the external facing carp devices depending upon the state of the internal facing carp devices. /etc/netstart currently does not deal with configuring and then setting an interface to down upon boot. example /etc/hostname.if: inet 192.168.0.1 255.255.255.0 NONE down CARP seems inconsistent in its handling of the carpdev status. Discovered that upon booting with all physical cables unplugged that carp interfaces enter master state despite carpdev's (em - Intel PRO/1000 10/100/Gigabit Ethernet devices) not having physical network connectivity. In general, this setup is not considered an optimal solution anyway. Thanks Again Shane Lazarus Infrastructure Engineer DataTorque +64 21 529278 [EMAIL PROTECTED]
