Re: sshd Connection Failures - 2 June Snapshot (amd64)

[Darren Tucker]

On Sun, Jun 5, 2016 at 7:40 AM, Alex Greif  wrote:
[...]
> hash mismatch
> debug1: ssh_rsa_verify: signature incorrect
> key_verify failed for server_host_key

Thanks for the report.  We believe we've identified the problem and
backed out the offending commit in usr.bin/ssh/kexgexs.c rev 1.29.

The original change was this one to kexgexs.c:

revision 1.28
date: 2016/06/01 04:19:49;  author: dtucker;  state: Exp;  lines: +9
-9;  commitid: H7nQMlahTocwHINf;
Check min and max sizes sent by the client against what we support before
passing them to the monitor.  ok djm@

It caused the problem because it modified the value that had already
been sent to the client so it computed the exchange hash it didn't
match what the server computed.

It didn't cause more problems (or fail the regression tests, which I
ran, honest!) because any client that send a min group size >-
DH_GRP_MIN (2048 since OpenBSD 5.9) thus didn't cause the min value to
be modified, and any client that preferred another key exchange method
(most recent versions of OpenSSH) never triggered the problem.

Sorry for the inconvenience.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: FOSS tools for flashing motherboard BIOS?

[Alan Corey]

> Are you sure there is no iso image with self boot and update, ready to
> be burned on a cdrom? I don't know for sure, but I think last time I
> was using that. I don't own HP gear, but IBM/Lenovo has this kind of
> iso image and I've used it a lot.

Not as far as I can tell, and the guy at HP support I've been chatting
with maintains that Vista is the only way to do it.  I remember Vista
beta came on DVD it was so big.  I used Rufus (Windows freeware) to
load my XP ISO onto an SD card and boot from it to install XP on a
hard drive, then did the BIOS update from that.  Dell would have a
more practical solution too.  I think they had self-extracting files
that wrote an image onto a boot floppy last time I needed to use one
about 2009.  Being tied to Vista?  Yuck.

-- 
Credit is the root of all evil.  - AB1JX

Re: [pf] NAT64 rule for *outgoing* packets

[Dan Lüdtke]

Follow-up:

This rule matches outgoing packets to nat64 well-known prefix 64:ff9b::/96:
pass out quick on $if_wan inet6 from $if_wan:network to 64:ff9b::/96 af-to
inet from ($if_wan)

Echo requests do leave $if_wan with translated address family, replies show up
in tcpdump on $if_wan:

19:09:54.038392 router > 8.8.8.8: icmp: echo request (DF)
19:09:54.051733 8.8.8.8 > router: icmp: echo reply

BUT the echo replies do *not* make it through to the ping6 process. It looks
like there is no back-translation taking place. Anyone ideas how to debug or
follow packets on their way through the kernel for this issue?

Cheers,

Dan



> On 7 Jun 2016, at 14:48, Dan Lüdtke  wrote:
>
> Hi,
>
> my setup: [host]--[router]--[internet]
>
> [Host] can ping legacy internet hosts via NAT64. Works fine. Corresponding
> line in pf.conf reads:
> pass in  quick on $if_lan inet6 from $if_lan:network to 64:ff9b::/96 af-to
> inet from ($if_wan)
>
> However, [router] can not ping legacy internet hosts via NAT64. It can, of
> course, reach legacy internet hosts natively.
>
> How to push outgoing traffic addressed to 64:ff9b::/96 through pf's NAT64
> engine?
>
> Cheers,
>
> Dan
>
>
>
> Some outputs FYI:
>
> router# route get 64:ff9b::/96
> route: writing to routing socket: No such process
>
>
> router# ping6 64:ff9b::8.8.8.8
> PING6 64:ff9b::8.8.8.8 (64:ff9b::808:808): 24 data bytes
> ^C--- 64:ff9b::8.8.8.8 ping6 statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss

Re: SYN_RCVD

[Peter J. Philipp]

