Re: Sun M-class hardware denial of service
My understanding of this issue is that it is only likely to be caused by an exploited domain, or running OpenBSD. Both should be a rare event (OpenBSD isn't really production-ready on this hardware). It's acceptable in the majority of cases to just let the domain be unused. It's a bug, it's irritating, it should be fixed, but it's not a huge problem.
Re: Packet Filter: how to keep device names on hardware failure?
Question: How can I make sure that em2 doesn't become em0 if my dual-port NIC dies? This would be fatal for my firewall setup. At least the antispoof rules _must_ be bound to the network devices. Yep, this is an ugly problem. You could have a shellscript at boot scan ifconfig output and associate NICs with their MAC addresses, adding appropriate macros to pf.conf.
Re: Hardware recommendation for firewalls (more than 4 NICs)
On Fri, Aug 08, 2008 at 06:54:05PM -0500, patric conant wrote: You strongly overestimate the value of your comments (3 cents), it seems like there are many places more appropriate than this one for you to suggest middle-of-the-road hardware running a proprietary OS that has among the worst security records in the industry. Oh, god, Cisco vs anyone else, especially free solutions seems to degenerate into things like this. IOS and IOS XR actually has quite a good security history - other Cisco software, no. If you doubt me, actually look at the security record - oh, and be careful not to just compare OpenBSD's only 2 remote holes in the default install vs IOS - many (most) of the IOS vulnerabilities are for things that haven't been enabled by default on recent IOS images. Cisco routers general purpose computer parts of their routers are middle-of-the-road hardware in speed; much (slow) embedded hardware is far more reliable than the 'PC' equivelant. Server hardware (you shouldn't run anything important on a PC -- use proper server hardware) + Linux/Solaris/NetBSD/FreeBSD/OpenBSD works well as a router and firewall. IOS on a Cisco router does as well. The *nix solution works well and is cheap, but in my experience it's still slightly less stable than the Cisco equivelant. More importantly in many ways, Cisco hardware is usually marginally more reliable (both are reliable) than server hardware. IOS, while a complete PITA, is easier to configure than plain *nix OSes for networking stuff - one does not have sprawling config files, and making a config change updates running-config, making it easy to save your changes; ip address 192.0.2.0 255.255.255.255;do wr m is much easier than ifconfig fxp0 192.0.2.0/24;vi /etc/hostname.fxp0;edit. It's also much less error prone, which is important. With things like Quagga/Zebra this advantage is eliminated, but both of those have problems far more frequently than IOS. IOS is a lot easier to upgrade than any *nix - just copy the image, reload. Downtime is short, though many of their routers boot slow. This *could* be changed (I'm thinking something along the lines of Solaris LU - but easier), but as of yet has not been. But, it's *much* cheaper, and PF is vastly better than IOS's firewall. Software routers struggle at high PPS; Cisco makes some nice hardware that can handle that. As does Juniper, and a few others.
Re: Hardware recommendation for firewalls (more than 4 NICs)
So you expect additional reliability from stacking ebayed cisco equipment with OpenBSD bridges behind them, as the original poster mentioned, and cost effectiveness by buying used cisco equipment and paying for relicensing so that you can get updates, compared to setting up OpenBSD boxes as routers, I am not following the logic, and still think the original post was ridiculous. I understand the logic behind the no moving parts embedded solution ideas, but am I the only person whom has seen embedded equipment fail 2-4x more often than the Proliants behind them? I just don't think that embedded=reliable is a cut and dry equation. Provided the Cisco boxes will failover to different bridges, I think that it would increase reliability. There are also many occasions where it is inpractical to have an OpenBSD box terminate a link - T3, OC-12, etc. I explicitly mentioned that OpenBSD is much cheaper. One might get higher cost effectiveness in a few occasions (such as where the networking guys are clueless about OpenBSD). Of course embedded != reliable, but there are many embedded systems available that provide much higher reliability than standard x86 systems. Most Cisco routers I've seen do have moving parts - big fans. You're probably not the only person to see such failure rates, but I expect new, well cared for Cisco routers have higher hardware reliability than new, well cared for Proliants. Other embedded equipment is very variable. What embedded equipment were you talking about? The original post was ridiculous, but that doesn't make your reply accurate.
Re: Any offshore OpenBSD hosting?
But if ISP's must have blackbox on their interfaces (hello FBI),than you can't trust your local hosting company even if they are very friendly ;-) Cisco prefers a blueish-black color. Juniper boxes tend to be white and blue. In most Western countries there are many ISPs; if many of them were forced to have, in secret, black boxes on their networks, it would soon be public that that is occuring. Providers are, in many cases, being forced to allow, unmonitored, snooping by their governments - read up on CALEA. Hardware based routing platforms will be able to handle only a very small amount of traffic, the CPUs that are used in them tend to be very slow and even the fastest CPUs can route only a tiny amount of the traffic modern hardware-based routers can. So, if the government wants to monitor YOU specifically, or occasionally monitor everyone, they might be able to do it via CALEA. If I wished to monitor a large amount of peoples traffic (not all - that's not technically feasible), I would try and use passive taps with the cooperation of major transit providers. If I was on a smaller budget, then I would just do that with some major telcos. The NSA appears to have decided to use a hybrid approach. If I had very large amounts of money that I am willing to spend (well, government has lots of money, and it's not theirs, so why would they mind spending it?) I would do the same with cable providers (not the coax kind). I would definitely try and avoid small ISPs and IXPs - high maintenance, high whining and very difficult to perform surveillance using them clandestinely. Laying a submarine cable is far more expensive than starting an ISP or IXP. So, basically, you are being paranoid about the wrong things.
Re: ssh-keygen not reading stdin as expected
Option -f filename, Filename of the key file, seems to be the right option and '-' is the usual way of indicating stdin. So? Just use /dev/stdin.
OpenBGPD IPv6 problems
I'm running OpenBSD 4.2 on SPARC64. I have managed to get a simple BGP setup
working on IPv4, however the IPv6 version of the same setup fails. A BGP
session is established in both cases and peer B claims to be announcing what it
should be announcing, yet in the IPv6 version peer A does not add it to its RIB.
Host A:
AS: 64512
Loopback: 192.168.0.1 2001:db8::1
To B: 192.168.1.1/24 2001:db8:1::1/64
Host B:
AS: 64513
Loopback: 192.168.0.2 2001:db8::2
To A: 192.168.1.2/24 2001:db8:1::2/64
To miscellaneous subnet: 192.168.2.1/24 2001:db8:2::1/64
Host A:
lo0:
inet6 ::1 prefixlen 128
inet6 2001:db8::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
inet 192.168.0.1 netmask 0x
gem1:
inet6 2001:db8:1::1 prefixlen 64
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
bgp.conf.v4:
AS 64512
router-id 192.168.0.1
neighbor 192.168.1.2 {
remote-as 64513
announce all
}
allow from any
bgp.conf.v6:
AS 64512
router-id 192.168.0.1
neighbor 2001:db8:1::2 {
remote-as 64513
announce all
}
allow from any
bgpctl sh (v4):
Neighbor AS MsgRcvdMsgSentOutQ Up/Down State/PrfRcvd
192.168.1.2 64513 3 3 0 00:00:13 2
bgpctl sh (v6):
Neighbor AS MsgRcvdMsgSentOutQ Up/Down State/PrfRcvd
2001:db8:1::2 64513 3 4 0 00:00:31 0
bgpctl sh rib:
*192.168.0.2/32 192.168.1.2100 0 64513 i
*192.168.2.0/24 192.168.1.2100 0 64513 i
bgpctl sh rib inet6:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
Host B:
lo0:
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet 192.168.0.2 netmask 0x
inet6 2001:db8::2 prefixlen 128
gem0:
inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255
inet6 2001:db8:2::1 prefixlen 64
gem1:
inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
inet6 2001:db8:1::2 prefixlen 64
bgpd.conf.v4:
AS 64513
router-id 192.168.0.2
network 192.168.0.2/32
network 192.168.2.0/24
neighbor 192.168.1.1 {
remote-as 64512
announce all
}
allow from any
bgpd.conf.v6
AS 64513
router-id 192.168.0.2
network 2001:db8::2/128
network 2001:db8:2::/64
neighbor 2001:db8:1::1 {
remote-as 64512
announce all
}
allow from any
bgpctl sh (v4)
Neighbor AS MsgRcvdMsgSentOutQ Up/Down State/PrfRcvd
192.168.1.1 64512 2 4 0 00:00:11 0
bgpctl sh (v6)
Neighbor AS MsgRcvdMsgSentOutQ Up/Down State/PrfRcvd
2001:db8:1::1 64512 2 2 0 00:00:06 0
bgpctl sh rib
AI* 192.168.0.2/32 0.0.0.0100 0 i
AI* 192.168.2.0/24 0.0.0.0100 0 i
bgpctl sh rib inet6
AI* 2001:db8::2/128 :: 100 0 i
AI* 2001:db8:2::/64 :: 100 0 i
Blackhole / reject routes
Currently I'm blackholing and rejecting some traffic with route add -reject/-blackhole address 127.0.0.1; this works fine, but bounces all the rejected/blackholed traffic to the loopback interface. This behaviour is.. annoying, and possibly ineffecient. I'm probably searching for a null/blackhole/fake address/interface. I tried creating an unconfigred pseudo-device, slapping an IP address on it and routing it to there; it blackholes traffic effectively, but also blackholes traffic if you have a reject. What is a better way to reject/blackhole traffic in OpenBSD?
Re: brute force voip QoS
My bandwidth is very very limited. Not more than 140 Kbps on both sides at any time. I use G729 as a codec in order to reduce consumption. Use the pf.conf below, when VoIP is the only traffic, the quality of the calls is excelent with no voice cutting at all. Now if I start a download I immediatelly see the quality degrade. That is why I thought of using some radical policy. That's strange; it may be your connection struggles at much lower bandwidths than nominal - for instance, perhaps it suffers high packet loss at 80% utilization; TCP could recover, but VoIP might be affected. Doing what you want should be quite simple, though. There are many ways I can think of of detecting VoIP traffic if your ruleset manages to - have pf log (all) on a pflog interface dedicated to it, look at queue traffic - and many ways of blocking everything other than that. I can't think of an elegant way of doing what you want, though!
Re: low-MHz server
You said you live rurally - in that case, perhaps you should build/buy a small quality (read as: won't get wet) shed, have your systems there and run some outdoor-rated CAT5e from it to your house. That should allow you to use KVM extenders, serial, etc. Remember the inverse-square law for RF. RF usually is attentuated greatly by opaque things, though just plants etc. will also attentuate. If you can place it behind a hill that would be good. Also, apply for the JREF Million Dollar Challenge. If you succeed, you should have a lot more options on reducing RF.
Re: brute force voip QoS
To: Stuart Henderson [EMAIL PROTECTED] Subject: Re: brute force voip QoS pass out queue (std_out,lowdelay) here, you place ACKs from downloads at a higher priority than your voip calls. this is unlikely to be what you want with priq over a 140Kb/s link.. According to pf.conf, that also prioritizes packets with ToS set to lowdelay; looking at what ToS the packets have would be a good idea.
