Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #167034 > unrolled thread
| Started by | Harris Paltrowitz <harrisupstate@yahoo.com> |
|---|---|
| First post | 2016-04-23 19:10 +0200 |
| Last post | 2016-04-27 13:50 +0200 |
| Articles | 10 — 7 participants |
Back to article view | Back to linux.debian.user
Firewall - basic config? Harris Paltrowitz <harrisupstate@yahoo.com> - 2016-04-23 19:10 +0200
Re: Firewall - basic config? Reco <recoverym4n@gmail.com> - 2016-04-23 20:10 +0200
Re: Firewall - basic config? Michael Milliman <michael.e.milliman@gmail.com> - 2016-04-24 07:20 +0200
Re: Firewall - basic config? Reco <recoverym4n@gmail.com> - 2016-04-24 11:00 +0200
Re: Firewall - basic config? Michael Milliman <michael.e.milliman@gmail.com> - 2016-04-26 04:10 +0200
Re: Firewall - basic config? Joe <joe@jretrading.com> - 2016-04-23 22:00 +0200
Re: Firewall - basic config? shawn wilson <ag4ve.us@gmail.com> - 2016-04-25 15:50 +0200
Re: Firewall - basic config? cbannister@slingshot.co.nz - 2016-04-27 10:40 +0200
Re: Firewall - basic config? Jonathan Dowland <jmtd@debian.org> - 2016-04-27 11:30 +0200
Re: Firewall - basic config? Harris Paltrowitz <harrisupstate@yahoo.com> - 2016-04-27 13:50 +0200
| From | Harris Paltrowitz <harrisupstate@yahoo.com> |
|---|---|
| Date | 2016-04-23 19:10 +0200 |
| Subject | Firewall - basic config? |
| Message-ID | <rr9ea-6Ge-9@gated-at.bofh.it> |
Hi List, I have a question regarding how I've configured my iptables to act as a very basic "firewall", i.e., one that simply prevents any and all incoming connections. Now, from my readings over the past several days I think I've learned that at least some of my outgoing requests will have responses that should be allowed to come back in -- but aside from that, I essentially want my firewall to act in a very "default" method, i.e., the way a complete neophyte would expect his or her firewall to work within Windows or Mac. Here's what I did -- I will also paste the results of my current "iptables -L" command... I hope the text block is not too large... 1. First, my issue with manually configuring iptables is not the complexity of it, per se -- but the fact that I want to avoid having my newness to it prevent me from setting it up in an insecure manner. So... 2. I found that "ufw" works as a line-command-based-front-end to iptables. I also came across "gufw" in my travels, and I even tried it, but I've since gleaned that all that's really needed in ufw to completely mimic the basic functionality of gufw is to (a) install ufw, and (b) enable it -- one does not even need to establish the default policies, although the Debian wiki page incorrectly states that this is necessary. 3. So after having installed and enabled ufw, here's the output of my "iptables -L" command. I noticed a mention of "microsoft-ds" in there... I assume this is just a protocol, and not a piece of software! Any suggestions/comments would be much appreciated. Thanks very much. Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anywhere ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywhere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ufw-before-logging-forward all -- anywhere anywhere ufw-before-forward all -- anywhere anywhere ufw-after-forward all -- anywhere anywhere ufw-after-logging-forward all -- anywhere anywhere ufw-reject-forward all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ufw-before-logging-output all -- anywhere anywhere ufw-before-output all -- anywhere anywhere ufw-after-output all -- anywhere anywhere ufw-after-logging-output all -- anywhere anywhere ufw-reject-output all -- anywhere anywhere ufw-track-output all -- anywhere anywhere Chain ufw-after-forward (1 references) target prot opt source destination Chain ufw-after-input (1 references) target prot opt source destination ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST Chain ufw-after-logging-forward (1 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] " Chain ufw-after-logging-input (1 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] " Chain ufw-after-logging-output (1 references) target prot opt source destination Chain ufw-after-output (1 references) target prot opt source destination Chain ufw-before-forward (1 references) target prot opt source destination ufw-user-forward all -- anywhere anywhere Chain ufw-before-input (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ufw-logging-deny all -- anywhere anywhere state INVALID DROP all -- anywhere anywhere state INVALID ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp source-quench ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc ufw-not-local all -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900 ufw-user-input all -- anywhere anywhere Chain ufw-before-logging-forward (1 references) target prot opt source destination Chain ufw-before-logging-input (1 references) target prot opt source destination Chain ufw-before-logging-output (1 references) target prot opt source destination Chain ufw-before-output (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ufw-user-output all -- anywhere anywhere Chain ufw-logging-allow (0 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] " Chain ufw-logging-deny (2 references) target prot opt source destination RETURN all -- anywhere anywhere state INVALID limit: avg 3/min burst 10 LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] " Chain ufw-not-local (1 references) target prot opt source destination RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10 DROP all -- anywhere anywhere Chain ufw-reject-forward (1 references) target prot opt source destination Chain ufw-reject-input (1 references) target prot opt source destination Chain ufw-reject-output (1 references) target prot opt source destination Chain ufw-skip-to-policy-forward (0 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-input (7 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-output (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain ufw-track-input (1 references) target prot opt source destination Chain ufw-track-output (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state NEW ACCEPT udp -- anywhere anywhere state NEW Chain ufw-user-forward (1 references) target prot opt source destination Chain ufw-user-input (1 references) target prot opt source destination Chain ufw-user-limit (0 references) target prot opt source destination LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning prefix "[UFW LIMIT BLOCK] " REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain ufw-user-limit-accept (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain ufw-user-logging-forward (0 references) target prot opt source destination Chain ufw-user-logging-input (0 references) target prot opt source destination Chain ufw-user-logging-output (0 references) target prot opt source destination Chain ufw-user-output (1 references) target prot opt source destination -end of posting
[toc] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-04-23 20:10 +0200 |
| Message-ID | <rraaf-7rl-29@gated-at.bofh.it> |
| In reply to | #167034 |
Hi. On Sat, 23 Apr 2016 13:04:36 -0400 Harris Paltrowitz <harrisupstate@yahoo.com> wrote: > Hi List, > > I have a question regarding how I've configured my iptables to act as a > very basic "firewall", i.e., one that simply prevents any and all > incoming connections. Now, from my readings over the past several days > I think I've learned that at least some of my outgoing requests will > have responses that should be allowed to come back in -- but aside from > that, I essentially want my firewall to act in a very "default" method, > i.e., the way a complete neophyte would expect his or her firewall to > work within Windows or Mac. > > Here's what I did -- I will also paste the results of my current > "iptables -L" command... I hope the text block is not too large... No, it's not large. Somewhat complex, but that's the price to pay for using ufw. For the reference, the simpliest possible set of netfilter rules that does what you want is (assuming static IP assignment, no DHCP): iptables -F INPUT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT iptables -A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED \ -j ACCEPT iptables -A INPUT -p udp -m conntrack --ctstate RELATED,ESTABLISHED \ -j ACCEPT iptables -P INPUT DROP iptables -F FORWARD iptables -P FORWARD DROP iptables -F OUTPUT iptables -P OUTPUT ACCEPT > 1. First, my issue with manually configuring iptables is not the > complexity of it, per se -- but the fact that I want to avoid having my > newness to it prevent me from setting it up in an insecure manner. So... You already allowed more holes in INPUT chain that you described. > 2. I found that "ufw" works as a line-command-based-front-end to > iptables. I also came across "gufw" in my travels, and I even tried it, > but I've since gleaned that all that's really needed in ufw to > completely mimic the basic functionality of gufw is to (a) install ufw, > and (b) enable it -- one does not even need to establish the default > policies, although the Debian wiki page incorrectly states that this is > necessary. There are numerous frontends to iptables. IMO they do simple things complex way and require really strange kludges to do complex things. Your iptables is an excellent example of the first of those approaches. If 'raw' iptables are not your cup of tea - consider using firewalld and firewall-applet. > 3. So after having installed and enabled ufw, here's the output of my > "iptables -L" command. I noticed a mention of "microsoft-ds" in > there... I assume this is just a protocol, and not a piece of > software! Indeed it's a protocol. I prefer 'iptables -nvL' or straightforward 'iptables-save' in such cases. > Any suggestions/comments would be much appreciated. Thanks > very much. Assuming you'd want to keep ufw, you'd need to worry about: > Chain ufw-after-input (1 references) > target prot opt source destination > ufw-skip-to-policy-input udp -- anywhere anywhere udp > dpt:netbios-ns > ufw-skip-to-policy-input udp -- anywhere anywhere udp > dpt:netbios-dgm > ufw-skip-to-policy-input tcp -- anywhere anywhere tcp > dpt:netbios-ssn > ufw-skip-to-policy-input tcp -- anywhere anywhere tcp > dpt:microsoft-ds There's no reason to accept these unless you're using Samba (either the server or client). > ufw-skip-to-policy-input udp -- anywhere anywhere udp > dpt:bootps There's no reason to allow udp:67 unless you're a DHCP server. > ufw-skip-to-policy-input udp -- anywhere anywhere udp > dpt:bootpc Have some use for DHCP client, but this rule is unnecessary weak. > ACCEPT udp -- anywhere anywhere udp > spt:bootps dpt:bootpc So, first they compose a perfectly good rule for DHCP client (ufw-before-input chain), but then they allow udp:68 unconditionally in ufw-after-input chain. I'll assume that something very clever is going on here. > ufw-not-local all -- anywhere anywhere > ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns Useful for Avahi users, no reason to allow this otherwise. > ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900 > ufw-user-input all -- anywhere anywhere No reason to allow UPnP unless you're planning to use this host as a firewall/router. All other rules have nothing to catch my eye. Reco
[toc] | [prev] | [next] | [standalone]
| From | Michael Milliman <michael.e.milliman@gmail.com> |
|---|---|
| Date | 2016-04-24 07:20 +0200 |
| Message-ID | <rrkCB-7Fn-1@gated-at.bofh.it> |
| In reply to | #167040 |
On 04/23/2016 01:01 PM, Reco wrote: > Hi. > > On Sat, 23 Apr 2016 13:04:36 -0400 > Harris Paltrowitz <harrisupstate@yahoo.com> wrote: > >> Hi List, >> >> I have a question regarding how I've configured my iptables to act as a >> very basic "firewall", i.e., one that simply prevents any and all >> incoming connections. Now, from my readings over the past several days >> I think I've learned that at least some of my outgoing requests will >> have responses that should be allowed to come back in -- but aside from >> that, I essentially want my firewall to act in a very "default" method, >> i.e., the way a complete neophyte would expect his or her firewall to >> work within Windows or Mac. >> >> Here's what I did -- I will also paste the results of my current >> "iptables -L" command... I hope the text block is not too large... > No, it's not large. Somewhat complex, but that's the price to pay for > using ufw. > > For the reference, the simpliest possible set of netfilter rules that > does what you want is (assuming static IP assignment, no DHCP): > > iptables -F INPUT > iptables -A INPUT -i lo -j ACCEPT > iptables -A INPUT -m conntrack --ctstate INVALID -j DROP > iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT > iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT > iptables -A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED \ > -j ACCEPT > iptables -A INPUT -p udp -m conntrack --ctstate RELATED,ESTABLISHED \ > -j ACCEPT > iptables -P INPUT DROP > iptables -F FORWARD > iptables -P FORWARD DROP > iptables -F OUTPUT > iptables -P OUTPUT ACCEPT > > >> 1. First, my issue with manually configuring iptables is not the >> complexity of it, per se -- but the fact that I want to avoid having my >> newness to it prevent me from setting it up in an insecure manner. So... > You already allowed more holes in INPUT chain that you described. > > >> 2. I found that "ufw" works as a line-command-based-front-end to >> iptables. I also came across "gufw" in my travels, and I even tried it, >> but I've since gleaned that all that's really needed in ufw to >> completely mimic the basic functionality of gufw is to (a) install ufw, >> and (b) enable it -- one does not even need to establish the default >> policies, although the Debian wiki page incorrectly states that this is >> necessary. > There are numerous frontends to iptables. IMO they do simple things > complex way and require really strange kludges to do complex things. > Your iptables is an excellent example of the first of those approaches. > > If 'raw' iptables are not your cup of tea - consider using firewalld > and firewall-applet. > > >> 3. So after having installed and enabled ufw, here's the output of my >> "iptables -L" command. I noticed a mention of "microsoft-ds" in >> there... I assume this is just a protocol, and not a piece of >> software! > Indeed it's a protocol. I prefer 'iptables -nvL' or straightforward > 'iptables-save' in such cases. > >> Any suggestions/comments would be much appreciated. Thanks >> very much. > Assuming you'd want to keep ufw, you'd need to worry about: > >> Chain ufw-after-input (1 references) >> target prot opt source destination >> ufw-skip-to-policy-input udp -- anywhere anywhere udp >> dpt:netbios-ns >> ufw-skip-to-policy-input udp -- anywhere anywhere udp >> dpt:netbios-dgm >> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp >> dpt:netbios-ssn >> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp >> dpt:microsoft-ds > There's no reason to accept these unless you're using Samba (either > the server or client). However, if you look at the ufw-skip-to-policy-input chain, it simply DROPs everything, so there is no hole here, as far as I can tell. Indeed, this chain specifies all protocols, from anywhere to anywhere, target DROP. So, in the end, all packets to these destination ports (dpt) are DROPed. >> ufw-skip-to-policy-input udp -- anywhere anywhere udp >> dpt:bootps > There's no reason to allow udp:67 unless you're a DHCP server. Again, see above, ufw-skip-to-policy-input will DROP these packets. > >> ufw-skip-to-policy-input udp -- anywhere anywhere udp >> dpt:bootpc > Have some use for DHCP client, but this rule is unnecessary weak. See above. > > >> ACCEPT udp -- anywhere anywhere udp >> spt:bootps dpt:bootpc > So, first they compose a perfectly good rule for DHCP client > (ufw-before-input chain), but then they allow udp:68 unconditionally in > ufw-after-input chain. I'll assume that something very clever is going > on here. Correct me if I'm wrong, however, the ufw-before-input chain concerns me greatly. The first rule here ACCEPTs all packets of all protocols coming from anywhere and going to anywhere. This appears to be an incredibly big hole. The above rule Reco mentions, will never be seen as it is quite a bit further down the chain, after everything has already been ACCEPTed. Surely, I'm reading something wrong?:-\ > >> ufw-not-local all -- anywhere anywhere >> ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns > Useful for Avahi users, no reason to allow this otherwise. > >> ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900 >> ufw-user-input all -- anywhere anywhere > No reason to allow UPnP unless you're planning to use this host as a > firewall/router. > > > All other rules have nothing to catch my eye. > > Reco > The INPUT chain seems to be problematic to me. As noted above, the ufw-before-input chain seems to ACCEPT everything in its first rule, so none of the other rules in the INPUT chain will have any effect. The OUTPUT chain seems to be the same way, though this is not as problematic for me, as usually, you will want to allow just about anything in the OUTPUT chain. Though, I suspect that this could allow an exploit wherein the user's machine is used to originate undesired packets heading out to the net. The FORWARD chain looks to be secure, as ultimately the default DROP policy for that chain is what happens to everything. Again, while I have done some studying of iptables, and think that I am fluent in the incantations necessary to set it up, I am not an expert, so if I have mis-interpreted the OPs provided iptables listing, please correct me for both my and his benefit!! -- Mike
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2016-04-24 11:00 +0200 |
| Message-ID | <rro3v-1Ak-9@gated-at.bofh.it> |
| In reply to | #167046 |
On Sun, 24 Apr 2016 00:17:51 -0500 Michael Milliman <michael.e.milliman@gmail.com> wrote: > >> Any suggestions/comments would be much appreciated. Thanks > >> very much. > > Assuming you'd want to keep ufw, you'd need to worry about: > > > >> Chain ufw-after-input (1 references) > >> target prot opt source destination > >> ufw-skip-to-policy-input udp -- anywhere anywhere udp > >> dpt:netbios-ns > >> ufw-skip-to-policy-input udp -- anywhere anywhere udp > >> dpt:netbios-dgm > >> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp > >> dpt:netbios-ssn > >> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp > >> dpt:microsoft-ds > > There's no reason to accept these unless you're using Samba (either > > the server or client). > However, if you look at the ufw-skip-to-policy-input chain, it simply > DROPs everything, so there is no hole here, as far as I can tell. > Indeed, this chain specifies all protocols, from anywhere to anywhere, > target DROP. So, in the end, all packets to these destination ports > (dpt) are DROPed. Good catch. I agree here. Although it would help to see if these rules apply to a certain network interface (see below). > >> ACCEPT udp -- anywhere anywhere udp > >> spt:bootps dpt:bootpc > > So, first they compose a perfectly good rule for DHCP client > > (ufw-before-input chain), but then they allow udp:68 unconditionally in > > ufw-after-input chain. I'll assume that something very clever is going > > on here. > Correct me if I'm wrong, however, the ufw-before-input chain concerns me > greatly. The first rule here ACCEPTs all packets of all protocols > coming from anywhere and going to anywhere. This appears to be an > incredibly big hole. The above rule Reco mentions, will never be seen > as it is quite a bit further down the chain, after everything has > already been ACCEPTed. Surely, I'm reading something wrong?:-\ I believe this to be an artifact of 'iptables -L', and the actual rule refers to lo interface only. For example, on my system this scary rule: # iptables -nL INPUT | head -3 ... ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Actually means this: # iptables -nvL INPUT | head -3 ... ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 Reco
[toc] | [prev] | [next] | [standalone]
| From | Michael Milliman <michael.e.milliman@gmail.com> |
|---|---|
| Date | 2016-04-26 04:10 +0200 |
| Message-ID | <rs0BQ-7Xv-13@gated-at.bofh.it> |
| In reply to | #167047 |
On 04/24/2016 03:56 AM, Reco wrote: > On Sun, 24 Apr 2016 00:17:51 -0500 > Michael Milliman <michael.e.milliman@gmail.com> wrote: >>>> Any suggestions/comments would be much appreciated. Thanks >>>> very much. >>> Assuming you'd want to keep ufw, you'd need to worry about: >>> >>>> Chain ufw-after-input (1 references) >>>> target prot opt source destination >>>> ufw-skip-to-policy-input udp -- anywhere anywhere udp >>>> dpt:netbios-ns >>>> ufw-skip-to-policy-input udp -- anywhere anywhere udp >>>> dpt:netbios-dgm >>>> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp >>>> dpt:netbios-ssn >>>> ufw-skip-to-policy-input tcp -- anywhere anywhere tcp >>>> dpt:microsoft-ds >>> There's no reason to accept these unless you're using Samba (either >>> the server or client). >> However, if you look at the ufw-skip-to-policy-input chain, it simply >> DROPs everything, so there is no hole here, as far as I can tell. >> Indeed, this chain specifies all protocols, from anywhere to anywhere, >> target DROP. So, in the end, all packets to these destination ports >> (dpt) are DROPed. > Good catch. I agree here. Although it would help to see if these rules > apply to a certain network interface (see below). > > >>>> ACCEPT udp -- anywhere anywhere udp >>>> spt:bootps dpt:bootpc >>> So, first they compose a perfectly good rule for DHCP client >>> (ufw-before-input chain), but then they allow udp:68 unconditionally in >>> ufw-after-input chain. I'll assume that something very clever is going >>> on here. >> Correct me if I'm wrong, however, the ufw-before-input chain concerns me >> greatly. The first rule here ACCEPTs all packets of all protocols >> coming from anywhere and going to anywhere. This appears to be an >> incredibly big hole. The above rule Reco mentions, will never be seen >> as it is quite a bit further down the chain, after everything has >> already been ACCEPTed. Surely, I'm reading something wrong?:-\ > I believe this to be an artifact of 'iptables -L', and the actual rule > refers to lo interface only. For example, on my system this scary rule: > > # iptables -nL INPUT | head -3 > ... > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > > Actually means this: > > # iptables -nvL INPUT | head -3 > ... > ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 > > Reco Yes, I missed that the iptables -L doesn't give the interface that a particular rule applies to. The iptables -L -v command would be more informative. -- Mike
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2016-04-23 22:00 +0200 |
| Message-ID | <rrbSG-ev-9@gated-at.bofh.it> |
| In reply to | #167034 |
On Sat, 23 Apr 2016 13:04:36 -0400 Harris Paltrowitz <harrisupstate@yahoo.com> wrote: > I noticed a mention of "microsoft-ds" in > there... I assume this is just a protocol, and not a piece of > software! Yes, iptables is being helpful in giving you a common name for the port or protocol used. It picks the name out of /etc/services, which is a useful file to know about. There is also an /etc/protocols, which is a list of actual IP protocols, but this is not as generally useful, tcp, udp and icmp are the commonly-used ones. Many VPNs use other IP protocols to carry the encrypted traffic. Reco suggests using iptables -nvL which will give numeric IP addresses and CIDR ranges, and avoid looking up either service names or DNS. You might also try iptables -S which will list the rules in the form that you would enter by hand as arguments to the iptables command. It is a different view, and you may see things that are less obvious in the -L view. Remember that IPv6 is alive and well in quite a lot of hardware these days, and there is an ip6tables to deal with it. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | shawn wilson <ag4ve.us@gmail.com> |
|---|---|
| Date | 2016-04-25 15:50 +0200 |
| Message-ID | <rrP3J-6Kr-7@gated-at.bofh.it> |
| In reply to | #167043 |
[Multipart message — attachments visible in raw view] — view raw
On Apr 23, 2016 3:54 PM, "Joe" <joe@jretrading.com> wrote: > . > > You might also try iptables -S which will list the rules in the form > that you would enter by hand as arguments to the iptables command. It is > a different view, and you may see things that are less obvious in the > -L view. > I'm guessing -S is the same as iptables-save...? If so, then yes that's the way to look at rules and what you want to paste when asking for help. There are two times when I went nL output - when testing and want a delete number (so with the --line-numbers option) and when I think a table is useless and want to call reference count. That's literally it. Otherwise you probably want to see the rules closer to how the kernel does. Also, if you script your restore (I'm guessing ufw handles this... properly) do use a restore file vs looping the iptables command for each rule - besides being proper, it's also a *hell* of a lot faster. > Remember that IPv6 is alive and well in quite a lot of hardware these > days, and there is an ip6tables to deal with it. > Ie, unless you're using it, disable it (both with ip6tables and blacklist modules)
[toc] | [prev] | [next] | [standalone]
| From | cbannister@slingshot.co.nz |
|---|---|
| Date | 2016-04-27 10:40 +0200 |
| Message-ID | <rstaO-6zk-17@gated-at.bofh.it> |
| In reply to | #167034 |
On Sat, Apr 23, 2016 at 01:04:36PM -0400, Harris Paltrowitz wrote: > Hi List, > > I have a question regarding how I've configured my iptables to act as a very > basic "firewall", i.e., one that simply prevents any and all incoming > connections. Now, from my readings over the past several days I think I've > learned that at least some of my outgoing requests will have responses that > should be allowed to come back in -- but aside from that, I essentially want > my firewall to act in a very "default" method, i.e., the way a complete > neophyte would expect his or her firewall to work within Windows or Mac. Have a look at shorewall, it saves you from having to worry about all that nonsense. [snipped all that nonsense.] -- The media's the most powerful entity on earth. They have the power to make the innocent guilty and to make the guilty innocent, and that's power. -- Malcolm X
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2016-04-27 11:30 +0200 |
| Message-ID | <rstXd-7fj-15@gated-at.bofh.it> |
| In reply to | #167034 |
On Sat, Apr 23, 2016 at 01:04:36PM -0400, Harris Paltrowitz wrote: > 2. I found that "ufw" works as a line-command-based-front-end to iptables. Good call. ufw is (IMHO) one of the best iptables-frontends for basic FWs. I am particularly fond of how easy it makes adding a rate-limiting rule. > 3. So after having installed and enabled ufw, here's the output of my > "iptables -L" command. Others have picked over the bones of this, but I'd be more interested in seeing the output of "ufw status" -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Harris Paltrowitz <harrisupstate@yahoo.com> |
|---|---|
| Date | 2016-04-27 13:50 +0200 |
| Message-ID | <rsw8G-s1-13@gated-at.bofh.it> |
| In reply to | #167139 |
On 04/27/2016 05:22 AM, Jonathan Dowland wrote: > On Sat, Apr 23, 2016 at 01:04:36PM -0400, Harris Paltrowitz wrote: >> 2. I found that "ufw" works as a line-command-based-front-end to iptables. > Good call. ufw is (IMHO) one of the best iptables-frontends for basic FWs. > I am particularly fond of how easy it makes adding a rate-limiting rule. > >> 3. So after having installed and enabled ufw, here's the output of my >> "iptables -L" command. > Others have picked over the bones of this, but I'd be more interested in > seeing the output of "ufw status" > Okay, here's the output of "ufw status verbose": Status: active Logging: on (low) Default: deny (incoming), allow (outgoing) New profiles: skip -Harris
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web