Re: PC-Engines Wireless - PPPOE timeouts.

[Patrick Dohman]

Todd

At this point I’ve elected to evaluate a MSS of 1452 to determine if a
theoretical max is beneficial.

In addition I’m currently testing a fixed MTU of 1492 on one LAN interface
in conjunction with my PS4 console.

Based on troubleshooting this afternoon it appears the number of device
interrupts has decreased by “thirty" percent.

When possible I’ll install 6.0 & hopefully configure the APUs RE(4) NICs
with (baby jumbo's) CenturyLink allowing.

Regards
Patrick

> On Dec 20, 2016, at 2:13 PM, Todd C. Miller 
wrote:
>
> On Tue, 20 Dec 2016 08:58:43 -0600, Patrick Dohman wrote:
>
>> I'm currently running a ZyXEL C1100Z VDSL2 modem.
>>
>> At this point the hardware WAN interface (RE1) is configured with an MTU
of
>> 1500
>>
>> In addition the PPPOE interface is configured with an MTU of 1492
>
> Are you setting the MSS to 1440 in pf.conf as per the pppoe man
> page?  If not, you should.  See the section on MTU/MSS ISSUES.
>
> I've tried using an MTU of 1508 on the ethernet interface (baby
> jumbos) but didn't get it working with Quest/Centurylink VDSL2.
> Presumably their equipment doesn't support RFC 4638.
>
> - todd

Re: PC-Engines Wireless - PPPOE timeouts.

[Todd C. Miller]

On Tue, 20 Dec 2016 08:58:43 -0600, Patrick Dohman wrote:

> I'm currently running a ZyXEL C1100Z VDSL2 modem.
> 
> At this point the hardware WAN interface (RE1) is configured with an MTU of
> 1500
> 
> In addition the PPPOE interface is configured with an MTU of 1492

Are you setting the MSS to 1440 in pf.conf as per the pppoe man
page?  If not, you should.  See the section on MTU/MSS ISSUES.

I've tried using an MTU of 1508 on the ethernet interface (baby
jumbos) but didn't get it working with Quest/Centurylink VDSL2.
Presumably their equipment doesn't support RFC 4638.

 - todd

Re: spamd and network whitelisting

[Craig Skinner]

Hello Clint,

On Fri, 16 Dec 2016 07:21:47 -0700 Clint Pachl wrote:
> I would like to share my 45-day experience with running spamd and my 
> observations and how I'm allowing mail from SMTP clusters to bypass 
> spamd. Feedback and discussion would be greatly appreciated.
> 

spamd in greylisting mode is indeed truly awesome!

With over 10 years real world experience running this way,
with several domains, I've tried a lot of ideas & scripts too...

The original design is very good and doesn't need much assistance.

To solve the clustered round robin senders (Gmail, etc.) simply bump
the -G:greyexp: time from 4 hours to 4+ days - 100 hours is good.
Job done! No scripts needed.

When configured like this, most gmails come through in around 6 hours
to 1.5 days, with some a bit longer. The more inbound gmails, the
shorter the delay, down to a few minutes as volume increases.
Same for Outlook, Amazon, (which are both worse than Gmail) etc,

Bumping the -G :whiteexp time to 40 days helps a bit too.


Aggressive stuttering and a shrunk window foils almost all zombies.

Add in a fake highlisting -M to the mix, and it is game over for the
zombies, which love to target a backup MX box, so give them a trap.
(This needs a constantly deferring MTA on that IP address too.)

spamd_flags='-G 25:100:960 -S 90 -s 5 -w 1 -M  -y  -Y ... -Y ... -Y ...'
spamlogd_flags='-I -W 960 -Y ... -Y ... -Y ...'

(AOL only retries for 25 minutes (not the RFC 4 days), so if you
want to receive from AOL, the -G passtime: needs to be ~10 minutes.)


Some pf rate limiting kills off those zombies that understand the 'try
again later' SMTP code, then start hammering the server all at once:

The 2nd rule blocks (after almost 2 days) badly setup M$ Extrange
servers, which retry every minute


set block-policy drop

