Sponsored Content
Full Discussion: Is my iptables fine?
Top Forums UNIX for Dummies Questions & Answers Is my iptables fine? Post 302910720 by Smiling Dragon on Sunday 27th of July 2014 05:15:53 PM
Old 07-27-2014
Your default policy on your INPUT chain is "DROP" but you end with a global REJECT (meaning the DROP will never happen), I'd recommend removing that last line, or changing your default policy to ACCEPT, having both could be confusing during debugging.

I'm a fan of DROP over REJECT as it slows scanners and helps differentiate between something being offline or broken, and something being blocked by your firewall.

I think you are probably accepting too many INPUT ports, I'd wager you don't need pop,pops,imap & imaps?

Are you sure you want to be allowing incoming DNS requests?

Change your default policy of the FORWARD chain to either REJECT or DROP (or at least add a few rules to ensure you are only forwarding for things on your internal network).

Near the start, you are accepting Related and Established replies, then further down near the end of the INPUT chain you accept Established again, don't need that second one.

The three DROP rules near the top also have some redundancy in them (dropping FIN packets in two different rules for instance).

Your OUTPUT chain's default policy is ACCEPT, but you also have a bunch of rules that ACCEPT certain outbound connections, I'd assume that you probably meant to have the default policy as REJECT or DROP?

---------- Post updated at 09:15 AM ---------- Previous update was at 09:15 AM ----------

Edit: These are relatively small points, though, overall I think you are on the right track with this.
 

8 More Discussions You Might Find Interesting

1. Linux

which linux products is used(fine) to me ?

which linux products is used(fine) to me ? I am learning linux now ,and a new memeber of linux ,hoping to know it more . (4 Replies)
Discussion started by: lsxymn
4 Replies

2. IP Networking

recv() not workin fine.....

