Tracking stealth portscan/pepsi attacks
Dear colleagues, there seems to have been quite a wash of stealth portscans and/or pepsi attacks lately (stealth portscan: you portscan with 99% of the sender addresses faked, but your own are among them; pepsi: "only" a DoS attack, you don't bother hiding your own address in the random sender flood, both of course UDP). cybercity.dk must have been seeing some of these attacks pass, first glance judging from http://stat.cybercity.dk/ripe/ and the fallout in de.xlink (where I positively know the addresses not to be routed) and de.zz (where most of the address space is handled by RIPE nowadays). Also my private machine at home has been attacked over several days, much good it did them, but that makes it a personal axe to grind :-> Besides, lots of people who admin firewalls don't necessarily expect such stealth attacks to happen and complain to all the owners of the faked addresses about the port scans, thus generation additional workload on the abuse people. I'd like to have a chance to catch the perpetrators. This would need to be a multi-provider cooperation in the majority of cases. Do we have an appropriate forum to discuss this at the next RIPE meeting? kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler@xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.
[ Quoting Petra Zeidler <zeidler@xlink.net> ]:
there seems to have been quite a wash of stealth portscans and/or pepsi attacks lately (stealth portscan: you portscan with 99% of the sender
Even worse (at least here): There's a modified Version of Pepsi5 around letting the attacker control his bot via ICMP which allow control even when the net is nearly down due to the UDP attacks.
cybercity.dk must have been seeing some of these attacks pass, first glance judging from http://stat.cybercity.dk/ripe/ and the fallout in de.xlink (where I positively know the addresses not to be routed) and de.zz (where most of the address space is handled by RIPE nowadays).
Same goes for de.IPF where these type of attacks caused quite a bit work and manpower to be wasted. The last few weeks I've been working fulltime just on these problems.
I'd like to have a chance to catch the perpetrators. This would need to be a multi-provider cooperation in the majority of cases. Do we have an appropriate forum to discuss this at the next RIPE meeting?
I'd vote for a WG focussing on these things. IIRC there have been plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger interest on this topics what about a Security-BOF next RIPE? In general, net-abuse has become one of the major problems these days, included but not limited to attacks, scans, mailbombs, a.s.o. regards, Jonas Luster -- Gigabell AG / Frankfurt Signed / encrypted maol welcome Chief Security Engineer Key to be found on the known places j.luster@cert.gigabell.net Securing the net of the future
Jonas Luster wrote:
I'd vote for a WG focussing on these things. IIRC there have been plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger interest on this topics what about a Security-BOF next RIPE? In general, net-abuse has become one of the major problems these days, included but not limited to attacks, scans, mailbombs, a.s.o.
Ahh now if we called it a RIPE-Security WG then that could encompass the whole lot and would IMO be a fine idea. As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier. -- Leigh
On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
Jonas Luster wrote:
I'd vote for a WG focussing on these things. IIRC there have been plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger interest on this topics what about a Security-BOF next RIPE? In general, net-abuse has become one of the major problems these days, included but not limited to attacks, scans, mailbombs, a.s.o.
Ahh now if we called it a RIPE-Security WG then that could encompass the whole lot and would IMO be a fine idea.
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Packet filters at all boundaries :) Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk]
[ Quoting Leigh Porter <leigh@insnet.net> ]:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
We're in a switched network so Spoofing is only possible by ARP-Hijackiking. To prevent such attacks I've coupled Arpwatch, Hunt and some selfmade tools to inject NULL-Routes against any source of more than 30 Flip-Flops in a given time. Until now I only had one false positive and three false negatives. jonas
Hi, On Thu, Sep 02, 1999 at 11:28:55AM +0200, Jonas Luster wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
We're in a switched network so Spoofing is only possible by ARP-Hijackiking.
Oh? That's not how I understand the benefits of switching... How do you prevent somone from injecting packets with spoofed source address at your boundary routers? Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do. On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log"). On our external interfaces from our upstreams we deny packets with a source address coming from one our network blocks. Interesting enough, we don't observe many attacks - what we do see is LOTS of broken end user configurations (leaking RFC 1918 networks, customers leaking IP addresses from other ISPs, ...). Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
"Gert Doering, Netmaster" wrote:
Hi,
On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do.
On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log").
How do you manage large BGP customers with lots of networks? I would also be interested to know performance hits on the routers for this. I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it? -- Leigh
Hi, On Thu, Sep 02, 1999 at 11:46:02AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do.
On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log").
How do you manage large BGP customers with lots of networks?
Hmmm, I have to admit that I don't - we're not THAT large yet, so our BGP customers are usually pretty small and only have two or three network blocks, so filtering is feasible. (As I filter their BGP announcements anyway, adding the networks to the incress access-list isn't much more effort).
I would also be interested to know performance hits on the routers for this.
The access lists per interface are usually no longer than up to 10 lines, and the routers seem to manage fine.
I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it?
This is in IOS 12.0, and you need to have CEF enabled to use it. As our production routers don't use IOS 12 yet, I haven't tried it. It would certainly be very nice. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Leigh Porter writes:
On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do.
Same here. Both dialup and leased line customer source addresses are strictly verified.
How do you manage large BGP customers with lots of networks?
The access lists are generated from combined sources, amoung them our internal database and the information from RIPE. For an update, the access lists are regenerated and the output is a diff in Cisco format for the bits that changed so that it can be directly copied onto the routers.
I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it?
No, but anyway this fails in more complex scenarios where symmetric routing cannot be guaranteed. Robert
Robert Kiessling wrote:
How do you manage large BGP customers with lots of networks?
The access lists are generated from combined sources, amoung them our internal database and the information from RIPE. For an update, the access lists are regenerated and the output is a diff in Cisco format for the bits that changed so that it can be directly copied onto the routers.
Does that scale to say a network with 100 prefixes that takes say 100Mb? -- Leigh
On Fri, 03 Sep 1999 15:11:43 +0100 Leigh Porter <leigh@insnet.net> wrote:
Does that scale to say a network with 100 prefixes that takes say 100Mb?
We insist upon it. -- Neil J. McRae C O L T I N T E R N E T neil@COLT.NET
In message <37CE556A.3B97A29E@insnet.net>, Leigh Porter writes:
"Gert Doering, Netmaster" wrote:
Hi,
On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do.
On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log").
How do you manage large BGP customers with lots of networks? I would also be interested to know performance hits on the routers for this.
You filter at your ingress points. If you have a leased-line customer you make sure they can't send from anything but the addresses they have from ripe. Dial up likewise.
I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it?
Hey, that sounds neat, more info ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it?
Hey, that sounds neat, more info?
It is an IOS 12.0 feature. It requires that you run CEF (most if not all platforms can do that in 12.0). The interface command is ip verify unicast reverse-path For each packet it checks that it has a route back to the source IP address pointing out the interface where the packet entered, and drops the packet if it doesn't. For rather obvious reasons this feature cannot be used where you have asymmetric traffic patterns. This commonly occurs in backbone networks with "hot-potato" routing between providers which peer in multiple places. But then again, this checking should be done on the edges of the network, where asymmetry should be much less of a problem. With early revisions of 12.0 there were issues with helper-address handling -- bootp requests from 0.0.0.0 would be dropped on the floor instead of being forwarded (ugh!). I think that is now fixed, though. And, yes, we are using the feature. - Håvard
On Sat, 04 Sep 1999 21:32:50 +0200 Havard.Eidnes@runit.sintef.no wrote: 11.1CC28 has new bug-fix [*] for dropping bad packet fragments also. We haven't tested it but it could be useful for some attacks we've seen in the past. * Some may call this a feature- but its definetly a bug fix. Regards, Neil.
I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it?
Hey, that sounds neat, more info?
It is an IOS 12.0 feature. It requires that you run CEF (most if not all platforms can do that in 12.0). The interface command is
ip verify unicast reverse-path
For each packet it checks that it has a route back to the source IP address pointing out the interface where the packet entered, and drops the packet if it doesn't.
For rather obvious reasons this feature cannot be used where you have asymmetric traffic patterns. This commonly occurs in backbone networks with "hot-potato" routing between providers which peer in multiple places. But then again, this checking should be done on the edges of the network, where asymmetry should be much less of a problem.
With early revisions of 12.0 there were issues with helper-address handling -- bootp requests from 0.0.0.0 would be dropped on the floor instead of being forwarded (ugh!). I think that is now fixed, though.
And, yes, we are using the feature.
- Hevard
-- Neil J. McRae C O L T I N T E R N E T neil@COLT.NET
Leigh Porter wrote:
"Gert Doering, Netmaster" wrote:
Hi,
On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
Sure we do.
On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log").
How do you manage large BGP customers with lots of networks? I would also be interested to know performance hits on the routers for this.
Last month I described the idea of an special prefix access list on de.comm.internet.routing that basically solves that problem. The syntax would look something like this: 'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks' It simply conscructs an automatic ip prefix access-list based on the prefixes received/announced to/from the BGP peer. This has the cute side effect that all ip filters can be done in one place; the bgp configuration. The 'permit received-networks' part looks pretty promising for an easy implementation because the router has to perform an bgp table lookup anyway for each incoming ip packet. It simply adds a compare to find the neighbor. The filtering on announced networks looks much more problematic to implement but it's not that important. Sure, this will eat some CPU but IMO not more than 10%. I've suggested this feature to cisco and they promised that they'll contact me tomorrow to discuss this further. As soon as I get cisco to think deeper about this I'll post here again with contacts so that you can voice your support too for this feature. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch
Last month I described the idea of an special prefix access list on de.comm.internet.routing that basically solves that problem.
The syntax would look something like this:
'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks'
It simply conscructs an automatic ip prefix access-list based on the prefixes received/announced to/from the BGP peer. This has the cute side effect that all ip filters can be done in one place; the bgp configuration.
Umm, how is this significantly different from doing RPF (Reverse Path Forwarding) checks for unicast packets, as I described earlier, and as already implemented by Cisco? If I understand what you're trying to do correctly, doing the "received-networks" would be to just turn on RPF checking on the incoming interface from the neighbor, while doing "announced- networks" will mean that you either have to make sure you have RPF checking on all your edges or that all interfaces on this particular customer access router has RPF checking turned on.
The 'permit received-networks' part looks pretty promising for an easy implementation because the router has to perform an bgp table lookup anyway for each incoming ip packet.
Um, that's not quite correct. The router does a forwarding table lookup for the destination address in each packet when doing packet forwarding; the forwarding table is being built from (among other sources) the BGP routing database. Doing the RPF check for unicast packets adds a second forwarding table lookup for each packet (look up the source and see if the packet entered on an interface where we have a route pointing back out), so it does have a cost, but demanding CEF (as Cisco does) reduces that cost over the other potential alternatives. Regards, - Håvard
Havard.Eidnes@runit.sintef.no wrote:
Last month I described the idea of an special prefix access list on de.comm.internet.routing that basically solves that problem.
The syntax would look something like this:
'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks'
It simply conscructs an automatic ip prefix access-list based on the prefixes received/announced to/from the BGP peer. This has the cute side effect that all ip filters can be done in one place; the bgp configuration.
Umm, how is this significantly different from doing RPF (Reverse Path Forwarding) checks for unicast packets, as I described earlier, and as already implemented by Cisco?
It allows asymetric routing.
If I understand what you're trying to do correctly, doing the "received-networks" would be to just turn on RPF checking on the incoming interface from the neighbor, while doing "announced- networks" will mean that you either have to make sure you have RPF checking on all your edges or that all interfaces on this particular customer access router has RPF checking turned on.
Well... What I imagine is an prefix based packet filter (no rule list). This would be as fast as the routing table lookup. Lets have a look what the router does with that feature: 1. ip packet comes enters through interface s0/0 2. ip packet source address gets checked against prefix filter. The prefix filter contains and allows only prefixes received from bgp neighbor 1.2.3.4 3. process the packet as usual
The 'permit received-networks' part looks pretty promising for an easy implementation because the router has to perform an bgp table lookup anyway for each incoming ip packet.
Um, that's not quite correct. The router does a forwarding table lookup for the destination address in each packet when doing packet forwarding; the forwarding table is being built from (among other sources) the BGP routing database.
Yes.
Doing the RPF check for unicast packets adds a second forwarding table lookup for each packet (look up the source and see if the packet entered on an interface where we have a route pointing back out), so it does have a cost, but demanding CEF (as Cisco does) reduces that cost over the other potential alternatives.
The problem with RPF is that as doesn't work in environments with asymetric routing. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch
On 1999-09-02T11:44:12, "Gert Doering, Netmaster" <netmaster@space.net> said:
On our ingress interfaces to our customers, we have very strict access lists ("permit ip <customer net> any / deny ip any any log").
Same here. A very good idea anyway, not just because of security, but because of customers who think "lets just continue increasing the last digit!". And I wish I had more time to work on the security issues. Fascinating topic. But there are so many fascinating topics and only 24hours plus the night per day...
On our external interfaces from our upstreams we deny packets with a source address coming from one our network blocks.
We also filter private addresses & martians. Sometimes a few of those come through. And on the outgoing interfaces we filter packets going to our own netblocks, so that we don't accidentially leak because of fucked up routing. And then there are the filters on the BGP4 sessions to prevent someone from injecting bogus routes into our AS (remember that EBGP learned routes take precedence over IGP, and more specific routes always take precendence, so if you don't filter correctly, someone might hijack one IP from your network).
Interesting enough, we don't observe many attacks - what we do see is LOTS of broken end user configurations (leaking RFC 1918 networks, customers leaking IP addresses from other ISPs, ...).
Yeah. But it also helps to prevent smurf attacks etc. I do see a need for a RIPE Security WG to point these issues out to all ISPs/LIRs so at least those easy measures get taken. According to the annual report from last year, funding shouldn't be that much of a problem ;-) Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH
Hi, On Fri, Sep 03, 1999 at 02:18:58PM +0200, Lars Marowsky-Bree wrote:
On our external interfaces from our upstreams we deny packets with a source address coming from one our network blocks.
We also filter private addresses & martians. Sometimes a few of those come through.
While I'd like to do that, I'm still not sure what's worse - seeing 192.168.x.y addresses in an outgoing traceroute, or listening to customer complaints about "why is there a line ' * * * ' in my traceroute output? something must be wrong!" when filtering those. So right now, I let packets with RFC addresses pass (from upstream, not from our customers). But I still hope that people will stop using them for transit networks.
And on the outgoing interfaces we filter packets going to our own netblocks, so that we don't accidentially leak because of fucked up routing.
Interesting idea. I'm not sure how that problem could happen, but maybe our network's topology is too simple :-)
And then there are the filters on the BGP4 sessions to prevent someone from injecting bogus routes into our AS (remember that EBGP learned routes take precedence over IGP, and more specific routes always take precendence, so if you don't filter correctly, someone might hijack one IP from your network).
Plus filters for the transit networks on the usual exchange points (DE-CIX, MAE-Frankfurt, etc.) - because that could hose up routing massively if one of those networks appears in your iBGP... Thanks for the tip with "filter bogus routes from our own network blocks", I didn't yet think of that problem, but it's certainly worth considering.
Interesting enough, we don't observe many attacks - what we do see is LOTS of broken end user configurations (leaking RFC 1918 networks, customers leaking IP addresses from other ISPs, ...).
Yeah. But it also helps to prevent smurf attacks etc.
Definitely - that's why I did it, but I just wanted to note that there are (well, "we observe") much more misconfiguration problems than active attacks. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <19990902114412.S13951@Space.Net>, "Gert Doering, Netmaster" writes:
Interesting enough, we don't observe many attacks - what we do see is LOTS of broken end user configurations (leaking RFC 1918 networks, customers leaking IP addresses from other ISPs, ...).
Talk about it. I don't log RFC1918 addresses anymore I just drop them. Some cheap NAT routers don't NAT UDP just pass it through. Most spoofed src attacks I've heard about happen from hi-jacked servers, so remember filters on your server parks too, in particular for co-hosted servers. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
-- Leigh
I think that a serious provider *should* prevent address spoofing. This is a simple filter in the access router. If this is not done, how can an ISP prove that a customer has done something wrong. I think this for protection of the ISP as well as other customers. Fredrik Johansson
As a side note, does anybody use anything to prevent address spoofing in
network? That would at prevent a lot of attacks completly and make
their tracing the
rest much easier.
-- Leigh
I think that a serious provider *should* prevent address spoofing. This is a simple filter in the access router.
If this is not done, how can an ISP prove that a customer has done something wrong. I think this for protection of the ISP as well as other customers.
I agree. A serious provider should also consider protecting itself from its customers. Michael
Fredrik Johansson
-- Michael Hallgren IT Consultant, Infrastructure FI System, Web Agency http://www.fisystem.fr michael.hallgren@fisystem.fr, Phone : +33 1 55 04 03 03 Always make mistakes. - E Dyson
In message <37CE4706.3B3D44D8@insnet.net>, Leigh Porter writes:
As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier.
We have egress filters, allowing only our "own" IP numbers in the source fields. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Petra Zeidler wrote: Hiya, INS try to be very co-operative in tracking down the source of any such attacks and in the past I have had nothing but complete co-operation and help from our peers in tracking the source of attacks. It would be interesting though to have a forum in which to dicsuss inter-providor co-operation though with the RIPE database it is usually just a case of calling the NOC of network at the ingress point to your network who would then trace the source to the ingress point of their network and so on. Since these DoS attacks usually last for quite some time this is pretty easy however tracing stealth portscans that could potentially last for a few days could be more interesting. -- Leigh Porter
I'd like to have a chance to catch the perpetrators. This would need to be a multi-provider cooperation in the majority of cases. Do we have an appropriate forum to discuss this at the next RIPE meeting?
participants (14)
-
Andre Oppermann -
Fredrik Johansson -
Gert Doering, Netmaster -
Havard.Eidnes＠runit.sintef.no -
Jonas Luster -
Jonas Luster -
Josef Karthauser -
Lars Marowsky-Bree -
Leigh Porter -
Michael Hallgren -
Neil J. McRae -
Petra Zeidler -
Poul-Henning Kamp -
Robert Kiessling