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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-22 12:00 +0200 |
| Message-ID | <wAMRH-2YC-7@gated-at.bofh.it> |
| In reply to | #200417 |
Hi. On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote: > 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 ? The benefit is that one cannot pinpoint the real attacker, of course. > Reflection attacks give a benefit for the attacker when the reflection > provides some kind of amplification. That's I agree with. Classic TCP RST flood does not offer any amplification, that's why this kind of attack has more historic than practical nature. Reco
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 13:00 +0200 |
| Message-ID | <wANNM-3x4-3@gated-at.bofh.it> |
| In reply to | #200423 |
Le 22/09/2018 à 11:51, Reco a écrit : > > On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote: >> 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 ? > > The benefit is that one cannot pinpoint the real attacker, of course. Isn't the same benefit provided by just forging the source address ?
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-22 13:30 +0200 |
| Message-ID | <wAOgN-3Vn-5@gated-at.bofh.it> |
| In reply to | #200427 |
Hi. On Sat, Sep 22, 2018 at 12:58:02PM +0200, Pascal Hambourg wrote: > Le 22/09/2018 à 11:51, Reco a écrit : > > > > On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote: > > > 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 ? > > > > The benefit is that one cannot pinpoint the real attacker, of course. > > Isn't the same benefit provided by just forging the source address ? Unsure. I only have theoretical knowledge of such attacks, never performed one myself. Defending against the thing - that's something I'm more versed with. Reco
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2018-09-22 22:00 +0200 |
| Message-ID | <wAWel-8tc-5@gated-at.bofh.it> |
| In reply to | #200427 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Sep 22, 2018 at 12:58:02PM +0200, Pascal Hambourg wrote: > Le 22/09/2018 à 11:51, Reco a écrit : [...] > >The benefit is that one cannot pinpoint the real attacker, of course. > > Isn't the same benefit provided by just forging the source address ? If all the routers in the path play along... but then, they are all broken. Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlumntYACgkQBcgs9XrR2kbArACfdKlCio5Ym6LIne2jjZMwpJlB PH4An15p+eUmR5q2uIBqK/x/v9X8VH5Q =m583 -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2018-09-22 22:20 +0200 |
| Message-ID | <wAWxH-mM-1@gated-at.bofh.it> |
| In reply to | #200448 |
> [...]
>> >The benefit is that one cannot pinpoint the real attacker, of course.
>> Isn't the same benefit provided by just forging the source address ?
> If all the routers in the path play along... but then, they are all
> broken.
There's also the fact that all those RST packets can come from all over
the place and they come from where they say they come.
So they're a lot more difficult to block, compared to packets with
a forged source address all coming from the same IP.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 23:40 +0200 |
| Message-ID | <wAXN8-12u-5@gated-at.bofh.it> |
| In reply to | #200449 |
Le 22/09/2018 à 22:16, Stefan Monnier a écrit : >> [...] >>>> The benefit is that one cannot pinpoint the real attacker, of course. >>> Isn't the same benefit provided by just forging the source address ? >> If all the routers in the path play along... but then, they are all >> broken. This condition must also be true in Reco's scenario to send the forged packets to the reflectors. > There's also the fact that all those RST packets can come from all over > the place and they come from where they say they come. How can the target tell the difference ? It will receive all packets from its internet router anyway. > So they're a lot more difficult to block, compared to packets with > a forged source address all coming from the same IP. "packets with a forged source address all coming from the same IP" does not make any sense. Packets do not "come from an IP", they just have a (possibly forged) source address wherever they come from.
[toc] | [prev] | [next] | [standalone]
| From | Henning Follmann <hfollmann@itcfollmann.com> |
|---|---|
| Date | 2018-09-22 12:10 +0200 |
| Message-ID | <wAN1o-3hT-9@gated-at.bofh.it> |
| In reply to | #200397 |
On Fri, Sep 21, 2018 at 09:32:45PM +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, > > > > > > > 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. > Sorry that is not how a RST attack works. You send a TCP package two either or both ends where the RST flag is set by faking your address. This way mostTCP implementation close the exsisting connection. The china firewall works that way. It is a kind of denial of service attack. If you send a TCP package to a computer not listening it will send a ICMP error back. > 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. > No > 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. > On those machines where I run a firewall, I use by default REJECT and not DROP. This also sends a ICMP back. In most cases this is desireable. If you drop the package without error the TCP sender will just think the package was lost and will resend the package. So in most cases REJECT might be better than DROP anyway. > > 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 > -H -- Henning Follmann | hfollmann@itcfollmann.com
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-22 12:40 +0200 |
| Message-ID | <wANup-3qD-9@gated-at.bofh.it> |
| In reply to | #200424 |
Hi. On Sat, Sep 22, 2018 at 06:05:01AM -0400, Henning Follmann wrote: > On Fri, Sep 21, 2018 at 09:32:45PM +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, > > > > > > > > > > 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. > > > Sorry that is not how a RST attack works. > You send a TCP package two either or both ends where the RST flag is set by > faking your address. This way mostTCP implementation close the exsisting > connection. The china firewall works that way. It is a kind of denial of > service attack. That's how it goes if you're in-between router. > If you send a TCP package to a computer not listening it will send a ICMP > error back. Does not work that way for me in a single L2 segment: nmap -sT -p 23 <victim.host.has.no.telnet> tcpdump -ni <outgoing interface> 13:28:17.826101 IP 10.20.0.1.37928 > 10.20.110.23.23: Flags [S], seq ...269 13:28:17.826111 IP 10.20.110.23.23 > 10.20.0.1.37928: Flags [R.], seq 0, ack ...270 Can I have my ICMP packet please? I can generate those with iptables' REJECT target, but I get TCP RST only with empty INPUT chain. > > 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. > > > > No Yes. Nobody does it anymore as there are numerous ways of traffic amplification, but still 'yes'. > > 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. > > > > On those machines where I run a firewall, I use by default REJECT and not > DROP. This also sends a ICMP back. In most cases this is desireable. In a LAN that's definitely desirable. Helps with the troubleshooting and stuff. Doing this in a WAN makes the host a bad netizen. > If you > drop the package without error the TCP sender will just think the package > was lost and will resend the package. So in most cases REJECT might be > better than DROP anyway. I stopped catering for the needs of clearly broken software years ago, so DROP for WAN is the way. Reco
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 13:10 +0200 |
| Message-ID | <wANXr-3Po-9@gated-at.bofh.it> |
| In reply to | #200424 |
Le 22/09/2018 à 12:05, Henning Follmann a écrit : > > If you send a TCP package to a computer not listening it will send a ICMP > error back. No, standard behaviour is to send a TCP RST back. An ICMP error may be sent back for other protocols such as UDP.
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2018-09-21 20:00 +0200 |
| Subject | netstat (was: Re: Why does Debian allow all incoming traffic by default) |
| Message-ID | <wAxSG-2EA-1@gated-at.bofh.it> |
| In reply to | #200377 |
On Friday, September 21, 2018 08:55:21 AM Henning Follmann wrote: > Run a netstat -t -l and you will see there is nothing listening. So what is > the point of running a firewall? I'm not the OP, but I decided to play along and run: <quote> root@s19:~# netstat -t -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 localhost:smtp *:* LISTEN tcp 0 0 *:microsoft-ds *:* LISTEN tcp 0 0 *:netbios-ssn *:* LISTEN tcp 0 0 *:53647 *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 localhost:ipp *:* LISTEN </quote> (This on my wheezy system.) What is that telling me, and should I be worried. > 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
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-09-21 20:20 +0200 |
| Subject | Re: netstat |
| Message-ID | <wAyc2-301-15@gated-at.bofh.it> |
| In reply to | #200391 |
Hi. On Fri, Sep 21, 2018 at 01:52:00PM -0400, rhkramer@gmail.com wrote: > On Friday, September 21, 2018 08:55:21 AM Henning Follmann wrote: > > Run a netstat -t -l and you will see there is nothing listening. So what is > > the point of running a firewall? > > I'm not the OP, but I decided to play along and run: > > <quote> > root@s19:~# netstat -t -l > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 localhost:smtp *:* LISTEN > tcp 0 0 *:microsoft-ds *:* LISTEN > tcp 0 0 *:netbios-ssn *:* LISTEN > tcp 0 0 *:53647 *:* LISTEN > tcp 0 0 *:sunrpc *:* LISTEN > tcp 0 0 localhost:ipp *:* LISTEN > </quote> > > (This on my wheezy system.) > > What is that telling me You have exim (most probably), samba, nfs portmapper and CUPS running. And that thing (whatever it is) which is listening tcp:53647. samba, portmapper and that 53647 thing are listening on all interfaces, i.e. are reachable from outside of your host. Unless a packet filter intervenes, that is. And, of course, that is TCP only, there can be processes listening UDP sockets too. Btw consider using 'ss -nptl' or 'netstat -nptl' for a more meaningful result. > and should I be worried. No, assuming that you're: 1) Using only Debian-provided software. 2) Installed and started Samba intentionally. 3) Do not intend to provide SMB to all the Internet. Reco
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2018-09-22 20:50 +0200 |
| Subject | Re: netstat |
| Message-ID | <wAV8C-7RO-9@gated-at.bofh.it> |
| In reply to | #200395 |
Thanks! On Friday, September 21, 2018 02:10:40 PM Reco wrote: > On Fri, Sep 21, 2018 at 01:52:00PM -0400, rhkramer@gmail.com wrote: > > What is that telling me
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-24 20:50 +0200 |
| Message-ID | <wBE5H-IS-7@gated-at.bofh.it> |
| In reply to | #200377 |
On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: >Run a netstat -t -l and you will see there is nothing listening. So >what is the point of running a firewall? There's plenty of reasons to run a firewall even if you think you are not running any services. You may be mistaken; a service may be started without your knowledge, either in error or as an unintended consequence of something you have done (install/run another piece of software); or, a third party may have acquired access to your machine in some way and attempted to run a backdoor process to listen for incoming connections. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ 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-24 21:30 +0200 |
| Message-ID | <wBEIq-1aR-13@gated-at.bofh.it> |
| In reply to | #200558 |
On Mon, Sep 24, 2018 at 07:39:59PM +0100, Jonathan Dowland wrote: > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote: > > Run a netstat -t -l and you will see there is nothing listening. So > > what is the point of running a firewall? > > There's plenty of reasons to run a firewall even if you think you are > not running any services. You may be mistaken; a service may be started > without your knowledge, either in error or as an unintended consequence > of something you have done (install/run another piece of software); or, > a third party may have acquired access to your machine in some way and > attempted to run a backdoor process to listen for incoming connections. > And there are also reasons not to install by default one. And this is what the OP was about. The default is to not install listening services a thus no need for a firewall. Any default firewall would then force maintainers of packages to test for the default firewall and if present inject a default rule to make the service available. Otherwise you will have endless rants about "why is my ssh not working.." etc. -H -- Henning Follmann | hfollmann@itcfollmann.com
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-26 15:50 +0200 |
| Message-ID | <wCimt-7zn-3@gated-at.bofh.it> |
| In reply to | #200567 |
On Mon, Sep 24, 2018 at 03:27:51PM -0400, Henning Follmann wrote: > And there are also reasons not to install by default one. And this is > what the OP was about. The default is to not install listening > services a thus no need for a firewall. You must have misread or misunderstood my message, because the point I was making was that the point of a firewall was not just to protect you from the things you *know* are listening, but the scenarios I outline where you have things happening you *don't* know about. > Any default firewall would then force maintainers of packages to test > for the default firewall and if present inject a default rule to make > the service available. Otherwise you will have endless rants about > "why is my ssh not working.." etc. Yes, we'd need an inter-package scheme for opening service ports when packages were installed (or services enabled, a subtle distinction). I outline a high-level approach to that in my last email to this thread (a reply to Joe). -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Pablo Álvarez Córdoba <pabloalvarezcordoba@protonmail.ch> |
|---|---|
| Date | 2018-09-21 18:30 +0200 |
| Message-ID | <wAwtz-1WX-1@gated-at.bofh.it> |
| In reply to | #200358 |
[Multipart message — attachments visible in raw view] — view raw
I do not know, but: \- By default there are no services listening (except in 127.0.0.1) \- A server is usually behind a router/firewall \- It is better that each user configure their system as they want, instead of having default values. Although it would be nice if the installer warns you that by default iptables does not have any rules. \-------- Mensaje original -------- On 21 sept. 2018 5:04, Subhadip Ghosh < subhadip.sky@gmail.com> escribió: > > > > 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. > > Thanks, > Subhadip
[toc] | [prev] | [next] | [standalone]
| From | Subhadip Ghosh <subhadip.sky@gmail.com> |
|---|---|
| Date | 2018-09-21 19:30 +0200 |
| Message-ID | <wAxpD-2v8-5@gated-at.bofh.it> |
| In reply to | #200386 |
Hi Pablo, On 21/09/18 9:50 PM, Pablo Álvarez Córdoba wrote: > > I do not know, but: > - By default there are no services listening (except in 127.0.0.1) > - A server is usually behind a router/firewall > - It is better that each user configure their system as they want, > instead of having default values. Although it would be nice if the > installer warns you that by default iptables does not have any rules. Exactly my point. I don't mind configuring the firewall for myself but I do like to be warned about the defaults when the default policies are not much strict. Thanks, Subhadip
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2018-09-22 00:10 +0200 |
| Message-ID | <wABMB-57G-9@gated-at.bofh.it> |
| In reply to | #200358 |
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. whenever i install a new system i include ufw (a firewall program) just to catch any funny stuff that might try to come through. the default settings seem to work well enough and i'm glad i don't have to relearn the terminology and rules for iptables. i'm sure a much better solution is to run a separate router as it's own layer of firewall may keep a lot of stuff out, but as of yet i'm just not under attack enough to make it worth it. songbird
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2018-09-22 09:40 +0200 |
| Message-ID | <wAKGe-1MF-9@gated-at.bofh.it> |
| In reply to | #200406 |
On Fri, 21 Sep 2018 18:04:59 -0400 songbird <songbird@anthive.com> wrote: > 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. > > whenever i install a new system i include ufw (a firewall > program) just to catch any funny stuff that might try to > come through. > > the default settings seem to work well enough and i'm glad > i don't have to relearn the terminology and rules for iptables. > > i'm sure a much better solution is to run a separate router > as it's own layer of firewall may keep a lot of stuff out, > but as of yet i'm just not under attack enough to make it > worth it. > Better to do both. Two layers of NAT work just fine, for anything but IPSec. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 10:40 +0200 |
| Message-ID | <wALCh-2kl-1@gated-at.bofh.it> |
| In reply to | #200416 |
Le 22/09/2018 à 09:39, Joe a écrit : > > Two layers of NAT work just fine, for anything but IPSec. 1) Even one single layer of NAT can cause trouble with other applications that IPSec : FTP, SIP... 2) IPSec works through NAT, provided that you enable UDP encapsulation aka NAT-T.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web