hi ! In my program I have a structure as shown below: struct data { int a; char *b; long c; }str; i have assigned the following values to it: strcpy(str.b,"John"); str.a=10; str.c=123435; The client is tryin to send struct data to the server using send(sock,(char *... (2 Replies)
Discussion started by: mridula
2 Replies

3. Shell Programming and Scripting

Script works fine until I | more

Hello all, This beats me. I have a script that executes some commands and redirects their output to some text files that I will parse. The commands are along the lines of: dsmadmc -id=admin -pa=admin -outfile=/home/tools/qlog.txt q log f=d If I just run the script it works. If I execute... (2 Replies)
Discussion started by: Skovian
2 Replies

4. Shell Programming and Scripting

NAWK Script not working fine

Hello to all can any one help me out with a nawk script. Actually i am having a shell script which uses nawk pattern searching and it is not parsing the file properly. I have been debugging it since long time, but nt able 2 find the root cause.. If any one can help me out with this one .. (3 Replies)
Discussion started by: dheeraj19584
3 Replies

5. AIX

fine grained audit control

I'm working with the audit system on aix 5.1 and 5.3 . But after lots of googling and RTFM, I can't figure out how to audit all files in a given directory rather than specifying each file individually like /etc. And how can I exclude a directory such as /var/tmp so I don't get records for every... (0 Replies)
Discussion started by: vaporlock
0 Replies

6. UNIX for Advanced & Expert Users

How to know whether my perodic thread is working fine

Dear All, I am using xenomai-2.4 along with linux kernel 2.6 In my application having following threads. 8ms perodic thread (RT TASK) 1ms perodic thread(RT TASK) 16ms perodic thread(RT TASK) 256ms perodic thread(RT TASK) 22 - pthread are condition based it may execute or else in... (1 Reply)
Discussion started by: rajamohan
1 Replies

7. Shell Programming and Scripting

Script runs fine, but not in a cron

Okay, I have the following script that runs fine from a command line as well as an executable .sh file. It just moves any file/folder with movie* in the name to a folder called _Movies. The issue I'm running into is when it's call from a cron. find /mnt/HD_a2/BT/complete -iname "movie.*" -exec... (4 Replies)
Discussion started by: sammyk
4 Replies

8. Shell Programming and Scripting

Script works fine but not with crontab

Hello All, This is driving me nuts. Wrote a very simple script (it's in csh so sorry about that). Just something very simple though. Here is the catch. Works great from command line sometimes. Other times it runs no errors or anything but I never receive an email. Never runs from crontab... (6 Replies)
Discussion started by: jacktay
6 Replies
SHOREWALL-POLICY(5)						  [FIXME: manual]					       SHOREWALL-POLICY(5)

NAME
policy - Shorewall policy file SYNOPSIS
/etc/shorewall/policy DESCRIPTION
This file defines the high-level policy for connections between zones defined in shorewall-zones[1](5). Important The order of entries in this file is important This file determines what to do with a new connection request if we don't get a match from the /etc/shorewall/rules file . For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server). Important Intra-zone policies are pre-defined For $FW and for all of the zones defined in /etc/shorewall/zones, the POLICY for connections from the zone to itself is ACCEPT (with no logging or TCP connection rate limiting) but may be overridden by an entry in this file. The overriding entry must be explicit (cannot use "all" in the SOURCE or DEST). Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf, then the implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE policies may also be overridden by an explicit entry in this file. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SOURCE - zone|$FW|all Source zone. Must be the name of a zone defined in shorewall-zones[1](5), $FW or "all". DEST - zone|$FW|all Destination zone. Must be the name of a zone defined in shorewall-zones[1](5), $FW or "all". If the DEST is a bport zone, then the SOURCE must be "all", another bport zone associated with the same bridge, or it must be an ipv4 zone that is associated with only the same bridge. POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}] Policy if no match from the rules file is found. If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the following: 1. The word "None" or "none". This causes any default action defined in shorewall.conf[2](5) to be omitted for this policy. 2. The name of an action (requires that USE_ACTIONS=Yes in shorewall.conf[2](5)). That action will be invoked before the policy is enforced. 3. The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. Possible policies are: ACCEPT Accept the connection. DROP Ignore the connection request. REJECT For TCP, send RST. For all other, send an "unreachable" ICMP. QUEUE Queue the request for a user-space application such as Snort-inline. NFQUEUE Queue the request for a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not given, queue zero (0) is assumed. CONTINUE Pass the connection request past any other rules that it might also match (where the source or destination zone in those rules is a superset of the SOURCE or DEST in this policy). See shorewall-nesting[3](5) for additional information. NONE Assume that there will never be any packets from this SOURCE to this DEST. Shorewall will not create any infrastructure to handle such packets and you may not have any rules with this SOURCE and DEST in the /etc/shorewall/rules file. If such a packet is received, the result is undefined. NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all". LOG LEVEL (loglevel) - [log-level|ULOG|NFLOG] Optional - if supplied, each connection handled under the default POLICY is logged at that level. If not supplied, no log message is generated. See syslog.conf(5) for a description of log levels. You may also specify ULOG or NFLOG (must be in upper case). This will log to the ULOG or NFLOG target and will send to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). If you don't want to log but need to specify the following column, place "-" here. BURST:LIMIT (limit) - [{s|d}:[[name]:]]]rate/{second|minute}[:burst] If passed, specifies the maximum TCP connection rate and the size of an acceptable burst. If not specified, TCP connections are not limited. If the burst parameter is omitted, a value of 5 is assumed. When s: or d: is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not give, the name shorewall is assumed. Where more than one POLICY specifies the same name, the connections counts for the policies are aggregated and the individual rates apply to the aggregated count. CONNLIMIT - limit[:mask] May be used to limit the number of simultaneous connections from each individual host to limit connections. While the limit is only checked on connections to which this policy could apply, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host individually but can be made to apply to networks of hosts by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask. EXAMPLE
1. All connections from the local network to the internet are allowed 2. All connections from the internet are ignored but logged at syslog level KERNEL.INFO. 3. All other connection requests are rejected and logged at level KERNEL.INFO. #SOURCE DEST POLICY LOG BURST:LIMIT # LEVEL loc net ACCEPT net all DROP info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT info FILES
/etc/shorewall/policy SEE ALSO
http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) NOTES
1. shorewall-zones http://www.shorewall.net/manpages/shorewall-zones.html 2. shorewall.conf http://www.shorewall.net/manpages/shorewall.conf.html 3. shorewall-nesting http://www.shorewall.net/manpages/shorewall-nesting.html [FIXME: source] 06/28/2012 SHOREWALL-POLICY(5)
All times are GMT -4. The time now is 11:36 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy