Centroid.EU Blog
(this blog is mostly encrypted - adults only)
|
Previous Page
May 17th, 2014
I tested this and it seems to work. Unfortunately I wasn't able to test
the IPv6 part of it, I lack an IPv6 master server.
0 comments
The NSA, 1 year after Snowden
May 14th, 2014
Before the Snowden revelation there was the
Warnings.
and after the Snowden revelation I've expressed:
and Solutions
But in conclusion there is nothing we can do. The NSA will still listen in
and backdoor equipment for as long as they can. There really is not much we
can do if we want to continue using the Internet. Change will be slowly as
recommendations are to phase out american equipment in order to be entirely
safe. And then we're still not safe. Take it in stride. At least we have
an inner clock that tells us that something is wrong with all this, but we
mainly (or I mainly) aren't ready to hear it. It's like meeting aliens for
the first time, we won't be ready.
0 comments
OpenBSD load sharing at the switch level
May 13th, 2014
Since I got my new computer I've set up a virtual lab with 5 QEMU vm's.
I want to show you an idea of mine that will drastically reduce load on
a set of routers seperated by a bridge. The idea is this: the lower you
go in OSI layers the less load. So you could have a setup like so:
[0] ISP router (layer 3)
|
[1] switch lev 0 (layer 2)
/ \
[2] [3] switch lev 1 (layer 2)
/ | | \
[4] [5] [6] [7] router lev 0 (layer 3)
Pretend you get a lot of pps (packets per second) or traffic that an OpenBSD
box can't handle. The idea in the above picture is to distribute the load
on layer 2 which has a lot less overhead than layer 3 (IP routing), so if
you have node 1, 2 and 3 be switches that round-robin their frames, the load
will be reduced by the time the frames get to nodes 4, 5, 6, and 7. I call
a router/switch a node here somethign with 3+ interfaces.
So how would that work without causign a mess? Well I set it up in the lab
and I only went as far as nodes 0, 1, 2, 3 and 4. The concept should work
with another few sets of switch levels but I'm gonna keep it short.
Here is the setup on node1:
$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.bridge0
add em0 add trunk0
up
/etc/hostname.em0
inet 10.0.0.2 255.255.255.0
/etc/hostname.em1
up
/etc/hostname.em2
up
/etc/hostname.trunk0
trunkproto roundrobin
trunkport em1 trunkport em2
up
As you can see I have added interfaces em1 and em2 to trunk0 which round robins
and added that with em0 to bridge0. This works! Interface em0 doesn't need
an IP but I put one on so I can reach it in the test environment. You can
add another interface for out of band access.
Now then for nodes 2 and 3 the magic happens:
Node2:
$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.carp0
inet 10.20.0.2 255.255.255.0
vhid 1
up
/etc/hostname.em0
lladdr 00:11:22:33:44:89
up
/etc/hostname.em1
inet 10.20.0.3 255.255.255.0
/etc/hostname.trunk0
inet 10.0.0.24 255.255.255.0
trunkport em0
up
!/usr/sbin/arp -s 10.0.0.2 68:03:09:13:04:07
!/usr/sbin/arp -s 10.0.0.254 fe:e1:ba:d3:a9:46
!/usr/sbin/arp -s 10.0.0.1 68:03:09:13:99:07
Node3:
$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.carp0
inet 10.20.0.2 255.255.255.0
vhid 1
up
/etc/hostname.em0
lladdr 00:11:22:33:44:89
up
/etc/hostname.em1
inet 10.20.0.4 255.255.255.0
/etc/hostname.trunk0
inet 10.0.0.24 255.255.255.0
trunkport em0
up
!/usr/sbin/arp -s 10.0.0.2 68:03:09:13:04:07
!/usr/sbin/arp -s 10.0.0.254 fe:e1:ba:d3:a9:46
!/usr/sbin/arp -s 10.0.0.1 68:03:09:13:99:07
As you can see here the link layer address on both has been set to the same
MAC address, and the network layer address as well (10.0.0.24). I had to set
static ARP because return packets in the round robin on node 1 would not
guarantee that ARP replies would come back to the node that asked for it. It
can answer ARP though because for all it cares or knows (on either node 2 or 3)
that this is it's own address. Access to these boxes can only be granted on
the em1 interface or on an out of band interface.
I have carped the em1 interface which goes to node 4 which is a user host.
From there I want to show you a ping and a traceroute to node 1.
$ ping -c 4 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=254 time=3.270 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=254 time=3.057 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=254 time=3.172 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=254 time=2.779 ms
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.779/3.069/3.270/0.192 ms
$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
1 10.20.0.4 (10.20.0.4) 2.653 ms 1.634 ms 1.187 ms
2 10.0.0.1 (10.0.0.1) 3.364 ms 2.917 ms 2.943 ms
As you can see all packets make it. I had to disable pf(4) on nodes 2 and 3,
as there was a state syncronization problem. This can be fixed with pfsync(4)
but is another project worth.
Also make sure that both CARP interfaces don't go into MASTER mode. Or else
this causes DUP!'s (duplicate packets) in ping. This happened to me just as
I was wrapping up.
I hope you can build extra capability with this idea if only 1 router would
not have been enough for the load behind the ISP (node 0).
0 comments
Happy 1400000000
May 13th, 2014
UNIX timestamp just wrapped over a bit more than an hour ago..
# date -r 1400000000
Tue May 13 18:53:20 CEST 2014
The next one is in 3 years and a month or so.
0 comments
Wildcarddnsd now has NAPTR support
May 11th, 2014
I wanted to get this in so I can try out ENUM services. NAPTR (stands for
Naming Authority Pointer) Resource Record is used in VOIP a lot. It helps
reading the RFC (which I admittedly have not done fully) to get a better idea
of what it does. RFC 2915. Joy!
0 comments
Wildcarddnsd now has EDNS0 support
May 10th, 2014
I just committed the last bits. EDNS0 (RFC 6891) allows greater UDP sized packets than the RFC 1035
specification of 512 bytes per answer. This now opens the door for me to do
NAPTR RR and DNSSEC which is on my Todo list. BTW RFC 6891 replaces RFC 2671
which was so impossible to figure out that I had to wait until a new RFC came
on the scene. Thanks Vixie (at least he polished it)!
0 comments
Administrivia and future plans network wise
May 7th, 2014
I have added ratelimiting to io.solarscale.de which runs nsd. For this the
nsd needed a recompile. This literature on the web was very helpful:
nsd-ratelimit. I have set it to 12 queries per second, same as wildcarddnsd's ratelimit
on americas.centroid.eu.
I have evaluated a lot of scenarios on how I want to reorganize my network
and I have decided to get a DSL with static IP's in February 2015 again.
I'll be running a wildcarddnsd from home again. Earlier in september 2014 my
vps moon.virgostar.net will expire, I'll take it out of active DNS duty
possibly in august. I'll run with 2 nameservers from that point on until
2015. In february I'm also going to get rid of the io.solarscale.de vps
possibly for a transip.eu (amsterdam) vps instead (which will run OpenBSD).
This is still in the clouds (so to speak) so I'm not entirely positive on that.
And to test the transip.eu vps I'll possibly get that in november 2014 possibly
after the Wildcarddnsd 0.9.0 BETA release. So a lot of shuffling is taking
place, the only thing that won't change is americas.centroid.eu which is
prepaid until 2016, unless they figure out how to hypervisor OpenBSD in bhyve,
which I will then probably take.
0 comments
Wildcarddnsd now has packet rate limiting
May 5th, 2014
I don't think I've ever had someone use me for an amplification DoS attack,
but I don't watch the logs all the time. However it's not impossible so I
have added a rate limiting algorithm on the hash of the IP querying my server
so that I will drop the query when a threshold is reached. I had given this
implementation thought for a while now and finally I wrote out the code.
Wildcarddnsd will use more memory depending on the packets per second
(details) and the hash of IP addresses is limited to 16 bit, meaning
that there can be collisions between unrelated IP addresses that cause the
ratelimiting to snare. But a high enough rate limit of say 12 packets per
second on a nameserver with a usual TTL of 1 day shouldn't cause a problem.
The pps is definable between 1 packet per second and 127 packets per second.
The maximum setting will consume up to 120 MB of RAM, but RAM is cheap when
we talk about 120 MB's. :-) I'm pretty happy right now.
0 comments
Got OpenBSD 5.5 in the mail yesterday
May 4th, 2014
I got my pre-ordered OpenBSD CD's in
the mail. Unfortunately the seal was broken so someone possibly tried these
out. Also I already upgraded my entire network to 5.5 on May 1st. Let this
be a warning to OpenBSD, release pre-orders early or be faced with us doing
ftp installs! We can't wait we're that hooked! However the CD's are quality
like always, it's just too bad these become cup coasters after half a year, but
that's part of the product that someone should know about.
0 comments
Two "racing" ARP's
April 28th, 2014
OpenBSD is different than other OS's in that it has a reverse ARP channel open
alongside a forward ARP channel. I tried to exploit this with one of my
programs I wrote, since frames are in sequence and scheduling in the OpenBSD
kernel is done in a FIFO manner.
20:33:05.793519 bc:ee:7b:dd:2e:5a ff:ff:ff:ff:ff:ff 0806 60: arp who-has \
192.168.34.1 (ff:ff:ff:ff:ff:ff) tell 192.168.34.5
0000: ffff ffff ffff bcee 7bdd 2e5a 0806 0001 ........{..Z....
0010: 0800 0604 0001 bcee 7bdd 2e5a c0a8 2205 ........{..Z..".
0020: ffff ffff ffff c0a8 2201 3100 0000 0000 ........".1.....
0030: 0000 0000 0000 0000 0000 0000 ............
20:33:05.793572 bc:ee:7b:dd:2e:5a ff:ff:ff:ff:ff:ff 8035 60: arp who-has \
192.168.34.1 (ff:ff:ff:ff:ff:ff) tell 192.168.34.5
0000: ffff ffff ffff bcee 7bdd 2e5a 8035 0001 ........{..Z.5..
0010: 0800 0604 0001 bcee 7bdd 2e5a c0a8 2205 ........{..Z..".
0020: ffff ffff ffff c0a8 2201 3200 0000 0000 ........".2.....
0030: 0000 0000 0000 0000 0000 0000 ............
Here you see two outgoing ARP's the first, a forward ARP is .000053 seconds
before the second one a reverse ARP (seen here with a 8035 ethernet type).
20:33:05.793773 00:90:0b:19:56:06 bc:ee:7b:dd:2e:5a 0806 60: arp reply \
192.168.34.1 is-at 00:90:0b:19:56:06
0000: bcee 7bdd 2e5a 0090 0b19 5606 0806 0001 ..{..Z....V.....
0010: 0800 0604 0002 0090 0b19 5606 c0a8 2201 ..........V...".
0020: bcee 7bdd 2e5a c0a8 2205 3200 0000 0000 ..{..Z..".2.....
0030: 0000 0000 0000 0000 0000 0000 ............
20:33:05.793774 00:90:0b:19:56:06 bc:ee:7b:dd:2e:5a 0806 60: arp reply \
192.168.34.1 is-at 00:90:0b:19:56:06
0000: bcee 7bdd 2e5a 0090 0b19 5606 0806 0001 ..{..Z....V.....
0010: 0800 0604 0002 0090 0b19 5606 c0a8 2201 ..........V...".
0020: bcee 7bdd 2e5a c0a8 2205 3100 0000 0000 ..{..Z..".1.....
0030: 0000 0000 0000 0000 0000 0000 ............
Here you see the return frames. The reverse (indicated by the number 2 in
offset 0x2A) beat the forward reverse (indicated by number 1) by 0.000001
seconds, it even made up time in the TCP IP stack on the remote OpenBSD
router. The reason this is, is that the reversearp does not get scheduled
inside the NETISR and thus is a lot faster, it pre-empts the packet that went
in before it.
These are net-games but this can be used to test the network stack load on an
OpenBSD host/router to look for how much usage it gets. That in itself isn't
an exploitation though.
0 comments
Next Page
|
Search
RSS Feed
Click here for RSS
On this day in
Other links
Have feedback?
By clicking on the header of an article you will be
served a cookie. If you do not agree to this do not
click on the header. Thanks!
Using a text-based webbrowser?
... such as lynx? Welcome back it's working again for the time being.
Older Blog Entries
March, 2023
February, 2023
January, 2023
December, 2022
November, 2022
October, 2022
September, 2022
August, 2022
July, 2022
June, 2022
May, 2022
April, 2022
March, 2022
February, 2022
January, 2022
December, 2021
November, 2021
October, 2021
September, 2021
March, 2021
February, 2021
January, 2021
December, 2020
November, 2020
October, 2020
September, 2020
August, 2020
July, 2020
June, 2020
May, 2020
April, 2020
March, 2020
February, 2020
January, 2020
December, 2019
November, 2019
October, 2019
September, 2019
August, 2019
July, 2019
June, 2019
May, 2019
April, 2019
March, 2019
February, 2019
January, 2019
December, 2018
November, 2018
October, 2018
September, 2018
August, 2018
July, 2018
June, 2018
May, 2018
April, 2018
March, 2018
February, 2018
January, 2018
December, 2017
November, 2017
October, 2017
September, 2017
August, 2017
July, 2017
June, 2017
May, 2017
April, 2017
March, 2017
February, 2017
January, 2017
December, 2016
November, 2016
October, 2016
September, 2016
August, 2016
July, 2016
June, 2016
May, 2016
April, 2016
March, 2016
February, 2016
January, 2016
December, 2015
November, 2015
October, 2015
September, 2015
August, 2015
July, 2015
June, 2015
May, 2015
April, 2015
March, 2015
February, 2015
January, 2015
December, 2014
November, 2014
October, 2014
September, 2014
August, 2014
July, 2014
June, 2014
May, 2014
April, 2014
March, 2014
February, 2014
January, 2014
December, 2013
November, 2013
October, 2013
September, 2013
August, 2013
July, 2013
June, 2013
May, 2013
April, 2013
March, 2013
February, 2013
January, 2013
December, 2012
November, 2012
October, 2012
September, 2012
August, 2012
July, 2012
June, 2012
May, 2012
April, 2012
March, 2012
February, 2012
January, 2012
December, 2011
November, 2011
October, 2011
September, 2011
August, 2011
July, 2011
June, 2011
May, 2011
April, 2011
March, 2011
February, 2011
January, 2011
December, 2010
November, 2010
October, 2010
September, 2010
August, 2010
July, 2010
June, 2010
May, 2010
April, 2010
March, 2010
February, 2010
January, 2010
December, 2009
November, 2009
October, 2009
September, 2009
August, 2009
July, 2009
June, 2009
May, 2009
Powered by BCHS
|