[pfSense-discussion] tool you might want to include in pfsense
Hello, I am the author of dfd_keeper, a tool for manipulating pf firewalls. I thought you guys might be interested in evaluating it for inclusion into pfsense. You may find futher information here: http://www.lightconsulting.com/~travis/dfd/ You may browse the code here: http://www.lightconsulting.com/~travis/dfd/dfd_keeper/dfd_keeper/ It is only about 1000 lines or so, including test cases. I welcome any comments or suggestions you may have. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] tool you might want to include in pfsense
Well it's not set in stone. C seems too unsafe a language to me in which to write security applications. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] Re: tool you might want to include in pfsense
> its not the language, its the programmer. I disagree. C has many constructs that are far too easy to handle incorrectly, such as buffer handling, pointer manipulation, and the string functions. The string functions are so non-intuitive in several important corner cases that OpenBSD created a new set of string handling functions (strlcat and such). One *can* write secure C code (or assembler for that matter), which is about as easy as writing portable C code, but it's far too easy to shoot yourself in the foot. I recall reading about a trivial program that Markus Ranum wrote for use in a presentation, that one of the audience members pointed out had a buffer overflow, to his embarrasment. If you don't know who he is, he ran the firewalls mailing list for a while. > I'm sure there are people who write unsafe code in Python. I'm equally sure there's not nearly as many. Whole classes of errors, such as stack and heap overflows, are (if not impossible) quite difficult to do, nearly eliminating lapses of attention as a cause of them. Having strings and sockets as a first-class object eliminates the string-handling routines as a source of buffer problems as well. Aside from logic errors (like allowing a user to open an arbitrary filename), that leaves very little -- everything I can think of right now involves passing stuff to external programs (not sanitizing their inputs). Of course you lose some expressive power, and some speed, but you gain portability and it makes development much faster (my program is 1000 lines, and would easily be ten times that in C). With only a few years of python, my edits usually work the first time. I'm sure I could achieve that proficiency with C, assembler, or hand-coded machine language (I know at least 12 languages), but it would take a lot longer. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] Payload inspection
On 9/21/05, A Rossi <[EMAIL PROTECTED]> wrote: > I was thinking of payload inspection as a way to check to see if the payload > contains requested data (like HTML, or mp3 or whatever the user is > downloading) to make sure that it doesn't contain infected data (with a worm > or such) that is piggybacking on legitimate data. A couple of things. When malicious code attaches itself to other data, it's generally called a virus. When they transmit themselves autonomously, they're called worms. Secondly, how in the world would you know if returned information is "what the user requested"? Seems like the user makes a query, and data comes back, and there's no other source of information on which you could make a determination. For example, I do an HTTP request like this: GET /cgi-bin/whatever.pl HTTP/1.0 And in return I get a 5k ASCII document of MIME type text/plain. Is that what I requested? Seems like you're getting into mind-reading and "do what I mean, not what I say" territory here. And that's just HTTP. Packet-by-packet regex is a dumb idea, but I don't exactly see how it isn't "secure", apart from implementation errors (e.g. buffer overflow) and some DoS issues (both endemic to all network applications). It won't do what you want, but that's not really a security issue, as it's more of an expectation problem on the part of the people who request this. Given how much data crosses a firewall, I think a short pattern like ".mp3" would match far too many innocuous connections. Certain network operations would just fail in some way, and you would end up with a user base that started to blame your firewall for everything. If you want layer 7 inspection, and you want to do it right, don't use a layer 3 device, get an IDS/IPS. It's hard enough to do right at layer 7, and playing games at layer 3 will only give you a false sense of security. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] block vs reject?
On 9/26/05, Greg Hennessy <[EMAIL PROTECTED]> wrote: > > so its safe to assume that internet -> WAN stuff should be > > blocked. but for internal access between my LAN/OPT > > interfaces and outbound WAN i can use reject and it wouldn't > > be considered bad form? Hmm, rejecting on the outbound WAN link? That doesn't make a lot of sense. If you're sending packets out, the remote systems (destinations) are doing to send a TCP RST or ICMP unreach, and yes, you should allow those back in. > Personally I junked the 'stealth' thing years ago. > Portscans happen in parallel, so the notion that you're slowing a script > kiddie down is laughable. Last time I ran it against my own system, nmap UDP scans took a very long time when you're not rejecting them with ICMP, and that was for a limited port range (not the full 65535). This assumes you're using -P0, because otherwise it skips a stealthed host entirely and exits rather quickly. Parallelism is limited by memory and network bandwidth. Plus, script kiddies have short attention spans. I'm not sure it's so laughable, have you actually timed it? There is one tool (I think it's scanrand from the Pakette Keiretsu) that doesn't allocate resources when scanning, as all the info comes back in the replies, which also means the sending and receiving halves of the scan can be seperated and that timeouts are mostly irrelevant, but that's not a widely used tool. > By all means attempt to figure out what I'm running OS wise on my gateway > :-). Nmap -O got that wrong also LOL. That sounds like an almost interesting challenge. There are tools other than nmap, you know. queso and p0f jump to mind, but scapy can be useful too. What it boils down to is any data you send could be useful. You don't always know what is and isn't useful. What you don't know *can* hurt you, so the safest thing is to send nothing. The time it takes you to respond, the type of the response, IP ID, TTL, MTU, sequence numbers in RST packets, uninitialized URG pointer contents, the payload in ICMP unreachables, padding at the end of short packets (google etherleak), and any ICMP throttling parameters, all provide information to the remote parties. I could go on and on, but for the full version, read "Silence on the Wire". It's the best security book I've read, although most of what he discusses is way over the head of the average script kiddie. I do network security for a living, and reading it was a humbling experience. I think there is a third class of scanners, those that don't get noticed. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] What about a Ramdisk?
I want to mention that you can also use SOCKS as a proxy. Many clients support this non-transparently (as a configuration option), and you could maybe even do it transparently. Keeping the proxy on the gateway host will reduce the latency compared with having it on a seperate host (TCP connection startup and teardown takes a noticable amount of time). Note that not all proxies are equal: I have found that some HTTP proxies work with GET/POST/HEAD but don't support CONNECT, which is essential for streaming. You may also be interested in my "metaprox" program, found at my home page in my .sig, which allows you to select different HTTP proxies based on the domain name in the request. Unfortunately, it uses an HTTP library which assumes a finite-length request and reply, which means it won't do streaming media properly. I really wish you could specify a proxy chain with each HTTP request, but alas, the protocol is designed for only one. You can chain them together, but it's a bit of a hack to do so. There is a library for reassembling TCP packets into streams, but unfortunately I do not remember the name. One good question is what you do when the stream gets longer than the available space on the ramdisk. For example, a streaming audio connection will easily fill the disk before it completes. Egress filtering of certain ports is essentially turning off essential functions of internetworking... soon malware writers will begin to tunnel the protocols over something that is allowed out, like ICMP, DNS or HTTP... I am not so sure this is a good long-term solution. Detecting malicious behavior and disabling ports on a managed switch seems like a better solution (I wish they were cheaper though). Mirage Networks uses arp spoofing to disable malicious hosts, which seems pretty clever and doesn't require an expensive managed switch. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] Traffic Shaper
SIP just isn't firewall/NAT friendly. I've been thinking of writing a pcap-based sniffer that modifies firewall rules using my dfd_keeper stuff to support SIP and other protocols across a pf firewall. Of course, with IAX/IAX2 it's much easier, since they only use one UDP port. If you can talk SIP locally to the asterisk box and IAX externally to a provider, it'd be much easier. I used to do that, but for some reason FWD's free IAX gateway no longer seems to work. It could be worse, you could be talking H.323... ;-) -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] What about a Ramdisk?
> > Note that not all proxies are equal: I have found that some HTTP > > proxies work with GET/POST/HEAD but don't support CONNECT, which is > > essential for streaming. > > Yes. We are speaking about Squid, don't we?? You may be. I'm speaking generally of HTTP proxies. I do not know the details of what squid does or does not support. -- http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] authpf package
> ssh need to be open on WAN interface and all user that have real shell > could be disabled for security concern. Be careful when trying to disable users via their login shell: http://www.csh.rit.edu/~psionic/articles/ssh-security/ -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] Restricted viewing...
http://www.loganalysis.org/ For all your log analysis needs. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: [pfSense-discussion] Hamachi and PFSense
On 8/18/06, Chris Godwin <[EMAIL PROTECTED]> wrote: If I disable the bimap while pinging, the pings still come through. Because the state for the outbound ICMP echo request is still in the state table. If I disconnect and reconnect hamachi after the bimap has been deleted the hosts become unreachable yet I still can login to hamachi's server and see the host list. When you "disable" the bimap (not sure what you mean by disable), do you have another NAT rule or direct access to pass the traffic that goes to hamachi's server? Can you give us a tcpdump output of this connection? -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] Dynamic DNS - no password encryption
On 8/29/06, DarkFoon <[EMAIL PROTECTED]> wrote: I was looking through my XML configuration recently, and I noticed that my Dynamic DNS password is not encrypted like the PFsense password is. It seems to me that this is a rather important password and should be encrypted (if possible). This is also true of other programs, such as gaim. Your IM passwords are stored in plaintext, for the same reasons. The best way to deal with this is to make your home directory encrypted, but that rules out unattended mounting almost by definition. Take a look at truecrypt for one cross-platform open-source tool that supports steganography as well. Another way to deal with it would be to use something like a keychain program (similar to ssh-agent) to give the daemon the key, or to get it from another machine (if you wish to have unattended boots with /home mounted). Of course if you're worried about power outages, you will want to UPS that other machine, and/or have a generator with automatic switchover from the grid. One advantage of natural gas generators is not having to be there to refill it with fuel. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] Dynamic DNS - no password encryption
On 9/1/06, Andrew C Burnette <[EMAIL PROTECTED]> wrote: Yes, short answer is, if you can't trust your filesystem (or more directly the OS with access to it), you've already been owned, and the train has already left the station. Well, there are a class of vulnerabilities which grant read access to [any] file(s), but in general, the game is over by that time. If it's that secret (read NSA guidelines on security as they're actually not half bad), Link: http://www.nsa.gov/snac/ Note they only have security guides for commercial OSes. If anyone is inclined, send their PR or public relations office a thank-you note for developing stuff for open-source OSes. They took a toungue-lashing from MS over SELinux, and are careful to state that they aren't endorsing one vendor over another, etc. Let them know that open-source allows the maximum benefit from their research and development because others can study the implementation easily. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] need some advice/help on multiple WAN subnet
Ewww, HTML in email. You are aware of the dangers of using a browser to read email, right? I am also trying to avoid cascading pfsense boxes, like routing from one to another, and the > second doing the NAT - as it is the opposite of high availability. The way this is normally done for HA is to have dual paths, and network cross-links between the different layers, so that whichever one goes down, there is still a connection through that layer. It shouldn't be necessary for you, but if you have different hardware for the different layers it is less avoidable. But yes, 4 devices in a 2x2 would give worse availability than 4 devices in a 4x1, you mostly do multiple layers to isolate layers from each other, like having multiple file systems on a server so that one function can't hose the other one. -- Enhance your calm, brother; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] IDS yet?
On 9/20/06, Sam Newnam <[EMAIL PROTECTED]> wrote: I've read a couple places but couldn't find a clear answer to whether SQUID or another intrusion diction system had been integrated yet. SQUID is a cache, not a NIDS. -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] IDS yet?
On 10/6/06, Chris Buechler <[EMAIL PROTECTED]> wrote: Scott Ullrich wrote: > It is a delayed IDS. Generally an IPS hooks into the network stack > directly and does not allow the traffic to pass through until its > scanned. Yep, sometimes these are called intrusion reaction systems, reactive firewalls, or other sundry terms. And generally you probably aren't going to want to hook snort into your network stack like that, because of the limitations of PC hardware. You could, theoretically, disable routing, then let the BPF read packets on one side and inject them on the other. However, the performance penalty of moving into userspace, through an application (scheduler latency), and then out to kernel space again, is probably prohibitive. But at least you know when you're hitting your limit without risking dropped packets. What you really want to do is be able to load the matching up into the kernel using some sort of sandboxing so that the complicated decoders and such don't cause a kernel panic. Some recent research papers show that this can be done with a ~17% performance penalty on x86 hardware with instruction re-writing. Then you can do all your work without incurring a copy/remap between kernelspace and userland. -- "It's not like I'm encrypting... it's just that my communications developed a massive entropy deficiency." -><- http://www.subspacefield.org/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: [pfSense-discussion] IDS yet?
Going through some old email, sorry for the anachronism. On 10/4/06, Bill Marquette <[EMAIL PROTECTED]> wrote: > Sorry, but I do not agree totally with you: the thing I love with pfSense is > that it is possible to install it everywhere, so it could be a _real_ > competitor to enterprise products (like Cisco ASA). So, I think that > CPU-power should not be a limit. Yep, and when you deploy end-to-end encryption, the "One Big NIDS" isn't going to help you very much. Plus, there's plenty of evasion techniques that rely on the NIDS not knowing the network topology or how the endpoint will interpret a series of packets. So the end result is either false alarms, or having to enter details about your endpoints and topology, or features to "learn" that information. But it's all rearranging deck chairs on the Titanic. Let me put it this way; if I send you the last fragment in a packet, wait n seconds, then send you the other fragments, how does the NIDS know whether the endpoint has timed out the fragment reassembly, in which case the packet is not passed to the application, versus if it kept the fragment, in which case the packet is passed to the application? Now think about every single parameter in the stack and you'll start to get an idea of how impossible this is. If your NIDS tries to handle all possibilities, not only do you have lots of false positives, but there's a state explosion that I can use to DoS your NIDS. Let me put it this way; if all your clients starts up massive transfers, then a single NIDS at the gateway must be prepared to handle it - basically, you have to have capacity for the whole uplink. But with NIDS being done at the endpoint, which I call a distributed host-based IDS, then each machine is responsible for its own traffic. You don't have to pay for your uplink speed; each endpoint transfers at the rate it can handle, automatically throttling itself if the IDS portion takes a CPU hit. The gateway NIDS can then be used to monitor only those machines which can't run it, and for attacks against the network stack itself. We have a serious disadvantage against hardware firewalls. Where they can crank out ASICs tuned to specific needs (which comes with a disadvantage we don't have...flexibility), we're stuck with general purpose CPU's which aren't necessarily fast. What an ASIC can do now, in ~3 years a general-purpose CPU can do it. So all that investment in ASIC design gets expensive; but if you don't keep pumping money into it, then the general-purpose CPUs will catch up, offering returns to scale that you can't match no matter how popular your NIDS. What really matters the most is the parallelization, in that you can have a board with 8 ASICs. But SMP can play that game too, with more cost-effective pieces, that have more utility than that one task. Let us also not forget that CPU's aren't getting faster, they're scaling wider Mostly that's due to the limited bandwidth of RAM, not a problem with CPU technology. A modern CPU can have a thread execute instructions as fast as RAM can deliver them. So you have things like dual-channel, where you've got two parallel paths to RAM, so hopefully it can deliver two instruction streams at full speed. And so if the RAM isn't speeding up, but getting wider, of course the CPU is going to go that way, because RAM is the bottleneck. The question is whether packet inspection could benefit from this; i.e. is the problem parallelizable? I think that it is, at least for different sessions. Right now people doing heavy-duty centralized IDS have to buy mutliple overpriced boards with proprietary designs, populated with many ASICs, and then have to get a session-aware load balancer to distribute them. So yes, it is parallelizable. And networks are getting faster; perhaps not at the acceleration of CPU power, but WAY faster than RAM and disk. This means that there's going to be more pressure on the NIDS system. For more information, and some rules of thumb, check out: http://storagemojo.com/?page_id=207 -- "It's not like I'm encrypting... it's just that my communications developed a massive entropy deficiency." -><- http://www.subspacefield.org/~travis/> GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
