Re: Bootable installation partition on a hard drive?
‐‐‐ Original Message ‐‐‐ On Monday, September 7, 2020 4:48 AM, Stuart Henderson wrote: > On 2020-09-07, tom ryan tomry...@gmail.com wrote: > > > On 7/9/20 5:07 pm, Walt wrote: > > > > > I have a new server on order that should arrive in a few days. > > > It's intended purpose is to replace my current firewall. It has no CD > > > and so I'll make and use a bootable flash drive as described in the > > > Installation Guide section of the FAQ. > > > The server will have a second ssd drive and so I got to wondering > > > if it might be useful to create a bootable partition on the drive and > > > install the installation on it. > > > I'm probably not going to do this but I am curious about whether it > > > would work very well. I'll probably install a second copy of the OS on > > > the second drive and mirror all configuration files to it so that if > > > anything happens to the main drive, I can turn around and boot from the > > > second and be up and running almost immediately. > > It's possible, but it's a challenge to keep them in sync. > > > Maybe you want to just run them in a softraid mirror... > > https://www.openbsd.org/faq/faq14.html#softraidDI > > This helps with some types of problem (drive failure), but doesn't help > with fat-fingered commands or bad upgrades that periodic or manual syncs > would protect against. > > My suggestions would be to keep the config files in a management system > of some sort. Whether that's a full-blown config management system like > ansible/salt, one of the simpler tools like rset, judo, rdist, or even > just commiting config files directly to a version control repository, > they will all help get a system back up and running much more quickly. > Keeping config changes to the minimum necessary helps too of course. My primary reason for the second hard drive is to use faubackup to make copies of /etc and /home to the second hard drive. I will have a 1 TB drive on the new machine and so I will have plenty of room for an extra bootable copy of the OS on it. Also, I keep copies of all the configuration files in a user directory and make my changes there instead of /etc and /etc/sshd and then use a makefile to copy the individual configuration files as necessary to /etc and elsewhere. This makes it particularly easy to replace one computer with another with a fresh copy of OpenBSD. Walt
Bootable installation partition on a hard drive?
I have a new server on order that should arrive in a few days. It's intended purpose is to replace my current firewall. It has no CD and so I'll make and use a bootable flash drive as described in the Installation Guide section of the FAQ. The server will have a second ssd drive and so I got to wondering if it might be useful to create a bootable partition on the drive and install the installation on it. I'm probably not going to do this but I am curious about whether it would work very well. I'll probably install a second copy of the OS on the second drive and mirror all configuration files to it so that if anything happens to the main drive, I can turn around and boot from the second and be up and running almost immediately. Thanks, Walt Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: How many IPs can I block before taking a performance hit?
‐‐ Original Message ‐‐‐ On Wednesday, August 12, 2020 7:11 AM, Alan McKay wrote: > Hey folks, > > This is one that is difficult to test in a test environment. > > I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM. > > With some scripting I'm looking at feeding block IPs to the firewalls > to block bad-guys in near real time, but in theory if we got attacked > by a bot net or something like that, it could result in a few thousand > IPs being blocked. Possibly even 10s of thousands. > > Are there any real-world data out there on how big of a block list we > can handle without impacting performance? > > We're doing the standard /etc/blacklist to load a table and then have > a block on the table right at the top of the ruleset. > > thanks, > -Alan > On our network, we maintain a running block of scanners but IP addresses are removed from the list after several hours of no scanning. One thing that has been useful for us is to create three sets of IP addresses from our allocation of IP addresses. One set ( currently with 9 IP addresses) allows incoming access from anywhere in the world. Another set (currently 18 IP addresses) allows incoming access from the US only. The third set (the remainder of our /24) allows no incoming access. Of course, each host may have its own rules to limit access to the services actually needed. Note that this applies to normal traffic. Regardless of where it originates, things like chargen are blocked for both incoming and outgoing traffic. Every afternoon, we download the current IPv4 and IPv6 address blocks for the US from http://www.ipdeny.com/ipblocks/data/aggregated/us-aggregated.zone for IPv4 and http://www.ipdeny.com/ipv6/ipaddresses/blocks/us.zone for IPv6. Thus, we use these lists to permit access to our "US only" hosts. The IP source of attempts to scan our IP addresses in the third set above are automatically added to the block of scanners to be blocked. These blocks are then applied to all incoming traffic. Thus, if someone tries to scan IP addresses of hosts that provide no services on the Internet, they are also blocked from connecting to any of our hosts for several hours. So if 192.0.2.20, for example, is seen as trying to scan our network, they will be blocked from accessing any of our network for a little while. During that time, connections to a service at 192.0.2.20 from our network are still permitted since it isn't entirely impossible that the interpretation of it being a network scan is an error. Walt
Re: PF firewall for desktop
‐‐‐ Original Message ‐‐‐ On Friday, May 24, 2019 2:30 PM, Jean-Francois Simon wrote: > Hi, > > Out of interest, I'd like to let you know a specific use of OpenBSD with > PF, in virtualbox, 2 virtual network card Bridged to physical NIC, and > building up a subnet with NAT and hence running Packet Filter as the > machine's firewall. > > That's the firewall I use under Win7, OpenBSD running in a VM, out of > pure interest into running BSD and let it purify the network access to > desktop (without need for additional hardware). > > Works well, love it. > > Jean-François I like having a firewall that would pretty much require someone physically entering the computer room in order to attack the firewall. With OpenBSD, your firewall can control your network traffic without having an IP address at all. One thing that you could try is to use the OpenBSD VM as the firewall, but don't assign any IP address to the firewall. The Win7 VM would have the actual IP address, but the OpenBSD VM would control the network. If I ever get around to getting enough IPv4 addresses so that I don't need a NAT, I'll go back to isolating access to the firewall with this approach. I am curious if there is any way to attack the firewall if it has no IP addresses. W
Re: Conundrum with pf
On August 20, 2018 3:58 PM, Jay Hart wrote: > Well, turned out that was indeed the issue, but only because [for some > reason] sysctl.conf did not > exist on the box...which I think instead of deleting the backup file, I must > have by mistake > deleted /etc/sysctl.conf. A quick copy over and all is well. > > I was tired yesterday and got to the point I wasn't thinking straight, so I > posted to the list to > see if the issue could be narrowed down a bit... > > dhcpd would not start due to it looking at the wrong interface, a result of > not editing > rc.conf.local properly... > > All is well and new box is online... 48 hour minimum test started now... > > THANK YOU, THANK YOU, THANK YOU!!! > > Jay I don't really remember for sure from the last time I did a fresh install, but I think that /etc/sysctl.conf isn't there by default -- if you need it, you have to create it yourself. Walt
Re: "no route to host" from pkg_add
On August 10, 2018 3:57 PM, Henry Bonath he...@thebonaths.com wrote: > Also could it be that you are using IPv6, not IPv4? (and your IPv6 is > missing its gateway) > If the IPv6 gateway is bad/missing you'll get that "no route to host" > message. I've encountered that issue before, but it isn't that big a problem with me. As an ISP, the /56 we have been allocated is too small to be very useful so I'm holding back on working on it much until such time as we get at least a /48 if not a /40. I'd like to be able to assign each customer a /56 but would settle for a /60 for each. With a /60, I could only handle sixteen customers. We have a number of customers for whom a /64 wouldn't cut it at all. I never have figured out the proper way to configure rtadvd.conf. In particular, there is an addr and an rtprefix. addr is, according to the man page, "The address filled into Prefix field" while rtprefix is " The prefix filled into the Prefix field of route information option". And then there are the proper prefix lengths -- do I use 64 or 56? It seems like prefixlen must be 64, but rtplen doesn't seem to make much difference. And then there is the kea side for prefix delegations. Since I can just put the IPv6 gateway into /etc/mygate, it's not a problem from the OpenBSD machines and it will never be a big issue if I can't get a properly sized allocation of addresses from AT Walt
Re: Best pf practices to limit ddos attacks
On July 16, 2018 8:14 PM, Ax0n a...@h-i-r.net wrote: > On Mon, Jul 16, 2018, 19:39 Walt neurobot...@protonmail.ch wrote: > > > I'm not sure what would be useful for when we are the target of an attack. > > It seems to me that when the attack is going on, our bandwidth is so > > saturated that I'm not sure what we can do except to wait it out or to pay > > our provider to help mitigate the attack. > This is pretty much the gist of it. One cannot stop this class of DDoS from > the customer's end. There are a variety of solutions involving reverse > proxies and big, scalable clusters, but the fact is if the attacker knows > your real IP address, they can food your residential or small business > connection easily. > > On the other hand, there are steps that we can take to limit any unwitting > > participation in an attack from our side. For example, I have already been > > blocking all incoming UDP, TCP, and ICMP packets from the internet that > > claim to originate from our IP addresses and all outgoing UDP, TCP, and > > ICMP packets to the internet that are not from our IP addresses. > This is a great start. Most recent attacks rely on either a fleet of many > hacked IoT/"Smart" devices to generate a bill of coordinated traffic from > thousands or even millions of networks, or they rely on UDP amplification > attacks. I just wish everyone could do this. > It sounds like you are taking adequate precautions against publicly > accessible assets that might get hijacked, so I'll focus on amplification > attacks. > UDP amplification is where an unwitting third party (such as yourself) is > hosting a UDP service that is capable of responding back with a much larger > payload than that which is sent to it. The simplest and most obvious example > is hosting an open, recursive DNS resolver. The attacker spoofs a request for > a large record (often a TXT entry) using the IP address of the real victim. > Your resolver, in return, recursively fetches and caches the answer, then > forwards the rather large response to the victim, which, of course, didn't > actually make the request and is not expecting this data. The attacker does > this repeatedly, and in tandem with a large corpus of similarly misconfigured > services hosted by other unwitting third parties. Now tens of thousands of > unsolicited DNS responses per second are exhausting the bandwidth of the > victim, and the attackers' real address isn't even involved. Similar attacks > have used misconfigured NTP servers. > Make sure your public, likely-authoritative DNS servers are not publicly > recursive for domains you don't control. > https://en.m.wikipedia.org/wiki/Split-horizon_DNS We did this some years ago when it began to be a problem. It's surprising how many probes we get every day by people looking for openly recursive servers. I am getting older (nearly retirement age but with no intention of retiring) and am trying to reduce my workload somewhat. This includes moving our web pages, e-mail, and DNS to outside providers. I'm trying to get rid of our e-mail and DNS servers first. I've already moved the DNS for our own domains to a third party provider. All that is left is the DNS we host for a customer's domain and I've been trying to get them to move it elsewhere, but they are really dragging it out. I've even offered to move it to where I moved our DNS and all they have to do is change the DNS records with the registrar, but the customer doesn't seem to be in any big hurry to move it elsewhere. One thing that I'm very curious about is how those behind ddos attacks decide which networks to attack. I know they attack some people for money but most seem to be just to cause problems. Do they just randomly pick a block of addresses and attack it or is there some criteria that make them more likely to attack? Walt
Best pf practices to limit ddos attacks
With the prevalance of ddos attacks today, are there any steps we can do to limit them. We've been the subject of a few ddos attacks over the last 15 years lasting anywhere between a couple of hours and several days. One lasted a week or two but was largely broken into two parts -- the first lasting a couple of days before disappearing and then showing up again a week later for a couple of hours. The last one lasted about three days nonstop. I'm not sure what would be useful for when we are the target of an attack. It seems to me that when the attack is going on, our bandwidth is so saturated that I'm not sure what we can do except to wait it out or to pay our provider to help mitigate the attack. On the other hand, there are steps that we can take to limit any unwitting participation in an attack from our side. For example, I have already been blocking all incoming UDP, TCP, and ICMP packets from the internet that claim to originate from our IP addresses and all outgoing UDP, TCP, and ICMP packets to the internet that are not from our IP addresses. With the ever increasing sophistication of ddos attacks, is anything else we can do in order to keep anything on our network from being used as part of a botnet or in order to reduce the severity of an incoming ddos attack. Walt Sent with ProtonMail Secure Email.
Re: Userland ppp: Change route failed -- no such process
Antti Harri wrote: On Fri, 6 Jun 2008, walt wrote: I've been running FreeBSD (userland ppp) on my old i486 firewall machine for several years and decided to try OpenBSD 4.3 on the same machine. Uhm, any particular reason for not running the kernel mode pppoe client? Wouldn't it be easier on your firewall's cpu too.. see pppoe(4) for more info. The real reason is that learning pf gives me a headache :o) I just tried kernel mode pppoe and it works fine but leaves me without a firewall. However, I just found Peter Hansteen's guide on the internet so I'll read that and then try pf again.
Re: Userland ppp: Change route failed -- no such process
walt wrote: Someone else reported this same problem back in 2005 but never got a response, so I'll try again. I've been running FreeBSD (userland ppp) on my old i486 firewall machine for several years and decided to try OpenBSD 4.3 on the same machine. I have it working well now (pppoe/DSL) except when ppp needs to change the default route e.g. when reestablishing a dropped connection. Here is ppp's log when that occurs: Jun 4 06:23:21 cyr ppp[469]: TCP/IP: route_UpdateMTU: Netif: 7 (tun0), dst 0.0.0.0/0, mtu 1492 Jun 4 06:23:21 cyr ppp[469]: ID0: 1 = socket(17, 3, 0) Jun 4 06:23:21 cyr ppp[469]: ID0: -1 = write(1, data, 120) Jun 4 06:23:21 cyr ppp[469]: TCP/IP: rt_Update failure: Jun 4 06:23:21 cyr ppp[469]: TCP/IP: rt_Update: Dst = 0.0.0.0/0 Jun 4 06:23:21 cyr ppp[469]: Warning: 0.0.0.0/0: Change route failed: errno: No such process... Again, just for the google record: I reinstalled FreeBSD and I see the same error message -- but the ppp connection works correctly anyway. Apparently the 'Change route failed' error is not the real problem but I don't know how to debug this any further. Meanwhile I'll stay with FreeBSD. Any other suggestions are welcome.
Userland ppp: Change route failed -- no such process
Someone else reported this same problem back in 2005 but never got a
response, so I'll try again.
I've been running FreeBSD (userland ppp) on my old i486 firewall machine
for several years and decided to try OpenBSD 4.3 on the same machine.
I have it working well now (pppoe/DSL) except when ppp needs to change
the default route e.g. when reestablishing a dropped connection.
Here is ppp's log when that occurs:
Jun 4 06:23:21 cyr ppp[469]: TCP/IP: route_UpdateMTU: Netif: 7 (tun0), dst
0.0.0.0/0, mtu 1492
Jun 4 06:23:21 cyr ppp[469]: ID0: 1 = socket(17, 3, 0)
Jun 4 06:23:21 cyr ppp[469]: ID0: -1 = write(1, data, 120)
Jun 4 06:23:21 cyr ppp[469]: TCP/IP: rt_Update failure:
Jun 4 06:23:21 cyr ppp[469]: TCP/IP: rt_Update: Dst = 0.0.0.0/0
Jun 4 06:23:21 cyr ppp[469]: Warning: 0.0.0.0/0: Change route failed: errno:
No such process
This happens when my ISP gives me a different IP address when reconnecting.
The new connection doesn't work until I use pppctl to add! default HISADDR
manually.
The ppp code responsible for changing the route is found in
/usr/src/usr.sbin/ppp/ppp/route.c:
s = ID0socket(PF_ROUTE, SOCK_RAW, 0);
wb = ID0write(s, rtmes, rtmes.m_rtm.rtm_msglen);
if (wb 0) {
ncprange_setsa(ncpdst, dst, mask);
log_Printf(LogTCPIP, rt_Update failure:\n);
log_Printf(LogTCPIP, rt_Update: Dst = %s\n, ncprange_ntoa(ncpdst));
if (rtmes.m_rtm.rtm_errno == 0)
log_Printf(LogWARN, %s: Change route failed: errno: %s\n,
ncprange_ntoa(ncpdst), strerror(errno));
So ppp writes to a socket when trying to change routes, but I don't
know who is supposed to be listening at the other end, or why he is
missing in action.
Any ideas?
Thanks!