On 06/07/16 15:33, Claudio Jeker wrote:
> On Tue, Jun 07, 2016 at 09:35:39AM +0200, Peter J. Philipp wrote:
>> On 06/06/16 21:57, Claudio Jeker wrote:
>>> OpenBSD uses the syncache for TCP sockets in the 3 way handshake to save a
>>> lot of work to create a full socket in case of synfloods, etc.
>>> These unhatched sockets do not show up in the netstat output. Maybe they
>>> should be added but this is the first request that asks for them in the
>>> 10+ years we use the syncache.
>>>
>> Thanks for the history of this Claudio.  I am not really asking for them
>> I just wanted to know where they went.  It's good to know that a
>> LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
>> have another question though.   How would an administrator tell I'm
>> getting SYN flooded without the hunch that something is going on and
>> jumping on tcpdump and doing packet accounting?  How would you determine
>> a syn flood?
>>
> There are some counters in netstat -sptcp output. In particular:
> 532358 SYN packets dropped due to queue or memory full
> 770174566 SYN cache entries added
> 0 hash collisions
> 768118448 completed
> 6 aborted (no space to build PCB)
> 905577 timed out
> 0 dropped due to overflow
> 0 dropped due to bucket overflow
> 1150155 dropped due to RST
> 0 dropped due to ICMP unreachable
> 7036108 SYN,ACKs retransmitted
> 13117384 duplicate SYNs received for entries already in the cache
> 2580 SYNs dropped (no route or no space)
>
> In syn floods hash collisions, and overflow drops will increase a lot.
> As you can see in normal operation those counters are normally 0.
>

Perfect!  Thanks also to everyone else who replied.

Cheers,
-peter

Re: SYN_RCVD

[Claudio Jeker]

On Tue, Jun 07, 2016 at 09:35:39AM +0200, Peter J. Philipp wrote:
> On 06/06/16 21:57, Claudio Jeker wrote:
> > OpenBSD uses the syncache for TCP sockets in the 3 way handshake to save a
> > lot of work to create a full socket in case of synfloods, etc.
> > These unhatched sockets do not show up in the netstat output. Maybe they
> > should be added but this is the first request that asks for them in the
> > 10+ years we use the syncache.
> >
> 
> Thanks for the history of this Claudio.  I am not really asking for them
> I just wanted to know where they went.  It's good to know that a
> LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
> have another question though.   How would an administrator tell I'm
> getting SYN flooded without the hunch that something is going on and
> jumping on tcpdump and doing packet accounting?  How would you determine
> a syn flood?
> 

There are some counters in netstat -sptcp output. In particular:
532358 SYN packets dropped due to queue or memory full
770174566 SYN cache entries added
0 hash collisions
768118448 completed
6 aborted (no space to build PCB)
905577 timed out
0 dropped due to overflow
0 dropped due to bucket overflow
1150155 dropped due to RST
0 dropped due to ICMP unreachable
7036108 SYN,ACKs retransmitted
13117384 duplicate SYNs received for entries already in the cache
2580 SYNs dropped (no route or no space)

In syn floods hash collisions, and overflow drops will increase a lot.
As you can see in normal operation those counters are normally 0.

-- 
:wq Claudio

Re: SYN_RCVD

[lists]

> >> OpenBSD uses the syncache for TCP sockets in the 3 way handshake to save a
> >> lot of work to create a full socket in case of synfloods, etc.
> >> These unhatched sockets do not show up in the netstat output. Maybe they
> >> should be added but this is the first request that asks for them in the
> >> 10+ years we use the syncache.
> >
> > Thanks for the history of this Claudio.  I am not really asking for them
> > I just wanted to know where they went.  It's good to know that a
> > LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
> > have another question though.   How would an administrator tell I'm
> > getting SYN flooded without the hunch that something is going on and
> > jumping on tcpdump and doing packet accounting?  How would you determine
> > a syn flood?
> 
> Well I'm sure it depends on the attack but good indications are
> 
> packets/sec on your interfaces
> packets blocked/sec
> number of state table entries
> number of state entries created by a rule
> counters in pfctl -si

Seconded, counters, graphs, logs, flows, visual observation,
knowledge of the networking expected to be normal and not so.
Multiple check points, multiple methods of observation, time.

Re: SYN_RCVD

[Kapetanakis Giannis]

On 07/06/16 10:35, Peter J. Philipp wrote:

On 06/06/16 21:57, Claudio Jeker wrote:

OpenBSD uses the syncache for TCP sockets in the 3 way handshake to save a
lot of work to create a full socket in case of synfloods, etc.
These unhatched sockets do not show up in the netstat output. Maybe they
should be added but this is the first request that asks for them in the
10+ years we use the syncache.


Thanks for the history of this Claudio.  I am not really asking for them
I just wanted to know where they went.  It's good to know that a
LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
have another question though.   How would an administrator tell I'm
getting SYN flooded without the hunch that something is going on and
jumping on tcpdump and doing packet accounting?  How would you determine
a syn flood?

Regards,

-peter



Well I'm sure it depends on the attack but good indications are

packets/sec on your interfaces
packets blocked/sec
number of state table entries
number of state entries created by a rule
counters in pfctl -si

G

[pf] NAT64 rule for *outgoing* packets

[Dan Lüdtke]

Hi,

my setup: [host]--[router]--[internet]

