From owner-freebsd-pf@FreeBSD.ORG Sun Oct 27 15:33:24 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CC4694B for ; Sun, 27 Oct 2013 15:33:24 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EAA52CF9 for ; Sun, 27 Oct 2013 15:33:24 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id x13so9515229ief.23 for ; Sun, 27 Oct 2013 08:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nG+MRojwK4KwNHqrLEE0OabKQpHPT6RxF1OwNOTRudc=; b=GwlrpTq+o5JkGDoLsXKge0Q00vGjqUKlRxG+knUCjaBydltXmm4vuiozMBBQIGlryX aBskEAEWmwiRVmOYVLVnogw86XQXyPgBL8uRanA1UlZyHHqV+jAuViTgKJryaA9I1pw9 hd5i36paYtd3lUcgEeInB6ZUWm0IHvtdsQxOzNP3FrZJmwK5HBPLChDlwlZabWhc/ydh WbQaPGpySV3OG0Ujd9deOWrpmFIf09QIXr/xtAYNI3NdSSoTIjf1CHLEdBRFRSIdyfkh EYsfRp6KRtP2hthTT5zm+YWuLHez/VZikBwPfgSxAZbW+JSOgO7p8ZGLagyx1ee/mWpu tP8Q== MIME-Version: 1.0 X-Received: by 10.43.129.197 with SMTP id hj5mr44405icc.84.1382888003268; Sun, 27 Oct 2013 08:33:23 -0700 (PDT) Received: by 10.50.2.101 with HTTP; Sun, 27 Oct 2013 08:33:23 -0700 (PDT) In-Reply-To: <201310270128.47766.vegeta@tuxpowered.net> References: <201310270128.47766.vegeta@tuxpowered.net> Date: Sun, 27 Oct 2013 08:33:23 -0700 Message-ID: Subject: Re: PF sanity check From: Rumen Telbizov To: Kajetan Staszkiewicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 15:33:24 -0000 Thanks for your answer and comments Kajetan. See my comments below. > The question is: Is keeping two states for one connection a bad thing or > is > > it an acceptable practice ? > > It's rather a requirement. A packet incoming on one interface creates a > different state than the same packet outgoing on other interface (even > without > if-bound state policy). And you want further, reverse direction packets in > connections to be matched to existing states and passed instead of > traversing > rule list or hitting the block rule. Cool. I know the states are different (due to direction differences) but I was wondering if there was a way around that to save on the number of states and somehow get away with only 1 state. So now I understand having two states per connection is fine. > If you want to fully ignore the interface, you can use "set skip" for that > purpose. Although I'm not sure if NAT will work in such case, should you > need > it. It also would be nice to set skip on the loopback interface. > > > pass quick on $ext_if no state > > This rule passes the traffic both directions, so it's probably fine. > Although > using stateful inspection would increase security a bit. The reason I didn't go on a complete skip on $ext_if is that I actually do have a handful of rules on the external interface just before that one. Things like blocking from bad hosts, etc. Very few though. I do skip on loopback. I went with the 'no state' since this was my 'hack' to reduce the number of states to only 1 on connections traversing the external interface. In fact this is partially what provoked my question on saving on the number of states between vlans. But I simply cannot figure out a way. I was more curious to know what you and other folks think regarding my first question: *Is there any security risk in me allowing the traffic pass the external interface and then dropping it on the internal interface?* Thank you very much, -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-pf@FreeBSD.ORG Sun Oct 27 22:03:33 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1A05F23 for ; Sun, 27 Oct 2013 22:03:32 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87CD92053 for ; Sun, 27 Oct 2013 22:03:32 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id na10so1531969bkb.28 for ; Sun, 27 Oct 2013 15:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=eymSIWDDMJs0lYybQzkZLyVgLbNV4rG9OWlcQBB9biw=; b=Uv84EybrsVXtAEmRUzcgaiCcgQH39G+6yTVyZtZ+Y8QrH22Vl9hZJM6XIDkbStuM27 tH0nngyAqa2fZuMO4s4jDmO1ujIl7egmI/fUGzhqUIQh/HU17o+914JQGDlcrDh8nPM8 RsWeNbHVG5CwrsttriYY1n8ThHWDdURqoWmBZv2tm2c4yI0PxbZS97O1QHXGxwYHMFqh zQodp2048LQArTBSMLWWDCNpPRmmNetFRF0vqVKdaLbkUn8U6EZvjp3XPHy5dfJwgmeC vW6SsakuwesS33cgQVqa4wGAVgbTZw+cUGOTh1QzdOvczMWuIMogvLiuG79FDY6rNzSz LmkQ== X-Gm-Message-State: ALoCoQklZpX5Porxq7V3AEjGT4D4amctaYbt6E6bzEzJIAzahGNX+hsCwQxiZIND9/wiNeiliyhm X-Received: by 10.204.123.199 with SMTP id q7mr8280078bkr.10.1382911405287; Sun, 27 Oct 2013 15:03:25 -0700 (PDT) Received: from zvezda.localnet ([2a02:8108:1440:e1:2677:3ff:fe7b:7648]) by mx.google.com with ESMTPSA id b6sm10224649bko.16.2013.10.27.15.03.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2013 15:03:24 -0700 (PDT) From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Subject: Re: PF sanity check Date: Sun, 27 Oct 2013 23:03:24 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201310270128.47766.vegeta@tuxpowered.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201310272303.24096.vegeta@tuxpowered.net> X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 22:03:33 -0000 Dnia niedziela, 27 pa=C5=BAdziernika 2013 o 16:33:23 Rumen Telbizov napisa= =C5=82(a): > > The question is: Is keeping two states for one connection a bad thing or > > is > >=20 > > > it an acceptable practice ? > >=20 > > It's rather a requirement. A packet incoming on one interface creates a > > different state than the same packet outgoing on other interface (even > > without > > if-bound state policy). And you want further, reverse direction packets > > in connections to be matched to existing states and passed instead of > > traversing > > rule list or hitting the block rule. >=20 > Cool. I know the states are different (due to direction differences) but I > was wondering if > there was a way around that to save on the number of states and somehow g= et > away with > only 1 state. So now I understand having two states per connection is fin= e. Why shouldn't it be? Searching through states is quite fast. Even with hund= reds=20 of thousands of states much faster than going through a few hundreds of rul= es,=20 from my experience. > I was more curious to know what you and other folks think regarding my > first question: >=20 > *Is there any security risk in me allowing the traffic pass the external > interface and then dropping it on the internal interface?* That depends if the traffic from the Internet can hit the router's IP stack= =20 directly. For example if you assign public IPs of servers in VLANs to the=20 router's $ext_if and use nat or route-to to forward traffic to VLANs. Whate= ver=20 does not hit those rules but is passed on $ext_if, will hit the router itse= lf=20 in such case. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Mon Oct 28 01:01:50 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 37C70735 for ; Mon, 28 Oct 2013 01:01:50 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0819D27D4 for ; Mon, 28 Oct 2013 01:01:49 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id aq17so10412713iec.34 for ; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J5eTplOWYYKyBTTOANBEXblG9XKABXjnJFMrR25SEpY=; b=abg7nnIukuNKsA5LIV1O/IQBGu4DbLMuvtPG2qIWe1UtSHW9CIXXMrwyb1ykjpiD0Q ArblwfSR98DQgj3DqaMHg3FE1LIYXkAXumySnuwNf3IC4d4+nI+9CWwUeedERqdKkT5M MJslAreoMm3DGLVKMG76ytKkuEgzllR8SF1kAk8fTL9AnMSKLRBy/PR+GDUE8nnJrHFA fBRYe4986d292gA6IqHmGDMPe7ep9mXvCs+p8zY6aFWGKRf0szmtU1pXm/qrHJ1YwCK1 oFv4F8ok9Zb4AQhpl9UdQ5D5+5QPGe6sI+TL5MJroXThEW+p7L6kqG8geRcXJQSrgYz2 XOjg== MIME-Version: 1.0 X-Received: by 10.50.61.205 with SMTP id s13mr6678027igr.29.1382922109201; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) Received: by 10.50.2.101 with HTTP; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) In-Reply-To: <201310272303.24096.vegeta@tuxpowered.net> References: <201310270128.47766.vegeta@tuxpowered.net> <201310272303.24096.vegeta@tuxpowered.net> Date: Sun, 27 Oct 2013 18:01:49 -0700 Message-ID: Subject: Re: PF sanity check From: Rumen Telbizov To: Kajetan Staszkiewicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:01:50 -0000 Thanks again for coming back with more comments Kajetan. > Cool. I know the states are different (due to direction differences) but I > > was wondering if > > there was a way around that to save on the number of states and somehow > get > > away with > > only 1 state. So now I understand having two states per connection is > fine. > > Why shouldn't it be? Searching through states is quite fast. Even with > hundreds > of thousands of states much faster than going through a few hundreds of > rules, > from my experience. Yeah, only the number of states was my concern. On a related note what is the maximum number of states that you have been able to sustain and in what amount of memory? I know it's pretty low memory overhead but still. In other words how much memory per state is being consumed by PF? Currently I am prepared to start with 200K states and the router has 24GB or RAM. What is a reasonable maximum that I can expect to be able to handle? I am monitoring closely (nagios + graphite) those states as well btw. > > *Is there any security risk in me allowing the traffic pass the external > > interface and then dropping it on the internal interface?* > > That depends if the traffic from the Internet can hit the router's IP stack > directly. For example if you assign public IPs of servers in VLANs to the > router's $ext_if and use nat or route-to to forward traffic to VLANs. > Whatever > does not hit those rules but is passed on $ext_if, will hit the router > itself > in such case. Yes, that's a good point! I should have mentioned that the first few rules take care of traffic going to the router itself and end with block quick from any to where is a constant table of {self}. No NAT. So I guess it was just an irrational fear that I wanted to make sure it's only me that having let the packet "half-way in" through the external interface is OK as long as I filter it on the internal/vlan interface. No further implications aside from traffic destined to the firewall itself. Correct ? Thanks for all your comments, -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-pf@FreeBSD.ORG Mon Oct 28 11:06:53 2013 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3F42AFC for ; Mon, 28 Oct 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BE812477 for ; Mon, 28 Oct 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9SB6rIR055185 for ; Mon, 28 Oct 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9SB6rmj055183 for freebsd-pf@FreeBSD.org; Mon, 28 Oct 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Oct 2013 11:06:53 GMT Message-Id: <201310281106.r9SB6rmj055183@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182401 pf [pf] pf state for some IPs reaches 4294967295 suspicou o kern/182350 pf [pf] core dump with packet filter -- pf_overlad_task o kern/179392 pf [pf] [ip6] Incorrect TCP checksums in rdr return packe o kern/177810 pf [pf] traffic dropped by accepting rules is not counted o kern/177808 pf [pf] [patch] route-to rule forwarding traffic inspite o kern/176763 pf [pf] [patch] Removing pf Source entries locks kernel. o kern/176268 pf [pf] [patch] synproxy not working with route-to o kern/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/87074 pf [pf] pf does not log dropped packets when max-* statef a kern/86752 pf [pf] pf does not use default timeouts when reloading c o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 57 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Oct 30 01:23:21 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AED12B34 for ; Wed, 30 Oct 2013 01:23:21 +0000 (UTC) (envelope-from www-data@modersmal.skolverket.se) Received: from modersmal.skolverket.se (dns.skolverket.se [62.13.78.2]) by mx1.freebsd.org (Postfix) with ESMTP id 771AA2646 for ; Wed, 30 Oct 2013 01:23:21 +0000 (UTC) Received: by modersmal.skolverket.se (Postfix, from userid 33) id 54382BF9F9; Wed, 30 Oct 2013 02:10:22 +0100 (CET) To: freebsd-pf@freebsd.org Subject: Re: Assalam X-PHP-Originating-Script: 33:247@abu.php From: Mohamad Hassan MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20131030011353.54382BF9F9@modersmal.skolverket.se> Date: Wed, 30 Oct 2013 02:10:22 +0100 (CET) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mohamad_hassan@rediffmail.com List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 01:23:21 -0000 Assalamalaikum Wr Wb I hope in the name of ALLAH that I have the right person who will assist me. I got your contact through a web directory. I want to transfer my family's money into your country/ business for investment purposes and to secure the future of my 3 children because we are uncertain of the future of this country; as such I would like to make contact with you residing in that country for assistance. Note these funds are already in a security company which has branches around the world for safe keeping. I would have done this myself but my present health condition will not warrant me to do so. Kindly help with this because I cannot travel out of libya at the moment due to some certain conditions and great difficulties added to the fact that am disabled on a wheel chair due to a bombing that occurred in Benghazi I will explain more to you when I am certain that I can trust you. The fall of Muammar Gaddafi came with a lot of destruction / Hell to our great country Libya and everything is practically difficult now and opportunities are closing up, the new government is trying to frustrate our life. Please if you accept this offer of assistance you are required to give me your Name, age, occupation, address also enclosing your telephone fax numbers. What I now need from you are as follows: 1. You will help me receive and secure the funds from the security company on my family's behalf and open a Bank account for my children in your country with the credentials i will give you. 2. You will be entitled to 30% of the total sum involved for your assistance. 3. As soon as you confirm to me by e-mail your readiness to assist with this, I will give you more details as regards claiming the funds from the security company. 4. Please note that this project is 100% risk free but you must keep it very secret and confidential with strong assurance that you will not let me down at all. Regards, Mohamad Hassan al-Rida