Re: perl interface to pf?
John N. Brahy wrote: Is there a perl interface to pf? No, and it would be totally insane to build one. PF is not a low-level assembly language for expressing ioctl(2) calls. It is an LALR(1) grammar for specifying firewall policies. Because of its high abstraction level compared to said assembly languages, chances are you do not need perl(1) at all for anything. Hopefully, this shuts up the thread.
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
per engelbrecht wrote: Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a 'no synchronization' option for this connection. Do I need it at all. Been poking around in /usr/src/usr.sbin/bgpd without solving it, but it's needed in zebra and Cisco IOS hence the question. A: ? Using your own AS as an remote ASn will, per definition, make your BGP session into an internal BGP session. In the Ciscoeee world, no synchronization means to begin announcing your networks before higher priority network protocols are up and stabilized. Without you will wait for OSPF/IS-IS to stabilize first (For OSPF, there is a certain state in its state machine it has to reach for all broadcast clouds etc). However, in modern BGP setups, you screw OSPF/IS-IS royally and ignore the stabilization. This is viable, since you ``nail down'' your networks as CIDR aggregates (to minimize the number of BGP prefixes you announce) and give a heck about internal reachability. Oh, and while we are at Zebra: Its crap, kill it as soon as possible or install quagga. Case in point: mirah% pwd /usr/ports/net/zebra/w-zebra-0.93ap3/zebra-0.93a/ospfd mirah% grep OSPF_LSA_HEADER ospf_lsa.c ospf_output_forward (s, OSPF_LSA_HEADER_SIZE); assert (l1-data-length OSPF_LSA_HEADER_SIZE); if (memcmp (p1 + OSPF_LSA_HEADER_SIZE, p2 + OSPF_LSA_HEADER_SIZE, ntohs( l1-data-length ) - OSPF_LSA_HEADER_SIZE) != 0) mirah% Lets see... On the last line, we have identified that l1-data-length is in network byte order. But in the assert 2 lines up, we do _not_ have a ntohs() call. This took a medium sized ISP down in Denmark because Zebra suddenly died due to the fact, that certain packets, if certain size, will be caught by the assertion and ospfd gets to say hello to the kernel thread known as reaper man. Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and internal intfaces in area 0.0.0.1 (and from ospfd.conf) [...] fib-update yes redistribute connected [...] This is about redistributing routes - will the above let BGP and OSPF play along in the same way a 'redistribute ospf' in Zebra/Cisco IOS A: ? It will push directly connected routes into OSPF. That is, if the machine has a network to which it has a direct connection in the routing table, then the rest of your OSPF speakers will learn that this network is reachable by going through this router. redistribute ospf in Ciscoee in the BGP section of the router configuration tells the IOS to take all OSPF learned routes and push them into BGP. This can be extremely dangerous to do, depending on the configuration. Q: default gateway is added to the routing table after all interfaces are configured. BGP is adding information into the routing table and so does OSPF (updates). That's 3 times redistributing of routes between different protocols and with 3 different administrative distances but still in/from the same table. Since directly connected (0) or static (1) connections are superior to e.g. eBGP (20) and OSPF (110) then should or shouldn't /etc/mygate be removed from a BGP router before putting it into production. Will it/can it mock the routing decision despite 'weight' in bgpd.conf due to the lower distance. A: ? A more specific route will always match. Normally, you do not need to redistribute routes between the protocols at all, considered all of your routers are running BGP as well as OSPF. BGP will then handle prefixes for external networks and OSPF will handle prefixes for internal ones in the case both BGP and OSPF have the route then BGP wins -- but note the note about specific matches ;)
Re: Limiting Shell Access Damage (was Guruness)
Will H. Backman wrote: Turning this into a learning experience: Does anyone have any hints or advice about hardening OpenBSD for shell accounts. Do people tweak things other than the login.conf settings? I have to deal with student shell accounts where students are learning to program and often create problems by accident. Apart from login.conf(5): It is really hard on UNIX(tm) systems to protect a system if users are conspiring to kill it. Therefore, the first rule should be to trust your users to a certain extent. Assume that the students are not dumb, but know that they will create code where malloc()'s are not free()'d (Leading to 800+Mb memory usage for a single process, login.conf(5) is your friend). Also, they will, after talking with their old somewhat nutty professor, attempt to write a simple protocol implementation in which every new incoming UDP packet results in a fork() being made Filesystem quotas can help a lot. So can process accounting in post-mortem analysis. A single odd-process-reaper running via cron(1) can do wonders to those 99%CPU spinning Matlab processes running under Linux-emulation where theres no source code fix. Remember to generalize the reaper and let the process accounting data be the guide of what to add. Do not underestimate the power of policy. A student having signed the Acceptable-Use-Policy form will not conspire as much against the system since the consequence is account deletion. Many computer users are accustomed to environments where there is a single user on a PC. A typical attack vector, however, for 1000+ account sites is a compromised account. You can assume at least 5 per 1000 accounts are compromised or have easily guessable passwords. Those will not heed your policy forms whatever you do. You can mitigate the risk by separating systems and limiting account access. When this is not possible, ProPolice, W^X, StackGhost, etc will come in very handy. Monitoring is also something you should ponder about. In general, students need the freedom to play -- they are in this to learn, so you should give them the freedom, but use policy enforcement if they abuse the freedom given. Network and filesystems can be monitored easily as well as memory, interrupt counts etc. The monitoring will make you able to act when something goes wrong in a quick manner. Beware of micro-management though.
Re: ThinkPad testers required
imEnsion wrote: I have a thinkpad x22.. not sure if I can help, but if i can slap a snapshot on the lappy, would it be of any help? Unfortunately not: Can people with the following laptops: - ThinkPad R50, R50p, R51, R52 - ThinkPad T41, T41p, T42, T42p, T43, T43p - ThinkPad X40 - ThinkPad X41, X41 Tablet The reason is quite simple: x22 (and the x24 I own) do not have the aps system in them. Testing snapshots regularily is however a good way to produce a stable release, so it should be done frequently. I like the idea of running -current on the laptop and test boxes and releases on the servers in production. That way you can play with new stuff quickly and be alerted when something changes that impacts you (proper mmap()-based malloc() comes to mind).
Re: Ammunition needed to defend OpenBSD/pf
chefren wrote: Two equal power supplies in line: Twice as much the risk of a brakedown of the system and two times as much failures of power supplies. Lets see. Let X be the (boolean) random variable designating ''system X breaks down in the first N years''. Equally, let Y be the random variable designating ''system Y breaks down in the first N years''. Then P(X = 1) is the probability of X breaking down and similarly, P(Y = 1) is the probability Y breaks down. Now (X = 1) and (Y = 1) are clearly independent. If one breaks down, it does not influence wether or not the other one does. But since the events are independent, they cannot be mutually exclusive. This makes sense logically, since both X and Y can break down in N years so intecsection(X = 1, Y = 1) is not the empty set which implies X and Y not mutually exclusive. The addition rule for independent events gives us: P(union(X = 1, Y = 1)) = P(X = 1) + P(Y = 1) - P(X = 1) * P(Y = 1) So you forget the last term by saying ''twice as much''. You have to deduct the probability that both events occur (or it would have been ''counted'' twice). Two equal power supplies in parallel: Half the risk of a brakedown of the system but still two times as much failures of power supplies and twice the support effort for the power supplies. Now in this case, we still have independence, but now both has to fail. In other words P(intersection(X = 1, Y = 1)) = P(X = 1) * P(Y = 1) This is theory. In practice a failing power supply will be changed as soon as it shows an error. Especially in the serial case. This means that in practice, one has to do a more heavyweight probability analysis. One needs the probabilities after one month, after 2, 3, 4, etc to do the discrete case. I can assure you the probabilities are not as easy as you are taking them to be.
Re: CVS - Lock File
Quoting Peter Valchev ([EMAIL PROTECTED]): Have you looked at subversion? A colleague of mine is fanatical about it, athough we don't use it here. You mean the one that has 23 build dependencies, and only compiles on i386? Hah. That is the primary problem. The second problem is the problems it solves are not that interesting. The minor touchups are atomic commits (a good thing) and faster branching. But currently, that is about it. I would rather have soeen a good refactoring of the CVS code. I can see that it is what I am going to get. -- jlouis