# Normal & highlisting Internet inbound operation via spamd:
pass in on $ext_if inet proto tcp \
from any port > 1023 \
to {$ext_if:0, $ext_if:2} port smtp \
divert-to localhost port spamd \
keep state \
(max-src-conn 30, max-src-conn-rate 50/9, \
overload  flush global)

pass in log on $ext_if inet proto tcp \
from  port > 1023 \
to {$ext_if:0, $ext_if:2} port smtp \
user root \
modulate state \
(max-src-conn 80, max-src-conn-rate 150/15000, \
overload  flush global)


block in log from 


EASY! SIMPLE! Nothing to break.

No special domain lookups or exception lists. No maintenance labour.





Bob's other tool I deployed for many years was his greyscanner (in
ports). Over the years, I modified this to do aggregate DNS black &
white listing too. When I realised that it was very rare for spam to
pass the extended stuttering, I stopped running greyscanner.




Reverting to the default -G flags (4 hours grey expire), and help
promote round robin senders faster from grey to white, I wrote this
simple script. It runs unprivileged once every 4 hours from cron.

No pf tables/lists, no doas/sudo rules. No SPF checks.

It operates on an fgrep pattern of spamd HELO hostnames, as Gmail,
Outlook, etc. relay for many domains, but HELO from Google/Outlook.

The decision to upgrade from grey to whitelisted status is based on
an accumulated sliding score of multiple DNS list lookups.

See http://web.Britvault.Co.UK/products/ungrey-robins/ & logs there.




Also try Boudewijn's patch (see his continued blocking graph):
https://github.com/bdijkstra82/OpenBSD-spamlogd


> 
> Thanks to all the developers who made spamd; an amazing, simple,
> clever tool.
> 

Aye!
-- 
Craig Skinner | http://linkd.in/yGqkv7

Re: PC-Engines Wireless - PPPOE timeouts.

[Patrick Dohman]

Holger

I’m currently running a ZyXEL C1100Z VDSL2 modem.

At this point the hardware WAN interface (RE1) is configured with an MTU of
1500

In addition the PPPOE interface is configured with an MTU of 1492

Please see below for more info:

[patrick@Firewall etc]$sysctl -a | grep ifq
net.inet.ip.ifq.len=0
net.inet.ip.ifq.maxlen=256
net.inet.ip.ifq.drops=0
net.inet6.ip6.ifq.len=0
net.inet6.ip6.ifq.maxlen=256
net.inet6.ip6.ifq.drops=0
net.mpls.ifq.len=0
net.mpls.ifq.maxlen=256
net.mpls.ifq.drops=0



Please note the router was rebooted to test previously mentioned PF changes
excluding the conservative optimization which appears to be needed.


[patrick@Firewall etc]$sudo pfctl -si
Password:
Status: Enabled for 0 days 11:04:33  Debug: err

State Table  Total Rate
 current entries   82
 searches   11655637  292.3/s
 inserts196210.5/s
 removals195390.5/s
Counters
 match  22179  0.6/s
 bad-offset  00.0/s
 fragment00.0/s
 short  00.0/s
 normalize  00.0/s
 memory 00.0/s
 bad-timestamp  00.0/s
 congestion00.0/s
 ip-option00.0/s
 proto-cksum  00.0/s
 state-mismatch10   0.0/s
 state-insert00.0/s
 state-limit  00.0/s
 src-limit 00.0/s
 synproxy   00.0/s
 translate   12   0.0/s


Regards
Patrick

