Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #200358 > unrolled thread
| Started by | Subhadip Ghosh <subhadip.sky@gmail.com> |
|---|---|
| First post | 2018-09-21 05:10 +0200 |
| Last post | 2018-09-24 20:50 +0200 |
| Articles | 20 on this page of 85 — 22 participants |
Back to article view | Back to linux.debian.user
Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 05:10 +0200
Re: Why does Debian allow all incoming traffic by default Roberto C. Sánchez <roberto@debian.org> - 2018-09-21 05:30 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 05:40 +0200
Re: Why does Debian allow all incoming traffic by default Roberto C. Sánchez <roberto@debian.org> - 2018-09-21 05:50 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 07:10 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:40 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-21 19:10 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:40 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 20:00 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 20:10 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 21:40 +0200
Re: Why does Debian allow all incoming traffic by default David Wright <deblis@lionunicorn.co.uk> - 2018-09-21 21:50 +0200
Re: Why does Debian allow all incoming traffic by default mick crane <mick.crane@gmail.com> - 2018-09-23 01:10 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-23 20:00 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-23 23:00 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-24 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 09:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 11:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:00 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-22 13:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 17:00 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 20:20 +0200
Re: Why does Debian allow all incoming traffic by default Richard Hector <richard@walnut.gen.nz> - 2018-09-24 05:20 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 05:30 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-24 09:10 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 11:00 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-24 11:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 14:20 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-22 20:30 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 22:20 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-22 22:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 23:20 +0200
Re: Why does Debian allow all incoming traffic by default Simon Kengelbacher <simon.kengelbacher@mail.ch> - 2018-09-22 23:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-23 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Simon Kengelbacher <simon.kengelbacher@mail.ch> - 2018-09-23 00:20 +0200
SSH X forwarding going awry (Was: Why does Debian allow all incoming traffic by default) Étienne Mollier <etienne.mollier@mailoo.org> - 2018-09-23 11:40 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Gene Heskett <gheskett@shentel.net> - 2018-09-23 16:10 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Joe <joe@jretrading.com> - 2018-09-23 23:00 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Gene Heskett <gheskett@shentel.net> - 2018-09-24 04:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 21:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-23 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 21:00 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-24 21:30 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-26 17:10 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 19:30 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 16:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-21 15:00 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 18:30 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 20:20 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 20:40 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 21:10 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 23:20 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 23:40 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 00:10 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 09:10 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 09:50 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 12:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:00 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 13:30 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-22 22:00 +0200
Re: Why does Debian allow all incoming traffic by default Stefan Monnier <monnier@iro.umontreal.ca> - 2018-09-22 22:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 23:40 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-22 12:10 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 12:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:10 +0200
netstat (was: Re: Why does Debian allow all incoming traffic by default) rhkramer@gmail.com - 2018-09-21 20:00 +0200
Re: netstat Reco <recoverym4n@gmail.com> - 2018-09-21 20:20 +0200
Re: netstat rhkramer@gmail.com - 2018-09-22 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-24 21:30 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pablo Álvarez Córdoba <pabloalvarezcordoba@protonmail.ch> - 2018-09-21 18:30 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:30 +0200
Re: Why does Debian allow all incoming traffic by default songbird <songbird@anthive.com> - 2018-09-22 00:10 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-22 09:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 10:40 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-22 13:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 17:10 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-23 10:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-27 14:00 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-23 00:00 +0200 |
| Message-ID | <wAY6t-18Q-5@gated-at.bofh.it> |
| In reply to | #200445 |
Le 22/09/2018 à 20:27, Dan Ritter a écrit : > On Sat, Sep 22, 2018 at 04:52:40PM +0200, Pascal Hambourg wrote: >> >> It does not matter what you entire point was, and I do not expect you to >> describe a complete firewall policy. *You* exposed a supposedly default >> firewall policy which I happened to find questionable, so I questioned it. > > You should certainly find it questionable, Thanks for acknowledging it. >> You would not have exposed a broken firewall policy on purpose in order to >> prove your point, would you ? > > Wouldn't I? I hope not. > I am explicitly describing a firewire policy for the sake of > argument, and in no way advocating it. For the sake of argument, you should have described a sensible firewall policy or no one would have taken your point seriously. The policy you described was not sensible. Here is a common one which allows outbound "connections" : - accept outbound packets and related inbound replies - deny other inbound packets
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-24 21:00 +0200 |
| Message-ID | <wBEfn-Mb-7@gated-at.bofh.it> |
| In reply to | #200422 |
On Sat, Sep 22, 2018 at 05:12:38AM -0400, Gene Heskett wrote: >Because you can set an ntp corrected machine as a broadcaster, therefore >reducing the load on the tier 2 servers such as debian maintains by >using their pool.debian.org or the tier 1 servers at pool.ntp.org. That >way I have 7 machines here, all synchronized to the first or 2nd tier of >time servers on the planet. This machine is a slave to my router, it >broadcasts to the other 6 machines, so I have all synched and well >within a millisecond. You certainly can, but is that really a use-case that a hypothetical default firewall should service? I don't think so. If you are setting such a thing up you should be expected to punch the requisite holes in the default firewall as part of that work. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2018-09-24 21:30 +0200 |
| Message-ID | <wBEIp-1aR-3@gated-at.bofh.it> |
| In reply to | #200560 |
On Mon, 24 Sep 2018 19:52:39 +0100 Jonathan Dowland <jmtd@debian.org> wrote: > On Sat, Sep 22, 2018 at 05:12:38AM -0400, Gene Heskett wrote: > >Because you can set an ntp corrected machine as a broadcaster, > >therefore reducing the load on the tier 2 servers such as debian > >maintains by using their pool.debian.org or the tier 1 servers at > >pool.ntp.org. That way I have 7 machines here, all synchronized to > >the first or 2nd tier of time servers on the planet. This machine is > >a slave to my router, it broadcasts to the other 6 machines, so I > >have all synched and well within a millisecond. > > You certainly can, but is that really a use-case that a hypothetical > default firewall should service? I don't think so. If you are setting > such a thing up you should be expected to punch the requisite holes in > the default firewall as part of that work. > And there you have the problem: it would be necessary for the installation of certain packages (e.g. MTA) to automatically poke holes in the firewall. For this to be practical, a completely standardised iptables architecture would be necessary, with limited user customisation. That's how Windows does it. Fine for Brian, and others who use no firewall at the moment, not so good for anyone with an existing hand-made set of iptables rules. My netbook, for example, has three sets of rules which are selected according to the environment and whether a VPN is in use. My server has a set of rules appropriate to a network firewall plus VPN server, with suitable named chains and 'subroutine' structure. All of this would be swept away by a standard firewall structure, and would need to be rebuilt in conformance with the standard. Such a standard would have to encompass all possible use-cases, including multiple NICs and multiple VPN arrangements. Any volunteers? -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-26 15:50 +0200 |
| Message-ID | <wCimt-7zn-5@gated-at.bofh.it> |
| In reply to | #200565 |
On Mon, Sep 24, 2018 at 08:21:55PM +0100, Joe wrote: >And there you have the problem: it would be necessary for the >installation of certain packages (e.g. MTA) to automatically poke holes >in the firewall. We agree this far. > For this to be practical, a completely standardised >iptables architecture would be necessary, with limited user >customisation. That's how Windows does it. This is where we disagree. What would be needed would be a standard interface for a package to say "open this port", that was implemented by the iptables (say) package by default, but, if you were writing a very DIY ruleset, you could override the iptables-package's implementation and provide one yourself (or ignore the package hooks if you wished). >Fine for Brian, and others who use no firewall at the moment, not so >good for anyone with an existing hand-made set of iptables rules. My >netbook, for example, has three sets of rules which are selected >according to the environment and whether a VPN is in use. My server has >a set of rules appropriate to a network firewall plus VPN server, with >suitable named chains and 'subroutine' structure. All of this would be >swept away by a standard firewall structure, and would need to be >rebuilt in conformance with the standard. Such a standard would have to >encompass all possible use-cases, including multiple NICs and multiple >VPN arrangements. Any volunteers? The approach I outline above would mean you would have the choice of reworking your configuration to work in harmony with the new arrangement, or override and ignore it, and continue as you are. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2018-09-26 17:10 +0200 |
| Message-ID | <wCjBT-8tg-3@gated-at.bofh.it> |
| In reply to | #200648 |
On Wed, 26 Sep 2018 14:39:41 +0100 Jonathan Dowland <jmtd@debian.org> wrote: > On Mon, Sep 24, 2018 at 08:21:55PM +0100, Joe wrote: > >And there you have the problem: it would be necessary for the > >installation of certain packages (e.g. MTA) to automatically poke > >holes in the firewall. > > We agree this far. > > > For this to be practical, a completely standardised > >iptables architecture would be necessary, with limited user > >customisation. That's how Windows does it. > > This is where we disagree. What would be needed would be a standard > interface for a package to say "open this port", that was implemented > by the iptables (say) package by default, but, if you were writing a > very DIY ruleset, you could override the iptables-package's > implementation and provide one yourself (or ignore the package hooks > if you wished). > You're only moving the problem around. Some completely standard piece of code *somewhere* has to know what is the right place to insert such a rule. I'll give you an example: neither the beginning nor the end of my INPUT chain is the right place, because I do some catch-all stuff about RELATED and INVALID at the beginning of the chain, and some assorted logging at the end. I don't want anything placed before or after those parts. In fact, the right place for my server firewall isn't in the INPUT chain at all, but in one of a few custom chains. There could be a standard custom chain in which such rules were inserted so that they all arrived at a place to suit the user, but my point is that enough such hooks must be defined and honoured to cover all reasonable use cases. This is a significant project, one which involves all IP-aware packages, and I don't think there is *yet* sufficient need to justify the resources to do it right. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-26 19:30 +0200 |
| Message-ID | <wClNn-1dn-5@gated-at.bofh.it> |
| In reply to | #200653 |
On Wed, Sep 26, 2018 at 04:07:33PM +0100, Joe wrote: >You're only moving the problem around. Some completely standard piece of >code *somewhere* has to know what is the right place to insert such a >rule. I'll give you an example: neither the beginning nor the end of my >INPUT chain is the right place, because I do some catch-all stuff about >RELATED and INVALID at the beginning of the chain, and some assorted >logging at the end. I don't want anything placed before or after those >parts. In fact, the right place for my server firewall isn't in the >INPUT chain at all, but in one of a few custom chains. Exactly, it would not be worth attempting to support meshing your setup with the system I sketched out. This is exactly the situation where I'd say you go it alone instead, exactly as you do now. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-09-22 15:50 +0200 |
| Message-ID | <wAQsi-57d-11@gated-at.bofh.it> |
| In reply to | #200415 |
Pascal Hambourg wrote: > Le 21/09/2018 à 19:09, Dan Ritter a écrit : >> >> Let's suppose Debian installs a basic firewall by default. How >> basic? Let's say: >> >> - outbound: permit >> - forward: deny >> - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a >> response to an outbound packet > > Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ? In my case, the box is running as a server for those protocols. Though, Gene (or others) may do things differently. NOTE -I only listen for unsolicited requests on the LAN for those. Only stuff on the internet is SSH and SMTP. > > Why should only TCP inbound responses be allowed ? What about UDP-based > protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ? DNS is UDP (er, by default; though it can use TCP). ICMP echo would most likely fall under the "response to something outbound". -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 16:50 +0200 |
| Message-ID | <wARom-5G2-11@gated-at.bofh.it> |
| In reply to | #200434 |
Le 22/09/2018 à 15:39, Dan Purgert a écrit : > Pascal Hambourg wrote: >> Le 21/09/2018 à 19:09, Dan Ritter a écrit : >>> >>> Let's suppose Debian installs a basic firewall by default. How >>> basic? Let's say: >>> >>> - outbound: permit >>> - forward: deny >>> - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a >>> response to an outbound packet >> >> Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ? > > In my case, the box is running as a server for those protocols. These services are not present *by default*. Dan Ritter talked about a basic firewall *by default*. >> Why should only TCP inbound responses be allowed ? What about UDP-based >> protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ? > > DNS is UDP (er, by default; though it can use TCP). ICMP echo would > most likely fall under the "response to something outbound". Dan Ritter did not mention "response to something outbound" but "any *TCP* packet which is a response to an outbound packet". ICMP echo is not TCP. I was questioning that TCP restriction.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-24 20:50 +0200 |
| Message-ID | <wBE5H-IS-1@gated-at.bofh.it> |
| In reply to | #200387 |
On Fri, Sep 21, 2018 at 01:09:35PM -0400, Dan Ritter wrote: >The basic reason is this: it makes sense. Yours (and Roberto's) reasons are, I think, post-hoc rationalisations. IMHO the real reason is nobody has successfully made the case and/or implementation of a decent default firewall for Debian, not that there's no case to be made. It's probably a contentious enough decision that it would require some bureaucratic machinery to determine whether the project, as a whole, agreed that there should be one or not. But that hasn't happened yet (in either direction) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Henning Follmann <hfollmann@itcfollmann.com> |
|---|---|
| Date | 2018-09-21 15:00 +0200 |
| Message-ID | <wAtcm-8kA-5@gated-at.bofh.it> |
| In reply to | #200358 |
On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote: > Hi, > > I am using Debian and the recently I learned that a standard Debian > installation allows all 3 types of traffics especially incoming by default. > I know I can easily use iptables to tighten the rules but I wanted to know > the reasons behind the choice of this default behaviour and if it makes the > system more vulnerable? I tried searching on the Internet but did not get > any satisfactory explanation. It will be helpful if anybody knows the > answers to my questions or can redirect me to a helpful document. > The answer is easy. Because Debian is awesome (TM). So are most other distributions. Run a netstat -t -l and you will see there is nothing listening. So what is the point of running a firewall? By default no services (ipp might be the one exception) are running and listening. So that's your security, just don't run what you don't need. -H -- Henning Follmann | hfollmann@itcfollmann.com
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-21 18:30 +0200 |
| Message-ID | <wAwtz-1WX-3@gated-at.bofh.it> |
| In reply to | #200377 |
Hi. On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote: > > Hi, > > > > I am using Debian and the recently I learned that a standard Debian > > installation allows all 3 types of traffics especially incoming by default. > > I know I can easily use iptables to tighten the rules but I wanted to know > > the reasons behind the choice of this default behaviour and if it makes the > > system more vulnerable? I tried searching on the Internet but did not get > > any satisfactory explanation. It will be helpful if anybody knows the > > answers to my questions or can redirect me to a helpful document. > > > > The answer is easy. Because Debian is awesome (TM). So are most other > distributions. Hear, hear. > Run a netstat -t -l and you will see there is nothing listening. So what is > the point of running a firewall? The point is to be a good netizen, as always. By running any sane kind of packet filter you're avoiding participating in TCP RST attack. > By default no services (ipp might be the one exception) are running and > listening. Portmapper does - tcp 111. Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-09-21 20:20 +0200 |
| Message-ID | <wAyc1-301-1@gated-at.bofh.it> |
| In reply to | #200385 |
On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote: > Hi. > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote: > > > Hi, > > > > > > I am using Debian and the recently I learned that a standard Debian > > > installation allows all 3 types of traffics especially incoming by default. > > > I know I can easily use iptables to tighten the rules but I wanted to know > > > the reasons behind the choice of this default behaviour and if it makes the > > > system more vulnerable? I tried searching on the Internet but did not get > > > any satisfactory explanation. It will be helpful if anybody knows the > > > answers to my questions or can redirect me to a helpful document. > > > > > > > The answer is easy. Because Debian is awesome (TM). So are most other > > distributions. > > Hear, hear. > > > Run a netstat -t -l and you will see there is nothing listening. So what is > > the point of running a firewall? > > The point is to be a good netizen, as always. By running any sane kind of > packet filter you're avoiding participating in TCP RST attack. How do you do attack when (as Henning Follmann says) nothing is listening? There is no point with a standard Debian installation (which is what the OP inquired about). Debian is already a good netizen. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-21 20:40 +0200 |
| Message-ID | <wAyvo-364-17@gated-at.bofh.it> |
| In reply to | #200394 |
Hi. On Fri, Sep 21, 2018 at 07:14:03PM +0100, Brian wrote: > On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote: > > > Hi. > > > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: > > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote: > > > > Hi, > > > > > > > > I am using Debian and the recently I learned that a standard Debian > > > > installation allows all 3 types of traffics especially incoming by default. > > > > I know I can easily use iptables to tighten the rules but I wanted to know > > > > the reasons behind the choice of this default behaviour and if it makes the > > > > system more vulnerable? I tried searching on the Internet but did not get > > > > any satisfactory explanation. It will be helpful if anybody knows the > > > > answers to my questions or can redirect me to a helpful document. > > > > > > > > > > The answer is easy. Because Debian is awesome (TM). So are most other > > > distributions. > > > > Hear, hear. > > > > > Run a netstat -t -l and you will see there is nothing listening. So what is > > > the point of running a firewall? > > > > The point is to be a good netizen, as always. By running any sane kind of > > packet filter you're avoiding participating in TCP RST attack. > > How do you do attack when (as Henning Follmann says) nothing is listening? TCP RST attack requires exactly that. That, and an absence of a firewall. > There is no point with a standard Debian installation (which is what the > OP inquired about). Debian is already a good netizen. Good person makes a TCP connection to unprotected (as in - no firewall interference) host. Since there's nothing on a host that does not listen appropriate TCP port - host's kernel sends back TCP RST packet. Good person's connection terminates, everyone's happy. That's how it goes in your typical LAN. Evil person makes a TCP connection to unprotected host, but forges source IP. Host sends TCP RST to this forged IP, host acting as a 'reflector' to an attack. And being a bad netizen at the same time. Evil person takes as many of such hosts as possible - and there goes your old-fashioned RST DDOS. I recall that you've stated that your servers do not run any kind of packet filter. So, just in case - one cannot harm the reflector that way. So, in this regard Debian is imperfect, but at least they give you right tools to solve the problem (iptables suite), and do not force braindead firewall policies by default (like RHEL does). Reco
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-09-21 21:10 +0200 |
| Message-ID | <wAyYq-3uX-13@gated-at.bofh.it> |
| In reply to | #200397 |
On Fri 21 Sep 2018 at 21:32:45 +0300, Reco wrote: > Hi. > > On Fri, Sep 21, 2018 at 07:14:03PM +0100, Brian wrote: > > On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote: > > > > > Hi. > > > > > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: > > > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote: > > > > > Hi, > > > > > > > > > > I am using Debian and the recently I learned that a standard Debian > > > > > installation allows all 3 types of traffics especially incoming by default. > > > > > I know I can easily use iptables to tighten the rules but I wanted to know > > > > > the reasons behind the choice of this default behaviour and if it makes the > > > > > system more vulnerable? I tried searching on the Internet but did not get > > > > > any satisfactory explanation. It will be helpful if anybody knows the > > > > > answers to my questions or can redirect me to a helpful document. > > > > > > > > > > > > > The answer is easy. Because Debian is awesome (TM). So are most other > > > > distributions. > > > > > > Hear, hear. > > > > > > > Run a netstat -t -l and you will see there is nothing listening. So what is > > > > the point of running a firewall? > > > > > > The point is to be a good netizen, as always. By running any sane kind of > > > packet filter you're avoiding participating in TCP RST attack. > > > > How do you do attack when (as Henning Follmann says) nothing is listening? > > TCP RST attack requires exactly that. That, and an absence of a > firewall. You have given much food for thought. Thank you. > > > There is no point with a standard Debian installation (which is what the > > OP inquired about). Debian is already a good netizen. > > Good person makes a TCP connection to unprotected (as in - no firewall > interference) host. Since there's nothing on a host that does not listen > appropriate TCP port - host's kernel sends back TCP RST packet. > Good person's connection terminates, everyone's happy. That's how it > goes in your typical LAN. > > Evil person makes a TCP connection to unprotected host, but forges > source IP. Host sends TCP RST to this forged IP, host acting as a > 'reflector' to an attack. And being a bad netizen at the same time. > > Evil person takes as many of such hosts as possible - and there goes > your old-fashioned RST DDOS. > > I recall that you've stated that your servers do not run any kind of > packet filter. So, just in case - one cannot harm the reflector that > way. They don't. And, I still think the OP is fussing over nothing, > So, in this regard Debian is imperfect, but at least they give you right > tools to solve the problem (iptables suite), and do not force braindead > firewall policies by default (like RHEL does). If I used a packet filter I would want to base its use on some sensible. Your post might help me to do it. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2018-09-21 23:20 +0200 |
| Message-ID | <wAB0d-4Df-3@gated-at.bofh.it> |
| In reply to | #200397 |
Reco wrote: > So, in this regard Debian is imperfect, but at least they give you right > tools to solve the problem (iptables suite), and do not force braindead > firewall policies by default (like RHEL does). So this is why a wise guy buys an industrial pc for 200 US or wrt capable router for 20-30 US installs linux and makes a good firewall then puts it between ISP and his own network.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-21 23:40 +0200 |
| Message-ID | <wABjz-4IS-3@gated-at.bofh.it> |
| In reply to | #200404 |
Hi. On Fri, Sep 21, 2018 at 11:18:36PM +0200, deloptes wrote: > Reco wrote: > > > So, in this regard Debian is imperfect, but at least they give you right > > tools to solve the problem (iptables suite), and do not force braindead > > firewall policies by default (like RHEL does). > > So this is why a wise guy buys an industrial pc for 200 US or wrt capable > router for 20-30 US installs linux and makes a good firewall then puts it > between ISP and his own network. That's one way of solving it as such measure only covers one's conventional household needs. Barely - as there's this guest Wi-Fi and that curious neighbour kid. There are laptops that are expected to connect for foreign LANs. And foreign LANs can be expected to contain all kinds of hostilities. There are hosting providers that provide you hardware, some OS installation customized to their (unusual if not perversive) tastes and all the Internet inbound access. So, as I wrote - they give everyone the right tools, so anyone has it. Using them is simple enough (some assembly required though), but as others wrote in this thread - there are no sane defaults. Reco
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-09-22 00:10 +0200 |
| Message-ID | <wABMB-57G-5@gated-at.bofh.it> |
| In reply to | #200405 |
Reco wrote: > Hi. > > On Fri, Sep 21, 2018 at 11:18:36PM +0200, deloptes wrote: >> Reco wrote: >> >> > So, in this regard Debian is imperfect, but at least they give you right >> > tools to solve the problem (iptables suite), and do not force braindead >> > firewall policies by default (like RHEL does). >> >> So this is why a wise guy buys an industrial pc for 200 US or wrt capable >> router for 20-30 US installs linux and makes a good firewall then puts it >> between ISP and his own network. > > That's one way of solving it as such measure only covers one's > conventional household needs. Barely - as there's this guest Wi-Fi and > that curious neighbour kid. You don't firewall between your guest wifi and your trusted stuff? -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-22 09:10 +0200 |
| Message-ID | <wAKdb-1D8-1@gated-at.bofh.it> |
| In reply to | #200407 |
Hi. On Fri, Sep 21, 2018 at 09:59:40PM -0000, Dan Purgert wrote: > Reco wrote: > > Hi. > > > > On Fri, Sep 21, 2018 at 11:18:36PM +0200, deloptes wrote: > >> Reco wrote: > >> > >> > So, in this regard Debian is imperfect, but at least they give you right > >> > tools to solve the problem (iptables suite), and do not force braindead > >> > firewall policies by default (like RHEL does). > >> > >> So this is why a wise guy buys an industrial pc for 200 US or wrt capable > >> router for 20-30 US installs linux and makes a good firewall then puts it > >> between ISP and his own network. > > > > That's one way of solving it as such measure only covers one's > > conventional household needs. Barely - as there's this guest Wi-Fi and > > that curious neighbour kid. > > You don't firewall between your guest wifi and your trusted stuff? Personally I went as far as putting household Wi-Fi into distinct VLAN, and guest Wi-Fi into another one. The question is - can you expect that D-Link/ASUS/TPLink box to do it by default? Reco
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-09-22 15:50 +0200 |
| Message-ID | <wAQsh-57d-5@gated-at.bofh.it> |
| In reply to | #200414 |
Reco wrote: > Hi. > > On Fri, Sep 21, 2018 at 09:59:40PM -0000, Dan Purgert wrote: >> Reco wrote: >> [...] >> >> So this is why a wise guy buys an industrial pc for 200 US or wrt capable >> >> router for 20-30 US installs linux and makes a good firewall then puts it >> >> between ISP and his own network. >> > >> > That's one way of solving it as such measure only covers one's >> > conventional household needs. Barely - as there's this guest Wi-Fi and >> > that curious neighbour kid. >> >> You don't firewall between your guest wifi and your trusted stuff? > > Personally I went as far as putting household Wi-Fi into distinct VLAN, > and guest Wi-Fi into another one. > The question is - can you expect that D-Link/ASUS/TPLink box to do it > by default? Actually with newer models that support "guest wifi", yes -- at least insofar as between guests and "trusted". Though not so much between the wired and "trusted" wifi. -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 09:50 +0200 |
| Message-ID | <wAKPU-1Q2-5@gated-at.bofh.it> |
| In reply to | #200397 |
Le 21/09/2018 à 20:32, Reco a écrit : > > Evil person makes a TCP connection to unprotected host, but forges > source IP. Host sends TCP RST to this forged IP, host acting as a > 'reflector' to an attack. And being a bad netizen at the same time. > > Evil person takes as many of such hosts as possible - and there goes > your old-fashioned RST DDOS. What is the attacker's benefit over just sending packets directly to the target with forged source addresses ? Reflection attacks give a benefit for the attacker when the reflection provides some kind of amplification. One example is broadcast ping in a LAN : one single request packet triggers many reply packets. Another example is DNS amplification : a small DNS request triggers a much bigger DNS reply. But TCP RST attack does not provide any amplification, as one SYN packet triggers one RST packet of similar length.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web