Blocking "shodan.io" - What are my options?

2019-01-02 Thread Antonino Sidoti
Hi,

I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) 
mail server using OpenSMTPD and notice quite bit of traffic all stemming from 
“shodan.io". I have PF configured so I was wondering how to block such a domain 
from making any attempts to connect to my server. There is little information 
about Public IP addresses being used by "shodan.io" scanner, so making an IP 
list for PF may be futile.

Could someone suggest a possible option? I was thinking along the lines of 
“relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN 
interface with Public IP. There is no internal LAN interface.

For those who do not know about “shodan.io”, please do a search and you will 
discover what it does.

Regards

Nino



Re: mount_ffs Permission denied as root

2019-01-02 Thread Misc User

On 1/2/2019 4:21 PM, myml...@gmx.com wrote:


On 1/1/19 10:02 PM, Philip Guenther wrote:
On Tue, Jan 1, 2019 at 6:27 PM myml...@gmx.com 
<mailto:myml...@gmx.com> mailto:myml...@gmx.com>> 
wrote:


    I just did a new install of current AMD64 from the 12/31/2018
    snapshot
    and having some permission issues mounting a usb drive, as root.
    I have
    been able to mount other usb drives just fine. (Also tried with the
    12/29 snapshots as well, same issue)

    #disklabel sd4

...

    #    size   offset  fstype [fsize bsize   cpg]
       a:    249682144   64  4.2BSD   2048 16384 12958
       c:    249692160    0  unused

    curry:/root:#mount -v /dev/sd4a /mnt/usb0
    mount_ffs: /dev/sd4a on /mnt/usb0: Permission denied

    I don't see any kind of messages in the logs related to the error.


 What's the output of "fsck /dev/rsd4a" ?

Philip Guenther

I had to reboot the machine related to this and the drive attached as a 
different device but here's the output.


20190102-1407:root@curry:/root:#disklabel sd2
# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: Survivor 3.0
duid: 70568afde7f5a241
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 15542
total sectors: 249692160
boundstart: 64
boundend: 249682230
drivedata: 0

16 partitions:
#    size   offset  fstype [fsize bsize   cpg]
   a:    249682144   64  4.2BSD   2048 16384 12958
   c:    249692160    0  unused

Fsck shows clean, I noticed however the (NO WRITE) bit at the end.

20190102-1408:root@curry:/root:#fsck /dev/sd2a
** /dev/rsd2a (NO WRITE)
** File system is clean; not checking

I was able to get the drive mounted in read only mode after mounting one 
of the directories, of course the most important one, gives a bad file 
descriptor and doesn't recognize it as a directory.


20190102-1410:root@curry:/root:#mount -o ro /dev/sd2a /mnt/usb0
20190102-1410:root@curry:/root:#ls /mnt/usb0
root   sata0  tbisch usb0   usb1

20190102-1410:root@curry:/root:#ls -l /mnt/usb0
ls: tbisch: Bad file descriptor
total 16
drwx--  8 root  wheel   512 Dec 28 06:33 root
drwxr-xr-x  2 root  wheel   512 Dec 30 21:01 sata0
drwxr-xr-x  9 root  wheel  1024 Dec 31  1979 usb0
drwxr-xr-x  2 root  wheel   512 Dec 30 21:01 usb1

20190102-1410:root@curry:/root:#ls /mnt/usb0/tbisch/
ls: /mnt/usb0/tbisch/: Not a directory

I tried unmounting and doing a fsck -f -y /dev/sd4a and it shows lots of 
errors, but doesn't give y for the answer as I thought the -y flag was 
supposed to do:


20190102-1413:root@curry:/root:#fsck -f -y /dev/sd2a
** /dev/rsd2a (NO WRITE)
** File system is already clean
** Last Mounted on /mnt/usb2
** Phase 1 - Check Blocks and Sizes
PARTIALLY ALLOCATED INODE I=25984
CLEAR? no

UNKNOWN FILE TYPE I=25985
CLEAR? no

UNKNOWN FILE TYPE I=25986
CLEAR? no

UNKNOWN FILE TYPE I=25987
CLEAR? no

UNKNOWN FILE TYPE I=25988
CLEAR? no

UNKNOWN FILE TYPE I=25989
CLEAR? no

UNKNOWN FILE TYPE I=25990
CLEAR? no

UNKNOWN FILE TYPE I=25991
CLEAR? no

UNKNOWN FILE TYPE I=25992
CLEAR? no

UNKNOWN FILE TYPE I=25993
CLEAR? no

UNKNOWN FILE TYPE I=25994
CLEAR? no

UNKNOWN FILE TYPE I=25995
CLEAR? no

UNKNOWN FILE TYPE I=25996
CLEAR? no

UNKNOWN FILE TYPE I=25997
CLEAR? no

PARTIALLY ALLOCATED INODE I=25998
CLEAR? no

UNKNOWN FILE TYPE I=25999
CLEAR? no

PARTIALLY ALLOCATED INODE I=26000
CLEAR? no

UNKNOWN FILE TYPE I=26001
CLEAR? no

UNKNOWN FILE TYPE I=26002
CLEAR? no

UNKNOWN FILE TYPE I=26003
CLEAR? no

UNKNOWN FILE TYPE I=26004
CLEAR? no

UNKNOWN FILE TYPE I=26005
CLEAR? no