> On Dec 19, 2016, at 3:40 AM, Holger Glaess  wrote:
>
> hi
>
> what kind of DSL you have ( DSL or VDSL2 ) ?
>
> if you use VDSL2 is AUTO MTU Active ? ( Mother Interface
> have to be set to MTU 1508 , and no MTU Setting das the PPPOE
> Interface.)
>
> what says pfctl -si ( Line congestion  )
>
> what say sysctl -a | grep ifq ?
>
> holger
>
>
>
>
>> Stuart
>>
>> Thanks for the reply
>>
>> At this point it appears a specific LAN client “PS4” is
responsible
>> for a
>> high number of device interrupts.
>>
>> Hoping to clarify if interrupts In excess of “3000” can cause
PPPOE
>> timeouts.
>>
>>
#
>> #
>> Lan Streaming cat5 no switch
>>
>> procsmemory   pagedisk traps  cpu
>> r b wavm  fre  flt  re  pi  po  fr  sr sd0  int   sys   cs us
>> sy
>> id
>> 1 0 0  18636 38255601   0   0   0   0   0   0 6872 7   10  0  9 91
>> 0 0 0  18636 38255601   0   0   0   0   0   0 2163 79  0  4 96
>> 0 0 0  18636 38255601   0   0   0   0   0   0 1921 9   11  0  2 98
>> 0 0 0  18636 38255601   0   0   0   0   0   0 1943 69  0  3 97
>> 0 0 0  18636 38255601   0   0   0   0   0   0 1705 69  0  3 97
>> 0 0 0  18636 38255601   0   0   0   0   0   0 1849 8   10  0  3 97
>> 0 0 0  18636 38255601   0   0   0   0   0   0 2276 69  0  4 96
>>
>>

>> Wlan Streaming
>>
>> procsmemory   pagedisk traps  cpu
>> r b wavm freflt  re  pi  po  fr  sr sd0  int   sys   cs us
>> sy
>> id
>> 1 0 0  18632 38257321   0   0   0   0   0   0  368 7   10  0  1 99
>> 0 0 0  18632 38257321   0   0   0   0   0   0  365 8   10  0  2 98
>> 0 0 0  18632 38257321   0   0   0   0   0   0  355109  0  1 99
>> 0 0 0  18632 38257321   0   0   0   0   0   0  362 9   10  0  2 98
>> 0 0 0  18632 38257321   0   0   0   0   0   0  356 8   10  0  1 99
>> 0 0 0  18632 38257321   0   0   0   0   0   0  36110   10  0  1 99
>> 0 0 0  18632 38257321   0   0   0   0   0   0  365 9   10  0  2 98
>> 0 0 0  18632 38257321   0   0   0   0   0   0  383 8   10  0  1 99
>>
>>
#
>> No Lan or Wlan traffic
>>
>> procsmemory   pagedisk traps  cpu
>> r b wavm fre flt  re  pi  po  fr  sr sd0  int   sys   cs
>> us sy
>> id
>> 1 0 0  18628 38257361   0   0   0   0   0   0   24 8   10  0  0
>> 100
>> 0 0 0  18628 38257361   0   0   0   0   0   0   23 69  0  0
>> 100
>> 0 0 0  18628 38257361   0   0   0   0   0   0   28 69  0  0
>> 100
>> 0 0 0  18628 38257361   0   0   0   0   0   0   24 8   10  0  0
>> 100
>> 0 0 0  

Re: doas prompting for password in script

[Stuart Henderson]

On 2016-12-15, Ax0n  wrote:
> I don't know how doas is keeping track of a session.

It's using a kernel "verified auth" feature. See tty(4) :

   TIOCCHKVERAUTH void
   Check the verified auth status of this session.  The calling
   process must have the same real user ID and parent process as
   the process which called TIOCSETVERAUTH.  A zero return
   indicates success.

Re: Openbgpd emulation on GNS3

[Stuart Henderson]

On 2016-12-15, Marko Cupać  wrote:
> Lat time I checked some 8 years ago when I was preparing my CCNA, GNS3
> was visual front-end to dynamips/dynagen cisco ios emulator and lab
> provisioning tool.
>
> In which way is this related to OpenBSD? Do you use OpenBSD as a OS
> where you install GNS3 package? Or are you bridging emulated cisco
> router to real network and trying to make it talk BGP to OpenBSD?

It can run qemu instances too.

Re: spamd and network whitelisting

[Clint Pachl]

Devin Reade wrote on 12/19/16 12:59:

You might also want to look at bgp-spamd.


Yes, this was on my radar for quite some time. However, my simple spamd 
setup with assistance from the zen.spamhaus.org DNSBL has been extremely 
effective. It's nice to know we've got more big guns if needed.




