Outpost rules - how do i learn this?

Discussion in 'other firewalls' started by timnicebutdim, Feb 12, 2005.

Thread Status:
Not open for further replies.
  1. timnicebutdim

    timnicebutdim Registered Member

    Joined:
    Jan 24, 2005
    Posts:
    66
    I am a novice, know nothing about ports, tcp, udp, ect. I am currently using a trial version of outpost pro ( latest version ).
    I would like to learn how to set up custom rules for applications through the outpost firewall but i find it very confusing.
    I have read the tutorial ( http://www.outpostfirewall.com/guide/rules/scratch.htm ) for this and understand how to change the settings for making a custom rule.

    The problem is that i would have no idea when to select when making a rule. How is a novice to learn if he should select tcp or udp or outgoing or incoming for a particular application?

    For example: I don't understand tcp, udp and general network terms and even when trying to study into these i find more technical terms in the definitions for them. Is there knowhere online that can explain in simple terms ( not jargon ) what these terms mean?

    Also even if i manage to learn what these terms mean, how am i supposed to know what an application is trying to do to set the rule?

    For example: How am i supposed to know if an application should have outbound or inbound access? I know that this might seem obvious if i know what the application is supposed to do but without having actually programmed the application how can i know for sure it doesnt need inbound also.. if i think it only needs outbound and vice versa.

    Also... have does a novice know what port an application will need? Since there is thousands of ports numbers how can i make a rule and magically know its port 3764 for example? Is there some special program that examines the application to determine the port or what?

    Even though i am a novice i still believe that if something is explained in simple terms ( no jargon ) with real world examples then anyone can learn how to do something which may at first seem impossible.

    I have obviously got a lot to learn... does anyone know of any websites that might help me on the right track or any advice that might help?
     
  2. profhsg

    profhsg Registered Member

    Joined:
    May 18, 2004
    Posts:
    145
    Paranoid 2000 is the leading expert on Outpost both in this forum and the forum specially dedicated to Outpost firewall. That forum is found at: http://www.outpostfirewall.com/forum/

    Until he can get to your inquiry, allow me to give you a quick and dirty answer to your question. First, I would suggest reading Paranoid 2000's guide to producing a secure configuration on the Outpost forum. It is found here:

    http://www.outpostfirewall.com/forum/showthread.php?t=9858

    After following his suggestions (at least as far as global rules are concerned--and maybe some application specific rules if you don't find the suggestions too complicated or difficult), simply put Outpost in the learning mode (via options/system/rules wizard). Whenever you start up an application, that uses an internet connection, Outpost will query you. Sometimes it gives you the option to select rules that correspond to the particular application, e.g., Real Player or IE, or for a generic type of program, e.g., e-mail client or browser. If you started the program yourself, you can't go to far wrong with chosing the corresponding choice (be it a specific program name or a type of program) and hitting allow. If you aren't given the option of selecting a particular program, or type of program, you can always simply select custom. A dialog will then pop up which gives you all sorts of options. If, however, you started the program seeking access, or know what it is, e.g., the automatic update function for your antivirus, and trust it, it is usually enough to simply check off "allow." Outpost will have automatically filled in the protocol, port, etc. which the program is trying to use.

    The above procedure doesn't always produce the most secure configuration possbile, but it certainly produces one which is adequate for most people. Hope this helps till Paranoid 2000 or another true expert gets around to answering you question.
     
  3. ding

    ding Guest

    As a new user using trial op2.5x lastest trial version, let try some input hope it helps somewhat. Please point out if something wrong.

    - Inbound requests: the requestes coming from outsiders. Mostly, if your computerr is not a running as a server (web/ftp) or not having a service running as server (accepting incoming request at specific ports/protocols, for example), always lock down on inbound requests anyway (global rule).
    - Outbound requests: the requests trying to go outside world (internet/lan) from your computer.

    - [TCP] protocol: establishing connection (stateful) with others and having acknownleged how the connection accepted/connected/disconnected (completed session). Internet browser is to surf the Internet; Antivirus program is to live update itself; for example.
    - [UDP] protocol: connections (stateless) with no-acknownlegde each other. Chitchat (typing) programs mostly use this. DNS lookup always use [UDP] protocol to find the numerous ip (64.91.226.241) of an frienly-wording address (wilderssecurity.com).

    - How to know an application (neccessary to have internet access)?
    1- look up from help/support on the website of the product maker.
    2- look up the internet for that program.
    3- choose OP run at block mode (explicit allowance or blocked), then run that prog and see what it is blocked (address/port/protocol) in the OP logs. Now it is to write the customized/general (yahooo chitchat tcp:5050)/(internet browsering tcp:80, tcp:443), for example.

    - Since I am not a current registered with the forum, so I can post/attach the file; I will list it out the customized/general rules for OP2.5x (if you want to try, disconnect internet first, then it is to shutdown OP temporarily and rename the file preset.lst to preset.lst.bak and make new text file preset.lst and copy all these following text into that file and save the file to the same folder as the original one; Then restart OP and see.
    When you reply and others, we will continue on.
    Please point out if something wrong or improper to have secure settings.
     
  4. CrazyM

    CrazyM Firewall Expert

    Joined:
    Feb 9, 2002
    Posts:
    2,428
    Location:
    BC, Canada
    The prompt from the firewall should provide information on the protocol, direction and remote service/port the application wants to use.

    Unfortunately a lot of the information available online will be technical.
    One online tutorial you could try is The TCP/IP Guide and see if that helps.

    If you are only surfing the web, using e-mail, instant messaging etc., think of your applications as clients connecting to a remote server for the service they host - web site, e-mail, etc. To do this your application rules should only require outbound connections.

    Inbound connections are not something you want to allow. If you were hosting a service as above then you would need to allow inbound connections to that server/service. Some file sharing applications will require this in order to work properly.

    The firewall may have predefined rules you could use to start with and then review later and make any modifications if required. The applications help file may contain information on what may be required. The prompt from the firewall should indicate what remote service/port the application is attempting to connect to and would be required for your rule.

    In addition to the links already provided, the Other Firewalls Sticky Posts also has some links on customizing rules.

    Don't hesitate to ask if a more detail description of something is required.

    Regards,

    CrazyM
     
  5. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    Timnicebutdim,

    You can avoid rules altogether by just making setting applications you use as Trusted and setting anything else as Blocked (Windows XP in particular has lots of "phone home" programs that you may feel better blocking). If in doubt, block traffic - you can always change it to allow if a program does not work as a result.

    The only exception is svchost.exe (if you are running Windows XP) or services.exe (if you are running Windows 2000) - these need access (you will lose your Internet connection otherwise) but should not be made trusted (this will leave your system vulnerable to RPC/DCOM exploits like MyDoom in the case of svchost). In this case the easiest option is to run Outpost in Rules Wizard policy and accept the preset rules it suggests ("Generic Host Process") - if you are unsure about your existing rules, just delete the entry for svchost or services in Options/Application, this will trigger a Rules Wizard popup the next time they try to connect.

    It is better practice though to make all your applications Partially Allowed and Outpost's Rules Wizard will suggest an appropriate ruleset for the common ones - therefore try the steps above for your other applications once you feel more familar with Outpost.

    Ding,

    You have customised your ruleset therefore it is not going to be suitable for other peoples' systems. I would recommend that you remove the direction from your "Allow DNS" rules (this can cause problems with UDP traffic) as well as the Stateful Inspection option (this is only of use with applications that make multiple connections - DNS connections are once-off affairs, see the Outpost forum Stateful Inspection FAQ for more).
     
  6. ding

    ding Guest

    Thanks for pointing out the mistakes.
    -Since inbound requests are dropped by one of the principal rule for an non-service/server box, why putting spi on those? Removed spi on these and wasting resources for nothing. THANKS a million.
    - UDP connection is stateless one. But I worry about spoofing/malform dns requests (a stealthed malware might make a dns lookup but to a dsn ip different from my isp dsn servers, just a thought might be in practical or wrong since my limit on networking stuff), it might be ok to put spi on outbound udp dns lookup requests? Please correct again at details if it is still wrong. Thanks.

    In fact, I had learn from your writing on those stuff for OP setting prior to customizing for mine.
    I removed all allowing access out by default in general (global) rule sets; instead, puting all block rules there as global rules. Then made general (most used) rules {dns lookup/browser/ftp/email} as general preset rules and with a little more specific on local ports/remote host going to be used to be more restrict on things having internet access out.

    Any inputs would be much appreciated help me to learn more to have a secure box.
    Thanks to All.
     
  7. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    Restricting DNS requests to your ISP server will help in many cases (and Outpost's DNS plugin does have the option of checking for malformed DNS requests) but the most secure option is to remove the DNS global rules and disable the Windows DNS Client Service - this will result in every application needing its own DNS rules and is the only method of blocking the DNSTester leaktest (see the Application DNS section of the Outpost Secure Configuration Guide for details). However this does involve extra work.
    Outpost's SPI option allows an application to make unlimited (by port) connections to an address once it has been triggered. There is no need for it in DNS (it would actually reduce security by allowing connections on other ports to the DNS servers) and should only be used in specific cases as detailed in the FAQ mentioned previously.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.