UNKNOWN FILE TYPE I=26006
CLEAR? no

UNKNOWN FILE TYPE I=26007
CLEAR? no

UNKNOWN FILE TYPE I=26008
CLEAR? no
  and it keeps going.


I unmounted the drive and tried to create an image of the drive, but it 
fails


20190102-1435:root@curry:/root:#time dd if=/dev/rsd2c 
of=/root/corsair.iso bs=1k

dd: /dev/rsd2c: Input/output error
15958016+0 records in
15958016+0 records out
16341008384 bytes transferred in 7313.789 secs (2234274 bytes/sec)
   122m03.94s real 0m16.54s user 6m36.66s system

After this doing a disklabel fails:

#disklabel sd2
disklabel: ioctl DIOCGDINFO: Input/output error

Additionally I see the following in the /var/log/messages.

Jan  2 13:52:52 curry /bsd: usb_insert_transfer: xfer=0xff025c1a35a0 
not free






Does it work when you revert back to the last version of OpenBSD it 
mounted properly?  There is a slight possibility that a code change has 
made OpenBSD unable to communicate properly with the controller (like 
the controller is expecting the OS to do the wear-leveling remapping or 
something), but its far more likely that the device is broken especially 
since OpenBSD seems to be able to read the partition table, but only 
parts of the file table and only a portion of your sectors.


The most likely scenario here is that your USB drive is broken and useless.



Re: OPenBSD 4.9 i386, Asus EEE 701, no network

2019-01-02 Thread Christopher Turkel
I wanted to say the same thing. Try a supported version, 4.9 is not
supported anymore.

On Wed, Jan 2, 2019 at 8:21 PM Ed Ahlsen-Girard  wrote:

> On 2019-01-01 12:13:47, oletus  wrote:
> >
> > Owain Ainsworth-2 wrote
> > >> - "ifconfig lii0" returns:
> > >> lii0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu
> > >> 1500 lladdr
> > > 
> > >>priority: 0
> > >>media: Ethernet autoselect (none)
> > >>status: no carrier
> > >>inet6 
> > >
> > > Did you up the interface?
> > >
> > > ifconfig lii0 up
> > >
> > > -0-
> > > --
> > > I've seen better heads on half a pint of beer.
> >
> > Having this exact same issue with EeePC 701 and OpenBSD 5.9. It uses
> > the lii0 driver. So far no luck with DHCP.
> >
> > dmesg says about the driver,
> > lii0 at pci2 dev 0 function 0 "Attansic Technology L2" rev 0xa0 apic
> > 1 int 17, address 00:1f:c6:d5:3c:80
> >
> > ifconfig lii0 says,
> > lii0: flags=8843 mtu 1500
> > lladdr 00:1f:c6:d5:3c:80
> > priority: 0
> > media: Ethernet none
> >
> > ifconfig lii0 up says nothing, same with ifconfig lii0 up scan
> >
> > doing ifconfig lii0 nwid iPhone wpakey mypassword gives me an error,
> > ifconfig: SIOCS80211NWID: Inappropriate ioctl for device
> > ifconfig: SIOCS80211NWID: Inappropriate ioctl for device
> >
> > doing dhclient lii0 says,
> > DHCPDISCOVER on lii0 - interval 3
> > DHCPDISCOVER on lii0 - interval 4
> > DHCPDISCOVER on lii0 - interval 7
> > DHCPDISCOVER on lii0 - interval 11
> > DHCPDISCOVER on lii0 - interval 14
> > DHCPDISCOVER on lii0 - interval 14
> > No acceptable DHCPOFFERS received.
> >
> > doing wpa_supplicant -i lii0 -c my_wpa_configuration_file says,
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> > lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> >
> >
> > I'm not sure if this is a bug or not, ref.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833507
>
> You're resurrecting a thread from 2011 about a version
> that became unsupported in 2017.
>
> --
>
> Edward Ahlsen-Girard
> Ft Walton Beach, FL
>
>
>


Re: OPenBSD 4.9 i386, Asus EEE 701, no network

2019-01-02 Thread Ed Ahlsen-Girard
On 2019-01-01 12:13:47, oletus  wrote:
> 
> Owain Ainsworth-2 wrote
> >> - "ifconfig lii0" returns:
> >> lii0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu
> >> 1500 lladdr 
> > 
> >>priority: 0
> >>media: Ethernet autoselect (none)
> >>status: no carrier
> >>inet6 
> > 
> > Did you up the interface?
> > 
> > ifconfig lii0 up
> > 
> > -0-
> > -- 
> > I've seen better heads on half a pint of beer.
> 
> Having this exact same issue with EeePC 701 and OpenBSD 5.9. It uses
> the lii0 driver. So far no luck with DHCP.
> 
> dmesg says about the driver,
> lii0 at pci2 dev 0 function 0 "Attansic Technology L2" rev 0xa0 apic
> 1 int 17, address 00:1f:c6:d5:3c:80
> 
> ifconfig lii0 says,
> lii0: flags=8843 mtu 1500
> lladdr 00:1f:c6:d5:3c:80
> priority: 0
> media: Ethernet none
> 
> ifconfig lii0 up says nothing, same with ifconfig lii0 up scan
> 
> doing ifconfig lii0 nwid iPhone wpakey mypassword gives me an error,
> ifconfig: SIOCS80211NWID: Inappropriate ioctl for device
> ifconfig: SIOCS80211NWID: Inappropriate ioctl for device
> 
> doing dhclient lii0 says,
> DHCPDISCOVER on lii0 - interval 3
> DHCPDISCOVER on lii0 - interval 4
> DHCPDISCOVER on lii0 - interval 7
> DHCPDISCOVER on lii0 - interval 11
> DHCPDISCOVER on lii0 - interval 14
> DHCPDISCOVER on lii0 - interval 14
> No acceptable DHCPOFFERS received.
> 
> doing wpa_supplicant -i lii0 -c my_wpa_configuration_file says,
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> lii0: CTRL-EVENT-SCAN-FAILED ret=1 retry=1
> 
> 
> I'm not sure if this is a bug or not, ref.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833507

