Monday, August 17, 2009

Network Bogons

bogon - /boh'gon/ [by analogy with proton/electron/neutron, but doubtless reinforced after 1980 by the similarity to Douglas Adams's "Vogons"] 1. The elementary particle of bogosity (see quantum bogodynamics). For instance, "the Ethernet is emitting bogons again" means that it is broken or acting in an erratic or bogus fashion.

2. A query packet sent from a TCP/IP domain resolver to a root server, having the reply bit set instead of the query bit.

3. Any bogus or incorrectly formed packet sent on a network.

4. A person who is bogus or who says bogus things. This was historically the original usage, but has been overtaken by its derivative sense


If you've spent any time responsible for networks you've probably come across Team CYMRU's network bogon lists before. Basically it's a list of source networks which you should never see on the public internet. Either because they were not yet allocated, reserved by IANA for specific uses or were defined and reserved by RFC's that had been adopted as standards.

The Team CYMRU Bogon List is here, http://www.cymru.com/Documents/bogon-list.html

With IPv4 address space exhaustion about to hit most of those bogon networks are fast being allocated. Worse still many previously reserved networks that were never intended to be allocated will be.

I've already had a situation in which despite receiving emails and otherwise maintaining an awareness for new allocations I missed a new allocation before a legitimate customer wound up with an IP in it and tried to use my services. It has become a pain in the ass updating your bogon lists at this point and it makes more sense I think to identify the networks that will continue to be bogons once there is no more IPv4 addresses to allocate. Particularly when you're not a large ISP acting as a transit AS and you already run a very secure network.

My upstream ISP's are fairly good at filtering the bogon sources themselves, and my ingress ACL's are specific enough and the general security of internet facing servers is good enough that even if someone does use an unallocated source IP to attack your network in the immediate future I'm not particularly concerned.

You can rely on your upstream ISP/s to filter them for you, and if you can utilise Team CYMRU's route server you can automate the process of filtering and removing new allocations using BGP. However if you don't have trust your ISP and have no BGP capability, for whatever reason, you may need to statically filter them.

I log at a warning level so that if I do start seeing a lot of invalid traffic I can start to investigate and possibly tell those upstream ISP's that they need to filter it or may have a misconfiguration of some kind.

Wikipedia has a good overview of the current situation with linkage to RFC documents so you can consider for yourself which networks you'd like to filter.

http://en.wikipedia.org/wiki/IPv4

And the below is a self documenting example for PIX/ASA with a group for placing any malicious sources that annoy you enough to block them.

object-group network RFC-1918
description http://tools.ietf.org/html/rfc1918
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.255.0
!
object-group network RFC-2544
description http://tools.ietf.org/html/rfc2544
network-object 198.18.0.0 255.254.0.0
!
object-group network RFC-3171
description http://tools.ietf.org/html/rfc3171
network-object 224.0.0.0 224.0.0.0
!
object-group network RFC-3330
description http://tools.ietf.org/html/rfc3330
network-object 0.0.0.0 255.0.0.0
network-object 127.0.0.0 255.0.0.0
network-object 169.254.0.0 255.255.0.0
network-object 192.0.2.0 255.255.255.0
!
object-group network Nasty-Gnomes
description People we don't like.
network-object host x.x.x.x
!
object-group network Bogons
group-object RFC-1918
group-object RFC-2544
group-object RFC-3171
group-object RFC-3330
group-object Nasty-Gnomes
!
access-list outside-ACL-Inbound line 1 remark Deny unwanted source hosts
access-list outside-ACL-Inbound line 2 extended deny ip object-group Bogons any log warning

Friday, August 14, 2009

Apple IIc plus 240V modification

I have recently acquired an Apple IIc plus. This is the fastest "stock" Apple II made by Apple Computer. It was only available for a short time, and only sold in the US.

Because of that, they only have a 120v power supply available. I initially plugged it into my 240v to 120v transformer. It's a bit inconvenient (because it is both big and heavy) and I don't really like lugging the transformer around. At first I thought there might be a provision for a switch inside... nope, no such luck. The other option would be to substitute an ATX power supply. Mark referred me to this:

http://www.weirdstuff.com/cgi-bin/item/22157

It looks ok.. and it *might* even fit into the IIc plus case... but it looks more like the size of a IIe power supply.

My intention was to keep everything looking "stock". The power supply had to stay internal with no power bricks, etc. I also considered using James Littlejohn's LittlePower Adapter IIc+:

http://www.reactivemicro.com/product_info.php?cPath=1_28&products_id=150

and placing a picoPSU-60WI and a 12v supply inside, but I am unsure I will be able to fit everything inside. I may reconsider going this route later on if I ever decide to make the IIc plus a truly portable battery-powered computer.

I then did a random google search and found this site:

http://homepage.mac.com/jorgechamorro/a2things/a2c+Web/index.html

Jorge has posted schematic diagrams and how he modified his IIc plus to allow it to be powered directly from the 240v mains.

This is the power supply after I took it out of the IIc plus.

This is the space it used to sit in.

Unfortunately, The replacement capacitor I got was too tall. It would fit just exactly but I did not want the metal shell pressing down on it. So I decided to mount the capacitor sideways

This is the replacement capacitor beside the original one:

This is how it looks mounted:


The electronics shop I get all my parts from (Jaycar) did not have the 20v 5watt zener diodes that Jorge used. I thought that instead of 7 20v ones, I could use 10 15v ones.

7*20v=140v (Jorge's mod)
10*15v=150v (My substitute)

This should give me Vab of 190v (which means I don't really have to replace the capacitor)... But as my luck would have it, they only have 9 remaining units of the 15v zener diodes.

9*15v=135v

Giving me a Vab of 205v.

So I took a pcb and soldered the diodes on the solder side (that way I don't have to worry about insulating the other side from hitting other high voltage stuff). This is how it looked:

Before closing the lid, I cut off a corner of the PCB because the yellow wire is a bit stretched. I also placed a piece of clear tape on the cover in case one of the legs touch the top of the case.

Then I tested it with a multimeter and the voltages looked right (I know. I should not power up a switching power supply with no load... but.. but it's only for a little while). Then hooked it up back to the IIc plus, and it fired up without a problem. (no smoke, nothing)

The unit does get warm in the area near the diodes. I have left it on running a BASIC program drawing random stuff on the hires screen. It's a bit warmer than what I would like but seems to be acceptable. If you do a lot of disk access (continuously cataloging the disk, it tends to get hotter).

Overall I'm happy with the way this turned out. The IIc plus still looks stock on the outside and I'm now able to plug it in anywhere without lugging the oversized transformer around. I have kept the jumper I took off and the capacitor in the event I want to restore it back to default.


Tuesday, August 11, 2009

PIX or ASA Stateful Failover Configuration

I subscribe to RSS feeds from some 20 or more Cisco centric blogs, many of them maintained by CCIE's or those studying for CCIE's.

Occassionally someone posts a PIX/ASA failover configuration example. Generally I feel they fall short of the mark in providing a detailed secure and real-world example on how to configure stateful failover.

This configuration below is as complete as it gets however. And it is relevent to both PIX and ASA devices. More so for ASA as they do not have a serial interface that was used for PIX failover once upon a time in the networking dark ages.

The configuration below uses two physical interfaces on each firewall. It's seems somewhat a waste however Cisco does recommend doing so in various documents. I've not had a problem mixing both failover communication and traffic state replication on a single interface. To use just one interface remove the references with "failover-state" on the line.

Take note however, some people tend to use the Management0/0 interface on ASA firewalls as the failover or state link. It can be OK to use the 10/100mbit Man0/0 interface for failover communication as this does not utilise much bandwidth. You should however avoid using it for failover state however. Particularly on ASA models with Gigabit interfaces as state replication requires the lowest possible latency and zero packet loss to work reliably and avoid having your firewalls fail over randomly or lag behind in maintaining traffic state when they do fail over for the right reason. With multiple Gigabit interfaces simply replicating connection state information for that the traffic being permitted through the firewall can exceed the capacity of a single 100mbit interface.

And if you're not using Man0 properly for out of band management of the device you really should be!

I've also used 169.254.x.x link-local addresses on the failover and failover state links. As PIX and ASA do not have a VRF/private routing table concept they do add routes to the IP addresses you configure to their routing table. Worse still they do seem to actually route/accept traffic for the IP's you configure on failover links/state interfaces from your other interfaces.

You would of course need to accept the traffic in an ACL but it's not uncommon for some people to permit all RFC-1918 addresses to particular services. Not a good idea.

169.254.x.x are supposed to be link-local self-configuration addresses and any decently configured intermediary router should route them to null0 so provided you don't accidentally permit them in an ACL there should be no way for anyone to try and talk to your firewall on those IP's.


! ---------------------- FAILOVER CONFIG PRIMARY ------------------------ !
!
failover lan unit primary
failover lan interface failover Ethernet3
failover link failover-state Ethernet4
failover key <%FAILOVER KEY%>
failover replication http
failover interface ip failover 169.254.255.1 255.255.255.252 standby 169.254.255.2
failover interface ip failover-state 169.254.255.5 255.255.255.252 standby 169.254.255.6
failover lan enable
failover
!
int Eth3
no shut
int Eth4
no shut
!
! If you're running a 7.2 image or newer the following is also recommended.
! It will change the CLI prompt to indicate the configured type and state of the device you're connected to,
! ie if your firewall's hostname was FW0 the prompt would look like,
!
! FW0/pri/act#
!
! Indicating it's configured as the primary and it is currently active.
!
prompt hostname priority state
!
! ---------------------- FAILOVER CONFIG STANDBY ------------------------ !
! Everything else will sync over from the primary
!
failover lan unit secondary
failover lan interface failover Ethernet3
failover link failover-state Ethernet4
failover key <%FAILOVER KEY%>
failover replication http
failover interface ip failover 169.254.255.1 255.255.255.252 standby 169.254.255.2
failover interface ip failover-state 169.254.255.5 255.255.255.252 standby 169.254.255.6
failover lan enable
failover
!
int Eth3
no shut
int Eth4
no shut
!
! EOF