With respect to dealing with SPF, the simple solution (permitting an
IP if it is on the sending domain's SPF list) doesn't work too well
in the general case since it appears many spammers publish SPF records.


You're right. When I ran ruby-spf against the the TRAPPED IPs in my 
spamdb, a surprising number passed SPF (like 15%). On the other hand, 
one of the popular email domains from our customer DB is @att.net, which 
doesn't even publish SPF. After some real life testing against our 
client email DB, I determined SPF was not effective in filtering spam 
for us. If it is used, it should be a small factor at best.

Re: rsyslog does not produce log on OpenBSD 6.0

[Stuart Henderson]

On 2016-12-17, Remi Locherer  wrote:
> On December 17, 2016 12:07:18 PM GMT+01:00, Federico Donati 
>  wrote:
>>Hi all,
>>
>>I've a problem with an OpenBSD 6.0 box with rsyslog.
>>
>>I need to send every local logs to a remote server and I can't use 
>>syslogd, because it does not send the hostname of the server (the one 
>>indicated in /etc/myname), but on the remote server messages come with 
>>the PTR record of my public ip.
>
> have you tried -h for syslogd from base?

Yep this is the easy way.

>>I've installed rsyslogd, but it doesn't send anything to the remote 
>>server. And more than that, it doesn't write anything local.

Since 5.6, OpenBSD uses a special sendsyslog(2) system call for
logging. This avoids the need for a device node and available file
descriptor, which helps with chrooted programs, or if someone is
able to cause too many FDs to be opened in an attempt to prevent
logging from working.

It needs a syslogd that is able to receive these messages. It's a
fairly simple change (see src/usr.sbin/syslogd/syslogd.c r1.111)
but afaik none of the third-party log daemons support it yet.
It's quite likely that diffs to add support for this to other
daemons would be accepted for ports, maybe upstreams would accept
them too.

Workaround for this without modifying the syslog daemon:
- run normal OpenBSD syslogd in addition to the other daemon
- have the other syslog daemon bind to a specific IP address
- have OpenBSD syslogd feed the other daemon using a network socket

Re: spamd and network whitelisting

[Clint Pachl]

Some have requested my scripts and configurations so here it is. Below 
you fill find the spamd-dnsbl and spamclusterd scripts that are used for 
blacklisting spammers and whitelisting networks, respectively. Also 
included is dnsbl-check which I use for testing IPs against multiple DNSBLs.


In the crontab below, you will see that I archive the spamdb daily and 
save some stats mainly for post analysis. For instance, my initial spam 
fighting technique many years ago (prior to enabling spamd actually) was 
to block the IP networks (20,000+ IPv4 networks) of the countries in 
which we received the most spam, yet weren't expecting legitimate email 
from (i.e. China, Russia, India, Brazil, etc.). I still had this enabled 
up until 2016-12-17. So I make notes of changes like this to see the 
positive or negative effects and I have the spamdb archives to assist 
the analysis. Changing spamd_flags is something else I document.


A side note: Years ago, blocking spamming countries, for me here in the 
US, essentially got rid of my spam problem, but has become ineffective 
as many spammers are sending from US networks now, thus spamd. It has 
only been three days since I disabled spam country blocking, but I have 
received exactly 2 emails that have made it pass spamd, which would have 
otherwise been blocked by the country IP block. Not bad, but we'll see 
what the stats look like in a couple of weeks. However, I can guarantee 
that the number of trapped entries in my spamdb will increase. I 
originally created my pf table of spamming countries from 
http://www.ipdeny.com/ipblocks/data/countries/


One of the other tests, which had significant impact, was using 
spamd.alloweddomains. I tried a few things, but settled on my current 
setup: for one email domain I list just the domain part (e.g. 
@domain1.com), but for the other domain, which has limited users, I list 
the full email addresses of all current accounts (e.g. 
us...@domain2.com, us...@domain2.com, ...). This increased my TRAPPED 
entries by 30%. These additional TRAPPED IPs were mainly one-shot 
spammers, so it was nice to tarpit them while I had the chance. So far 
spamd has been very effective so I haven't defined and published any 
SPAMTRAP addresses, but this is just another knob I can turn on and 
measure if needed.


To assist with spam management without root privileges, I added the spam 
administrator to the _spamd group, gave r/w group privileges on 
/var/db/spamd, and added a few pfctl commands to the doas.conf.


Overall I am ecstatic about spamd and its integration with pf, as well 
as the simple spamdb interface (with the help of grep(1), cut(1), 
sort(1), wc(1), column(1), sed(1), etc.). It is an extremely flexible 
and powerful toolset. Hopefully my experience and scripts are helpful to 
other spam fighters. I think you can look to other projects, like 
spamassassin for example, to get ideas of spam fighting techniques which 
can be implemented at a lower level using pf and spamd. For example, a 
set of factors could determine a spam "score" similar to spamassassin: 
if an IP is on multiple DNSBLs (each list weighted by quality), the DNS 
PTR doesn't correspond to the HELO, and it fails SPF, then it is 
probably safe to blacklist. The bgp-spamd.net project is another tool 
that could be added to the mix. You will have to balance complexity and 
effectiveness, but I would encourage simplicity and minimal resource usage.


Again, hats off to all the developers.


=== spamclusterd ===

#!/bin/sh
#
# Whitelist an SMTP cluster network.
#
# NOTE: pipe spamdb(8) or an archive to stdin.

extract_helo_tld() { echo "$1" | sed -En 's/.*[[:<:]]([^.]+\.[^.]+)$/\1/p'; }
extract_ip_net() { echo "${1%.*}"; }

print_ip_net_with_mask() {
echo "$(extract_ip_net $1).0/24"
}

helo_tld_match()
{
tld1=$(extract_helo_tld "$1")
tld2=$(extract_helo_tld "$2")
[[ -n $tld1 && $tld1 = $tld2 ]]
}

ip_net_match()
{
net1=$(extract_ip_net $1)
net2=$(extract_ip_net $2)
[[ $net1 = $net2 ]]
}

_ip=""
_helo=""
_from=""
_to=""
is_cluster=0

grep "^GREY" |
tr "|" "\t" |
cut -f2-5 |
sort -k3,4 -k2 -k1 |
while read ip helo from to
do
if [[ $to = $_to && $from = $_from ]] &&
   helo_tld_match "$helo" "$_helo" &&
   ip_net_match "$ip" "$_ip"
then
is_cluster=1
elif [[ $is_cluster = 1 ]]
then
is_cluster=0
print_ip_net_with_mask $_ip
fi

_ip="$ip"
_helo="$helo"
_from="$from"
_to="$to"

done




=== spamd-dnsbl ===

#!/bin/sh
#
# Query DNSBL using the IPs in spamdb(8). If an IP is on a black list, add it
# as a TRAPPED entry in the spamdb.
#
# It seems most spammers send once and go away. The 1 minute pass time is
# effective at stopping most of these spammers. The other spammers seem to
# resend 10 minutes to more than an hour later, so a longer pass time won't
# defend against such spammers. 

Re: Manual update

[Marc Peters]

Am 12/19/16 um 19:01 schrieb Todd Carpenter:
> Hi All,
> 
> I recently installed 6.0 and was struggling to get my softraid0 stripe to
> build properly and or boot.  I went over section 14 carefully and did some
> research.  The part that I found was missing was the creation of a 100 meg
> partition on the A slice and how to successfully create a bootable raid
> stripe. (I'm sure there is something somewhere that I missed, but I thought
> it would be awesome to include step #2 and #3 in the raid setup)

That's not needed anymore. On the page you mention, it states clearly:

"[...] and booting from softraid devices isn't supported on all of them.
It's currently only possible to boot from RAID1, RAID5 and crypto
volumes on i386, amd64 and sparc64."

The same in the manpages:
http://man.openbsd.org/?query=boot=0=8=default=OpenBSD-current

As this already works for me on several systems, i assume that something
with your process is wrong here. Or you messed up your upgrade (yes, i
upgraded some of the machines).

Hth,
Marc