You're resurrecting a thread from 2011 about a version
that became unsupported in 2017.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL




Re: Advice on Security Cameras

2019-01-02 Thread Ed Ahlsen-Girard
> From:   "Elias M. Mariani" 
> Date:   2019-01-01 17:46:25
> 
> Hi list,
> I'm thinking in installing some cameras in my private home, I have
> been looking for solutions, my concern is that I wish to be able to
> look the videos from outside the house and I'm a little paranoid about
> the quality of the software that the different vendors use. I have
> seen clusters of camaras that only work over ActiveX...
> I know that is a little off-topic but maybe someone knows about a good
> brand of cameras.
> Of-course one can always set a VPN tunnel trough OpenBSD for the
> security matter, OpenVPN works on Android so is easy to access from a
> smartphone. But I would prefer to have a single secure service running
> that adding a layer of complexity with the VPN.
> 
> I'm looking for:
> - Not overpriced cameras.
> - They don't need to be "external cameras", they will be covered
> under a roof.
> - I need to set at least 4, so I need them to be accessible from a
> single platform.
> - Android / Browser friendly (not only IE plz...)
> - WiFi is not needed, I have a 12v supply and Ethernet connections for
> each camera.
> - Good video quality but I'm not looking for anything super great...
> - the ability to centralize recording and access to view the cameras
> is a must.
> 
> Again, sorry for the off-topic but were would I find a better place to
> ask about surveillance and security ? :D
> 
> Cheers and happy new year.

This might be helpful:

https://archive.fosdem.org/2018/schedule/event/openbsd_alarm_system/
-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL



Re: mount_ffs Permission denied as root

2019-01-02 Thread myml...@gmx.com


On 1/1/19 11:53 PM, Otto Moerbeek wrote:

On Tue, Jan 01, 2019 at 07:25:14PM -0700, myml...@gmx.com wrote:


I just did a new install of current AMD64 from the 12/31/2018 snapshot and
having some permission issues mounting a usb drive, as root.  I have been
able to mount other usb drives just fine. (Also tried with the 12/29
snapshots as well, same issue)

#disklabel sd4
# /dev/rsd4c:
type: SCSI
disk: SCSI disk
label: Survivor 3.0
duid: 70568afde7f5a241
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 15542
total sectors: 249692160
boundstart: 64
boundend: 249682230
drivedata: 0

16 partitions:
#    size   offset  fstype [fsize bsize   cpg]
   a:    249682144   64  4.2BSD   2048 16384 12958
   c:    249692160    0  unused


curry:/root:#mount -v /dev/sd4a /mnt/usb0
mount_ffs: /dev/sd4a on /mnt/usb0: Permission denied

I don't see any kind of messages in the logs related to the error.

device r/o switch is set to r/o?
/mnt/usb0 is r/o?

If that's not it, please ktrace the command and show kdump

-Otto


Hi Otto,

There is no hw switch on this usb drive, I'm not sure why it's showing 
up as read only.


I attached a ktrace for both the disklabel command as well as an ls on 
the drive after I was able to mount it read only.


Thanks,

Thomas



ktrace-ls-mounted-ro.out
Description: Binary data


ktrace-disklabel.out
Description: Binary data


Re: mount_ffs Permission denied as root

2019-01-02 Thread myml...@gmx.com



On 1/1/19 10:02 PM, Philip Guenther wrote:
On Tue, Jan 1, 2019 at 6:27 PM myml...@gmx.com 
<mailto:myml...@gmx.com> mailto:myml...@gmx.com>> wrote:


I just did a new install of current AMD64 from the 12/31/2018
snapshot
and having some permission issues mounting a usb drive, as root. 
I have
been able to mount other usb drives just fine. (Also tried with the
12/29 snapshots as well, same issue)

#disklabel sd4

...

#    size   offset  fstype [fsize bsize   cpg]
   a:    249682144   64  4.2BSD   2048 16384 12958
   c:    249692160    0  unused

curry:/root:#mount -v /dev/sd4a /mnt/usb0
mount_ffs: /dev/sd4a on /mnt/usb0: Permission denied

I don't see any kind of messages in the logs related to the error.


 What's the output of "fsck /dev/rsd4a" ?

Philip Guenther

I had to reboot the machine related to this and the drive attached as a 
different device but here's the output.


20190102-1407:root@curry:/root:#disklabel sd2
# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: Survivor 3.0
duid: 70568afde7f5a241
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 15542
total sectors: 249692160
boundstart: 64
boundend: 249682230
drivedata: 0

16 partitions:
#    size   offset  fstype [fsize bsize   cpg]
  a:    249682144   64  4.2BSD   2048 16384 12958
  c:    249692160    0  unused