[Host] can ping legacy internet hosts via NAT64. Works fine. Corresponding
line in pf.conf reads:
pass in  quick on $if_lan inet6 from $if_lan:network to 64:ff9b::/96 af-to
inet from ($if_wan)

However, [router] can not ping legacy internet hosts via NAT64. It can, of
course, reach legacy internet hosts natively.

How to push outgoing traffic addressed to 64:ff9b::/96 through pf's NAT64
engine?

Cheers,

Dan



Some outputs FYI:

router# route get 64:ff9b::/96
route: writing to routing socket: No such process


router# ping6 64:ff9b::8.8.8.8
PING6 64:ff9b::8.8.8.8 (64:ff9b::808:808): 24 data bytes
^C--- 64:ff9b::8.8.8.8 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Re: SYN_RCVD

[Raul Miller]

On Tue, Jun 7, 2016 at 3:35 AM, Peter J. Philipp  wrote:
> Thanks for the history of this Claudio.  I am not really asking for them
> I just wanted to know where they went.  It's good to know that a
> LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
> have another question though.   How would an administrator tell I'm
> getting SYN flooded without the hunch that something is going on and
> jumping on tcpdump and doing packet accounting?  How would you determine
> a syn flood?

That is a very good question.

Received wisdom, that I have been taught, is that no one cares, or
that qualified administrators know already.

My guess is that, instead, people should care and that there should be
alarms (warnings, not errors / hard stops) that indicate common attack
modes are in play and yet more documentation needed to describe them.
This is somewhat in the same economic niche as virus checkers, and
eventually should probably be moved to hardware.

But I do not expect quick progress here. There's a lot of pushback,
for a lot of reasons, some good, many not so good.

Or, as Theo might or might not say: "show me the implementation",
likely followed by heavy criticism of the flaws of the implementation.
And the easy response there is to do nothing and say nothing. Another
easy response is to over build.

That said, as best I can determine from web searching, the current
"state of the art" is to turn on pf logging (a bunch of rules to get
right here which depend on the scale and focus of what you want to
happen) and then focus a log analyzer on the results. Or, if you are
in a large company, the current "state of the art" is to wait for
someone else to tell you, or better yet to wait until something
breaks. (Your manager will tell you to instead focus on "X" where "X"
is the current business priority.)

A fundamental underlying problem is that while "syn flood" is a real
thing, it's also something of a sliding scale thing - in practice,
it's just one of many denial of service attacks, which basically are
"the machine is getting more traffic than it can handle". And the
general solution to that problem is to have someone who cares how much
traffic is being handled look for spikes and dips. And that winds up
needing to be measured in several ways (so that inconsistencies can be
detected), and then ride things out.

-- 
Raul

Re: openbsd book references

[Stephane HUC "PengouinPdt"]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Francois ...
Not mine... i collaborate ;)

"Bienvenue"

> 
> i am also glad i found stephane huc's site.
> 
> best regards to all,
> 
> francois
> 

- -- 
 ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD "
+=<<< 
- 
Stephane HUC as PengouinPdt or CIOTBSD
b...@stephane-huc.net
iQIcBAEBCgAGBQJXVozqAAoJEJUiXy553OsCMowP/3ZtnC8qKxEBBb+x4xG7Go/A
+5dLpr+Jg4jVeciJnvJdebOqaaClJtbhXXrw1di2SHTC2W5uRITwpKQDrU1CTCGb
4qJyTPV6q5K+zoBIkSBalVCEcSe7AjcyQhNAa/eg/HdxVKQQPRQPlY9yPPnUktLG
2Eckm1GzdsvItQ7ZjBcGfY07DbtsWpwG1T/8oKy+35c36ssRXOBy7BDSKpq/M8o0
0ky5Z8ei5C47XZFVW2VeuyncOpfX2ygC4RJexLAE1ce4/JIQKzl4tUjS1gxq8jzO
AqlHSdwOFNVl1n4rTm3j0caXn20CM/Lfd/JWETjGZtd7oQYe/TKKU34u1pNzx46f
v3yvzQWvHDV+rKpnJjpgUFQW14d8OOwtsHhjr9yGDCeoJi9bzkqiNvklcl0cHby7
Q+883DjmeI+2C9lTFoPEzJw2RuOU+syS70ya67xuUKNJKIfv2zHJY0HbnRH1eAMu
vTHSAWn+zRplrMZLS8RuJRAsf+uGA5CZZXijBUn3QOJJAxdShvOSjD7sibnLVV0j
8pj03+IPdbP6ZsLNWMJu82umx5FBQAxQKvbuiZan9K3rgBy+9PKSWyENtZsYaArh
s4CScjjmzuPsYnf+0oGD1u6OISFgKScWVmk2dTjfFqKsq95h/8k/qWEyaGBT6iVw
2wcMiV9AKZcBsyFpIHYX
=t49u
-END PGP SIGNATURE-

