Posts Tagged ‘freebsd’

make buildworld & IBM x3650 m3

Sunday, September 28th, 2014

Upgrade from 10.0-RELEASE to 10.1-PRERELEASE

Brand: IBM x3650 m3

In order to successfully boot the server make sure to enable legacy support as per this thread.

Processor: 2 x Intel Xeon X5650 2.67Ghz (6 cores each)
Memory: 144GB
HDD: 2 x 72GB (15k RPM, 6Gbps SAS 2.5-inch) in RAID1

Softupdates: ON
SMP: ON

  1. CPU: Intel(R) Xeon(R) CPU X5650  @ 2.67GHz (2666.82-MHz K8-class CPU)
  2. real memory = 154618822656 (147456 MB)
  3. avail memory = 150235295744 (143275 MB)
  4. mfi0: <LSI MegaSAS Gen2> port 0x1000-0x10ff mem 0x97940000-0x97943fff,0x97900000-0x9793ffff irq 16 at device 0.0 on pci1
  5. mfid0: 68664MB (140623872 sectors) RAID volume (no label) is optimal

make -j4 buildworld: 31mm 20ss
make -j4 buildkernel: 03mm 31ss
make installkernel: 09ss
make installworld: 58ss

NSD and OpenDNSSEC under FreeBSD 10 [Part 4: Firewall]

Sunday, August 31st, 2014

This is the forth part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

It’s just a reference for firewall freaks like me showing which ports need to be opened on each respective server.

I’m using PF on all four servers with the ‘deny all’ default rule.

NS-FEED needs to be able to send 53/udp to the signer and both slaves (to NOTIFY about zone changes). It has to accept incoming 53/tcp from the signer and both slaves (to allow zone transfers) and also it has to accept 53/udp from the signer (the signer will periodically poll the hidden master for zone changes):

  1. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.1 port = domain keep state
  2. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.2 port = domain keep state
  3. pass out quick on xl0 inet proto udp from xl0 to 10.9.128.2 port = domain keep state
  4.  
  5. pass in quick on xl0 inet proto tcp from 192.168.128.1 to xl0 port = domain flags S/SA keep state
  6. pass in quick on xl0 inet proto tcp from 192.168.128.2 to xl0 port = domain flags S/SA keep state
  7. pass in quick on xl0 inet proto tcp from 10.9.128.2 to xl0 port = domain flags S/SA keep state
  8.  
  9. pass in quick on xl0 inet proto udp from 10.9.128.2 to xl0 port = domain keep state

NS-SIGN has to be able to send 53/udp and 53/tcp to the hidden master (to request and perform zone transfer from the hidden master). It has to be able to send 53/udp to both slaves (to notify slaves about zone changes). It has to accept incoming 53/tcp from both slaves (to allow zone transfers) and also it has to accept 53/udp from the hidden master:

  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto udp from xl0 to 10.9.128.1 port = domain keep state
  3. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.1 port = domain keep state
  4. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.2 port = domain keep state
  5.  
  6. pass in quick on xl0 inet proto tcp from 192.168.128.1 to xl0 port = domain flags S/SA keep state
  7. pass in quick on xl0 inet proto tcp from 192.168.128.2 to xl0 port = domain flags S/SA keep state
  8. pass in quick on xl0 inet proto tcp from 10.9.128.1 to xl0 port = domain flags S/SA keep state

NS-3 and NS-4 have to be able to send 53/tcp to the hidden master and the signer (to request zone transfers). They also have to accept incoming 53/udp and 53/tcp from anywhere to serve recursive DNS requests:

  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.2 port = domain flags S/SA modulate state
  3.  
  4. pass in quick on xl0 inet proto udp from any to 192.168.128.1 port = domain keep state
  5. pass in quick on xl0 inet proto tcp from any to 192.168.128.1 port = domain flags S/SA modulate state
  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.2 port = domain flags S/SA modulate state
  3.  
  4. pass in quick on xl0 inet proto udp from any to 192.168.128.2 port = domain keep state
  5. pass in quick on xl0 inet proto tcp from any to 192.168.128.2 port = domain flags S/SA modulate state

NSD and OpenDNSSEC under FreeBSD 10 [Part 3: OpenDNSSEC]

Sunday, August 31st, 2014

This is the third part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

In this exercise we’re going to configure our signing server NS-SIGN which will be running OpenDNSSEC with DNSSEC keys stored in SoftHSM.