Fsck shows clean, I noticed however the (NO WRITE) bit at the end.

20190102-1408:root@curry:/root:#fsck /dev/sd2a
** /dev/rsd2a (NO WRITE)
** File system is clean; not checking

I was able to get the drive mounted in read only mode after mounting one 
of the directories, of course the most important one, gives a bad file 
descriptor and doesn't recognize it as a directory.


20190102-1410:root@curry:/root:#mount -o ro /dev/sd2a /mnt/usb0
20190102-1410:root@curry:/root:#ls /mnt/usb0
root   sata0  tbisch usb0   usb1

20190102-1410:root@curry:/root:#ls -l /mnt/usb0
ls: tbisch: Bad file descriptor
total 16
drwx--  8 root  wheel   512 Dec 28 06:33 root
drwxr-xr-x  2 root  wheel   512 Dec 30 21:01 sata0
drwxr-xr-x  9 root  wheel  1024 Dec 31  1979 usb0
drwxr-xr-x  2 root  wheel   512 Dec 30 21:01 usb1

20190102-1410:root@curry:/root:#ls /mnt/usb0/tbisch/
ls: /mnt/usb0/tbisch/: Not a directory

I tried unmounting and doing a fsck -f -y /dev/sd4a and it shows lots of 
errors, but doesn't give y for the answer as I thought the -y flag was 
supposed to do:


20190102-1413:root@curry:/root:#fsck -f -y /dev/sd2a
** /dev/rsd2a (NO WRITE)
** File system is already clean
** Last Mounted on /mnt/usb2
** Phase 1 - Check Blocks and Sizes
PARTIALLY ALLOCATED INODE I=25984
CLEAR? no

UNKNOWN FILE TYPE I=25985
CLEAR? no

UNKNOWN FILE TYPE I=25986
CLEAR? no

UNKNOWN FILE TYPE I=25987
CLEAR? no

UNKNOWN FILE TYPE I=25988
CLEAR? no

UNKNOWN FILE TYPE I=25989
CLEAR? no

UNKNOWN FILE TYPE I=25990
CLEAR? no

UNKNOWN FILE TYPE I=25991
CLEAR? no

UNKNOWN FILE TYPE I=25992
CLEAR? no

UNKNOWN FILE TYPE I=25993
CLEAR? no

UNKNOWN FILE TYPE I=25994
CLEAR? no

UNKNOWN FILE TYPE I=25995
CLEAR? no

UNKNOWN FILE TYPE I=25996
CLEAR? no

UNKNOWN FILE TYPE I=25997
CLEAR? no

PARTIALLY ALLOCATED INODE I=25998
CLEAR? no

UNKNOWN FILE TYPE I=25999
CLEAR? no

PARTIALLY ALLOCATED INODE I=26000
CLEAR? no

UNKNOWN FILE TYPE I=26001
CLEAR? no

UNKNOWN FILE TYPE I=26002
CLEAR? no

UNKNOWN FILE TYPE I=26003
CLEAR? no

UNKNOWN FILE TYPE I=26004
CLEAR? no

UNKNOWN FILE TYPE I=26005
CLEAR? no

UNKNOWN FILE TYPE I=26006
CLEAR? no

UNKNOWN FILE TYPE I=26007
CLEAR? no

UNKNOWN FILE TYPE I=26008
CLEAR? no
  and it keeps going.


I unmounted the drive and tried to create an image of the drive, but it 
fails


20190102-1435:root@curry:/root:#time dd if=/dev/rsd2c 
of=/root/corsair.iso bs=1k

dd: /dev/rsd2c: Input/output error
15958016+0 records in
15958016+0 records out
16341008384 bytes transferred in 7313.789 secs (2234274 bytes/sec)
  122m03.94s real 0m16.54s user 6m36.66s system

After this doing a disklabel fails:

#disklabel sd2
disklabel: ioctl DIOCGDINFO: Input/output error

Additionally I see the following in the /var/log/messages.

Jan  2 13:52:52 curry /bsd: usb_insert_transfer: xfer=0xff025c1a35a0 
not free






Re: Experiences with single mode fibre on OpenBSD ?

2019-01-02 Thread Misc User

On 1/2/2019 12:12 PM, Rachel Roch wrote:

Hi,

I see the man pages mention the odd SM fibre NIC, which is a good start.

However I could do with some real-world feedback from people in terms of the SM 
NICs they're using and any other experiences with SM on OpenBSD.

Thanks !

Rachel



