Prevent circumventing dansguardian with pf
Greetings! Included below is my pf.conf set up to use
dansguardian (proxyport 3128, filterport 8080)
and tinyproxy (listen port 3128) as a transparent
proxy.
What changes do I need to make to keep someone on
int_if/int_net from circumventing dansguardian
by changing their browser to point to 3128?
Thanks and take care,
Allen
--8<--cut here--8<--
ext_if="rl0"
int_if="xl0"
int_net="192.168.0.0/24"
proxy_server = "127.0.0.1"
tcp_services="{ 113 }"
icmp_types="echoreq"
set block-policy return
set skip on lo
scrub in
nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr on $int_if inet proto tcp
from $int_net
to any port www -> $proxy_server port 8080
block in
antispoof quick for { lo $int_if }
pass in inet proto icmp all icmp-type $icmp_types keep state
pass in on $ext_if inet proto tcp
from any
to ($ext_if) port $tcp_services flags S/SA keep state
pass on $int_if
pass out keep state
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Prevent circumventing dansguardian with pf
On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: pass in inet proto icmp all icmp-type $icmp_types keep state This can be used as a covert communication channel. Allowing internal IPs to send/receive ping is bad. As for your question, only allow internal devices to do what you want and deny the rest. rdr requests to external web servers on port 80 to your transparent/filtering proxy. -Chad
Re: Prevent circumventing dansguardian with pf
Chad M Stewart wrote: > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > > > > pass in inet proto icmp all icmp-type $icmp_types keep state > > This can be used as a covert communication channel. Allowing > internal IPs to send/receive ping is bad. Bull. Not allowing ICMP is just as bad. Worse actually, as you are violating RFCs. Quit spreading this FUD. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Re: Prevent circumventing dansguardian with pf
On Wed, 25 Apr 2007 20:19:42 + (UTC) Tobias Weingartner <[EMAIL PROTECTED]> wrote: > Chad M Stewart wrote: > > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > > > > > > pass in inet proto icmp all icmp-type $icmp_types keep state > > > > This can be used as a covert communication channel. Allowing > > internal IPs to send/receive ping is bad. > > Bull. Not allowing ICMP is just as bad. Worse actually, as you > are violating RFCs. Quit spreading this FUD. hi, actually, me thinks the same about allowing/denying ICMP as you, tobias. however, we recently had a CCIE/NSA certified blahblah guy in our company, tuning our, err, Cizcoooeee equipment. guess what he did -- he violated 'the RFCs'. unfortunately, i wasn't able to find them on the net. do you have them handy? i'm very curious about that :) tia, -- Timo Schoeler | http://riscworks.net/~tis | [EMAIL PROTECTED] RISCworks -- Perfection is a powerful message Ex-ISP | RISC afficinados | Networking, Security, BSD services GPG Key fingerprint = 76E0 BEAF 762A BD1B 383C F88C EBCF 6DDF D87F CDF0 You can fly away to the end of the world But where does it get you to? (Tennant/Lowe)
Re: Prevent circumventing dansguardian with pf
On Apr 25, 2007, at 4:19 PM, Tobias Weingartner wrote: Chad M Stewart wrote: On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: pass in inet proto icmp all icmp-type $icmp_types keep state This can be used as a covert communication channel. Allowing internal IPs to send/receive ping is bad. Bull. Not allowing ICMP is just as bad. Worse actually, as you are violating RFCs. Quit spreading this FUD. I did NOT suggest blocking ALL ICMP, just echo-request and echo- replies from internal hosts to untrusted IPs. Trojans have used echo-request and echo-reply as a method of covert communication. If you had read the original post you'd see that $icmp_types was defined to be echoreq. I don't this is FUD. -Chad
Re: Prevent circumventing dansguardian with pf
On Wed, Apr 25, 2007 at 10:40:45PM +0200, Timo Schoeler wrote: > On Wed, 25 Apr 2007 20:19:42 + (UTC) > Tobias Weingartner <[EMAIL PROTECTED]> wrote: > > > Chad M Stewart wrote: > > > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > > > > > > > > pass in inet proto icmp all icmp-type $icmp_types keep state > > > > > > This can be used as a covert communication channel. Allowing > > > internal IPs to send/receive ping is bad. > > > > Bull. Not allowing ICMP is just as bad. Worse actually, as you > > are violating RFCs. Quit spreading this FUD. > > hi, > > actually, me thinks the same about allowing/denying ICMP as you, > tobias. however, we recently had a CCIE/NSA certified blahblah guy in > our company, tuning our, err, Cizcoooeee equipment. > > guess what he did -- he violated 'the RFCs'. > > unfortunately, i wasn't able to find them on the net. do you have them > handy? i'm very curious about that :) In general, though, it will almost always be possible to get data in/out of the network. IP-over-DNS comes to mind. If this particular vector is used by a widely deployed worm, it might be worth it; but otherwise, just ignore it. Do you intend to ask where 'the RFCs' are? (If so, www.ietf.org is a good choice.) Or in what RFC this particular requirement is? (No real idea...) Joachim -- TFMotD: kadmin (8) - Kerberos administration utility
Re: Prevent circumventing dansguardian with pf
On Wed, 25 Apr 2007 23:56:50 +0200 Joachim Schipper <[EMAIL PROTECTED]> wrote: > On Wed, Apr 25, 2007 at 10:40:45PM +0200, Timo Schoeler wrote: > > On Wed, 25 Apr 2007 20:19:42 + (UTC) > > Tobias Weingartner <[EMAIL PROTECTED]> wrote: > > > > > Chad M Stewart wrote: > > > > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > > > > > > > > > > pass in inet proto icmp all icmp-type $icmp_types keep state > > > > > > > > This can be used as a covert communication channel. Allowing > > > > internal IPs to send/receive ping is bad. > > > > > > Bull. Not allowing ICMP is just as bad. Worse actually, as you > > > are violating RFCs. Quit spreading this FUD. > > > > hi, > > > > actually, me thinks the same about allowing/denying ICMP as you, > > tobias. however, we recently had a CCIE/NSA certified blahblah guy > > in our company, tuning our, err, Cizcoooeee equipment. > > > > guess what he did -- he violated 'the RFCs'. > > > > unfortunately, i wasn't able to find them on the net. do you have > > them handy? i'm very curious about that :) > > In general, though, it will almost always be possible to get data > in/out of the network. IP-over-DNS comes to mind. If this particular > vector is used by a widely deployed worm, it might be worth it; but > otherwise, just ignore it. yeah, i know -- that's why i watched him doing in my typical skeptical way... > Do you intend to ask where 'the RFCs' are? (If so, www.ietf.org is a > good choice.) Or in what RFC this particular requirement is? (No real > idea...) the latter one... > Joachim > > -- > TFMotD: kadmin (8) - Kerberos administration utility timo
Re: Prevent circumventing dansguardian with pf
On 25/04/07, Joachim Schipper <[EMAIL PROTECTED]> wrote: On Wed, Apr 25, 2007 at 10:40:45PM +0200, Timo Schoeler wrote: > On Wed, 25 Apr 2007 20:19:42 + (UTC) > Tobias Weingartner <[EMAIL PROTECTED]> wrote: > > > Chad M Stewart wrote: > > > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > > > > > > > > pass in inet proto icmp all icmp-type $icmp_types keep state > > > > > > This can be used as a covert communication channel. Allowing > > > internal IPs to send/receive ping is bad. > > > > Bull. Not allowing ICMP is just as bad. Worse actually, as you > > are violating RFCs. Quit spreading this FUD. > > hi, > > actually, me thinks the same about allowing/denying ICMP as you, > tobias. however, we recently had a CCIE/NSA certified blahblah guy in > our company, tuning our, err, Cizcoooeee equipment. > > guess what he did -- he violated 'the RFCs'. > > unfortunately, i wasn't able to find them on the net. do you have them > handy? i'm very curious about that :) In general, though, it will almost always be possible to get data in/out of the network. IP-over-DNS comes to mind. If this particular vector is used by a widely deployed worm, it might be worth it; but otherwise, just ignore it. Do you intend to ask where 'the RFCs' are? (If so, www.ietf.org is a good choice.) Or in what RFC this particular requirement is? (No real idea...) I didn't expect it to come that easily, but google was helpful here: RFC2979 has this: 3.1.1. Path MTU Discovery and ICMP ICMP messages are commonly blocked at firewalls because of a perception that they are a source of security vulnerabilities. This often creates "black holes" for Path MTU Discovery [3], causing legitimate application traffic to be delayed or completely blocked when talking to systems connected via links with small MTUs. By the transparency rule, a packet-filtering router acting as a firewall which permits outgoing IP packets with the Don't Fragment (DF) bit set MUST NOT block incoming ICMP Destination Unreachable / Fragmentation Needed errors sent in response to the outbound packets from reaching hosts inside the firewall, as this would break the standards-compliant usage of Path MTU discovery by hosts generating legitimate traffic. On the other hand, it's proper (albeit unfriendly) to block ICMP Echo and Echo Reply messages, since these form a different use of the network, or to block ICMP Redirect messages entirely, or to block ICMP DU/FN messages which were not sent in response to legitimate outbound traffic. [3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. Joachim -- TFMotD: kadmin (8) - Kerberos administration utility -- viq
Re: Prevent circumventing dansguardian with pf
On Wednesday, April 25, Timo Schoeler wrote: > > actually, me thinks the same about allowing/denying ICMP as you, > tobias. however, we recently had a CCIE/NSA certified blahblah guy in > our company, tuning our, err, Cizcoooeee equipment. > > guess what he did -- he violated 'the RFCs'. > > unfortunately, i wasn't able to find them on the net. do you have them > handy? i'm very curious about that :) The RFCs? Google will point you to them. Or go to the source at IETF http://ietf.org/rfc.html --Toby.
Re: Prevent circumventing dansguardian with pf
> I did NOT suggest blocking ALL ICMP, just echo-request and echo- > replies from internal hosts to untrusted IPs. Trojans have used > echo-request and echo-reply as a method of covert communication. If > you had read the original post you'd see that $icmp_types was defined > to be echoreq. > > I don't this is FUD. Don't forget to also configure your firewalls to block traffic with the evil bit set. :-) -- Mathieu Sauve-Frankel
Re: Prevent circumventing dansguardian with pf
On 2007/04/26 08:02, Mathieu Sauve-Frankel wrote: > > I did NOT suggest blocking ALL ICMP, just echo-request and echo- > > replies from internal hosts to untrusted IPs. Trojans have used > > echo-request and echo-reply as a method of covert communication. If > > you had read the original post you'd see that $icmp_types was defined > > to be echoreq. > > > > I don't this is FUD. > > Don't forget to also configure your firewalls to block traffic with the > evil bit set. :-) watch out, this causes problems for clients behind rfc3514-compliant NAT...
Re: Prevent circumventing dansguardian with pf
On Wednesday, April 25, Chad M Stewart wrote: > > I did NOT suggest blocking ALL ICMP, just echo-request and echo- > replies from internal hosts to untrusted IPs. And how is this not violating RFCs? > Trojans have used echo-request and echo-reply as a method of covert > communication. I've you've been compromised, it's already too late. > If you had read the original post you'd see that $icmp_types was > defined to be echoreq. Irrelevant. > I don't this is FUD. Telling people to worry about the door to the barn after the horse has left is not FUD? It's not misdirection? Tell them to solve the root of their problems instead. --Toby.
Re: Prevent circumventing dansguardian with pf
Tobias Weingartner wrote: Telling people to worry about the door to the barn after the horse has left is not FUD? It's not misdirection? Tell them to solve the root of their problems instead. Don't poo-poo his effort to mitigate information leaks. Did you realize that even LAMP can be used to transmit hidden messages? The Lightbulb Amplification and Modulation Protocol is often used to transmit sequences of boolean information using unfiltered windows and an untrusted light source. The only truly secure countermeasure is to unplug all potential sources of LAMP. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Prevent circumventing dansguardian with pf
On Wednesday 25 April 2007 17:48, Jason Dixon wrote: > Tobias Weingartner wrote: > > Telling people to worry about the door to the barn after the horse > > has left is not FUD? It's not misdirection? Tell them to solve > > the root of their problems instead. > > Don't poo-poo his effort to mitigate information leaks. > > Did you realize that even LAMP can be used to transmit hidden > messages? The Lightbulb Amplification and Modulation Protocol is > often used to transmit sequences of boolean information using > unfiltered windows and an untrusted light source. The only truly > secure countermeasure is to unplug all potential sources of LAMP. Yes, but all of us already know that windows are insecure. -jcr
Re: Prevent circumventing dansguardian with pf
Tobias Weingartner wrote: Chad M Stewart wrote: On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: pass in inet proto icmp all icmp-type $icmp_types keep state This can be used as a covert communication channel. Allowing internal IPs to send/receive ping is bad. Bull. Not allowing ICMP is just as bad. Worse actually, as you are violating RFCs. Quit spreading this FUD. As very often in this world, none of these points of view is absolutely perfect in all situations. Regarding violation of RFCs, I found RFC 1812, which states that routers have to implement echo replies, but one should be able to switch them off: RFC 1812 "Requirements for IP Version 4 Routers", page 57/58: 4.3.3.6 Echo Request/Reply A router MUST implement an ICMP Echo server function that receives Echo Requests sent to the router, and sends corresponding Echo Replies. A router MUST be prepared to receive, reassemble and echo an ICMP Echo Request datagram at least as the maximum of 576 and the MTUs of all the connected networks. The Echo server function MAY choose not to respond to ICMP echo requests addressed to IP broadcast or IP multicast addresses. A router SHOULD have a configuration option that, if enabled, causes the router to silently ignore all ICMP echo requests; if provided, this option MUST default to allowing responses. Andreas
Re: Prevent circumventing dansguardian with pf
On Wed, 25 Apr 2007 16:29:17 -0600 Tobias Weingartner <[EMAIL PROTECTED]> wrote: > On Wednesday, April 25, Timo Schoeler wrote: > > > > actually, me thinks the same about allowing/denying ICMP as you, > > tobias. however, we recently had a CCIE/NSA certified blahblah guy > > in our company, tuning our, err, Cizcoooeee equipment. > > > > guess what he did -- he violated 'the RFCs'. > > > > unfortunately, i wasn't able to find them on the net. do you have > > them handy? i'm very curious about that :) > > The RFCs? Google will point you to them. Or go to the source at IETF google is evil. :) > http://ietf.org/rfc.html actually, i know this source and i was looking for this: http://marc.info/?l=openbsd-misc&m=117754000230466&w=2 as we're talking about TCP/ICMP issues, and not RFCs in general. thanks, timo
Re: Prevent circumventing dansguardian with pf
* Chad M Stewart <[EMAIL PROTECTED]> [2007-04-25 19:31]: > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > >pass in inet proto icmp all icmp-type $icmp_types keep state > > This can be used as a covert communication channel. Allowing > internal IPs to send/receive ping is bad. that is the biggest bullshit i have read on this list in some time. if you deny icmp, you shall burn in hell -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Prevent circumventing dansguardian with pf
On 5/4/07, Henning Brauer <[EMAIL PROTECTED]> wrote: * Chad M Stewart <[EMAIL PROTECTED]> [2007-04-25 19:31]: > On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > >pass in inet proto icmp all icmp-type $icmp_types keep state > > This can be used as a covert communication channel. Allowing > internal IPs to send/receive ping is bad. that is the biggest bullshit i have read on this list in some time. if you deny icmp, you shall burn in hell You may burn in hell, but ICMP can be used to infiltrate and exfiltrate data: http://www.cs.uit.no/~daniels/PingTunnel/
Re: Prevent circumventing dansguardian with pf
* Open Phugu <[EMAIL PROTECTED]> [2007-05-04 15:36]: > On 5/4/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > >* Chad M Stewart <[EMAIL PROTECTED]> [2007-04-25 19:31]: > >> On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > >> >pass in inet proto icmp all icmp-type $icmp_types keep state > >> > >> This can be used as a covert communication channel. Allowing > >> internal IPs to send/receive ping is bad. > > > >that is the biggest bullshit i have read on this list in some time. > > > >if you deny icmp, you shall burn in hell > You may burn in hell, but ICMP can be used to infiltrate and exfiltrate > data: > http://www.cs.uit.no/~daniels/PingTunnel/ so can tcp, so we shall block all tcp so can udp, so we shall block all udp so can water pipes, so let's deny access to all toilets for everybody so can underwear, so let us require everybody to work naked -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Prevent circumventing dansguardian with pf
On Fri, 2007-05-04 at 07:26 -0600, Open Phugu wrote: > > if you deny icmp, you shall burn in hell > You may burn in hell, but ICMP can be used to infiltrate and exfiltrate data: > http://www.cs.uit.no/~daniels/PingTunnel/ > > This looks like it's pretty trivially defeated; bzero()'ing the data portion of the ICMP echo request/response removes the piggybacked data channel. For even more fun, you could overwrite the actual data in the covert channel with a fun message about the Care Bears. Or, for bonus points, some nice Harry Potter slashfic ;-) - Bert
Re: Prevent circumventing dansguardian with pf
On Friday 04 May 2007 15:42:58 Henning Brauer wrote: > so can underwear, so let us require everybody to work naked Actually, depending who you work with, this can be a good thing... -- Antoine
Re: Prevent circumventing dansguardian with pf
On Fri, May 04, 2007 at 07:26:32AM -0600, Open Phugu wrote: > On 5/4/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > >* Chad M Stewart <[EMAIL PROTECTED]> [2007-04-25 19:31]: > >> On Apr 25, 2007, at 11:05 AM, Allen Theobald wrote: > >> >pass in inet proto icmp all icmp-type $icmp_types keep state > >> > >> This can be used as a covert communication channel. Allowing > >> internal IPs to send/receive ping is bad. > > > >that is the biggest bullshit i have read on this list in some time. > > > >if you deny icmp, you shall burn in hell > You may burn in hell, but ICMP can be used to infiltrate and exfiltrate > data: > http://www.cs.uit.no/~daniels/PingTunnel/ Yes, but so can DNS and pretty much any data you let out of your network. Consider encoding data in send time if you have both of those covered. See the .sig for a better solution; due to an oversight by the developers, those man pages are not found on a stock OpenBSD system, but Google will be happy to help. Joachim -- TFMotD: knife, axe, cutter, chainsaw(8) - tools to improve network performance via SNIP
Re: Prevent circumventing dansguardian with pf
Bret Lambert([EMAIL PROTECTED]) on 2007.05.04 09:47:43 +: > This looks like it's pretty trivially defeated; bzero()'ing the data > portion of the ICMP echo request/response removes the piggybacked data > channel. Then I'll encode my data with the morse over ping protocol. If a user can send any sort of packet to the outside world, he can send almost any information. If you want deny users the possiblility to smuggle data outside of their workplace (or whatever) then don't connect them to the internet. /Benno -- Sebastian Benoit <[EMAIL PROTECTED]> "There are no good wars, with the following exceptions: the American Revolution, World War Two and the Star Wars Trilogy." -- Bart Simpson
Re: Prevent circumventing dansguardian with pf
On Fri, 2007-05-04 at 09:47 -0400, Bret Lambert wrote: > On Fri, 2007-05-04 at 07:26 -0600, Open Phugu wrote: > > > if you deny icmp, you shall burn in hell > > You may burn in hell, but ICMP can be used to infiltrate and exfiltrate data: > > http://www.cs.uit.no/~daniels/PingTunnel/ > > This looks like it's pretty trivially defeated; bzero()'ing the data > portion of the ICMP echo request/response removes the piggybacked data > channel. > > For even more fun, you could overwrite the actual data in the covert > channel with a fun message about the Care Bears. > > Or, for bonus points, some nice Harry Potter slashfic ;-) For certain types of network links it can be useful for troubleshooting/debugging purposes to put different patterns into the data portion of the ICMP packet: http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00800 a7599.shtml Although I agree that having the option to scrub or block ICMP packets with non-zero data payloads would be useful. Jeff [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Prevent circumventing dansguardian with pf
>From: Sebastian Benoit <[EMAIL PROTECTED]> > >If you want deny users the possiblility to smuggle data outside of their >workplace (or whatever) then don't connect them to the internet. No, no, no. You must go one step beyond this if you want to prevent employees from smuggling data. To do this properly, copy machines should be remove! Pen, pencils and papers removed! Employees should be searched for thumb drives, zip drive, floppy drives, tape recorders, papers, cd's, dvd's, and burners. It's better to strip search them just to be sure. As a matter of fact, because humans are so innovative, all materials should be removed from the office because I'm sure someone will come up with some way to write something down. Oh, don't forget to remove phones, faxes and cell phones, and cameras. You should only hire people who don't know how to read or write to reduce the work load of preventing others from smuggling data. It's probably best that they don't know how to receive or transmit any form of language/communication either.
Re: Prevent circumventing dansguardian with pf
On 4/25/07, Allen Theobald <[EMAIL PROTECTED]> wrote: Greetings! Included below is my pf.conf set up to use dansguardian (proxyport 3128, filterport 8080) and tinyproxy (listen port 3128) as a transparent proxy. What changes do I need to make to keep someone on int_if/int_net from circumventing dansguardian by changing their browser to point to 3128? By blocking all outbound ports, and redirecting those they need to the firewall itself. Ie. run a DNS server on the firewall so they can resolve (alternatively only pass traffic to your ISP's DNS), use port forwarding to redirect all www traffic to your filter etc... Don't leave any port unblocked is the only way. I remember I was once dared to get on napster (yeah it was awhile ago :-) at an old job by one of the admins. They had recently gone through a whole seminar-thing on how to block these kinds of things. So I set up a socks proxy on my home computer running on port 80, and proceeded to fill up my work HD with mp3's. They didn't filter web traffic so it just looked like web traffic as far as the firewall was concerned. Took me about 5 minutes to waste their thousands of dollars on training. I also used the same 'trick' to get around a filtering internet provider. I think that time was by using port 53. Any open port would be subject to the same. So close them. All of them. --Bryan
Re: Prevent circumventing dansguardian with pf
On 5/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >From: Sebastian Benoit <[EMAIL PROTECTED]> > >If you want deny users the possiblility to smuggle data outside of their >workplace (or whatever) then don't connect them to the internet. No, no, no. You must go one step beyond this if you want to prevent employees from smuggling data. To do this properly, copy machines should be remove! Pen, pencils and papers removed! Employees should be searched for thumb drives, zip drive, floppy drives, tape recorders, papers, cd's, dvd's, and burners. It's better to strip search them just to be sure. As a matter of fact, because humans are so innovative, all materials should be removed from the office because I'm sure someone will come up with some way to write something down. Oh, don't forget to remove phones, faxes and cell phones, and cameras. You should only hire people who don't know how to read or write to reduce the work load of preventing others from smuggling data. It's probably best that they don't know how to receive or transmit any form of language/communication either. Also, make the whole building a large faraday cage to prevent them from using radio communication. And have automatic direction-finding recievers to triangulate the location of (l)users who attempt to use radio. In fact, there is a much cheaper method: don't hire humans. _Every_ compromise of security or instance of data exfiltration has been traced back to a human action. If you don't have humans, you don't have problems.
Re: Prevent circumventing dansguardian with pf
Any working TCP/IP connection can transmit covert data by encoding the data in the sequence numbers. Let's not forget to block/allow new protocols such as described in RFC 1149 On 5/7/07, Open Phugu <[EMAIL PROTECTED]> wrote: On 5/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >From: Sebastian Benoit <[EMAIL PROTECTED]> > > > >If you want deny users the possiblility to smuggle data outside of > their > >workplace (or whatever) then don't connect them to the internet. > > No, no, no. You must go one step beyond this if you want to > prevent employees from smuggling data. To do this properly, copy > machines should be remove! Pen, pencils and papers removed! > Employees should be searched for thumb drives, zip drive, floppy > drives, tape recorders, papers, cd's, dvd's, and burners. It's > better to strip search them just to be sure. As a matter of fact, > because humans are so innovative, all materials should be removed > from the office because I'm sure someone will come up with some way > to write something down. Oh, don't forget to remove phones, faxes > and cell phones, and cameras. You should only hire people who > don't know how to read or write to reduce the work load of > preventing others from smuggling data. It's probably best that > they don't know how to receive or transmit any form of > language/communication either. Also, make the whole building a large faraday cage to prevent them from using radio communication. And have automatic direction-finding recievers to triangulate the location of (l)users who attempt to use radio. In fact, there is a much cheaper method: don't hire humans. _Every_ compromise of security or instance of data exfiltration has been traced back to a human action. If you don't have humans, you don't have problems.
OT: Blocking of ICMP type 3 code 4 packets [Was: Prevent circumventing dansguardian with pf]
Although it's not well known TCP seriously depends on ICMP packets of type 3 code 4 for "Path MTU Discovery" (PTMTUD). Blocking of these packets lead to congested IP connections, broken transmissions and thus to frustrated users. Some documentation: http://en.wikipedia.org/wiki/Pmtud http://www.usenix.org/events/lisa02/tech/full_papers/vanderberg/vanderberg_html/ http://www.ietf.org/rfc/rfc2923.txt Various serious solutions: BSD: pass quick proto icmp from any to any icmp-type 3 code 4| Linux: iptables -I CHAIN-NAME -p ICMP --icmp-type 3/4 -j ACCEPT Check Point firewalls: Explicitly allow ICMP type 3 code 4 packets to the servers that use Path MTU Discovery A firewall that allows TCP and disallows ICMP type 3 code 4 is a broken firewall that should be repaired or replaced immediately since it's not usable for serious TCP traffic. +++chefren
Re: OT: Blocking of ICMP type 3 code 4 packets [Was: Prevent circumventing dansguardian with pf]
On 2007/04/26 01:01, chefren wrote: > Although it's not well known TCP seriously depends on ICMP packets of > type 3 code 4 for "Path MTU Discovery" (PTMTUD). Blocking of these > packets lead to congested IP connections, broken transmissions and thus > to frustrated users. for PF, 'keep state' on the TCP rule (default in 4.1) does the right thing and matches the appropriate ICMP messages as well.
