| View previous topic :: View next topic |
| Author |
Message |
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
 Posted: Sat Aug 29, 2009 3:00 am Post subject: Configuring iptables to accept outbound connections |
 |
|
Ok, so I am running gentoo and I wanted to use iptables to build a firewall using the stateful rules. The problem is that now the machine that I setup the firewall wont allow outbound connections to it. I run a backup of my other computer that sends it to this machine via ftp, but since I have setup the firewall things went a little haywire. I can't ping the machine. I am wondering if anyone has any advice on how I can tweak my existing rules to allow this outbound connection that I need.
Here are the rules:
#!/bin/sh
export LAN=eth0
#setup logging
#iptables -N logdrop_I
#iptables -A logdrop_I -j LOG --log-prefix "DROP INPUT PACKET"
#iptables -A logdrop_I -j DROP
iptables --flush
iptables --delete-chain
iptables -A INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i ! ${LAN} -j ACCEPT
#http
iptables -A INPUT -s ipaddresses-p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#samba
iptables -A INPUT -s ipaddresses-p udp -m udp --dport 137 -j ACCEPT
iptables -A INPUT -s ipaddresses-p udp -m udp --dport 138 -j ACCEPT
iptables -A INPUT -s.ipaddresses -p tcp -m tcp --dport 139 -j ACCEPT
iptables -A INPUT -s ipaddresses-p tcp -m tcp --dport 445 -j ACCEPT
#ftp
iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
#domain
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
#ping
iptables -I INPUT -p icmp -j ACCEPT
#output
iptables -A OUTPUT -j ACCEPT
#log
iptables -A INPUT -p tcp -m tcpmulti --dport 22,20,21,53,80,139,445 -j LOG --log-prefix "DROP PACKET:"
iptables -A INPUT -p udp -m udpmulti --dport 137,138 -j LOG --log-prefix "DROP PACKET:"
iptables -A INPUT -p udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A OUTPUT -p tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
#iptables -A OUTPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info
#reject everything else
#iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
/etc/init.d/iptables save
_________________
Mr. Clark |
|
| Back to top |
|
 |
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Sat Aug 29, 2009 7:46 am Post subject: |
|
|
If I follow your description and if I see this correctly, the problem is actually inbound connections to that machine?
Your third rule is:
| Code: | | iptables -A INPUT DROP |
after that you only append to the INPUT-chain - which is already set to DROP
You may have meant to set a policy of DROP and then selectively open it?
| Code: | | iptables -P INPUT DROP |
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Mon Aug 31, 2009 4:45 pm Post subject: |
|
|
Ok, so I changed iptables -A INPUT DROP, to use iptables -P INPUT DROP which makes sense, and seemed to solve the ping problems that I was having. Now, I am having trouble with nmblookup, I run the command: nmblookup -d 5 machine1 which debugs the machine1 should return the machines ip address as well, right? Well as of now, nmblookup is failing, when it queries machine 1 and returns this message..querying neo1 on 192.168.x.x(brdcastip)......Sending a packet of len 50 to (brdcastip) on port 137
Sending a packet of len 50 to (brdcastip) on port 137
Sending a packet of len 50 to (brdcastip) on port 137
name_query failed to find name machine1
any suggestions on what I could now in this instance.
I appreciate you helping me with this situation!!
Thanks,
Thomas Clark
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Mon Aug 31, 2009 5:04 pm Post subject: |
|
|
I'm not proficient - only suggesting.
Not much more I can do - just spotted the glitch in the first post.
If someone knows better - please do correct!
The ports to open would be 137, 138, 139 and 445 - for both UDP and TCP.
I'm not sure if both protocols are really needed or if eighter one is enough.
You used UDP for 137, 138 and TCP for 139, 445.
Is "brdcastip" allowed in?
| Quote: | | Sending a packet of len 50 to (brdcastip) on port 137 |
Maybe this can help?
http://troy.jdmz.net/samba/fw/
Just the first hit at google with terms: samba tcp udp ports
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Mon Aug 31, 2009 5:13 pm Post subject: |
|
|
brdcastip is and actual value like 192.168.x.x for example, but yes it is allowed in...
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Mon Aug 31, 2009 5:28 pm Post subject: |
|
|
broadcast is x.x.x.255 while normal IP's are usually not x.x.x.0 or x.x.x.1 - but everything in between up to x.x.x.254.
Did you allow the whole range like so for example?
| Code: | | iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 137 -j ACCEPT |
With the actual values commented out in the script you posted one cannot be sure about this...
These are local only IP's - don't worry too much about posting them...
BTW: using "-p udp -m udp" is redundant
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Mon Aug 31, 2009 5:53 pm Post subject: |
|
|
yeah those netwrok addresses aren't commented out anymore..And the thing still wont allow me to perform the command nmblookup, which needs to work. From what I have read, I shouldn't be able to ping, if nmblookup isnt working, but I can ping the machines. Weird to me!
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Mon Aug 31, 2009 6:06 pm Post subject: |
|
|
| Quote: | | yeah those netwrok addresses aren't commented out anymore. |
I meant the script you posted - your first post. There are no real adresses in there - just the word "ipaddresses" instead.
...don't know what you mean with:
| Quote: | | From what I have read, I shouldn't be able to ping, if nmblookup isnt working, but I can ping the machines. |
You have:
| Code: | | iptables -I INPUT -p icmp -j ACCEPT |
in your scripts rules - so ping is allowed.
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Mon Aug 31, 2009 6:26 pm Post subject: |
|
|
#!/bin/sh
export LAN=eth0
#setup logging
#iptables -N logdrop_I
#iptables -A logdrop_I -j LOG --log-prefix "DROP INPUT PACKET"
#iptables -A logdrop_I -j DROP
iptables --flush
iptables --delete-chain
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i ! ${LAN} -j ACCEPT
#http
iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT
#ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#samba
iptables -A INPUT -p udp -m udp --dport 137 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 138 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 139 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 139 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 445 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 137 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 138 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 445 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 445 -j ACCEPT
#ftp
iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
#domain
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
#ping
iptables -I INPUT -p icmp -j ACCEPT
#output
iptables -A OUTPUT -j ACCEPT
#log
#iptables -A INPUT -p tcp -m tcpmulti --dport 22,20,21,53,80,139,445 -j LOG --log-prefix "DROP PACKET:"
#iptables -A INPUT -p udp -m udpmulti --dport 137,138 -j LOG --log-prefix "DROP PACKET:"
iptables -A INPUT -p udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info
iptables -A OUTPUT -p tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
iptables -A OUTPUT -p udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info
#iptables -A OUTPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info
#reject everything else
#iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
/etc/init.d/iptables save
is the script that I have, kind sir!
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Mon Aug 31, 2009 7:45 pm Post subject: |
|
|
May I suggest to use the "Code" button next time you post code - it looks better and is more readable 
Sorry for saying this but: your script is unneccesarily complicated with a lot of redundancy and unused/commented out things.
I'm suggesting this:
| Code: | #!/bin/sh
export LAN=eth0
iptables -F
# set a policy of DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
# allow local-only connections
iptables -A INPUT -i lo -j ACCEPT
# free output on any interface to any ip for any service (equal to -P ACCEPT)
iptables -A OUTPUT ACCEPT
# ACCEPT everything not from the LAN? Whats this for?
iptables -A INPUT -i ! ${LAN} -j ACCEPT
# permit answers on already established connections
# and permit new connections related to established ones (eg active-ftp)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# http - are you running a webserver?
# Then port 443 is missing...and ONE specific adress instead of /24 should suffice
# iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/24 -p tcp -m state --state NEW --dport 80 -j ACCEPT
#ssh
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# samba
# accept udp and tcp on all its ports - or do it more selectively if needed
iptables -A INPUT -p udp --dport 137:139 -j ACCEPT
iptables -A INPUT -p tcp --dport 137:139 -j ACCEPT
iptables -A INPUT -p udp --dport 445 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -j ACCEPT
# FTP if you run a server - can use a wider range in the second line
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 20:21 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --destination-ports 20000:20020 -j ACCEPT
# domain - here I changed -sport (in your script) to -dport in the second line
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# ping
iptables -I INPUT -p icmp -j ACCEPT
# Log everything else - before it is getting rejected by the next rule
# or - if not catched - according to the policy
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "
#reject everything else
iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
# maybe this too - or is this done by your init-scripts?
# /etc/init.d/iptables save |
All needed (and some for the task unneeded) ports are open - problems should be not with iptables anymore but rather with samba itself.
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Mon Aug 31, 2009 8:27 pm Post subject: |
|
|
I'm gonna try it out and see what happens. As far as, apologizing about my code, I wouldn't worry to much about that, as we learn from trial and error. I will let you know if this helps. So you are saying that if this doesn't work, then I may have an issue with samba altogether? I surely hope that is not the case, but I guess we shall see, ey?
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Mon Aug 31, 2009 8:36 pm Post subject: |
|
|
| Quote: | | I wouldn't worry to much about that, as we learn from trial and error |
right - no need to apologise - I did'nt mean it like that
If you are not sure whether your samba or your script is not working as it should, why not disable the firewall completely while testing and configuring samba?
Is that not an option?
Then you know it is working and the firewall is preventing something which was working o.k. without.
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Tue Sep 01, 2009 2:53 pm Post subject: |
|
|
Ok, so I tried all of your suggestions, I stopped the firewall altogether, and tried using.. | Code: | | nmblookup -d 5 neo1 |
and the respone returned | Code: | querying neo1 on 192.168.0.255
Sending a packet of len 50 to (192.168.0.255) on port 137
Received a packet of len 62 from (192.168.0.1) port 137
nmb packet from 192.168.0.1(137) header: id=622 opcode=Query(0) response=Yes
header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes
header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0
answers: nmb_name=NEO1<00> rr_type=32 rr_class=1 ttl=300000
answers 0 char ...... hex 0000C0A80001
Got a positive name query response from 192.168.0.1 ( 192.168.0.1 )
192.168.0.1 neo1<00> |
So, I would say that samba works fine when the firewall is down, after I did that I turned the firewall back up and tried using my nmblookup command and I get the name_query error. I'm not sure what is going on. Bear in mind that I am trying to use your suggested script and it is still not working...Any more suggestions? Anyone?
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Tue Sep 01, 2009 7:53 pm Post subject: |
|
|
wierd - when I ran the script - I could not even ping my Gateway - not even after flushing all the chains (iptables -F)
That clearly shows that I'm in over my head here - but learning myself while at it.
anyway
The samba server runs on the machine with the firewall - yes?
Which machines IP is 192.168.0.1 ? - it is the Gateway
I may have overlooked something - can you try replacing the "samba" portion first with this :
| Code: | # samba
# accept udp and tcp on all its ports - or do it more selectively if needed
iptables -A INPUT -p udp -m state --state NEW --dport 137:139 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 137:139 -j ACCEPT
iptables -A INPUT -p udp -m state --state NEW --dport 445 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 445 -j ACCEPT |
and then with this (YOURIP is the outside machine trying to connect)
| Code: | # samba
# accept udp and tcp on all its ports - or do it more selectively if needed
iptables -A INPUT -s YOURIP -p udp -m state --state NEW --dport 137:139 -j ACCEPT
iptables -A INPUT -s YOURIP -p tcp -m state --state NEW --dport 137:139 -j ACCEPT
iptables -A INPUT -s YOURIP -p udp -m state --state NEW --dport 445 -j ACCEPT
iptables -A INPUT -s YOURIP -p tcp -m state --state NEW --dport 445 -j ACCEPT |
and see if and which one is working
Is there anything in the system-log (/var/log/messages) when the script is active and a connection is tried
(dropped packets _are_ logged before)?
_________________
Cheers |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Wed Sep 02, 2009 12:53 am Post subject: |
|
|
| Flushing a chain does not clear any associated policy. Since you are (correctly) using policy to decide the final action for unmatched packets, flushing all chains means the policy applies to all packets. The simplest path forward would be to lower the firewall, start net-analyzer/tcpdump with the appropriate options, run your desired query, and then examine the resulting packet capture to find exactly which protocols and ports are required. We can then write rules to permit those. |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Wed Sep 02, 2009 1:49 am Post subject: |
|
|
well - Tank you! 
| Quote: | | ...flushing all chains means the policy applies to all packets. |
I have my own firewall script here.
If I run it - instead of the one posted here - everything is working again (for me).
...it re - sets the policy as the first thing - just like this one...
tcpdump is a good idea - the logs (the dropped packets according to the script) should provide similar info.
But only the OP can run that diagnosis and I'm not prepared to suggest that to him - because I can't do much more than a guess ... with the results.
What do you think is causing this script blocking a ping to 192.168.0.1 - or any connection to it/from it.
I don't understand how anything can be left after flushing all the chains.
If I flush all the chains - the policy set at the start still persists?
Why? - Can you provide a reference? (not that I doubt it - it is obviously so... but what info did I miss?)
It appears logical though
How would I clear/wipe the policy (which is set to DROP everything not allowed)?
set it to ACCEPT
| Code: |
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT |
when shutting down the script?
_________________
Cheers |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Wed Sep 02, 2009 6:43 pm Post subject: |
|
|
yea the machine with the firewall is also the machine that has samba on it. As far as the suggestion go, trying your samba script does work when I run it the machine freezes up and I have to reboot to get in via ssh..I have tried | Code: | | tcpdump -1 etho host 192.168.0.1 |
nothing happens it says listening on that, but it just sits there I let it sit for about 30 minutes and nothing happened...I'm so lost at this point, I just need this to work!! I didn't figure how complicated this turned out to be on what should have been relatively simple..
_________________
Mr. Clark |
|
| Back to top |
|
|
jomen
Guru
Joined: 04 Jan 2006
Posts: 536
Location: Leipzig, Germany
|
| Posted: Wed Sep 02, 2009 8:09 pm Post subject: |
|
|
The tcpdump-command you posted is no good - and it should have given you an error - or the usage instructions instead.
"-1" is not a valid switch - if it was "-I" then: no need for that if run as root - which I'd suggest
etho is not valid - it would be eth0 instead
| Code: | | tcpdump -ni eth0 ip host 192.168.0.1 |
or
| Code: | | tcpdump -ni eth0 ip host 192.168.0.1 -s 0 -A |
would be working I suppose
| Quote: | | ...trying your samba script does work |
I think you really mean it doesn't, don't you?
| Quote: | | ...when I run it the machine freezes up and I have to reboot to get in via ssh..I have tried |
if it really freezes - it is NOT the fault of the script - if you only can't get in, run:
plus the three commands from my previous post - it will open up the firewall completely by setting a new policy of ACCEPT everything
[edit] what about the system logs? (/var/log/messages) - on the machine running the firewall
| Code: | | watch tail /var/log/messages |
should do
or
CTRL+ALT+F12 to get to it (CTRL+ALT+F7 to get back to xour X session)
_________________
Cheers |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Wed Sep 02, 2009 10:27 pm Post subject: |
|
|
| jomen wrote: | tcpdump is a good idea - the logs (the dropped packets according to the script) should provide similar info.
But only the OP can run that diagnosis and I'm not prepared to suggest that to him - because I can't do much more than a guess ... with the results. |
I can probably do a useful job with the results of the packet capture. I suggested tcpdump instead of the logs on the theory that the proposed rules may be overly permissive in some areas, as well as being overly restrictive in others. The logs will tell us where the rules are overly restrictive, but only the packet capture will let us identify the minimum set of rules required to permit the desired traffic and nothing further.
The original poster's script as posted looks wrong in several areas. For example, why does it permit all non-LAN traffic right at the start? Usually a LAN is the trusted area and the WAN is the untrusted area. Why log the dropped packets multiple times if they are sent to select ports?
| jomen wrote: | | What do you think is causing this script blocking a ping to 192.168.0.1 - or any connection to it/from it. |
Ping ought to work, as the script explicitly allows ICMP. It is possible, though not likely, that the machine has been set to ignore all ICMP echo requests, in which case letting them through the firewall would be insufficient. At this point, I think seeing the output of iptables-save -c would be more helpful than seeing the revised script. It will show us the rules as actually loaded.
| jomen wrote: | I don't understand how anything can be left after flushing all the chains.
If I flush all the chains - the policy set at the start still persists? |
Nothing is left. The policy is not a rule, but a default action.
| jomen wrote: | | Why? - Can you provide a reference? (not that I doubt it - it is obviously so... but what info did I miss?) |
The iptables man page hints at this by its lack of wording to the contrary. Specifically, it says: This is equivalent to deleting all the rules one by one. Since the policy is not a rule and cannot be deleted, it is exempt from the flush.
| jomen wrote: | How would I clear/wipe the policy (which is set to DROP everything not allowed)?
set it to ACCEPT
| Code: |
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT |
when shutting down the script? |
You must always have some policy. Changing the policy to ACCEPT will make the rules be most like they were when you first booted.
Technically, the policy applies to any packet which reaches the end of the chain. Accepting a packet stops its traversal of the chain. You can also explicitly DROP or REJECT packets using a rule in the chain, which could be useful in some cases. Rejecting a packet does not allow it, but does prevent it from reaching the end of the chain where policy would apply. Suppose you have a subnet of 256 hosts, of which two should be rejected. All the others should be allowed, and any traffic not from that subnet should be dropped. The simplest way to write that is with:iptables -P INPUT DROP ; iptables -A INPUT -s badhost1 -j REJECT ; iptables -A INPUT -s badhost2 -j REJECT ; iptables -A -s goodsubnet/24 -j ACCEPT. |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Wed Sep 09, 2009 4:00 pm Post subject: |
|
|
[post=][/post]This is still a problem for me. I have tried to revise the script several times and it produces the same results the firewall starts up fine, with the exception of the name query issue. I am not sure what the problem is here but someone said that seeing the output of iptables-save -c would help to find the problem.
| Quote: | | At this point, I think seeing the output of iptables-save -c would be more helpful than seeing the revised script. It will show us the rules as actually loaded. |
Here's that info
| Code: | :OUTPUT ACCEPT [2910:330879]
COMMIT
# Completed on Wed Sep 9 11:03:14 2009
# Generated by iptables-save v1.4.2 on Wed Sep 9 11:03:14 2009
*mangle
:PREROUTING ACCEPT [318788:50015830]
:INPUT ACCEPT [318788:50015830]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [219435:432498110]
:POSTROUTING ACCEPT [220907:432827405]
COMMIT
# Completed on Wed Sep 9 11:03:14 2009
# Generated by iptables-save v1.4.2 on Wed Sep 9 11:03:14 2009
*filter
:INPUT DROP [24021:2391169]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [0:0]
[238:14948] -A INPUT -p icmp -j ACCEPT
[0:0] -A INPUT -i ! eth0 -j ACCEPT
[0:0] -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
[5207:428542] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
[5820:467334] -A INPUT -p udp -m udp --dport 137 -j ACCEPT
[2700:636789] -A INPUT -p udp -m udp --dport 138 -j ACCEPT
[41584:6990058] -A INPUT -p tcp -m tcp --dport 139 -j ACCEPT
[0:0] -A INPUT -p udp -m udp --dport 139 -j ACCEPT
[0:0] -A INPUT -p udp -m udp --dport 445 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 137 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 138 -j ACCEPT
[238945:39054550] -A INPUT -p tcp -m tcp --dport 445 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
[132:18400] -A INPUT -p udp -m udp --sport 53 -j ACCEPT
[0:0] -A INPUT -p udp -m udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level 6
[0:0] -A INPUT -p tcp -m tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level 6
[0:0] -A INPUT -p tcp -m tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level 6
[9660:555500] -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level 6
[219325:432484126] -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -j ACCEPT
[0:0] -A OUTPUT -p tcp -m tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6
[0:0] -A OUTPUT -p tcp -m tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6
[0:0] -A OUTPUT -p udp -m udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6
[0:0] -A OUTPUT -p udp -m udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6
COMMIT
# Completed on Wed Sep 9 11:03:14 2009 |
After seeing this I am still not 100 percent
_________________
Mr. Clark |
|
| Back to top |
|
|
mrclark219
n00b
Joined: 27 Aug 2009
Posts: 14
|
| Posted: Tue Sep 15, 2009 5:50 pm Post subject: |
|
|
any suggestions?
_________________
Mr. Clark |
|
| Back to top |
|
|
|
Networking & Security
