Re: httpd and wordpress
On 06/03/17 20:52, Markus Rosjat wrote: Hi there, well if it would be up to me I would skip wordpress for good but well it's not my decition. So I was wondering if there is some recommendations on what to block in the httpd.conf and what file permissions to use. For now I have: - like wordpress suggest 0755 on dirs and 0644 on files - wp-config.php setting to 0400 is not going to work at all I need at least a 0644 or nothing shows up - in http.conf I blocked /wp_content , /wp-content /uploads/*.php, /wp-includes, /wp-includes/*.php and /wp-admin so if there is something I can do further to harden things just let me know :) advice is most apreciated Regards Running WPScan[1] against your WordPress installation can be useful to check that your WordPress install isn't too full of holes. Cheers Fred [1]https://github.com/wpscanteam/wpscan
bgp-spamd added 192.43.244.163
hi there, just had some strange encounter, I was wondering why I don't get mail from this list for a while. So I did some digging and found that even 192.43.244.163 was whitelisted with like 32k mails delivered there are also GREY entries for this ip. so I checked my blacklists, nothing to find and then I thought okay check the list from the bgp-spamd project and to my surprise I found 192.43.244.163 in the table. I deleted it and my mails from this list coming in again. since I didnt do anything lately on my setup I wonder if someone else had this encounter. regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
httpd and wordpress
Hi there, well if it would be up to me I would skip wordpress for good but well it's not my decition. So I was wondering if there is some recommendations on what to block in the httpd.conf and what file permissions to use. For now I have: - like wordpress suggest 0755 on dirs and 0644 on files - wp-config.php setting to 0400 is not going to work at all I need at least a 0644 or nothing shows up - in http.conf I blocked /wp_content , /wp-content /uploads/*.php, /wp-includes, /wp-includes/*.php and /wp-admin so if there is something I can do further to harden things just let me know :) advice is most apreciated Regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Trivial bug in installer's .profile
Job control is disabled prior to setting up the auto-install timeout. It is then re-disabled when the timer has been started. The second set +m should be set -m or be removed. # Stop monitoring background processes to avoid printing # job completion notices in interactive shell mode. This # doesn't stop the "[1] " on starting a job though; # that's why re redirect stdout and stderr temporarily. set +m exec 3<&1 4<&2 >/dev/null 2>&1 (sleep 5; kill $$) & timer_pid=$! exec 1<&3 2<&4 3<&- 4<&- set +m Matthew
Question about p2p OpenVPN interfaces
Hi, I’m currently experimenting to run OpenBGPD over OpenVPN p2p links (not the common /30 or /31 interconnection network we can see on Internet). It works great for the BGP part, but the exported routes to the kernel does not correspond to the BGP ones. For exemple, if I look for the route to 172.23.0.53, it should goes via 172.22.141.148 according to BGPD: # bgpctl show rib 172.23.0.53 flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *>172.23.0.48/28 172.22.141.148 100 0 64737 i * 172.23.0.48/28 172.23.67.1100 0 4242420022 i * 172.23.0.48/28 172.20.31.252 100 0 4242423957 64737 i * 172.23.0.48/28 172.20.190.129 100 0 4242423759 4242420022 i * 172.23.0.48/28 172.22.159.239 100 0 4242420812 4242420022 i But if I do the same query on the kernel table, the route is set thought tun3: # route get 172.23.0.53 route to: 172.23.0.53 destination: 172.23.0.48 mask: 255.255.255.240 gateway: 172.23.135.129 interface: tun3 if address: 172.23.135.129 priority: 48 (bgp) flags: use mtuexpire 463 0 0 # ifconfig tun3 tun3: flags=8051 mtu 1500 index 8 priority 0 llprio 3 groups: tun status: active inet 172.23.135.129 --> 172.20.44.1 netmask 0x inet6 fe80::8db:5e3f:eb64:fb57%tun3 -> prefixlen 64 scopeid 0x8 inet6 fd40:9dc7:b528:1::2 -> prefixlen 64 But, 172.22.141.148 (the BGP gateway) is on tun1: # ifconfig tun1 tun1: flags=8051 mtu 1500 index 23 priority 0 llprio 3 groups: tun status: active inet 172.23.135.129 --> 172.22.141.148 netmask 0x inet6 fe80::8db:5e3f:eb64:fb57%tun1 -> prefixlen 64 scopeid 0x17 inet6 fd40:9dc7:b528:35::1:1 -> prefixlen 112 Am I missing something obvious or is it a bug? Thanks for your help, -- alarig signature.asc Description: PGP signature
Re: OpenBSD 6.1 current relayd TLS error "cannot load certificates"
On Fri, Jun 02, 2017 at 08:38:50PM -0700, Dillon Jay Pena wrote:
> I'm not understanding why I'm getting a relayd error. Thanks in advance.
>
> According to
> http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/relayd.conf.5#listen_on,
> I just need address.crt and private/address.key to use tls with
> relayd, which you can see I do below.
> So why am I getting the relayd error "cannot load certificates for relay www"?
>
> I have included how I got the key and crt files from acme-client/lets
> encrypt in case it's relevant.
>
>
> $ uname -prsv
> OpenBSD 6.1 GENERIC#88 amd64
>
> $ cat /etc/acme-client.conf
> #
> # $OpenBSD: acme-client.conf,v 1.4 2017/03/22 11:14:14 benno Exp $
> #
> authority letsencrypt {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
> api url "https://acme-v01.api.letsencrypt.org/directory";
> account key "/etc/acme/letsencrypt-privkey.pem"
> }
>
> authority letsencrypt-staging {
> agreement url
> "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf";
> api url "https://acme-staging.api.letsencrypt.org/directory";
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
>
> domain thelang.space {
> alternative names { mail.thelang.space www.thelang.space }
> domain key "/etc/ssl/private/thelang.space.key"
> domain certificate "/etc/ssl/thelang.space.crt"
> domain full chain certificate "/etc/ssl/thelang.space.fullchain.pem"
> sign with letsencrypt
> challengedir "/var/www/htdocs/.well-known/acme-challenge"
> }
>
> $ doas acme-client -vAD thelang.space
> acme-client: /etc/ssl/private/thelang.space.key: domain key exists
> (not creating)
> acme-client: /etc/acme/letsencrypt-privkey.pem: account key exists
> (not creating)
> acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
> acme-client: acme-v01.api.letsencrypt.org: DNS: 104.68.109.156
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: mail.thelang.space
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz:
> req-auth: www.thelang.space
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/hALHIbtLAX4k274bN4AFBV0W-T08pKTqD6lBw0-CplM:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> challenge
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/SMwY0p1ma9ZDQrlyM6h9BbZkEnMCKx2lW69__zcmCgI:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> challenge
> acme-client:
> /var/www/htdocs/.well-known/acme-challenge/wu3Zhef8NA8b9wmxHeMjXBZCg3EKGHgnM30Tx_qn1Ws:
> created
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> challenge
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/mempVpv498Gw4d7Wr24qcinn5ZUfX_6IO2kQOeskf40/1271082083:
> status
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/bwNrTgnJmUIH-XqInRMDmRNgRMnXQKBUZngPi3wuHt4/1271082087:
> status
> acme-client:
> https://acme-v01.api.letsencrypt.org/acme/challenge/fHeHrAzF9RAXO-eJMZxfWElhkf4duUw934pUWy2gWyM/1271082092:
> status
> acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificate
> acme-client: http://cert.int-x3.letsencrypt.org/: full chain
> acme-client: cert.int-x3.letsencrypt.org: DNS: 165.254.42.42
> acme-client: /etc/ssl/thelang.space.crt: created
> acme-client: /etc/ssl/thelang.space.fullchain.pem: created
>
> $ cat /etc/relayd.conf
> table { 127.0.0.1 }
>
> relay www {
> listen on thelang.space port 443 tls
>
> forward to check tcp port 8080
> }
>
> $ doas relayd -d
> startup
> /etc/relayd.conf:7: cannot load certificates for relay www
> no actions, nothing to do
> hce exiting, pid 2324
> pfe exiting, pid 21204
> ca exiting, pid 18722
> ca exiting, pid 45718
> ca exiting, pid 79639
> relay exiting, pid 31292
> relay exiting, pid 32940
> relay exiting, pid 75225
>
> $ ls /etc/ssl/thelang.space.crt
> /etc/ssl/thelang.space.crt
> $ doas ls /etc/ssl/private/thelang.space.key
> /etc/ssl/private/thelang.space.key
>
> - Dillon
>
Hey,
ktrace is also useful help here.
# ktrace relayd -d -v
# kdump ...
I've had a similar thing to debug listening on IPV6 interface(s).
Hope this helps you,
--
Kind regards,
Hiltjo
Re: Multi-path router with ftp-proxy problem
On Fri, Jun 02 2017 at 42:07, cdix wrote: > I have the same problem. > Did you ever found a resolution for your problem? > If so what was it? > Hi, FTP has one command tcp connection and one dynamic data connection that makes an entire applicative session. In order FTP to work, it needs both connections to be established on the same dsl link. With that information, you can try to buil a setup to achieve that goal or, as I did years ago, ended with lines as active/passive modes because load balancing of FTP can result in a very complicated setup. Depending on the aim, having a simpler setup is sometimes better than having an overengineered one. Think of maintaining your setup through years. Also, don't forget we are in 2017, not 2013 anymore. Personally I removed FTP support from my gateways. Regards,