For the sake of simplicity, let’s assume we’re going to host a zone called signed.org.

(more…)

NSD and OpenDNSSEC under FreeBSD 10 [Part 2: NSD]

Friday, August 29th, 2014

This is the second part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

Today, we’re going to deploy NS-FEED, NS-3 and NS-4 dealing with plain zones only. We’re not going to sign anything yet — we’ll deploy NS-FEED as a hidden master, configure it to feed NS-3 and NS-4 and configure NS-3/NS-4 to be masters for the ISP slave. This is probably the easiest part since configuration of NSD is quite easy.

(more…)

NSD and OpenDNSSEC under FreeBSD 10 [Part 1: Layout]

Wednesday, August 27th, 2014

In the following set of articles I’m planning to explain how to run NSD and OpenDNSSEC under FreeBSD 10. Since the setup involves a number of servers and at the end becomes “kind of” complicated I’m going to split it into series of articles, so it should be easier to track the progress.

Before we jump into technical nuances let me try to explain what exactly I’m trying to achieve and why.

Prior to deploying DNSSEC our setup was pretty straight-forward — a pair of authoritative DNS servers: one acting as a master and another one as a slave, with extra slave on the ISP side. Nothing fancy — it just works. With the introduction of DNSSEC a number of questions arose.

The first one is obviously related to the security: authoritative servers are exposed to the Internet. If the server is compromised your DNSSEC keys are gone, so we need to segregate authoritative servers from the signing engine and store keys in some secure media.

The second question is manageability: you will be dealing with regular renewals of ZSK keys and occasional renewals of KSK keys. Multiply this by a number of domains and you quickly realize that you would like to automate it to the maximum possible extent (either by using scripts like zkt or something more intelligent like OpenDNSSEC). And although KSK renewal is still manual ZSK renewal should be fully automated.

The third question is flexibility: you should be able to construct a “tree” of DNS servers in a such way that will allow you to add additional slaves quickly without touching the master node.

So here is the setup that we’ll be working on. I’m sure it’s not fully bullet-proof and there are plenty of things to improve, but it’s a good start.

2014082101

We’re going to configure four servers: NS-FEED, NS-SIGN, NS-3 and NS-4. ISP’s slave DNS is out of our control and is shown as a reference only, since it’s going to be one of the slaves. The operating system on all four servers is FreeBSD 10.0-STABLE (for those interested: KERNEL, make.conf, src.conf) with IPv6 disabled.

Here are more details about each server:

NS-FEED is our hidden master running NSD. It’s placed in the private LAN and it can only communicate with NS-SIGN, NS-3 and NS-4. This server will hold plain DNS zones. As you can see from the setup there are certain zones that don’t need to be signed — they will be fed directly to NS-3 and NS-4. Those zones that do need to be signed will be fed to NS-SIGN. This is the only server you need to access in order to make zone changes (add/delete/update records). The IP address of NS-FEED is 10.9.128.1.

NS-SIGN is our signing server running OpenDNSSEC. It’s also placed in the private LAN and it can only communicate with NS-FEED, NS-3 and NS-4. The primary role of this server is to get a plain zone from NS-FEED, sign it and transfer it to NS-3 and NS-4. This is the server where the DNSSEC keys are stored in a secure store provided by SoftHSM. All operational tasks, like how and when to (re-)sign zones, using what algorithm and such are handled by OpenDNSSEC. SoftHSM cryptographic store is accessible through a PKCS #11 interface which gives you a possibility to replace it with the “proper” hardware HSM in the future. Keep in mind that from the DNS perspective NS-SIGN is not an authoritative server — although it does zone transfers over AXFR/IXFR and listens on port 53/udp/tcp it doesn’t actually hold any zones so if you try to query it with dig you’ll get no response. The IP address of NS-SIGN is 10.9.128.2.

NS-3 and NS-4 are our publicly visible slaves running NSD. They are located in the DMZ, respond to 53/udp/tcp from the outside and keep plain and signed zones. However, they are not simple slaves (and this is where the fun begins), but also act as masters for other slaves (in our case it’s the ISP DNS). Without this hook, the slave from the ISP won’t be able to fetch zones, so you’ll have to feed it from NS-SIGN which you don’t want to do. IP addresses of NS-3 and NS-4 are 192.168.128.1 and 192.168.128.2.

Finally, ISP SLAVE DNS is the slave located on the ISP side. The IP address is 172.16.128.1.

