2009 Jun 27 - Sat
Network Broadcast Addresses
A customer was performing penetration testing on their network. Once the test results
were in, among other things, they had a couple questions about responses to certain addresses
on their external subnet range.
As a background, every subnet with a network mask of /30 or shorter has three address groups:
- first address: the zeros address aka network address
- middle addresses: usuable addresses
- last address: the ones address aka broadcast address
For explanation purposes, imagine a router with two interfaces:
- interface 1, the ingress interface, with address range of 10.0.0.0/30 and interface address of 10.0.0.1.
- interface 2, the egress interface, with address range of 10.0.0.4/30 and interface address of 10.0.0.5.
For some network devices, for a packet arriving on the ingress interface destined for the broadcast address
of the egress interface (10.0.0.7), the network device will forward the packet, effectively broadcasting to
all devices located in the subnet of the egress interfaces. When many packets arrive in this manner,
this is known as a
Smurf Attack.
Current Cisco devices, by default, no longer forward packets to broadcast addresses, but may respond to these
packets. The following command is applied by default to prevent forwarding of packets to broadcast addresses:
no ip directed-broadcast
At the other end of the subnet, for the network address, I originally thought this was a quiescent address. However,
I did find that the an ICMP echo request arriving on the ingress interface destined to the network address (10.0.0.4) of the
egress interface will generate an echo-reply with the ingress ip address (10.0.0.1) as the source address.
It appears that in days gone past, that for BSD Unix boxes and various other equipment, the network address was *the*
broadcast address. This is why some configurations allow one to configure the address of the broadcast address setting,
whether it be the high end or low end of a subnet. (thanx to Steinar Haug for this info).
rfc 1122 formalizes this broadcast address
configuration (thanx to an inciteful responder named Lee):
3.3.6 Broadcasts
There is a class of hosts* that use non-standard broadcast
address forms, substituting 0 for -1. All hosts SHOULD
recognize and accept any of these non-standard broadcast
addresses as the destination address of an incoming datagram.
A host MAY optionally have a configuration option to choose the
0 or the -1 form of broadcast address, for each physical
interface, but this option SHOULD default to the standard (-1)
form.
The host will respond with the echo-reply because of
rfc 791:
3.2.1.3 Addressing: RFC-791 Section 3.2
... An incoming datagram is destined
for the host if the datagram's destination address field is:
(1) (one of) the host's IP address(es); or
(2) an IP broadcast address valid for the connected
network; or
From a Cisco router perspective, the default use of the command 'no ip directed-broadcast', allows one
to use a /31 subnet (two ip addresses) for point to point links instead of the usual /30 subnet (four ip addresses).
One can effectively address twice as many links with the same number of addresses. This feature is mentioned in
Cisco's Feature Guide:
Using 31-Bit Prefixes on IPv4 Point-to-Point Links.
Coincidently, while I was writing this article, I received a note that there are a couple of TCP Security Assessment
documents available:
These documents go into the details of the bits and bytes making up the TCP protocol, analyzing the reasons for the bits,
how they can be misused, and suggesting counter-measures when used illegally. Theres is a detailed bibilography with
active links to related papers and documents.
An idea of the scope of the document can be seen through its first level table of content:
- The Transmission Control Protocol
- TCP Header Fields
- Common TCP Options
- Connection-Establishment Mechanism
- Connection-Termination Mechanism
- Buffer Management
- TCP Segment Reassembly Algorithm
- TCP Congestion Control
- TCP API
- Blind In-Window Attacks
- Information Leaking
- Covert Channels
- TCP Port Scanning
- Processing of ICMP Error Messages by TCP
- TCP Interaction with the Internet Protocol (IP>
- References
[/Networks]
permanent link
Securely Erasing Files
On a Linux system, there are a number of tools available for over-writing a file
with random data and then deleting the file and hiding the name of the name of the file as well.
Of course, there are certain caveats that go along with this. If you focus only on
securely deleting files, you will miss file content that may have been written to bad sectors,
file journals, sectors released when files have been relocated from one area to another
(as in when you edit or shorten files),
and various other disk dead areas.
On popular tool is a utility called shred, and is found natively on most distributions. In
the most basic form:
shred --remove filename
If you use the -v (verbose) option, you can see how many times it over-writes a file, and with
what patterns it uses. It also uses a descending 0 write in order to obliterate
a file name.
If you need to recurse sub-directories:
find * -depth -type f | xargs shred --remove
If you have created then moved or erased files and want to ensure that the released content
is overwritten, then you need to over-write drive free space and then release it. There are some
poeople who suggest using dd to fill the free space and then use shred to overwrite and delete the single
large file.
An alternative is to use
scrub, a tool built by the
Lawrence Livermore National Library folks. It uses various national standards for selecting suitable patterns
and over-writing strategies. Source can be found at
Sourceforge.
A quick way to apply all 0's to the free space of a drive:
dd if=/dev/zero of=zerofile bs=1M
sync
rm zerofile
If you can't get scrub to work, then the above command with the shred might be a good combination.
To ensure you have all the data, not just what was located in files or drive free space, one needs to
apply scrub/shred to whole partitions and/or drives. The Gentoo Wiki talks about ways of
securely deleting drives and partitions.
For near-absolute protection of data, I've known companies to specify that once a drive is no longer
useful, that it be crushed and sent to landfill.
[/OpenSource/Linux]
permanent link
|