Re: Joining bridge(4) changes broadcast?

[Martin Pieuchot]

On 07/06/16(Tue) 12:36, Masao Uebayashi wrote:
> On Mon, Jun 06, 2016 at 12:50:04PM +0200, Martin Pieuchot wrote:
> > On 06/06/16(Mon) 16:23, Masao Uebayashi wrote:
> > > On Mon, Jun 06, 2016 at 08:50:49AM +0200, Martin Pieuchot wrote:
> > > > On 06/06/16(Mon) 13:04, Masao Uebayashi wrote:
> > > > > Broadcast frame, coming into a bridge'ed interface, passes if_input() 
> > > > > 3 times,
> > > > > and actually input (ether_input()) twice.
> > > > > 
> > > > > - A frame enters an interface (e.g. pair(4)), the interface calls 
> > > > > if_input()
> > > > >   on it.  The frame is queued in if_input_queue.
> > > > > 
> > > > > - A task running if_input_process() is triggered.  It takes the frame 
> > > > > and
> > > > >   calls bridge_input().  Frame is queued in bridgeintrq.
> > > > > 
> > > > > - bridge_process() dispatches frame as multicast/broadcast (if
> > > > >   (ETHER_IS_MULTICAST())) and calls bridge_ifinput() on it, then 
> > > > > passes the
> > > > >   frame to bridgeintr_frame().
> > > > > 
> > > > > - bridgeintr_frame() calls bridge_broadcast() on it.
> > > > > 
> > > > > - bridge_broadcast() calls bridge_localbroadcast(), which again calls
> > > > >   bridge_ifinput().
> > > > > 
> > > > > bridge_ifinput() is called twice for each broadcast frames.  
> > > > > bridge_ifinput()
> > > > > calls if_input().  Thus 3 if_input() for each.
> > > > > 
> > > > > These duplicate frames confuse pppoe(4), that's why it stops working.
> > > > 
> > > > What do you mean by "confuse pppoe(4)"?  I still don't understand what's
> > > > the link between pppoe(4) and bpf(4) in this case and why BPF matters
> > > > for a kernel driver.
> > > 
> > > - PPPoE client (pppoe(4)) sends a PPPoE Discovery "initiation" frame, 
> > > which is
> > >   broadcast.
> > > 
> > > - PPPoE server (npppd(8)) receives 3 copies of it via bpf(4), then returns
> > >   3 PPPoE Discovery "offer" frames.
> > > 
> > > - pppoe(4) receives 3 "offer" frames and gets confused ... somehow.
> > > 
> > > I don't know the internal of pppoe(4) yet.  pppoe(4) might have a bug, it
> > > might be able to work even if it receives 3 replies at once, I don't know.
> > > 
> > > I don't think that npppd(8) receiving 3 copies of broadcast frames (via
> > > bpf(4)) is an intentional design anyway.
> > 
> > I agree.  Diff below should reduce the number of copies to 2.
> 
> Diff works as expected for me, and reads me good.  OK uebayasi@.
> 
> > In order
> > to remove the last copy somebody has to turn bridge_process() MP-safe
> > and merge it with bridge_input().  
> > 
> > Once this is done, bridge_input() can return "0" for multicast packets
> > and ether_input() will be call directly without the need for requeueing
> > the packet.
> 
> I admit I don't fully understand the intention of if_ih_* handler.  Can
> you safely assume that there is always ether_input() hook just after
> bridge_input()?

Since bridge(4) mostly work with Ethernet drivers, you can assume that
it is after.  Maybe you'll have a vlan_input() before.

Re: SYN_RCVD

[Peter J. Philipp]

On 06/06/16 21:57, Claudio Jeker wrote:
> OpenBSD uses the syncache for TCP sockets in the 3 way handshake to save a
> lot of work to create a full socket in case of synfloods, etc.
> These unhatched sockets do not show up in the netstat output. Maybe they
> should be added but this is the first request that asks for them in the
> 10+ years we use the syncache.
>

Thanks for the history of this Claudio.  I am not really asking for them
I just wanted to know where they went.  It's good to know that a
LISTENING tcp socket goes directly to ESTABLISHED in OpenBSD.  I would
have another question though.   How would an administrator tell I'm
getting SYN flooded without the hunch that something is going on and
jumping on tcpdump and doing packet accounting?  How would you determine
a syn flood?

Regards,

-peter