Re: regarding firewall discussion
On 2/06/22 05:26, Joe wrote: On Tue, 31 May 2022 03:17:52 +0100 mick crane 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
Re: regarding firewall discussion
On 2022-06-01 18:26, Joe wrote: On Tue, 31 May 2022 03:17:52 +0100 mick crane 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. I have pfsense between me and the big bad world and I got some OINK code which I think is community based Snort list of undesirable addresses. It is described as "Legacy" so I don't know if there is something newer I should be doing. mick -- Key ID4BFEBB31
Re: regarding firewall discussion
On Wed, 1 Jun 2022 15:02:10 -0400 rhkra...@gmail.com wrote: > > mick crane 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
Re: regarding firewall discussion
> mick crane 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).
Re: regarding firewall discussion
On Tue, 31 May 2022 03:17:52 +0100 mick crane 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
Re: regarding firewall discussion
On 2022-05-31 12:21, IL Ka wrote: What's to stop some spurious instructions being sent in response to genuine request? Packets do not contain instructions, only data. If your TCP/IP implementation doesn't have vulnerabilities any packet shouldn't be a problem. Firewall prevents technically legal packets from reaching software that shouldn't be accessible from the Internet. In most cases a hacker finds an opened port (port listened to by some daemon) and connects to it. Firewall prevents hacker from doing it. I have wondered since ages ago, likely on windows, I wanted to know about something, I forget what, and there was one result in Alta Vista or something. Go to website there is a message "GO AWAY". I go away but then curious go back and my computer crashes. mick -- Key ID4BFEBB31
Re: regarding firewall discussion
> > > I think the idea is that nothing is accepted it depends on policy (-P): either ACCEPT, REJECT or DROP > unless it is in response to > a request. > You must enable it explicitly, i.e. -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > What's to stop some spurious instructions being sent in response to > genuine request? Packets do not contain instructions, only data. If your TCP/IP implementation doesn't have vulnerabilities any packet shouldn't be a problem. Firewall prevents technically legal packets from reaching software that shouldn't be accessible from the Internet. In most cases a hacker finds an opened port (port listened to by some daemon) and connects to it. Firewall prevents hacker from doing it.
Re: regarding firewall discussion
On 31/5/22 10:17 am, mick crane 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? regards mick In the usual firewall tool iptables, you can tell it to accept related connections. That is it remembers the host you just sent a request to and will let in new connections from that host on some other port -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: regarding firewall discussion
mick crane 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? Firewalls can have whitelists, blocklists, employ various algorithms to determine what should pass and what should not based on characteristics of the material but also factors such as time, recent activity and so on - you can think of a lot of things to do and try ... -- underground experts united https://dataswamp.org/~incal