There shouldn't be anything different, OpenBSD doesn't care about the 
media so much as the controller, and so long as the controller isn't 
doing anything different (Not that there is a reason for the controller 
to do, at least form the OS's side of the controller), there shouldn't 
be any difference.


I am using a bunch of Intel 10 Gb NICs running on OpenBSD with various 
SFPs plugged into them and I haven't seen any difference in operation 
between SM and MM SFPs other than a different media showing up in the 
ifconfig output.




Re: Experiences with single mode fibre on OpenBSD ?

2019-01-02 Thread Sebastian Benoit
Rachel Roch(rr...@tutanota.de) on 2019.01.02 21:12:53 +0100:
> Hi,
> 
> I see the man pages mention the odd SM fibre NIC, which is a good start.
> 
> However I could do with some real-world feedback from people in terms of
> the SM NICs they're using and any other experiences with SM on OpenBSD.

Hi,

you are not giving much details what you are trying to do.

That said, if you do 10G use intel X520 DA2 cards (ix(4)) or onboard
hardware with the same chipset. These have SFP+ slots and you can insert
SFP+ tranceivers (coded for intel). They also support 1G SFP tranceivers.

Swapping tranceivers may require a reboot.

/Benno



Experiences with single mode fibre on OpenBSD ?

2019-01-02 Thread Rachel Roch
Hi,

I see the man pages mention the odd SM fibre NIC, which is a good start.

However I could do with some real-world feedback from people in terms of the SM 
NICs they're using and any other experiences with SM on OpenBSD.

Thanks !

Rachel



Re: Who is 'anchor 11' (pfctl -vvss ./. pfctl -vsA)?

2019-01-02 Thread Klemens Nanni
On Wed, Jan 02, 2019 at 07:09:54PM +0100, Philipp Buehler wrote:
> 'pfctl -vvss':
> all tcp 10.45.30.7:993 (public-nat:993) <- remote-ip:4690
> ESTABLISHED:ESTABLISHED
>[1683650613 + 66296] wscale 7  [3702552199 + 16768] wscale 2
>age 04:32:22, expires in 00:09:25, 745:737 pkts, 55579:87226 bytes,
> anchor 11, rule 0, source-track
Anchor 11 is the twelfth rule in your main ruleset (the anchor rule),
in which the first rule established this state.

>id: 5b5139707ff0259a creatorid: cfe3cb20
> 
> Now, who is 'anchor 11'? By no means 'relayctl show redirects' or 'pfctl
> -vsA' or "pfctl -a 'relayd/*' -vvsr"
> would give me a "numbered" clue. The anchors are ascii/literally named - no
> number like on the
> rules in 'pfctl -vvsr'.
`pfctl -vv -s rules -R 11' shows this very rule,
`pfctl -vv -s states -R 11' will show all states established by this
rule if any.

> In the current case I've only one relayd-redirection with port 993, so I can
> guestimate the anchor.
> 
> Am I overlooking a pfctl/relayctl option or is '11' internal only?
Provide your ruleset so we can look at actual rules without guessing in
case your problem persists, `pfctl -a\* -s rules' prints them including
anchors.



Re: bgpd as-set

2019-01-02 Thread Theo de Raadt
> Yes, as-set is a lookup table and so 42-4294967295 would add
> more than 94 Million entries to that table. That is not sensible. Doing
> range lookups is more complex especially to make those efficent and fast.

It is really not that hard.



Re: bgpd as-set

2019-01-02 Thread Claudio Jeker
On Wed, Jan 02, 2019 at 05:05:20PM +0100, Stéphane wrote:
> Hello Guys and happy news year to all !
> 
> I have recently setups a news BGP router for peering purpose using OpenBSD.
> 
> In order to do input filtering I have tried to use an as-set looking like
> that :
> 
> 
> ## use as-set to reject bogon AS number
> as-set bogon-as { 0 23456 64496-131071 64512-65534 65535 65536-65551
> 65552-131071 42-4294967295 4294967295 }
> 
> But this configuration did not work.
> 
> It seems that bgpd cannot handle as rang in as-set unlike the filter
> directive.
> 
> As anyone tries that before me ? Can you confirm that filter is the best
> solution for now ?

Yes, as-set is a lookup table and so 42-4294967295 would add
more than 94 Million entries to that table. That is not sensible. Doing
range lookups is more complex especially to make those efficent and fast.
AS sets are used primerably by config generators like bgpq3 or arouteserver.
In those cases ranges are not needed and lookup speed is more important.
This is why it was not built that way.
 
> I have fallen back on this configuration :
> 
> ## use filter to reject bogon AS numbers
> deny quick from any AS 0 # reserved [RFC7607]
> deny quick from any AS 23456 # AS_TRANS [RFC6793]
> deny quick from any AS 64496 - 131071# reserved for
> documentation [RFC5398]
> deny quick from any AS 64512 - 65534 # reserved for private
> usage [RFC5398]
> deny quick from any AS 65535 # reserved [RFC7300]
> deny quick from any AS 65536 - 65551 # reserved for
> documentation [RFC5398]
> deny quick from any AS 65552 - 131071# reserved by IANA
> deny quick from any AS 42 - 4294967295   # reserved for private
> usage [RFC6996]
> deny quick from any AS 4294967295# reserved [RFC7300]
> 

You can write that a bit more compact:
deny quick from any AS 23456
deny quick from any AS 64496 - 131071
deny quick from any AS 42 - 4294967295

Or as an alternative
AS_BOGON="{ 23456, 64496 - 131071, 42 - 4294967295}"
deny quick from any AS $AS_BOGON

AS 0 can never match so no need for such a rule. Then you have a lot of
overlapping ranges which can be simply combined.

-- 
:wq Claudio



Who is 'anchor 11' (pfctl -vvss ./. pfctl -vsA)?

2019-01-02 Thread Philipp Buehler

Hello,

in the midst of debugging ruleset/migrations, I came across this output 
in 'pfctl -vvss':
all tcp 10.45.30.7:993 (public-nat:993) <- remote-ip:4690   
ESTABLISHED:ESTABLISHED

   [1683650613 + 66296] wscale 7  [3702552199 + 16768] wscale 2
   age 04:32:22, expires in 00:09:25, 745:737 pkts, 55579:87226 bytes, 
anchor 11, rule 0, source-track

   id: 5b5139707ff0259a creatorid: cfe3cb20

Now, who is 'anchor 11'? By no means 'relayctl show redirects' or 'pfctl 
-vsA' or "pfctl -a 'relayd/*' -vvsr"
would give me a "numbered" clue. The anchors are ascii/literally named - 
no number like on the

rules in 'pfctl -vvsr'.

In the current case I've only one relayd-redirection with port 993, so I 
can guestimate the anchor.


Am I overlooking a pfctl/relayctl option or is '11' internal only?

TIA,
--
pb



Re: make obj failed

2019-01-02 Thread Edgar Pettijohn


On Jan 2, 2019 7:29 AM, Maciej Jan Broniarz  wrote:
>
> Hi,
>
> I am following the same  guide as always: https://www.openbsd.org/stable.html
>
> mjb
>

Did you rm -rf /usr/obj

Before building? I think the only time I've ever had a build fail was because I 
had something old hanging out in there.
>
> - Oryginalna wiadomość -
> Od: "Theo de Raadt" 
> Do: "Maciej Jan Broniarz" 
> DW: misc@openbsd.org
> Wysłane: środa, 2 styczeń 2019 14:27:22
> Temat: Re: make obj failed
>
> You are not using the build process in "man release"
>
> You are doing something different..
>
> > Hi,
> > 
> > I am updating OpenBSD 6.4 on sparc64 and during make obj i get the 
> > following error:
> > 
> > building rem.S from /usr/src/lib/libc/arch/sparc64/gen/divrem.m4
> > /bin/sh: cannot create rem.S: Permission denied
> > *** Error 1 in lib/libc (arch/sparc64/Makefile.inc:23 'rem.S': @(echo 
> > "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')";  cat /usr/sr...)
> > *** Error 1 in lib (:48 'all')
> > *** Error 1 in . (:48 'all')
> > *** Error 1 in . (Makefile:95 'do-build')
> > *** Error 1 in /usr/src (Makefile:74 'build')
> > 
> > What might be the issue here?
> > 
> > all best,
> > mjb
> > 
>
>
> !DSPAM:1,5c2cbd73862871338720621!
>
>



bgpd as-set

2019-01-02 Thread Stéphane

Hello Guys and happy news year to all !

I have recently setups a news BGP router for peering purpose using 
OpenBSD.


In order to do input filtering I have tried to use an as-set looking 
like that :



## use as-set to reject bogon AS number
as-set bogon-as { 0 23456 64496-131071 64512-65534 65535 65536-65551 
65552-131071 42-4294967295 4294967295 }


But this configuration did not work.

It seems that bgpd cannot handle as rang in as-set unlike the filter 
directive.


As anyone tries that before me ? Can you confirm that filter is the best 
solution for now ?


I have fallen back on this configuration :

## use filter to reject bogon AS numbers
deny quick from any AS 0 # reserved 
[RFC7607]
deny quick from any AS 23456 # AS_TRANS 
[RFC6793]
deny quick from any AS 64496 - 131071# reserved for 
documentation [RFC5398]
deny quick from any AS 64512 - 65534 # reserved for 
private usage [RFC5398]
deny quick from any AS 65535 # reserved 
[RFC7300]
deny quick from any AS 65536 - 65551 # reserved for 
documentation [RFC5398]

deny quick from any AS 65552 - 131071# reserved by IANA
deny quick from any AS 42 - 4294967295   # reserved for 
private usage [RFC6996]
deny quick from any AS 4294967295# reserved 
[RFC7300]


Best Regards,
Stéphane



Re: Advice on Security Cameras

2019-01-02 Thread Misc User

On 1/1/2019 9:46 AM, Elias M. Mariani wrote:

Hi list,
I'm thinking in installing some cameras in my private home, I have
been looking for solutions, my concern is that I wish to be able to
look the videos from outside the house and I'm a little paranoid about
the quality of the software that the different vendors use. I have
seen clusters of camaras that only work over ActiveX...
I know that is a little off-topic but maybe someone knows about a good
brand of cameras.
Of-course one can always set a VPN tunnel trough OpenBSD for the
security matter, OpenVPN works on Android so is easy to access from a
smartphone. But I would prefer to have a single secure service running
that adding a layer of complexity with the VPN.

I'm looking for:
- Not overpriced cameras.
- They don't need to be "external cameras", they will be covered under a roof.
- I need to set at least 4, so I need them to be accessible from a
single platform.
- Android / Browser friendly (not only IE plz...)
- WiFi is not needed, I have a 12v supply and Ethernet connections for
each camera.
- Good video quality but I'm not looking for anything super great...
- the ability to centralize recording and access to view the cameras is a must.

Again, sorry for the off-topic but were would I find a better place to
ask about surveillance and security ? :D

Cheers and happy new year.
Elias.

Anything that support RTP/RTSP works pretty well with OpenBSD and 
FFMPEG.  I have FFMPEG listening for my cameras' streams, then tees the 
output to a series of files (MP4) and to a socket where 
nginx-rtmp-module is able to push it out via https (HLS).


I've been using some to monitor in and around the datacenter.  A bunch 
of PoE-powered network cameras, hooked up to a PoE switch, forming an 
air-gapped surveillance network and an OpenBSD box with a couple 
high-capacity SSDs for storing video and a connection to the main 
network for users to access the web server port.


I've been using Monoprice-branded cameras, but I bought them a few years 
ago, not sure if the current models offer the same protocols.


A bit of advice for cameras outside:  You are going to want 
outdoor-rated cameras even if they aren't getting hit directly with 
rain.  Moisture in the air is still going to condense inside the camera 
if there are any gaps in the case at all.  Eventually the lens is just 
going to become a permanently foggy mess.


-CA
.



Re: CVS: cvs.openbsd.org: src (maillog simplified)

2019-01-02 Thread Walter Alejandro Iglesias
Hello Gilles,

In article <20190101143249.ga41...@ams-1.poolp.org> Gilles Chehade 
 wrote:
> On Tue, Jan 01, 2019 at 01:14:54PM +0100, Walter Alejandro Iglesias wrote:
> > On Fri, Dec 21, 2018 at 06:59:58PM +0100, Gilles Chehade wrote:
> > > On Fri, Dec 21, 2018 at 06:56:57PM +0100, Walter Alejandro Iglesias wrote:
> > > > Hello Gilles,
> > > > 
> > > > In article <20181221145201.ga90...@ams-1.poolp.org> Gilles Chehade 
> > > >  wrote:
> > > > > On Fri, Dec 21, 2018 at 07:41:41AM -0700, Gilles Chehade wrote:
> > > > > > CVSROOT:  /cvs
> > > > > > Module name:  src
> > > > > > Changes by:   gil...@cvs.openbsd.org  2018/12/21 07:41:41
> > > > > > 
> > > > > > Modified files:
> > > > > >   usr.sbin/smtpd : smtp_session.c 
> > > > > > 
> > > > > > Log message:
> > > > > > start simplifying log lines, they're no longer intended to be 
> > > > > > parseable, we
> > > > > > have a reporting API for tools that want to analyze events, maillog 
> > > > > > is just
> > > > > > for us, hoomans.
> > > > > > 
> > > > > 
> > > > > that was not the best way to phrase my commit log ... sorry
> > > > > 
> > > > > i meant they're no longer intended to be friendlier to scripts than to
> > > > > humans: there will still be in a format that's easy to quickly script,
> > > > > but they will hold information easily readable by humans, not a lot of
> > > > > unrelated context infos so tools can generate dashboards out of single
> > > > > lines.
> > > > > 
> > > > > logs for humans, event reports for tools.
> > > > > 
> > > > 
> > > > Since long I've been greping IPs from spammers and attackers from
> > > > /var/log/maillog, /var/log/authlog and /var/log/daemon using a shell
> > > > script I wrote that automatically includes them in a file read by a pf
> > > > table.  In the case of maillog, it relies in the address="" and host=""
> > > > info currently included.
> > > > 
> > > > Will it appear sender's IP and hostname in /var/log/maillog after this
> > > > change?
> > > > 
> > > 
> > > yes, you'll still be able to grep that information from maillog
> > 
> > You selected carefully the words in your answer. :-)
> > 
> 
> not really, I don't know what your scripts do and how you wrote them.

I made this clear in my explanation below.  At least the relevant part.

> 
> the sender IP and hostname appear in the log, they are just not repeated
> on every single log line but that shouldn't prevent scripts from keeping
> track of them.

Also clear in my explanation that I understood this.

> 
> anyways, as stated in the commit log and my follow up message:
> 
> "we have a reporting API for tools that want to analyse events, maillog
>  is just for us, hoomans"
> 
> "logs for humans, event reports for tools"

System administrators (i.e. those who will use your software) are also
humans. :-)


> 
> the maillog format is going to go through many changes to simplify it,
> remove redundant information, add missing information, etc... basing a
> script on it is not recommended as we'll break them with every change.
> 
> > Indeed, I still can grep "IP" and "host" in maillog, but they are alone
> > in a first line and the only way to associate them with the following
> > lines containing the from= to= and result= (to know what "happened" with
> > that connection) is by using the connection id, what will *painfully*
> > overcomplicate my scripts.
> > 
> 
> As you imagine, I can't take into account individual scripts.
> 
> Other people have asked that the port or listener tag appear in lines.
> Should these appear on all lines too ?
> And the cipher ? and the authenticated user ?
> Why is the IP/host information more legitimate to be repeated than other
> information on every single line ?
> What about the fcrdns check which will appear on connect lines, does the
> check have to appear on every line now ?
> What about the spf check when it is added at some point ?
> 
> maillog is not a context-free format, where each individual line carries
> all of the information so you don't have to look at previous lines. Line
> should describe an event and carry informations related to THAT event.

I'm aware, nowadays, most people out there are a bit childish, not my
case.  I sent you this message because I think the issue is relevant for
anyone.  I don't bother developers with my own particular problems or
"asking for features".  On the contrary, the less "features" the better
for me.

My point is, I still think the IP is the more relevant data, it was
sensible to be redundant in this case.  The new format is not only more
difficult for scripting but also to the eye.  Now when I see a line
telling me "Invalid command" I have to scan the previous lines with the
same id to identify what IP came the attack from.

But don't worry, I won't die.  I'm able to change my scripts. :-)


> 
> The only guarantee I make on the format is that you can always find what
> you're looking for with at most 2 grep, one to find a session id, one to
> find the event you're 

Re: make obj failed

2019-01-02 Thread Theo de Raadt
Maciej Jan Broniarz  wrote:

> Hi,
> 
> I am following the same  guide as always: https://www.openbsd.org/stable.html

That information is quite incomplete.  If you really want to do this,
you need to read release(8).

My personal opinion is people should not bother building -stable.  We
throw almost nothing into -stable.



Re: make obj failed

2019-01-02 Thread Maciej Jan Broniarz
Hi,

I am following the same  guide as always: https://www.openbsd.org/stable.html

mjb


- Oryginalna wiadomość -
Od: "Theo de Raadt" 
Do: "Maciej Jan Broniarz" 
DW: misc@openbsd.org
Wysłane: środa, 2 styczeń 2019 14:27:22
Temat: Re: make obj failed

You are not using the build process in "man release"

You are doing something different..

> Hi,
> 
> I am updating OpenBSD 6.4 on sparc64 and during make obj i get the following 
> error:
> 
> building rem.S from /usr/src/lib/libc/arch/sparc64/gen/divrem.m4
> /bin/sh: cannot create rem.S: Permission denied
> *** Error 1 in lib/libc (arch/sparc64/Makefile.inc:23 'rem.S': @(echo 
> "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')";  cat /usr/sr...)
> *** Error 1 in lib (:48 'all')
> *** Error 1 in . (:48 'all')
> *** Error 1 in . (Makefile:95 'do-build')
> *** Error 1 in /usr/src (Makefile:74 'build')
> 
> What might be the issue here?
> 
> all best,
> mjb
> 



Re: make obj failed

2019-01-02 Thread Theo de Raadt
You are not using the build process in "man release"

You are doing something different..

> Hi,
> 
> I am updating OpenBSD 6.4 on sparc64 and during make obj i get the following 
> error:
> 
> building rem.S from /usr/src/lib/libc/arch/sparc64/gen/divrem.m4
> /bin/sh: cannot create rem.S: Permission denied
> *** Error 1 in lib/libc (arch/sparc64/Makefile.inc:23 'rem.S': @(echo 
> "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')";  cat /usr/sr...)
> *** Error 1 in lib (:48 'all')
> *** Error 1 in . (:48 'all')
> *** Error 1 in . (Makefile:95 'do-build')
> *** Error 1 in /usr/src (Makefile:74 'build')
> 
> What might be the issue here?
> 
> all best,
> mjb
> 



Iridium: Aw, snap! Something went wrong

2019-01-02 Thread Isimsiz
hello, guys, happy new year!
After last update faced some issues with MEGA.NZ - after login my Iridium
page just crash with "Aw, snap! Something went wrong while displaying this
page"

My login conf
# Default allowed authentication styles
auth-defaults:auth=passwd,skey:

# Default allowed authentication styles for authentication type ftp
auth-ftp-defaults:auth-ftp=passwd:

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin
/usr/local/sbin:\
:umask=022:\
:datasize-max=768M:\
:datasize-cur=768M:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-max=1024:\
:openfiles-cur=512:\
:stacksize-cur=4M:\
:localcipher=blowfish,a:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

daemon:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=infinity:\
:openfiles-max=1024:\
:openfiles-cur=128:\
:stacksize-cur=8M:\
:localcipher=blowfish,a:\
:tc=default:

#
# Staff have fewer restrictions and can login even when nologins are set.
#
staff:\
:datasize-cur=infinity:\
:datasize-max=infinity:\
:maxproc-max=infinity:\
:maxproc-cur=infinity:\
:ignorenologin:\
:requirehome@:\
:tc=default:

authpf:\
:welcome=/etc/motd.authpf:\
:shell=/usr/sbin/authpf:\
:tc=default:

#
# Building ports with DPB uses raised limits
#
pbuild:\
:datasize-max=infinity:\
:datasize-cur=4096M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
:tc=default:

#
# Override resource limits for certain daemons started by rc.d(8)
#
bgpd:\
:openfiles=512:\
:tc=daemon:

unbound:\
:openfiles=512:\
:tc=daemon:

Anyone alse with the same trouble? How can i fix it?
Openbsd current.


Re: Advice on Security Cameras

2019-01-02 Thread Christian Schulte



Am 01.01.2019 um 18:46 schrieb Elias M. Mariani:
> Hi list,
> I'm thinking in installing some cameras in my private home, I have
> been looking for solutions, my concern is that I wish to be able to
> look the videos from outside the house and I'm a little paranoid about
> the quality of the software that the different vendors use. I have
> seen clusters of camaras that only work over ActiveX...

I would just pay attention to the cameras to support ONVIF. Most do.
Rest is a matter of using software supporting that and your specific use
cases.

Regards,
-- 
Christian



make obj failed

2019-01-02 Thread Maciej Jan Broniarz
Hi,

I am updating OpenBSD 6.4 on sparc64 and during make obj i get the following 
error:

building rem.S from /usr/src/lib/libc/arch/sparc64/gen/divrem.m4
/bin/sh: cannot create rem.S: Permission denied
*** Error 1 in lib/libc (arch/sparc64/Makefile.inc:23 'rem.S': @(echo 
"define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')";  cat /usr/sr...)
*** Error 1 in lib (:48 'all')
*** Error 1 in . (:48 'all')
*** Error 1 in . (Makefile:95 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')

What might be the issue here?

all best,
mjb