Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248640 > unrolled thread

Re: regarding firewall discussion

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: regarding firewall discussion Joe <joe@jretrading.com> - 2022-06-01 19:30 +0200
    Re: regarding firewall discussion rhkramer@gmail.com - 2022-06-01 21:10 +0200
      Re: regarding firewall discussion Joe <joe@jretrading.com> - 2022-06-01 21:40 +0200
    Re: regarding firewall discussion Richard Hector <richard@walnut.gen.nz> - 2022-06-04 05:00 +0200

#248640 — Re: regarding firewall discussion

On Tue, 31 May 2022 03:17:52 +0100
mick crane <mick.crane@gmail.com> wrote:

> regarding firewall discussion I'm uncertain how firewalls are
> supposed to work.
> I think the idea is that nothing is accepted unless it is in response
> to a request.
> What's to stop some spurious instructions being sent in response to 
> genuine request?
> 

Nothing really, but the reply can only come from the site you made the
request to.

Don't connect to untrustworthy sites.

It is of course possible for a legitimate site to get hacked and some
malware embedded in its pages or linked from them, but that will
normally require JavaScript to run, and many people run browsers with JS
disabled. It's quite rare for a professionally-run site to get defaced,
as the terminology has it, but there's no way I would run a
public-facing website, as I don't know enough to secure it (and I know
that I don't know enough).

There are other defences: use a proxy server which blocks anything
suspicious, and so on. We're into application-level firewalls here,
that actually parse the returned packets, beyond the scope of iptables
and the like. 

Browsers usually have a number of configurations concerning third-party
content, as well as plugins such as No-Script for Firefox. But a
blanket ban on JS will result in many (most?) websites today not
working. I despair of the 'web designers' who cannot display a single
character on a user's browser without using JS.

-- 
Joe

[toc] | [next] | [standalone]

#248643

> mick crane <mick.crane@gmail.com> wrote:
> > regarding firewall discussion I'm uncertain how firewalls are
> > supposed to work.
> > I think the idea is that nothing is accepted unless it is in response
> > to a request.
> > What's to stop some spurious instructions being sent in response to
> > genuine request?

Just for the record, what you described (nothing is accepted unless it is in 
response to a request) is more like the way that NAT worked (at least in its 
original incarnations).  (I say it that way because I haven't kept up with 
NAT, so don't know how it may have changed).

[toc] | [prev] | [next] | [standalone]

#248645

On Wed, 1 Jun 2022 15:02:10 -0400
rhkramer@gmail.com wrote:

> > mick crane <mick.crane@gmail.com> wrote:  
> > > regarding firewall discussion I'm uncertain how firewalls are
> > > supposed to work.
> > > I think the idea is that nothing is accepted unless it is in
> > > response to a request.
> > > What's to stop some spurious instructions being sent in response
> > > to genuine request?  
> 
> Just for the record, what you described (nothing is accepted unless
> it is in response to a request) is more like the way that NAT worked
> (at least in its original incarnations).  (I say it that way because
> I haven't kept up with NAT, so don't know how it may have changed).
> 

It still should, with exceptions for certain special cases that use a
second (usually data) channel that has to be associated with the
request. FTP and many older VPNs are of this kind.

An iptables-based firewall does the same (it can also do NAT) if a
RELATED rule exists. If there is no such rule, only packets explicitly
listed in the firewall code will be allowed in. This is necessary with
unsolicited packets i.e. the protocols allowed to bypass the firewall
e.g. ssh.

But the OP asked about malicious reply data, and neither iptables nor
NAT are equipped to detect this. Either a filtering proxy server (e.g.
http://e2guardian.org/cms/index.php) or the original requesting
application must deal with this.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#248731

On 2/06/22 05:26, Joe wrote:
> On Tue, 31 May 2022 03:17:52 +0100
> mick crane<mick.crane@gmail.com>  wrote:
> 
>> regarding firewall discussion I'm uncertain how firewalls are
>> supposed to work.
>> I think the idea is that nothing is accepted unless it is in response
>> to a request.
>> What's to stop some spurious instructions being sent in response to
>> genuine request?
>>
> Nothing really, but the reply can only come from the site you made the
> request to.

A source IP address can be faked.

Richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web