So, to summarize: there is a hidden master (NS-FEED) holding plain zones and distributing it further, there is a hidden signer (NS-SIGN) getting plain zones from NS-FEED, signing and distributing them to NS-3/NS-4, there are two public slaves (NS-3 and NS-4) acting as slave+master, and there is a slave on the ISP side.

Tomorrow we’ll start with the first task: configuring NS-FEED and NS-3/NS-4 to deal with plain zones.

Policy routing with IP Filter on FreeBSD

Saturday, January 3rd, 2009

In this post I’ll write about implementation of policy routing with IP Filter on FreeBSD. Policy routing is a process of forcing packets to follow a particular route not necessary through default gateway. This is very useful in a multihomed environment when your FreeBSD server acts as a router and you want different networks to be routed differently based on a source network or interface.

(more…)

make buildworld & Asus P5KPL-VM

Tuesday, September 16th, 2008

Upgrade from 7.0-RELEASE to 7.1-PRERELEASE

Brand: N/A
Motherboard: Asus P5KPL-VM

Processor: Intel Core 2 Duo E6550 2.33Ghz
Memory: 2GB DDR2 800
HDD: 250GB 7200rpm SATA150

Softupdates: ON
SMP: ON

  1. CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2331.01-MHz 686-class CPU)
  2. real memory = 2147090432 (2047 MB)
  3. avail memory = 2091548672 (1994 MB)
  4. ad4: 238475MB <MAXTOR STM3250310AS 3.AAC> at ata2-master SATA150

make -j4 buildworld: 17mm 55ss
make -j4 buildkernel: 07mm 56ss
make installkernel: 12ss
make installworld: 01mm 39ss

How to enable SMP support in Compaq Proliant 800

Saturday, August 30th, 2008

I was thinking to write about how to enable SMP support in Compaq Proliant 800 quite a while ago, but only today found my four years old notes.

First of all, download Compaq System Configuration Utility for Proliant 800 (go to hp.com -> Software & Driver Downloads -> check Download drivers and software and type Proliant 800 -> Microsoft MS-DOS -> Software – System Management -> Compaq System Configuration Utility (multi-part download)). This SoftPaq creates four diskettes but you basically need the first and the second one.

Insert the Compaq System Configuration Utility diskette 1 and reboot the server. Hit F10 after you have memory, processors and SCSI devices initialized and the server will start System Configuration from a floppy drive. Now, in order to reach “APIC Mode” settings you should press “Ctrl-A” at the very first menu. As soon as you did it you should see small notification window saying something like “Advanced Mode was activated”. Enter System Configuration and follow the prompts to complete basic configuration load (at some point you will be prompted to insert the Compaq System Configuration Utility diskette 2).

Select “Review” from the menu and then “View/Edit Details”. Scroll down the list and look for “APIC Mode”. Enter it and select “Full Table, Mapped” (by default it should be disabled). Once done, exit and save the configuration changes.

Make sure that FreeBSD is happy, assuming that the kernel was compiled with SMP support:

  1. MPTable: <COMPAQ PROLIANT>
  2. FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  3. cpu0 (BSP): APIC ID: 1
  4. cpu1 (AP): APIC ID: 0
  5. SMP: AP CPU #1 Launched!

Upgrading to FreeBSD 7 from 6.3-STABLE

Monday, August 25th, 2008

Yesterday, I’ve finally get some time to upgrade one of my FreeBSD 6.3-STABLE test machines to FreeBSD 7.

Note that starting from 6.2-RELEASE you can do binary upgrades by using freebsd-update utility. Detailed explanation is provided by Colin Percival in his blog entry available at http://www.daemonology.net/blog/2007-11.html.

Source-based upgrades are supported as well and this is what I prefer to use. I’ll try to summarize key points you should take into consideration before starting upgrading to version 7.

(more…)

Adding extra points with Botnet

Friday, August 15th, 2008

Here is another SpamAssassin plugin that helps adding extra points to get that desired message rejected effect. It was written by John Rudd and available at http://people.ucsc.edu/~jrudd/spamassassin/. This plugin does really nice job for me! Here are some numbers during eight hours of operation on a pretty low volume email server:

  1. cat /var/spool/qscan/qmail-queue.log | grep BOTNET | wc -l
  2. 226

That’s great! I did faced already with a couple of false-positives, mainly because our projects host email servers on DSL lines with either no A records or client-like hostnames (which is almost fixed!), but all in all I’m pretty happy with Botnet. Keep up good work and thanks!