subject:"Firewalls"

On 2024-08-06, George at Clug wrote:

> To disable port forwarding would this be a better method?

"ceinture et bretelles" (I let you translate)

> # echo 0 > /proc/sys/net/ipv4/ip_forward
> # cat /etc/sysctl.conf
> # Uncomment the next line to enable packet forwarding for IPv4
> #net.ipv4.ip_forward=1
>
> # Uncomment the next line to enable packet forwarding for IPv6
> #  Enabling this option disables Stateless Address Autoconfiguration
> #  based on Router Advertisements for this host
> #net.ipv6.conf.all.forwarding=1

Put in a file in /etc/sysctl.d with .conf
  net.ipv4.ip_forward = 0
as /etc/sysctl.conf is a package conf and raise some problems as said in
this list

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread john doe


On 8/6/24 01:47, George at Clug wrote:



On Monday, 05-08-2024 at 22:25 john doe wrote:

On 8/5/24 12:50, George at Clug wrote:



On Monday, 05-08-2024 at 17:25 Michel Verdier wrote:

On 2024-08-04, George at Clug wrote:



YOu realy need to be intimate with nftables, you might want to consider
a frontend to nftables.


It is hard to give up on iptables, but you are correct, in both your points. 
Thank you.



When I understand that I'm asking to much questions that are unrelated
to the purpose  of a mailing list, I take that as an opportunity to
regroup and see what I can do about it.

Mailing lists eticket suggests to keep the traffic to a minimum and to
send privately things that are not of the interest of everyone.
This also allows to have an archive that is as relevent as possible and
on topick as possible!

Firewalld, UFW and Foomuuri are all options you might want to play with.

--
John Doe

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread jeremy ardley





On 6/8/24 08:05, George at Clug wrote:

Is it possible to be aware of all the ports required by systems/services
  like "AWS / Cloudflare / etc", such that it is possible to ensure any
firewalls that are put in place do not inhibit the features of these
systems?


In AWS you have a Virtual Private Cloud (VPC)


Inside the VPC you have one of more virtual private LANs. Within those 
you can allocat a non-routable CIDR  - minimum class c (/24).

You can allocate a non-routabble IPv6 CIDR,

You may allocate a public IPv4 Address that is connected by AWS to your 
LAN via NAT.


Within the VPC you manage security policies that control the flow of 
data between the various


Assuming your private IP range is 192.168.100.0/24

192.168.100.1 is the router
192.168.100.2 is the DNS server
192.168.100.3 - reserved

Firewalling is provided by policies managed by you for connections 
between your different virtual private LANs and various AWS services and 
your public IPs


You can add additional firewalls on your virtual hosts independent of 
the AWS policies. You can also add security software like SELinux for 
hosts that provide public services such as a web server.


By default AWS policies are blocking, so you need to enable any traffic 
in the AWS policies as well as on your hosts.


If you want to access an AWS service such as S3 you need to add policy 
VPC rules to allow that.

Re: Internet facing Firewalls mDNS UPnP SMB

On Monday, 05-08-2024 at 23:27 Dan Purgert wrote:
> On Aug 04, 2024, George at Clug wrote:
> > 
> > 
> > On Sunday, 04-08-2024 at 16:15 john doe wrote:
> > > On 8/4/24 06:48, jeremy ardley wrote:
> > > >
> > > > On 4/08/2024 12:26 pm, George at Clug wrote:
> > > >>
> > > >> If I go to the local coffee shop and connect my laptop to their WiFi,
> > > >> which incoming and now outgoing ports should I have blocked to ensure
> > > >> that no nefarious people are able to communicate with my laptop
> > > >
> > > > The rules for public networks are very simple.
> > > >
> > > > - Allow all outgoing traffic
> > > >
> > > 
> > > On a laptop, inbound connections should be restricted unless you want
> > > services to be accessible on your laptop by way of FWing and and
> > > securing the services.
> > > 
> > > Outbound connections is up to you.
> > 
> > Thanks, John,
> > 
> > I do like the idea of blocking all outbound connections, and only
> > opening ports that are required for whatever services I want to use. 
> > 
> > For servers I often do, but for workstations, sadly I am often lazy
> > and default to allowing all outgoing traffic.
> 
> It's perfectly fine for a server or other installation that's setup to
> do "one thing" -- but the idea just falls over when you want to do
> "generic things" on the machine.   
> 
> There's just too much out there that's running behind AWS / Cloudflare /
> etc. that you can't just block them; likewise, new protocols and the
> like (which, yes, are focused to "the web", but details) will just fail
> if you only allow certain ports to be reached.
> 

Dan, I would like to apologise. I have been 'caught in my thinking', about past 
days when I was using quite simple, in-house hosted, systems where you had full 
control, and responsibility for all security implementations. 

I have not used the services of AWS or Cloudflare. I have only once used a 
CLOUD hosted VM (OpenStack) and it was not much different to using our in-house 
servers.

Now I just tinker at home, hence I am not in the mind set that comes with using 
large commercial services like Cloudflare or AWS.

Is it possible to be aware of all the ports required by systems/services like 
"AWS / Cloudflare / etc", such that it is possible to ensure any firewalls that 
are put in place do not inhibit the features of these systems?

I am wondering how much direct control of security one looses when using third 
party services like Cloudflare.

George.

> As for the (snipped) analogies you made -- they more addressed the ideas
> of 'security in depth' as a general concept, rather than addressed
> "outbound firewalls" at all.
> 
> 
> 
> -- 
> |_|O|_| 
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860
>

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread Charles Curley

On Tue, 06 Aug 2024 09:44:32 +1000
George at Clug  wrote:

> This morning, after thinking on these things I realise I am wrong. 
> 
> I am showing both my ignorance and my stupidity. 
> 
> "Times have changed", "That was then, this is now".

My compliments on your willingness to do so. It is not easy to do.

> 
> While I find it difficult to let go, I do need to learn to use
> firewalld and make use of firewall-cmd, you are correct.

It is indeed difficult to let go and move on to other things. Doing so
is one way we old farts can show that we're still alive.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Internet facing Firewalls mDNS UPnP SMB




On Monday, 05-08-2024 at 22:25 john doe wrote:
> On 8/5/24 12:50, George at Clug wrote:
> >
> >
> > On Monday, 05-08-2024 at 17:25 Michel Verdier wrote:
> >> On 2024-08-04, George at Clug wrote:
> >>
> >>> I think I finally have success (had to fix way too many typos).
> >>>
> >>> Please review, and please comment if it can be improved.
> >>
> >> Don't fix typo and instead rewrite your rules with nftables
> >> https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
> >> It's so much easier and cleaner with nftables :)
> >>
> >>
> >
> > Thanks for the link, Michel, it had an interesting translation commands 
> > which I put to good use.
> >
> > There will be some new learning if I am going to be able to do as it 
> > suggests, "implement new nftables mechanisms such as sets, maps, verdict 
> > maps, concatenations and more".
> >
> > Down below is the output of the translation commands for my Iptables 
> > commands.  Interesting but again, I will need to learn what this means, it 
> > does not look self explanatory. But hopefully, like everything computer 
> > related, it is usually not that complex, just you need to understand the 
> > new syntax and how to use it.
> >
> 
> YOu realy need to be intimate with nftables, you might want to consider
> a frontend to nftables.

It is hard to give up on iptables, but you are correct, in both your points. 
Thank you.

> 
> --
> John Doe
> 
>

Re: Internet facing Firewalls mDNS UPnP SMB

On Tuesday, 06-08-2024 at 04:12 Charles Curley wrote:
> On Tue, 06 Aug 2024 01:12:08 +1000
> George at Clug  wrote:
> 
> > It would be nice if systems were not so complex that they required
> > frontends to be usable.
> 
> Perhaps it would be nice. But that's not the way of the world. I wrote
> 6502 assembly code and hand-assembled it way back when. I was very glad
> to get my hands on an assembler and a computer with enough ram to run
> it. Hiding complexity is a good thing.
> 
> > 
> > I am feeling a little overwhelmed by how confusing nftables is, but
> > that is how I felt about iptables before getting to a point I could
> > set up a simple set of rules.
> 
> I'm lazy. I use a front end precisely so I don't have to learn nftables
> in all its complexity. I suggest you look at firewalld and its two
> front ends, firewalld-config (GUI) and firewall-cmd (command line). As
> an extra added bonus, it integrates nicely with Network Manager.

This morning, after thinking on these things I realise I am wrong. 

I am showing both my ignorance and my stupidity. 

"Times have changed", "That was then, this is now".

While I find it difficult to let go, I do need to learn to use firewalld and 
make use of firewall-cmd, you are correct.

For example, I have noticed, web pages are no longer code running from a single 
server (eg. local html, php code), but a litany of libraries sourced life from 
other sites on the Internet.

(I do recall being taught programming using machine code, once I reached an 
environment that used assembler, I only used machine code for debugging. 
At that time I was also introduced to programming using BASIC via punch cards. 
I am not going to give up using IDEs and go back to those days, so I should 
apply the same logic to firewalld)

> 
> -- 
> Does anybody read signatures any more?
> 
> https://charlescurley.com
> https://charlescurley.com/blog/
> 
>

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread Charles Curley

On Tue, 06 Aug 2024 01:12:08 +1000
George at Clug  wrote:

> It would be nice if systems were not so complex that they required
> frontends to be usable.

Perhaps it would be nice. But that's not the way of the world. I wrote
6502 assembly code and hand-assembled it way back when. I was very glad
to get my hands on an assembler and a computer with enough ram to run
it. Hiding complexity is a good thing.

> 
> I am feeling a little overwhelmed by how confusing nftables is, but
> that is how I felt about iptables before getting to a point I could
> set up a simple set of rules.

I'm lazy. I use a front end precisely so I don't have to learn nftables
in all its complexity. I suggest you look at firewalld and its two
front ends, firewalld-config (GUI) and firewall-cmd (command line). As
an extra added bonus, it integrates nicely with Network Manager.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Internet facing Firewalls mDNS UPnP SMB




On Monday, 05-08-2024 at 21:52 Michel Verdier wrote:
> On 2024-08-05, George at Clug wrote:
> 
> > Down below is the output of the translation commands for my Iptables
> > commands.  Interesting but again, I will need to learn what this means,
> > it does not look self explanatory. But hopefully, like everything
> > computer related, it is usually not that complex, just you need to
> > understand the new syntax and how to use it.
> >
> > I am also a bit concerned about the statement "table ip nat", I do not
> > want [e.g. need] any Network Address Translation occurring.
> 
> Simply remove table ip nat and table ip mangle as they are empty and you
> don't use them.

Thanks.

> 
> > table ip filter {
> > chain INPUT {
> > type filter hook input priority filter; policy drop;
> > iifname "lo" counter packets 0 bytes 0 accept
> > iifname "enp1s0" ct state established,related counter packets 
> > 243 bytes 27964 accept
> > iifname "enp1s0" ct state new tcp dport 22 counter packets 0 
> > bytes 0 accept
> > iifname "enp1s0" ct state new tcp dport 25565 counter packets 0 
> > bytes 0 accept
> > iifname "enp1s0" ct state new tcp dport 8123 counter packets 0 
> > bytes 0 accept
> > }
> 
> Remove "packets nnn bytes nnn", syntax is:
>   iifname lo counter accept
> The action "counter" will count packets matching the rule. If you do the
> shell command:
>   nft list ruleset
> the line will be listed with the packets and bytes counters.
> Also you don't need to test iifname "enp1s0" if you don't have multiple
> interfaces or don't want to differenciate them.
> Only loopback (lo) is to be tested.
> 
> > chain OUTPUT {
> > type filter hook output priority filter; policy drop;
> > oifname "lo" counter packets 0 bytes 0 accept
> > oifname "enp1s0" ct state established,related counter packets 
> > 189 bytes 33916 accept
> > oifname "enp1s0" ct state new udp dport 53 counter packets 16 
> > bytes 984 accept
> > oifname "enp1s0" ct state new tcp dport { 22, 53, 80, 123, 443 
> > } counter packets 9 bytes 540 accept
> > }
> 
> Same as for input don't test oifname "enp1s0" if not needed.
> 
> So you drop packets not accepted. Here for workstation I add a last rule
> like this one:
> log level warn prefix "[FW accept output] " counter accept
> This will log a warning but still accept the packet out.
> 
> 

I would like to specify the interface, as on another interface, and have a 
different set of rules for the other interface.

I do not think I need the counter to be counting packets, so for now I will 
remove the statement for now.

To disable port forwarding would this be a better method?

# echo 0 > /proc/sys/net/ipv4/ip_forward
# cat /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


After sleep, tomorrow I would like to test this out:

===
# nano /etc/nftables.conf

flush ruleset

#!/usr/sbin/nft -f

flush ruleset

table ip filter {
chain INPUT {
type filter hook input priority filter; policy drop;
iifname "lo" accept
iifname "enp1s0" ct state established,related accept
iifname "enp1s0" ct state new tcp dport ssh accept
iifname "enp1s0" ct state new tcp dport 25565 accept
iifname "enp1s0" ct state new tcp dport 8123 accept
}

chain FORWARD {
type filter hook forward priority filter; policy drop;
}

chain OUTPUT {
type filter hook output priority filter; policy drop;
oifname "lo" accept
oifname "enp1s0" ct state established,related accept
oifname "enp1s0" ct state new udp dport dns accept
oifname "enp1s0" ct state new tcp dport { ssh, dns, http, ntp, 
https } accept
}
}

# systemctl restart nftables.service

Re: Internet facing Firewalls mDNS UPnP SMB




On Monday, 05-08-2024 at 22:25 john doe wrote:
> On 8/5/24 12:50, George at Clug wrote:
> >
> >
> > On Monday, 05-08-2024 at 17:25 Michel Verdier wrote:
> >> On 2024-08-04, George at Clug wrote:
> >>
> >>> I think I finally have success (had to fix way too many typos).
> >>>
> >>> Please review, and please comment if it can be improved.
> >>
> >> Don't fix typo and instead rewrite your rules with nftables
> >> https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
> >> It's so much easier and cleaner with nftables :)
> >>
> >>
> >
> > Thanks for the link, Michel, it had an interesting translation commands 
> > which I put to good use.
> >
> > There will be some new learning if I am going to be able to do as it 
> > suggests, "implement new nftables mechanisms such as sets, maps, verdict 
> > maps, concatenations and more".
> >
> > Down below is the output of the translation commands for my Iptables 
> > commands.  Interesting but again, I will need to learn what this means, it 
> > does not look self explanatory. But hopefully, like everything computer 
> > related, it is usually not that complex, just you need to understand the 
> > new syntax and how to use it.
> >
> 
> YOu realy need to be intimate with nftables, you might want to consider
> a frontend to nftables.

It would be nice if systems were not so complex that they required frontends to 
be usable.

I am feeling a little overwhelmed by how confusing nftables is, but that is how 
I felt about iptables before getting to a point I could set up a simple set of 
rules.

I am currently in the "Initial learning curve" phase.

> 
> --
> John Doe
> 
>

Re: Internet facing Firewalls mDNS UPnP SMB




On Monday, 05-08-2024 at 23:27 Dan Purgert wrote:
> On Aug 04, 2024, George at Clug wrote:
> > 
> > 
> > On Sunday, 04-08-2024 at 16:15 john doe wrote:
> > > On 8/4/24 06:48, jeremy ardley wrote:
> > > >
> > > > On 4/08/2024 12:26 pm, George at Clug wrote:
> > > >>
> > > >> If I go to the local coffee shop and connect my laptop to their WiFi,
> > > >> which incoming and now outgoing ports should I have blocked to ensure
> > > >> that no nefarious people are able to communicate with my laptop
> > > >
> > > > The rules for public networks are very simple.
> > > >
> > > > - Allow all outgoing traffic
> > > >
> > > 
> > > On a laptop, inbound connections should be restricted unless you want
> > > services to be accessible on your laptop by way of FWing and and
> > > securing the services.
> > > 
> > > Outbound connections is up to you.
> > 
> > Thanks, John,
> > 
> > I do like the idea of blocking all outbound connections, and only
> > opening ports that are required for whatever services I want to use. 
> > 
> > For servers I often do, but for workstations, sadly I am often lazy
> > and default to allowing all outgoing traffic.
> 
> It's perfectly fine for a server or other installation that's setup to
> do "one thing" -- but the idea just falls over when you want to do
> "generic things" on the machine.   

"server that's setup to do "one thing"  - this is my use case.

> 
> There's just too much out there that's running behind AWS / Cloudflare /
> etc. that you can't just block them; likewise, new protocols and the
> like (which, yes, are focused to "the web", but details) will just fail
> if you only allow certain ports to be reached.

I do not use AWS / Cloudflare / etc, so I am not sure what you mean by "you 
can't just block them; likewise, new protocols and the like (which, yes, are 
focused to "the web", but details) will just fail  if you only allow certain 
ports to be reached."

The whole idea of blocking ports other that the ports required for the services 
being hosted by the server, it to have all other ports fail to be reached.

Sorry, but I do not understand what it is you are concerned about?  I feel 
there is something I may have missed, that could be important.

> 
> As for the (snipped) analogies you made -- they more addressed the ideas
> of 'security in depth' as a general concept, rather than addressed
> "outbound firewalls" at all.
> 
> 
> 
> -- 
> |_|O|_| 
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860
>

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread Dan Purgert

On Aug 04, 2024, George at Clug wrote:
> 
> 
> On Sunday, 04-08-2024 at 16:15 john doe wrote:
> > On 8/4/24 06:48, jeremy ardley wrote:
> > >
> > > On 4/08/2024 12:26 pm, George at Clug wrote:
> > >>
> > >> If I go to the local coffee shop and connect my laptop to their WiFi,
> > >> which incoming and now outgoing ports should I have blocked to ensure
> > >> that no nefarious people are able to communicate with my laptop
> > >
> > > The rules for public networks are very simple.
> > >
> > > - Allow all outgoing traffic
> > >
> > 
> > On a laptop, inbound connections should be restricted unless you want
> > services to be accessible on your laptop by way of FWing and and
> > securing the services.
> > 
> > Outbound connections is up to you.
> 
> Thanks, John,
> 
> I do like the idea of blocking all outbound connections, and only
> opening ports that are required for whatever services I want to use. 
> 
> For servers I often do, but for workstations, sadly I am often lazy
> and default to allowing all outgoing traffic.

It's perfectly fine for a server or other installation that's setup to
do "one thing" -- but the idea just falls over when you want to do
"generic things" on the machine.   

There's just too much out there that's running behind AWS / Cloudflare /
etc. that you can't just block them; likewise, new protocols and the
like (which, yes, are focused to "the web", but details) will just fail
if you only allow certain ports to be reached.

As for the (snipped) analogies you made -- they more addressed the ideas
of 'security in depth' as a general concept, rather than addressed
"outbound firewalls" at all.

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

signature.asc
Description: PGP signature

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-05 Thread john doe


On 8/5/24 12:50, George at Clug wrote:



On Monday, 05-08-2024 at 17:25 Michel Verdier wrote:

On 2024-08-04, George at Clug wrote:


I think I finally have success (had to fix way too many typos).

Please review, and please comment if it can be improved.


Don't fix typo and instead rewrite your rules with nftables
https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
It's so much easier and cleaner with nftables :)




Thanks for the link, Michel, it had an interesting translation commands which I 
put to good use.

There will be some new learning if I am going to be able to do as it suggests, 
"implement new nftables mechanisms such as sets, maps, verdict maps, concatenations 
and more".

Down below is the output of the translation commands for my Iptables commands.  
Interesting but again, I will need to learn what this means, it does not look 
self explanatory. But hopefully, like everything computer related, it is 
usually not that complex, just you need to understand the new syntax and how to 
use it.



YOu realy need to be intimate with nftables, you might want to consider
a frontend to nftables.

--
John Doe

VM, wifi, NAT (was: Re: Internet facing Firewalls mDNS UPnP SMB)

2024-08-05 Thread Max Nikulin


On 05/08/2024 17:50, George at Clug wrote:

I am also a bit concerned about the statement "table ip nat", I do not
want [e.g. need] any Network Address Translation occurring.



Re: VirtualBox (VB) and Windows on Debian
On 19/07/2024 11:11, George at Clug wrote:

And I gave up on setting up Bridges on Wireless network interfaces as I
think each wireless connection is treated as a new network interface.


NAT allows to create a network for virtual machines in the case of 
outgoing WiFi connection.

Re: Internet facing Firewalls mDNS UPnP SMB

On 2024-08-05, George at Clug wrote:

> Down below is the output of the translation commands for my Iptables
> commands.  Interesting but again, I will need to learn what this means,
> it does not look self explanatory. But hopefully, like everything
> computer related, it is usually not that complex, just you need to
> understand the new syntax and how to use it.
>
> I am also a bit concerned about the statement "table ip nat", I do not
> want [e.g. need] any Network Address Translation occurring.

Simply remove table ip nat and table ip mangle as they are empty and you
don't use them.

> table ip filter {
>   chain INPUT {
>   type filter hook input priority filter; policy drop;
>   iifname "lo" counter packets 0 bytes 0 accept
>   iifname "enp1s0" ct state established,related counter packets 
> 243 bytes 27964 accept
>   iifname "enp1s0" ct state new tcp dport 22 counter packets 0 
> bytes 0 accept
>   iifname "enp1s0" ct state new tcp dport 25565 counter packets 0 
> bytes 0 accept
>   iifname "enp1s0" ct state new tcp dport 8123 counter packets 0 
> bytes 0 accept
>   }

Remove "packets nnn bytes nnn", syntax is:
  iifname lo counter accept
The action "counter" will count packets matching the rule. If you do the
shell command:
  nft list ruleset
the line will be listed with the packets and bytes counters.
Also you don't need to test iifname "enp1s0" if you don't have multiple
interfaces or don't want to differenciate them.
Only loopback (lo) is to be tested.

>   chain OUTPUT {
>   type filter hook output priority filter; policy drop;
>   oifname "lo" counter packets 0 bytes 0 accept
>   oifname "enp1s0" ct state established,related counter packets 
> 189 bytes 33916 accept
>   oifname "enp1s0" ct state new udp dport 53 counter packets 16 
> bytes 984 accept
>   oifname "enp1s0" ct state new tcp dport { 22, 53, 80, 123, 443 
> } counter packets 9 bytes 540 accept
>   }

Same as for input don't test oifname "enp1s0" if not needed.

So you drop packets not accepted. Here for workstation I add a last rule
like this one:
log level warn prefix "[FW accept output] " counter accept
This will log a warning but still accept the packet out.

Re: Internet facing Firewalls mDNS UPnP SMB




On Monday, 05-08-2024 at 17:25 Michel Verdier wrote:
> On 2024-08-04, George at Clug wrote:
> 
> > I think I finally have success (had to fix way too many typos).
> >
> > Please review, and please comment if it can be improved.
> 
> Don't fix typo and instead rewrite your rules with nftables
> https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
> It's so much easier and cleaner with nftables :)
> 
> 

Thanks for the link, Michel, it had an interesting translation commands which I 
put to good use.

There will be some new learning if I am going to be able to do as it suggests, 
"implement new nftables mechanisms such as sets, maps, verdict maps, 
concatenations and more".

Down below is the output of the translation commands for my Iptables commands.  
Interesting but again, I will need to learn what this means, it does not look 
self explanatory. But hopefully, like everything computer related, it is 
usually not that complex, just you need to understand the new syntax and how to 
use it.

I am also a bit concerned about the statement "table ip nat", I do not want 
[e.g. need] any Network Address Translation occurring.

As with all new systems, it is best to start at the beginning with the simple, 
then build on that. Anyway, something to amuse myself with.

George.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/security_guide/sec-creating_and_managing_nftables_tables_chains_and_rules#sec-Creating_an_nftables_table

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/getting-started-with-nftables_configuring-and-managing-networking

https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management
https://wiki.nftables.org/wiki-nftables/index.php/Scripting
https://wiki.nftables.org/wiki-nftables/index.php/Simple_rule_management

table ip filter {
chain INPUT {
type filter hook input priority filter; policy drop;
iifname "lo" counter packets 0 bytes 0 accept
iifname "enp1s0" ct state established,related counter packets 
243 bytes 27964 accept
iifname "enp1s0" ct state new tcp dport 22 counter packets 0 
bytes 0 accept
iifname "enp1s0" ct state new tcp dport 25565 counter packets 0 
bytes 0 accept
iifname "enp1s0" ct state new tcp dport 8123 counter packets 0 
bytes 0 accept
}

chain FORWARD {
type filter hook forward priority filter; policy drop;
}

chain OUTPUT {
type filter hook output priority filter; policy drop;
oifname "lo" counter packets 0 bytes 0 accept
oifname "enp1s0" ct state established,related counter packets 
189 bytes 33916 accept
oifname "enp1s0" ct state new udp dport 53 counter packets 16 
bytes 984 accept
oifname "enp1s0" ct state new tcp dport { 22, 53, 80, 123, 443 
} counter packets 9 bytes 540 accept
}
}
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}

chain INPUT {
type nat hook input priority 100; policy accept;
}

chain OUTPUT {
type nat hook output priority -100; policy accept;
}

chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
}

chain INPUT {
type filter hook input priority mangle; policy accept;
}

chain FORWARD {
type filter hook forward priority mangle; policy accept;
}

chain OUTPUT {
type route hook output priority mangle; policy accept;
}

chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
}
}

Re: Internet facing Firewalls mDNS UPnP SMB

On 2024-08-04, George at Clug wrote:

> I think I finally have success (had to fix way too many typos).
>
> Please review, and please comment if it can be improved.

Don't fix typo and instead rewrite your rules with nftables
https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
It's so much easier and cleaner with nftables :)

Re: Internet facing Firewalls mDNS UPnP SMB

On 2024-08-04, George at Clug wrote:

> I do like the idea of blocking all outbound connections, and only
> opening ports that are required for whatever services I want to use.

I do the same.

> For servers I often do, but for workstations, sadly I am often lazy and
> default to allowing all outgoing traffic.

On workstations I allow all outbound and log traffic to unauthorized
ports. So I got warned of suspicious connections.

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-04 Thread George at Clug




On Sunday, 04-08-2024 at 18:48 Christofer C. Bell wrote:
> On Sun, Aug 4, 2024 at 3:12 AM George at Clug  wrote:
> 
> >
> >
> > On Sunday, 04-08-2024 at 16:15 john doe wrote:
> > > On 8/4/24 06:48, jeremy ardley wrote:
> > > >
> > > > On 4/08/2024 12:26 pm, George at Clug wrote:
> > > >>
> > > >> If I go to the local coffee shop and connect my laptop to their WiFi,
> > > >> which incoming and now outgoing ports should I have blocked to ensure
> > > >> that no nefarious people are able to communicate with my laptop
> > > >
> > > > The rules for public networks are very simple.
> > > >
> > > > - Allow all outgoing traffic
> > > >
> > >
> > > On a laptop, inbound connections should be restricted unless you want
> > > services to be accessible on your laptop by way of FWing and and
> > > securing the services.
> > >
> > > Outbound connections is up to you.
> >
> > Thanks, John,
> >
> > I do like the idea of blocking all outbound connections, and only opening
> > ports that are required for whatever services I want to use.
> >
> > For servers I often do, but for workstations, sadly I am often lazy and
> > default to allowing all outgoing traffic.
> >
> > When asked to explain why I want to block outgoing connections, I do find
> > it difficult to justify but here are a few thoughts:
> >
> > 1) I like the principle of making this as hard as possible for the 'bad'
> > guys. If they break in, they might as well not have it easy. As analogy, I
> > can have a gate at the front of my house, then I have a dead locked door
> > (not just a lock from the outside). then if I had valuables, they would be
> > in a steel safe, and the safe would be bolted to the concrete floor. All of
> > this will not stop the determined, but why let it be easy.
> >
> > 2)  Staying with analogies, I like having double locked doors. If someone
> > breaks in through the window, they have to exit the same way, and not just
> > walk out through the front/back door, making it bit more difficult to carry
> > everything out. In IT terms, is someone has gained access to my server via
> > a service level exploit, they (hopefully) only have that service's level of
> > access. If the local network is blocked, port scanning is going to be more
> > challenging, as would a number of other network based attacks.
> >
> > 3) I believe a number of exploits, once gain a small footprint, then
> > create a listening service to allow remote access to the system. If this
> > cannot be achieved, then again, I have made their lives harder.
> >
> > The main challenge as I see it is to ensure no 'bad' guys gain root
> > access, but as above, until then, make their lives hard as possible to do
> > anything by limiting and locking down anything you can while still allowing
> > the system achieve its intended purpose.
> >
> > Any comments on the above thoughts?
> >
> > George.
> >
> 
> Outbound ports are selected randomly. If you block outbound ports, you'll
> block your ability to communicate with anything over the network. If you
> want to "block outbound stuff" block all outbound connections to any
> destination, then allow outbound connections to address ranges you want to
> connect to, from any local port.

I should clarify: I am speaking about incoming and outgoing blocking ports for 
NEW connections, not RELATED,ESTABLISHED connections, so randomly selected 
outbound ports should only be for RELATED,ESTABLISHED connections.

I have been experimenting this afternoon based on previous efforts. 

I think I finally have success (had to fix way too many typos).

Please review, and please comment if it can be improved.

I used Minecraft and DynMap as a test scenario. 

I can ping or disable ping, I can run updates. I wonder what I will find 
sometime in the future that does not work?




# Delete all existing rules
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

ip6tables -F
ip6tables -X
ip6tables -t nat -F
ip6tables -t nat -X
ip6tables -t mangle -F
ip6tables -t mangle -X

# Allow traffic on loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

# Allow all inbound established connections
iptables -A INPUT -i enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT

ip6tables -A INPUT -i enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow all outbound established connections
iptables -A OUTPUT -o enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT

ip6tables -A OUTPUT -o enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Enable incoming ssh, for remote access
iptables -A INPUT -i enp1s0 -p tcp -m state --state NEW --dport 22 -j ACCEPT
ip6tables -A INPUT -i enp1s0 -p tcp -m state --state NEW --dport 22 -j ACCEPT


# Enable specific incoming port for Minecraft and DynMap
iptables -A INPUT -i enp1s0 -p tcp -m state --state NEW --dport 25565 -j AC

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-04 Thread jeremy ardley





On 4/8/24 16:11, George at Clug wrote:

I do like the idea of blocking all outbound connections, and only
opening ports that are required for whatever services I want to use.

For servers I often do, but for workstations, sadly I am often lazy and
default to allowing all outgoing traffic.


Lets look at the different cases.

*Source port blocking*

Here you block source ports on your machine from connecting to a remote 
system say on a well known remote port.


This is a bad idea. Most applications on your system will select random 
source addresses from your unprivileged range and use those. 
Particularly web browsers but even system services. If you block them 
you won't have internet access.


Then there services using a source port from the privileged range. It's 
less common but does happen. Again, blocking privileged source ports is 
a bad idea.


*Destination Port blocking*

These are service your client needs to connect to. Principally these 
will be http and https and dns and ntp and dhcp etc. If you block these 
destination ports you'll lose internet connectivity.


But there is more problems with destination port blocking. Some services 
such as SIP Telephony will direct your client to connect to specific 
ports on a remote system. If you have a blanket ban your phone service 
won't work


*You have been compromised*

Here something nasty has got in your system. The majority of these 
nasties won't connect to random remote ports, they will use well known 
ports including SMTP, HTTP, HTTPS, DNS, NTP etc. These must be kept open 
for usual use so that is why the baddies use them.


(There used to be the case that SMB ports were exploited. This is one 
destination port it's good to explicitly ban)


*Summary*

- You can't block source ports
- Blocking unknown destination ports will cause you problems
- The destination ports you don't/can't block will be used in preference 
by baddies.
- You may get some benefit by explicitly blocking some destination ports 
on a case by case basis.


Your best defence is to install mandatory access controls on your system 
to limit any exploit. Personally I use SELinix.

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-04 Thread Christofer C. Bell

On Sun, Aug 4, 2024 at 3:12 AM George at Clug  wrote:

>
>
> On Sunday, 04-08-2024 at 16:15 john doe wrote:
> > On 8/4/24 06:48, jeremy ardley wrote:
> > >
> > > On 4/08/2024 12:26 pm, George at Clug wrote:
> > >>
> > >> If I go to the local coffee shop and connect my laptop to their WiFi,
> > >> which incoming and now outgoing ports should I have blocked to ensure
> > >> that no nefarious people are able to communicate with my laptop
> > >
> > > The rules for public networks are very simple.
> > >
> > > - Allow all outgoing traffic
> > >
> >
> > On a laptop, inbound connections should be restricted unless you want
> > services to be accessible on your laptop by way of FWing and and
> > securing the services.
> >
> > Outbound connections is up to you.
>
> Thanks, John,
>
> I do like the idea of blocking all outbound connections, and only opening
> ports that are required for whatever services I want to use.
>
> For servers I often do, but for workstations, sadly I am often lazy and
> default to allowing all outgoing traffic.
>
> When asked to explain why I want to block outgoing connections, I do find
> it difficult to justify but here are a few thoughts:
>
> 1) I like the principle of making this as hard as possible for the 'bad'
> guys. If they break in, they might as well not have it easy. As analogy, I
> can have a gate at the front of my house, then I have a dead locked door
> (not just a lock from the outside). then if I had valuables, they would be
> in a steel safe, and the safe would be bolted to the concrete floor. All of
> this will not stop the determined, but why let it be easy.
>
> 2)  Staying with analogies, I like having double locked doors. If someone
> breaks in through the window, they have to exit the same way, and not just
> walk out through the front/back door, making it bit more difficult to carry
> everything out. In IT terms, is someone has gained access to my server via
> a service level exploit, they (hopefully) only have that service's level of
> access. If the local network is blocked, port scanning is going to be more
> challenging, as would a number of other network based attacks.
>
> 3) I believe a number of exploits, once gain a small footprint, then
> create a listening service to allow remote access to the system. If this
> cannot be achieved, then again, I have made their lives harder.
>
> The main challenge as I see it is to ensure no 'bad' guys gain root
> access, but as above, until then, make their lives hard as possible to do
> anything by limiting and locking down anything you can while still allowing
> the system achieve its intended purpose.
>
> Any comments on the above thoughts?
>
> George.
>

Outbound ports are selected randomly. If you block outbound ports, you'll
block your ability to communicate with anything over the network. If you
want to "block outbound stuff" block all outbound connections to any
destination, then allow outbound connections to address ranges you want to
connect to, from any local port.

You'll find this is an exercise in frustration, however, in today's cloud
powered Internet.

It's best to follow Jeremy Ardley's advice.

-- 
Chris

"If you wish to make an apple pie from scratch, you must first invent the
Universe." -- Carl Sagan

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-04 Thread George at Clug

On Sunday, 04-08-2024 at 16:15 john doe wrote:
> On 8/4/24 06:48, jeremy ardley wrote:
> >
> > On 4/08/2024 12:26 pm, George at Clug wrote:
> >>
> >> If I go to the local coffee shop and connect my laptop to their WiFi,
> >> which incoming and now outgoing ports should I have blocked to ensure
> >> that no nefarious people are able to communicate with my laptop
> >
> > The rules for public networks are very simple.
> >
> > - Allow all outgoing traffic
> >
> 
> On a laptop, inbound connections should be restricted unless you want
> services to be accessible on your laptop by way of FWing and and
> securing the services.
> 
> Outbound connections is up to you.

Thanks, John,

I do like the idea of blocking all outbound connections, and only opening ports 
that are required for whatever services I want to use. 

For servers I often do, but for workstations, sadly I am often lazy and default 
to allowing all outgoing traffic.

When asked to explain why I want to block outgoing connections, I do find it 
difficult to justify but here are a few thoughts:

1) I like the principle of making this as hard as possible for the 'bad' guys. 
If they break in, they might as well not have it easy. As analogy, I can have a 
gate at the front of my house, then I have a dead locked door (not just a lock 
from the outside). then if I had valuables, they would be in a steel safe, and 
the safe would be bolted to the concrete floor. All of this will not stop the 
determined, but why let it be easy. 

2)  Staying with analogies, I like having double locked doors. If someone 
breaks in through the window, they have to exit the same way, and not just walk 
out through the front/back door, making it bit more difficult to carry 
everything out. In IT terms, is someone has gained access to my server via a 
service level exploit, they (hopefully) only have that service's level of 
access. If the local network is blocked, port scanning is going to be more 
challenging, as would a number of other network based attacks.

3) I believe a number of exploits, once gain a small footprint, then create a 
listening service to allow remote access to the system. If this cannot be 
achieved, then again, I have made their lives harder.

The main challenge as I see it is to ensure no 'bad' guys gain root access, but 
as above, until then, make their lives hard as possible to do anything by 
limiting and locking down anything you can while still allowing the system 
achieve its intended purpose.

Any comments on the above thoughts?

George.

> 
> --
> John Doe
> 
>

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-03 Thread john doe


On 8/4/24 06:48, jeremy ardley wrote:


On 4/08/2024 12:26 pm, George at Clug wrote:


If I go to the local coffee shop and connect my laptop to their WiFi,
which incoming and now outgoing ports should I have blocked to ensure
that no nefarious people are able to communicate with my laptop


The rules for public networks are very simple.

- Allow all outgoing traffic



On a laptop, inbound connections should be restricted unless you want
services to be accessible on your laptop by way of FWing and and
securing the services.

Outbound connections is up to you.

--
John Doe

Re: Internet facing Firewalls mDNS UPnP SMB

2024-08-03 Thread jeremy ardley




On 4/08/2024 12:26 pm, George at Clug wrote:


If I go to the local coffee shop and connect my laptop to their WiFi, 
which incoming and now outgoing ports should I have blocked to ensure 
that no nefarious people are able to communicate with my laptop


The rules for public networks are very simple.

- Allow all outgoing traffic

- Allow related/established incoming connections. That is if your system 
connects to a remote system and that remote system responds, it will 
reply to your originating port or may also reply/connect to another port 
on your system. You want allow those.


- If you have specific needs to receive multicast (such as mDNS) you 
need to enable that for each case.


- Finally block all other incoming connections.

Internet facing Firewalls mDNS UPnP SMB

2024-08-03 Thread George at Clug

Hi,

Thanks to all who have been explaining mDNS nssswitch, etc.

I had not realised how 'chatty' our computers have become.

If I go to the local coffee shop and connect my laptop to their WiFi,
which incoming and now outgoing ports should I have blocked to ensure
that no nefarious people are able to communicate with my laptop?

For some of my servers I block all "low ports" 0-1023 for both
incoming and outgoing ports, only opening whatever ports are actually
required (incoming ports for the server's services, outgoing ports for
DNS, software updating, etc). I have left "high ports" 1024-65535
open.

My understanding of networking was:

Low ports are used for services listening for incoming traffic to
establish communications, high ports are used when comminations with a
service has been established and on going communication will continue
and so it is agreed that the communications will continue on a new,
high port number (ephemeral).

For example, a request for an FTP transfer will start on port 21, but
the actual transfer/s will be move to using a high port number,
freeing port 21 for listening for new incoming FTP requests.

If my computer's services start communicating on high ports, for
example, mDNS uses port 5353/udp, then I expect I should block these
high ports to/from the Internet.

Which brings me back to "what ports" are systems today using? mDNS is
news to me, and ignorantly I have never thought of the implications of
UPnP even though I new it existed as a technology.

Hence which high ports should be blocked in the Internet firewall to
outgoing and/or incoming traffic?

I am only familiar with the idea of "low ports" 0-1023 and "high
ports" 1024-65535, dating back to the 1990's, so I guess things
'might' have changed since then.

Previously I only blocked "low ports" 0-1023, and leave high ports not
blocked, but now that services are using ports above 1023, should I be
blocking more ports?

https://en.wikipedia.org/wiki/Port_(computer_networking)
The well-known ports (also known as system ports) are those numbered
from 0 through 1023.
The registered ports are those from 1024 through 49151. IANA maintains
the official list of well-known and registered ranges.[3]
The dynamic or private ports are those from 49152 through 65535. One
common use for this range is for ephemeral ports.

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known_ports

Though I find different interpretations as to the use of various
ports:

https://support.checkpoint.com/results/sk/sk156852
The different type of ports:
Low: Reserved ports for services that require ports from 600 to
1024.
High: Ports for general use, from 10,000 to 60,000.
Extra: Reserved ports for VoIP connections, from 60,000 and
above.

This comment made me smile:
"Ports numbered 64000 (an arbitrary number which might be varied as a
result of experience) or above will not be blocked because, as far as
UIS is aware, these have not so far been used for malicious activities
to any extent. "

https://help.uis.cam.ac.uk/service/network-services/techref/portblocking

Other sources:

https://support.huawei.com/enterprise/en/doc/EDOC1100297670

High-Risk Ports: What Are the Common High-Risk Ports and How to Block
Them

https://support.microsoft.com/en-au/topic/preventing-smb-traffic-from-lateral-connections-and-entering-or-leaving-the-network-c0541db7-2244-0dce-18fd-14a3ddeb282a
Perimeter hardware and appliance firewalls that are positioned at the
edge of the network should block unsolicited communication (from the
internet) and outgoing traffic (to the internet) to the following
ports.

https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/CERT-Bund-Reports/HowTo/Offene-mDNS-Dienste/Offene-mDNS-Dienste_node.html
Multicast DNS (mDNS) is used for resolving host names to IP addresses
within small networks that do not include a local DNS server. It is
implemented e. g. by the Apple 'Bonjour' and Linux/BSD 'Avahi'
(nss-mdns) services. mDNS uses port 5353/udp.

https://www.sprocketsecurity.com/resources/why-no-workstation-needs-inbound-smb
Why no Workstation Needs Inbound SMB

https://nordvpn.com/blog/what-is-upnp/
What is UPnP and why you should disable it immediately

https://www.hackercombat.com/the-universal-plug-plays-unending-security-nightmare/
The Universal Plug & Play’s Unending Security Nightmare
What made UPnP vulnerabilities as effective attack surface/loophole is
the tyranny of the default.

George

Re: I can confirm that Fortigate firewalls are definitely based on Linux

2023-06-22 Thread tomas

On Thu, Jun 22, 2023 at 09:33:57PM +0800, Turritopsis Dohrnii Teo En Ming wrote:
> On Thu, 22 Jun 2023 at 21:22,  wrote:
> >
> > On Thu, Jun 22, 2023 at 09:17:17PM +0800, Turritopsis Dohrnii Teo En Ming 
> > wrote:
> > > Subject: I can confirm that Fortigate firewalls are definitely based on 
> > > Linux
> > >
> > > Good day from Singapore,
> >
> > [...]
> >
> > > Do you guys know which Linux distro Fortigate firewalls are based on?
> > > I would like to know. This will be very interesting.
> >
> > If I were you, I'd ask Fortigate: if they are using GPL licensed components
> > (the Linux kernel would be one), they have to give you a copy of their
> > modified sources.
> >
> > Cheers
> > --
> > t
> 
> I think Fortinet wouldn't say.

I think you might want to practice your search-engine-fu :) It seems
that someone (Harald Welte) has been already there [1].

So if they still don't say, they are clearly repeat offenders. Do ask
them, don't be lazy, and if they don't comply, tell gpl-violations.org.

Cheers

[1] https://en.wikipedia.org/wiki/Gpl-violations.org#Fortinet
-- 
t


signature.asc
Description: PGP signature

Re: I can confirm that Fortigate firewalls are definitely based on Linux

2023-06-22 Thread Nils

On Donnerstag, 22. Juni 2023 15:33:57 CEST Turritopsis Dohrnii Teo En Ming 
wrote:
> I think Fortinet wouldn't say.


They are required to ;-)


signature.asc
Description: This is a digitally signed message part.

Re: I can confirm that Fortigate firewalls are definitely based on Linux

2023-06-22 Thread Turritopsis Dohrnii Teo En Ming

On Thu, 22 Jun 2023 at 21:22,  wrote:
>
> On Thu, Jun 22, 2023 at 09:17:17PM +0800, Turritopsis Dohrnii Teo En Ming 
> wrote:
> > Subject: I can confirm that Fortigate firewalls are definitely based on 
> > Linux
> >
> > Good day from Singapore,
>
> [...]
>
> > Do you guys know which Linux distro Fortigate firewalls are based on?
> > I would like to know. This will be very interesting.
>
> If I were you, I'd ask Fortigate: if they are using GPL licensed components
> (the Linux kernel would be one), they have to give you a copy of their
> modified sources.
>
> Cheers
> --
> t

I think Fortinet wouldn't say.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: I can confirm that Fortigate firewalls are definitely based on Linux

2023-06-22 Thread tomas

On Thu, Jun 22, 2023 at 09:17:17PM +0800, Turritopsis Dohrnii Teo En Ming wrote:
> Subject: I can confirm that Fortigate firewalls are definitely based on Linux
> 
> Good day from Singapore,

[...]

> Do you guys know which Linux distro Fortigate firewalls are based on?
> I would like to know. This will be very interesting.

If I were you, I'd ask Fortigate: if they are using GPL licensed components
(the Linux kernel would be one), they have to give you a copy of their
modified sources.

Cheers
-- 
t


signature.asc
Description: PGP signature

I can confirm that Fortigate firewalls are definitely based on Linux

2023-06-22 Thread Turritopsis Dohrnii Teo En Ming

Subject: I can confirm that Fortigate firewalls are definitely based on Linux

Good day from Singapore,

These few days, I have discovered that the output of the Fortigate
firewall CLI command "diag hardware sysinfo cpu" is exactly the same
as the output of the command "cat /proc/cpuinfo" in Linux operating
systems. Hence I can confirm that the underlying operating system of
Fortigate firewalls is definitely Linux. But I do not know which Linux
distro Fortigate firewalls are based on.

Fortigate 90E firewall has 2-Core Intel(R) Atom(TM) CPU  C2338  @
1.74GHz processor.

Fortigate 101F firewall has 8-core ARMv8 Processor rev 4 (v8l) 1400
MHz processor.

Fortigate 200F firewall has 8-core Intel(R) Xeon(R) CPU D-1627 @
2.90GHz processor.

I will try to find out what processors my own personal Fortigate 60D
and Fortigate 60E firewalls have later on.

I have configured and deployed 22 Fortigate firewalls for 20
companies/organizations in Singapore so far (as of 22 June 2023
Thursday). On 15 June 2020, I joined my present company (Systems
Integrator/Managed Services) as an IT support engineer. I have been
working at my present company for slightly more than 3 years already.
My 3rd anniversary falls on 15 June 2023.

The following are useful commands for troubleshooting high CPU usage
on Fortigate firewalls (provided by Fortinet technical support).

get system status
get system performance status --run 5 times
diag hardware sysinfo cpu
diag sys top
diag debug crashlog read
execute tac report

Do you guys know which Linux distro Fortigate firewalls are based on?
I would like to know. This will be very interesting.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
Blogs:
https://tdtemcerts.blogspot.com
https://tdtemcerts.wordpress.com
GIMP also stands for Government-Induced Medical Problems.

Re: firewalls

2020-08-05 Thread Kenneth Parker

On Wed, Aug 5, 2020, 7:22 AM deloptes  wrote:

> Dan Ritter wrote:
>
> > After install you have a powerful L3 firewall system available to
> > you, but not configured to block anything.
> >
> > There are two command-line interfaces to it, iptables and
> > nftables. nftables is the newer interface, but iptables has more
> > documentation written.
> >
> > You also have options to install other interfaces to the system.
>
> I've been struggling with those for years and tried many tools ... at the
> end I ended up with shorewall.
>
> While most of the tools target a single host - perhaps desktop or notebook
> computer. I also needed flexibility and simplicity configuring a firewall
> with 3 interfaces (DMZ, intranet and internet). I must admit that shorewall
> beat it all.
>
> So while some distros like RedHat offer active firewall per default, Debian
> gives you the choice what system you will choose to manage the firewall.
>
> It is matter of philosophy and I allow to speak for some of the users here,
> that we really appreciate this philosophy of choice.
>
> I don't know about Ubuntu, I would expect it would have a preconfigured
> firewall and some kind of Gnome interface to it.
>

Ubuntu has a package, ufw (Uncomplicated Firewall), as a frontend to
iptables.  It is off, by default.

Along with Debian (and Devuan), I use Xubuntu, for xfce.  I have not tried
the "original" Gnome version of Ubuntu, though I run a Partition with
Buster Gnome.

Kenneth Parker

Re: firewalls

2020-08-05 Thread deloptes

Dan Ritter wrote:

> After install you have a powerful L3 firewall system available to
> you, but not configured to block anything.
> 
> There are two command-line interfaces to it, iptables and
> nftables. nftables is the newer interface, but iptables has more
> documentation written.
> 
> You also have options to install other interfaces to the system.

I've been struggling with those for years and tried many tools ... at the
end I ended up with shorewall.

While most of the tools target a single host - perhaps desktop or notebook
computer. I also needed flexibility and simplicity configuring a firewall
with 3 interfaces (DMZ, intranet and internet). I must admit that shorewall
beat it all.

So while some distros like RedHat offer active firewall per default, Debian
gives you the choice what system you will choose to manage the firewall.

It is matter of philosophy and I allow to speak for some of the users here,
that we really appreciate this philosophy of choice.

I don't know about Ubuntu, I would expect it would have a preconfigured
firewall and some kind of Gnome interface to it.

regards

Re: firewalls

2020-08-05 Thread Reco

Hi.

On Wed, Aug 05, 2020 at 07:11:12AM -0400, Dan Ritter wrote:
> riveravaldez wrote: 
> > 
> > If I can ask: which is the situation, in this aspect, in a plain
> > plain/straightforward Debian (net)installation? Let's say: what's the
> > by-default setting of the system?
> 
> 
> After install you have a powerful L3 firewall system

A small nitpick - netfilter is L4, not L3, although it can be used as
such. netfilter is more than capable of matching IP-based transport
level protocols and their properties.

Reco

Re: firewalls

2020-08-05 Thread Dan Ritter

riveravaldez wrote: 
> 
> If I can ask: which is the situation, in this aspect, in a plain
> plain/straightforward Debian (net)installation? Let's say: what's the
> by-default setting of the system?

After install you have a powerful L3 firewall system available to
you, but not configured to block anything.

There are two command-line interfaces to it, iptables and
nftables. nftables is the newer interface, but iptables has more
documentation written.

You also have options to install other interfaces to the system.

-dsr-

Re: firewalls

2020-08-05 Thread Andrei POPESCU

On Ma, 04 aug 20, 22:56:21, riveravaldez wrote:
> 
> If I can ask: which is the situation, in this aspect, in a plain
> plain/straightforward Debian (net)installation? Let's say: what's the
> by-default setting of the system?

There is no firewall configured by default in Debian.

The configuration between a typical "server" and a typical "client" 
system (desktop, laptop) is different enough to make it very difficult 
to come up with a useful default configuration.

Besides, one can also run services on a client system or use a server as 
client system, etc.

See also this discussion on -devel
https://lists.debian.org/debian-devel/2019/07/msg00332.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

signature.asc
Description: PGP signature

Re: firewalls

2020-08-04 Thread mick crane


On 2020-08-05 00:51, Dan Ritter wrote:

mick crane wrote:
I've never really understood firewalls. I think the idea is that they 
don't
let anything in that wasn't requested but if you go on a website there 
are
so many hundreds of scripts looking at this and that who knows what 
happens.


I notice you didn't ask a question, but I'll answer it anyway.

Near the bottom of the stack of networking is a link layer. For
ethernet and related protocols, that means that there's an
address for each interface -- ethernet calls it the MAC address.

If you build a firewall to intercept at this level, you can stop
traffic from specific local sources. That's it. There are
situations where we do this -- layer 2 firewalling -- but they
aren't very common.

The next layer up, called layer 3, is IP addressing. IP
connections involve IP addresses and IP subprotocols: UDP, TCP,
and so forth. This is where most firewalls operate. An L3
firewall usually starts with a generic directive to drop all
traffic that it doesn't specifically allow, and then has a list
of what to allow to each or all addresses being protected.

So: you can stop all DNS traffic from Cloudflare, but you can't
drop JavaScript embedded in a web page from Google.

To do that, you need what is generically called an
application-layer firewall, and those are usually set up on
individual machines -- though they don't have to be -- and are
frequently supplied with extensive, rapidly-updated block lists.

Some of them you even run *inside* your web browser: uBlock
Origin, for example. Highly recommended.

-dsr-

P.S. you may be wondering why the numbering goes 2, 3,
"application". This is because:

a) the OSI 7-layer model doesn't actually represent real
   networks in this universe
b) everything above layer 3 is kind of squishy
c) most firewalls are actually reflecting the owner's policies
in layers 8 and 9 of the 7-layer model: religion and politics.


thanks for that.
I dunno, have pfsense with community snort on it between me and the ISP 
router so I guess I'm OK with people having a go at the IP address but 
with the browser I imagine you can't filter every packet so somebody who 
doesn't really know what they are doing has to rely on whoever wrote the 
browser I suppose.


mick
--
Key ID4BFEBB31

Re: firewalls

2020-08-04 Thread riveravaldez

On 8/4/20, Dan Ritter  wrote:
> mick crane wrote:
>> I've never really understood firewalls. I think the idea is that they
>> don't
>> let anything in that wasn't requested but if you go on a website there
>> are
>> so many hundreds of scripts looking at this and that who knows what
>> happens.
>
> I notice you didn't ask a question, but I'll answer it anyway.
>
> Near the bottom of the stack of networking is a link layer. For
> ethernet and related protocols, that means that there's an
> address for each interface -- ethernet calls it the MAC address.
>
> If you build a firewall to intercept at this level, you can stop
> traffic from specific local sources. That's it. There are
> situations where we do this -- layer 2 firewalling -- but they
> aren't very common.
>
> The next layer up, called layer 3, is IP addressing. IP
> connections involve IP addresses and IP subprotocols: UDP, TCP,
> and so forth. This is where most firewalls operate. An L3
> firewall usually starts with a generic directive to drop all
> traffic that it doesn't specifically allow, and then has a list
> of what to allow to each or all addresses being protected.
>
> So: you can stop all DNS traffic from Cloudflare, but you can't
> drop JavaScript embedded in a web page from Google.
>
> To do that, you need what is generically called an
> application-layer firewall, and those are usually set up on
> individual machines -- though they don't have to be -- and are
> frequently supplied with extensive, rapidly-updated block lists.
>
> Some of them you even run *inside* your web browser: uBlock
> Origin, for example. Highly recommended.
>
> -dsr-
>
> P.S. you may be wondering why the numbering goes 2, 3,
> "application". This is because:
>
> a) the OSI 7-layer model doesn't actually represent real
>networks in this universe
> b) everything above layer 3 is kind of squishy
> c) most firewalls are actually reflecting the owner's policies
> in layers 8 and 9 of the 7-layer model: religion and politics.

Thanks a lot, Dan.

That was extremely educative (and beautiful).

If I can ask: which is the situation, in this aspect, in a plain
plain/straightforward Debian (net)installation? Let's say: what's the
by-default setting of the system?

Regards

Re: firewalls

2020-08-04 Thread Dan Ritter

mick crane wrote: 
> I've never really understood firewalls. I think the idea is that they don't
> let anything in that wasn't requested but if you go on a website there are
> so many hundreds of scripts looking at this and that who knows what happens.

I notice you didn't ask a question, but I'll answer it anyway.

Near the bottom of the stack of networking is a link layer. For
ethernet and related protocols, that means that there's an
address for each interface -- ethernet calls it the MAC address.

If you build a firewall to intercept at this level, you can stop
traffic from specific local sources. That's it. There are
situations where we do this -- layer 2 firewalling -- but they
aren't very common. 

The next layer up, called layer 3, is IP addressing. IP
connections involve IP addresses and IP subprotocols: UDP, TCP,
and so forth. This is where most firewalls operate. An L3
firewall usually starts with a generic directive to drop all
traffic that it doesn't specifically allow, and then has a list
of what to allow to each or all addresses being protected.

So: you can stop all DNS traffic from Cloudflare, but you can't
drop JavaScript embedded in a web page from Google.

To do that, you need what is generically called an
application-layer firewall, and those are usually set up on
individual machines -- though they don't have to be -- and are
frequently supplied with extensive, rapidly-updated block lists.

Some of them you even run *inside* your web browser: uBlock
Origin, for example. Highly recommended.

-dsr-

P.S. you may be wondering why the numbering goes 2, 3,
"application". This is because:

a) the OSI 7-layer model doesn't actually represent real
   networks in this universe
b) everything above layer 3 is kind of squishy
c) most firewalls are actually reflecting the owner's policies
in layers 8 and 9 of the 7-layer model: religion and politics.

Re: firewalls

2020-08-04 Thread deloptes

mick crane wrote:

> I've never really understood firewalls. I think the idea is that they
> don't let anything in that wasn't requested but if you go on a website
> there are so many hundreds of scripts looking at this and that who knows
> what happens.

this is a good point :) especially with a browser that has audio and
probably video hook up and running :D

firewalls

2020-08-04 Thread mick crane

I've never really understood firewalls. I think the idea is that they 
don't let anything in that wasn't requested but if you go on a website 
there are so many hundreds of scripts looking at this and that who knows 
what happens.


mick

--
Key ID4BFEBB31

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-22 Thread Rick Thomas



On Apr 22, 2013, at 4:55 AM, Celejar wrote:


Yes: http://m19s28.dyndns.org/iblech/nat-traverse/#technique

General discussion:
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html


Celejar


Thanks!  Interesting stuff...

Rick


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/f6eb04a6-7095-4f9f-b6c2-1251afba1...@pobox.com

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-22 Thread Celejar

On Sun, 21 Apr 2013 23:59:00 -0700
Rick Thomas  wrote:

> Alberto,
> 
> What you want to do is possible.  In particular, skype and bittorrent do it.
> 
> As I understand it, they make use of a server with a public IP address.  I'm 
> not going to get it exactly right, but the general idea is this:
> 
> Two clients, A and B, both behind NAT firewalls.  Server, S, with a public 
> IP, i.e. *not* behind NAT.
> 
> A calls S and says I want to talk to B.  (This is possible because the call 
> is originated inside A's NAT)
> At approximately the same time, B calls S and says I'm willing to talk to A. 
> (Possible because call is originated inside B's NAT)
> 
> Server tells each of A and B (over the connections each of them have open 
> with S) in exactly 1 second (or whenever) from receiving this packet, try to 
> open a connection to your opposite number on port 4 (or whatever).
> 
> With luck, each NAT will receive and act upon the outgoing request to setup 
> the connection *before* it receives the incoming request.  So by the time the 
> incoming request is received, the channel will be open and ready to receive.
> 
> If it doesn't work the first time, try again with slightly different timing.
> 
> Keep trying until it does work -- or you get tired and quit.
> 
> The result is a direct connection between A and B, which *both* NATs see as 
> having been started from inside.
> 
> The server, S, is only involved for a brief time at the beginning.
> 
> Other than skype and bittorrent, I'm not aware of any packages that do this.  
> Neither of them are directly useful for your purposes.
> 
> It's possible that nat-traverse is a general purpose implementation of this 
> trick, but I haven't read the documentation, so I can't say for sure.

Yes: http://m19s28.dyndns.org/iblech/nat-traverse/#technique

General discussion:
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html


Celejar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130422075508.4caa8c8b.cele...@gmail.com

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-21 Thread Rick Thomas

Alberto,

What you want to do is possible.  In particular, skype and bittorrent do it.

As I understand it, they make use of a server with a public IP address.  I'm 
not going to get it exactly right, but the general idea is this:

Two clients, A and B, both behind NAT firewalls.  Server, S, with a public IP, 
i.e. *not* behind NAT.

A calls S and says I want to talk to B.  (This is possible because the call is 
originated inside A's NAT)
At approximately the same time, B calls S and says I'm willing to talk to A. 
(Possible because call is originated inside B's NAT)

Server tells each of A and B (over the connections each of them have open with 
S) in exactly 1 second (or whenever) from receiving this packet, try to open a 
connection to your opposite number on port 4 (or whatever).

With luck, each NAT will receive and act upon the outgoing request to setup the 
connection *before* it receives the incoming request.  So by the time the 
incoming request is received, the channel will be open and ready to receive.

If it doesn't work the first time, try again with slightly different timing.

Keep trying until it does work -- or you get tired and quit.

The result is a direct connection between A and B, which *both* NATs see as 
having been started from inside.

The server, S, is only involved for a brief time at the beginning.

Other than skype and bittorrent, I'm not aware of any packages that do this.  
Neither of them are directly useful for your purposes.

It's possible that nat-traverse is a general purpose implementation of this 
trick, but I haven't read the documentation, so I can't say for sure.

Enjoy!

Rick

On Apr 18, 2013, at 2:18 PM, alberto fuentes wrote:

> Its a long shot because i can really picture how could it work
> 
> I know I can connect using the third server, but I just want to use the 
> server to establish the connection
> 
> Any ideas :)

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f24df815-cd06-4ad8-9177-7e698d454...@pobox.com

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Kevin Chadwick

> That looks like you have to somehow be logged into both hosts and run 
> nat-traverse on each.  But it looks interesting.

Firewalls can track and block UDP (create state) even if it is a
stateless protocol too, so you may have to have control of the gateways
too.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130419230357.556ad...@kc-sys.chadwicks.me.uk

Re: connect directly to another computer bypassing firewalls using a third server

On Fri, Apr 19, 2013 at 10:29 PM, alberto fuentes  wrote:

> Actually I got the idea from filetea [0]
>

I just checked it out. Its less magical than I thought. It *does* use the
server to route all packets :(

Re: connect directly to another computer bypassing firewalls using a third server

On Fri, Apr 19, 2013 at 6:56 PM, Bob Proulx  wrote:

>  Since alberto said that both A and B know about Server then NAT
> traversal shouldn't be needed.
>

Actually I want to connect from A to B directly, so nat traversal seems
nice, but I cant try it right now... when I have the machine back up I will
try it and report back ;)

>
> > > Both computer A and B know about Server.
>
> If both A and B can get to Server then it is very easy to just hop
> through Server to get to the other.
>

The server is just a convenience since both machines are behind firewalls,
but I would like to avoid having to use it, because packets have to travel
long distance. Also Im planning to make heavy use of it and I have to pay
for bandwidth on server ;)

Actually I got the idea from filetea [0] that allows to send files from A
to B using a third server to make the connection. Actually I dont know how
it works and if the traffic is sent through the server. Now that I think
about it, I guess it does and I thought it was only used to establish the
connection

if nat-travesal works, it seems the only way so far to do it. I only need
the vpn to start it on both ends. I will see how to automate this :)

[0] https://filetea.me/default/

Re: connect directly to another computer bypassing firewalls using a third server

On Fri, Apr 19, 2013 at 6:32 PM, Bob Proulx  wrote:

> alberto fuentes wrote:
> > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> >
> > To make it a little more clear. Both computer A and B know about Server.
> > Right now I use openvpn to bring all the computers together into the same
> > network. But it seems too much overhead being both computers on the same
> > city. Even if the server where in the same city as well, it adds another
> > extra jump that i would like to avoid.
>
> Then using ssh -W as I originally suggested is easy and will do it.
>

Thank you for your answer

-W will not do because all the traffic has to go through the server even if
its transparent from the point of view of the client A. Also it will hit
the firewall when trying to reach B from the server.

Right now A and B connect to vpn in server and so I can connect from A to B
via vpn, But i wanted to avoid having to send packets that far since I plan
to be using the connection heavily.

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Lars Nooden

On Fri, 19 Apr 2013, green wrote:

> Lars Nooden wrote at 2013-04-19 10:35 -0500:
> > On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes  wrote:
> > > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> > 
> > To make a direct connection between A and B with ssh, you need to have at 
> > least on of them be publicly available even if the other is blocked behind 
> > a firewall.
> 
> nat-traverse is something new (to me at least) that supposedly allows
> a direct connection to be made between 2 systems which are *both*
> behind NAT/masquerading gateways.  In this case, the third publicly
> accessible server would not be necessary, and traffic would not be
> required to leave the local area.
> 
> http://m19s28.dyndns.org/iblech/nat-traverse/

That looks like you have to somehow be logged into both hosts and run 
nat-traverse on each.  But it looks interesting.

Regards,
/Lars


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/alpine.bso.2.03.1304192133250.13...@gmail.com

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Bob Proulx

green wrote:
> Lars Nooden wrote:
> > alberto fuentes wrote:
> > > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> > 
> > To make a direct connection between A and B with ssh, you need to have at 
> > least on of them be publicly available even if the other is blocked behind 
> > a firewall.
> 
> nat-traverse is something new (to me at least) that supposedly allows
> a direct connection to be made between 2 systems which are *both*
> behind NAT/masquerading gateways.  In this case, the third publicly
> accessible server would not be necessary, and traffic would not be
> required to leave the local area.
> 
> http://m19s28.dyndns.org/iblech/nat-traverse/

Since alberto said that both A and B know about Server then NAT
traversal shouldn't be needed.

> > Both computer A and B know about Server.

If both A and B can get to Server then it is very easy to just hop
through Server to get to the other.

Bob


signature.asc
Description: Digital signature

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread green

Lars Nooden wrote at 2013-04-19 10:35 -0500:
> On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes  wrote:
> > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> 
> To make a direct connection between A and B with ssh, you need to have at 
> least on of them be publicly available even if the other is blocked behind 
> a firewall.

nat-traverse is something new (to me at least) that supposedly allows
a direct connection to be made between 2 systems which are *both*
behind NAT/masquerading gateways.  In this case, the third publicly
accessible server would not be necessary, and traffic would not be
required to leave the local area.

http://m19s28.dyndns.org/iblech/nat-traverse/

signature.asc
Description: Digital signature

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Bob Proulx

alberto fuentes wrote:
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> 
> To make it a little more clear. Both computer A and B know about Server.
> Right now I use openvpn to bring all the computers together into the same
> network. But it seems too much overhead being both computers on the same
> city. Even if the server where in the same city as well, it adds another
> extra jump that i would like to avoid.

Then using ssh -W as I originally suggested is easy and will do it.

On A (you):

  ssh -o ProxyCommand="ssh -W %h:%p server" B

Look in my previous message for how to put this in your ssh config file.

Bob


signature.asc
Description: Digital signature

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Lars Nooden

On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes  wrote:
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)

To make a direct connection between A and B with ssh, you need to have at 
least on of them be publicly available even if the other is blocked behind 
a firewall.  Depending on the direction you are connecting in that case 
you may need to use a reverse tunnel.

Regards,
/Lars


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/alpine.bso.2.03.1304191833160.13...@gmail.com

Re: connect directly to another computer bypassing firewalls using a third server

On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes  wrote:

> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>

To make it a little more clear. Both computer A and B know about Server.
Right now I use openvpn to bring all the computers together into the same
network. But it seems too much overhead being both computers on the same
city. Even if the server where in the same city as well, it adds another
extra jump that i would like to avoid.

Thank you

Re: connect directly to another computer bypassing firewalls using a third server

On Fri, Apr 19, 2013 at 1:24 PM, Pascal Hambourg wrote:

> I guess the OP means "packets" instead of "packages". Some languages
> have the same word for "packet" and "package". However I cannot figure
> out clearly what he is asking for either.
>
>
Yes. I never noticed packages and packets are the same word in my language.

Sorry to express myself so badly. Its evident my question was confusing

I want to avoid the packets travel overseas to connect via vpn to another
computer in my own city. I mean ssh, yes.

I can connect to the computer in my city opening ports in the firewall for
every specific case. And I usually do so. But i was looking for a generic
way to use in a third party (openvpn server overaseas) to just handle the
establishment of the connection somehow avoiding all firewalls. Some way
for B to know I want to establish ssh conection with him and once the
connection and dont make all the packets of the session go to the server,
just the initial handshake (generic use of word handshake, not necesarily
tpc/ip handshake)

A (me) -> Server (overseas) -> B (arbitrary computer in my city)

This seems rather hard and I cant even picture how would it work. Ill take
a look at the nat-traverse package and report back :)

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-19 Thread Pascal Hambourg

Hello,

Bob Proulx a écrit :
> 
> You first mentioned connecting to a server so I guessed ssh.  That was
> apparently not what you were asking about.  Now you mention packages.
> I could guess that you want to set up an apt proxy of some sort.  Is
> that what you are asking about?  A way to set up an apt proxy?  If you
> don't say then I give up.

I guess the OP means "packets" instead of "packages". Some languages
have the same word for "packet" and "package". However I cannot figure
out clearly what he is asking for either.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5171297c.4020...@plouf.fr.eu.org

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-18 Thread green

alberto fuentes wrote at 2013-04-18 16:18 -0500:
> Its a long shot because i can really picture how could it work
> 
> I know I can connect using the third server, but I just want to use the
> server to establish the connection

Perhaps the nat-traverse package is of interest to you.


signature.asc
Description: Digital signature

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-18 Thread Bob Proulx

alberto fuentes wrote:
> That way all the packages would be forwarded via the server.
> 
> The server is overseas. Im trying to connect to a computer in my city.
> Packages have to travel and comeback. I was hoping some kind of magic that
> would allow me to use the server overseas *just* to establish the
> connection between the two computers :)

First you must tell us what server.  Apache?  OpenSSH?  OpenVPN?
MySQL?  There are zillions of servers.

Please.  Just tell us what you are asking.  I cannot guess.

You first mentioned connecting to a server so I guessed ssh.  That was
apparently not what you were asking about.  Now you mention packages.
I could guess that you want to set up an apt proxy of some sort.  Is
that what you are asking about?  A way to set up an apt proxy?  If you
don't say then I give up.

Bob

signature.asc
Description: Digital signature

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-18 Thread alberto fuentes

On Thu, Apr 18, 2013 at 11:27 PM, Bob Proulx  wrote:

> alberto fuentes wrote:
> > Subject: connect directly to another computer bypassing firewalls
> > using a third server
> > Its a long shot because i can really picture how could it work
> >
> > I know I can connect using the third server, but I just want to use the
> > server to establish the connection
>
> The crystal ball isn't working well today.  Please say more about what
> you are asking to do.
>
> Are you asking for something like this?
>
>   Host lilypadmachine.example.com
> ProxyCommand none
>
>   Host *.example.com
> ProxyCommand ssh -W %h:%p lilypadmachine.example.com
>
>
That way all the packages would be forwarded via the server.

The server is overseas. Im trying to connect to a computer in my city.
Packages have to travel and comeback. I was hoping some kind of magic that
would allow me to use the server overseas *just* to establish the
connection between the two computers :)

Re: connect directly to another computer bypassing firewalls using a third server

2013-04-18 Thread Bob Proulx

alberto fuentes wrote:
> Subject: connect directly to another computer bypassing firewalls
> using a third server
> Its a long shot because i can really picture how could it work
> 
> I know I can connect using the third server, but I just want to use the
> server to establish the connection

The crystal ball isn't working well today.  Please say more about what
you are asking to do.

Are you asking for something like this?

  Host lilypadmachine.example.com
ProxyCommand none

  Host *.example.com
ProxyCommand ssh -W %h:%p lilypadmachine.example.com

Bob


signature.asc
Description: Digital signature

connect directly to another computer bypassing firewalls using a third server

2013-04-18 Thread alberto fuentes

Its a long shot because i can really picture how could it work

I know I can connect using the third server, but I just want to use the
server to establish the connection

Any ideas :)

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-29 Thread Pascal Hambourg

Matej Kosik a écrit :
>>> I am experiencing some deterministic packet drop:
>>> - when I tcpreplay on "lo" some pcap (0.pcap) file,
>>>   that traffic does not reach listening applications
> 
> I have discovered the following regularity:
> - if source IP address in given pcap is one of "my" IP addresses,
>   then when I try to tcpreplay given pcap, the data is not delivered
>   to applications
> - if I change all source IP addresses to any other non-local
>   IP addresses (e.g. 10.0.10.6, 10.0.10.7, ...
>   or if I use whatever other address from local network
>   except for my address), then when I tcpreplay modified pcap file,
>   then data is delivered to applications.

The tcpreplay FAQ (e.g. ) mentions
this issue, but the explanation about layer-2 header sounds dubious, as
just changing the source IP address changes the behaviour.

I may be wrong, but this sounds very much to me like the "martian
source" filtering which discards incoming IP packets with a source
address belonging to the host. Of course this should not happen (and
does not normally happen) on a loopback interface ; but my guess is that
"normally" generated IP packets sent over the loopback interface may
take some kind of "shortcut" in the networking stack and skip this
check, whereas packets injected by tcpreplay may take the full inbound
path as if they had be received on an external interface. You can enable
the log_martians sysctl to check this.

> iptables-save does not print anything so the list of rules might be
> empty, I guess.

Correct. Actually iptables is not even active (loaded), otherwise
iptables-save would at least display the empty built-in chains.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b7bcb4.3070...@plouf.fr.eu.org

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-29 Thread Matej Kosik

On 11/28/2012 12:04 PM, Darac Marjal wrote:
> On Wed, Nov 28, 2012 at 11:54:04AM +, Matej Kosik wrote:
>> Hi,
>>
>> I am experiencing some deterministic packet drop:
>> - when I tcpreplay on "lo" some pcap (0.pcap) file,
>>   that traffic does not reach listening applications
>> - when I change source IP address from whatever it was to, e.g.,
>>   10.0.10.6, 10.0.10.7 etc,
>>   then when I try to replay the modified pcap file (1.pcap),
>>   that traffic does reache applications.
>>
>> I would like to find out the cause of this.
>> The only thing which could be causing thing I was aware of was
>> "iptables". However, when I apt-get removed it, nothing changed.
>>
>> What else should I check?
> 
> Have a look at the TCP sequence numbers and the TCP Handshake.

In my case, given pcap contains only some UDP multicast traffic.
There are not TCP segments.

> To
> establish a connection:
>  * The client sends a SYN packet to the server with a random sequence
>number (A).
>  * The server replies with a SYN-ACK packet with an acknowledgement
>number set to one more than the client's sequence number (A + 1) 
>and its own random sequence number (B).
>  * The client sends an ACK packet to the server with an acknowledgement
>number set to one more than the servers sequence number (B + 1) and
>a sequence number of the received acknowlegement number (A + 1).
> 
> So, when you replay the traffic, that third stage goes wrong (basically,
> you send the wrong B+1 value).
> 
> Have a look at
> "http://tcpreplay.synfin.net/wiki/FAQ#Doestcpreplaysupportsendingtraffictoaserver";
> 




signature.asc
Description: OpenPGP digital signature

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-29 Thread Matej Kosik

On 11/29/2012 12:21 AM, Pascal Hambourg wrote:
> Hello,
> 
> Matej Kosik a écrit :
>>
>> I am experiencing some deterministic packet drop:
>> - when I tcpreplay on "lo" some pcap (0.pcap) file,
>>   that traffic does not reach listening applications
>> - when I change source IP address from whatever it was to, e.g.,
>>   10.0.10.6, 10.0.10.7 etc,
> 
> Why these addresses ? What's special with them ?
> What is the original source address ?

I have discovered the following regularity:
- if source IP address in given pcap is one of "my" IP addresses,
  then when I try to tcpreplay given pcap, the data is not delivered
  to applications
- if I change all source IP addresses to any other non-local
  IP addresses (e.g. 10.0.10.6, 10.0.10.7, ...
  or if I use whatever other address from local network
  except for my address), then when I tcpreplay modified pcap file,
  then data is delivered to applications.

> 
>>   then when I try to replay the modified pcap file (1.pcap),
>>   that traffic does reache applications.
>>
>> I would like to find out the cause of this.
>> The only thing which could be causing thing I was aware of was
>> "iptables". However, when I apt-get removed it, nothing changed.
> 
> You can display the active ruleset with iptables-save.
> 
> 

iptables-save does not print anything so the list of rules might be
empty, I guess.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b7218b.5030...@gmail.com

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-28 Thread Pascal Hambourg

Hello,

Matej Kosik a écrit :
> 
> I am experiencing some deterministic packet drop:
> - when I tcpreplay on "lo" some pcap (0.pcap) file,
>   that traffic does not reach listening applications
> - when I change source IP address from whatever it was to, e.g.,
>   10.0.10.6, 10.0.10.7 etc,

Why these addresses ? What's special with them ?
What is the original source address ?

>   then when I try to replay the modified pcap file (1.pcap),
>   that traffic does reache applications.
> 
> I would like to find out the cause of this.
> The only thing which could be causing thing I was aware of was
> "iptables". However, when I apt-get removed it, nothing changed.

You can display the active ruleset with iptables-save.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b6aa9c.7030...@plouf.fr.eu.org

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-28 Thread Andrei POPESCU

On Mi, 28 nov 12, 11:54:04, Matej Kosik wrote:
> The only thing which could be causing thing I was aware of was
> "iptables". However, when I apt-get removed it, nothing changed.

iptables is just the tool to make changes to the kernel firewall. If you 
suspect troubles due to the firewall you are much better of using 
iptables to inspect them and clear the offending rules.

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

signature.asc
Description: Digital signature

Re: a question about firewalls (or whatever else that might cause packet drop)

2012-11-28 Thread Darac Marjal

On Wed, Nov 28, 2012 at 11:54:04AM +, Matej Kosik wrote:
> Hi,
> 
> I am experiencing some deterministic packet drop:
> - when I tcpreplay on "lo" some pcap (0.pcap) file,
>   that traffic does not reach listening applications
> - when I change source IP address from whatever it was to, e.g.,
>   10.0.10.6, 10.0.10.7 etc,
>   then when I try to replay the modified pcap file (1.pcap),
>   that traffic does reache applications.
> 
> I would like to find out the cause of this.
> The only thing which could be causing thing I was aware of was
> "iptables". However, when I apt-get removed it, nothing changed.
> 
> What else should I check?

Have a look at the TCP sequence numbers and the TCP Handshake. To
establish a connection:
 * The client sends a SYN packet to the server with a random sequence
   number (A).
 * The server replies with a SYN-ACK packet with an acknowledgement
   number set to one more than the client's sequence number (A + 1) 
   and its own random sequence number (B).
 * The client sends an ACK packet to the server with an acknowledgement
   number set to one more than the servers sequence number (B + 1) and
   a sequence number of the received acknowlegement number (A + 1).

So, when you replay the traffic, that third stage goes wrong (basically,
you send the wrong B+1 value).

Have a look at
"http://tcpreplay.synfin.net/wiki/FAQ#Doestcpreplaysupportsendingtraffictoaserver";

signature.asc
Description: Digital signature

a question about firewalls (or whatever else that might cause packet drop)

2012-11-28 Thread Matej Kosik

Hi,

I am experiencing some deterministic packet drop:
- when I tcpreplay on "lo" some pcap (0.pcap) file,
  that traffic does not reach listening applications
- when I change source IP address from whatever it was to, e.g.,
  10.0.10.6, 10.0.10.7 etc,
  then when I try to replay the modified pcap file (1.pcap),
  that traffic does reache applications.

I would like to find out the cause of this.
The only thing which could be causing thing I was aware of was
"iptables". However, when I apt-get removed it, nothing changed.

What else should I check?
Which other programs might cause dropping of packets?
Are there any logs with dropped packets?
Or is there a way to enable such logs?

Thank you in advance for any clues.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50b5fb5c.10...@gmail.com

Re: Re(2): openvpn in spite of firewalls

2007-07-19 Thread Celejar

On Thu, 19 Jul 2007 09:16:42 -0700
PETER EASTHOPE <[EMAIL PROTECTED]> wrote:

[snip]

> Not that I know of.  Is there an efficient & reliable 
> way to search for a UDP port?

Nmap scans UDP ports with the -sU option.

[snip]

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator

Re: Re(2): openvpn in spite of firewalls

2007-07-19 Thread David Brodbeck



On Jul 19, 2007, at 9:16 AM, PETER EASTHOPE wrote:

The socket concept is sound.  Yet where administrators
insist on closing ports & etc. indiscriminately, the
concept is defeated.  I'm afraid that your software
will become a necessity in many environments.


I don't know what sort of environment you're working in, but in  
corporate environments it's common to set up a firewall by blocking  
everything, then allowing only what's necessary.  This is arguably  
the most secure way to arrange things, but it can be frustrating if  
the sysadmin's idea of what's "necessary" is strict.


In those sorts of environments it's often better to start with too  
much security than too little.  If you clamp down too hard, people  
will let you know and you can ease up a bit, but if you're being less  
secure than necessary you're unlikely to get any feedback. ;)



David Brodbeck
Information Technology Specialist 3
Computational Linguistics
University of Washington

Re(2): openvpn in spite of firewalls

2007-07-19 Thread PETER EASTHOPE

David, Alex, Karl & others,

At Thu, 19 Jul 2007 09:50:37 +0100 Karl wrote,
kj> I presume that you do not have control over the firewall?

Correct.  

The socket concept is sound.  Yet where administrators
insist on closing ports & etc. indiscriminately, the 
concept is defeated.  I'm afraid that your software 
will become a necessity in many environments.

kj> ... any holes in the firewalls for UDP?

Not that I know of.  Is there an efficient & reliable 
way to search for a UDP port?

kj> Since the firewalls allow SSH through, you can 
always run a PPP link over ssh...

Will keep it in mind as a last resort(?).

kj> Hope this helps

Certainly, thanks, ... Peter E.




 http://carnot.pathology.ubc.ca/

Re: openvpn in spite of firewalls

2007-07-19 Thread Karl E. Jorgensen

On Wed, Jul 18, 2007 at 10:15:32AM -0700, PETER EASTHOPE wrote:
> Folk,
> 
> I've installed openvpn on two systems and tried some
> configurations including Example 2 from the man page.

For those without access to the man page: Uses an UDP tunnel with static 
key security.

> Seems that firewalls block successfully (sarcasm). 
> Nevertheless, http, ssh, ftp and a few other protocols
> work.

I presume that you do not have control over the firewall?  If not then 
you'll have to make use of the existing holes.

The protocols you mentioned all use TCP - any holes in the firewalls for 
UDP? That's openvpn's preferred mode of operation, although a TCP hole 
can be used too...

> Is there any chance of using one of the open ports for
> the tunnel between the two machines?  

Yes :-)

> For example,
> can the tunnel between 10.4.0.1 and 10.4.0.2 use port
> 22 while ssh uses it for other connections? 
> 
> Can a proxy server solve this? 

If you run openvpn in tcp mode, then you can use a proxy server at the 
receiving end. I've written some software that just might fit the bill 
here: It allows the same port to be used for two different protocols:
http://sourceforge.net/projects/ssh-ssl-proxy/
It should be possible to use this to switch between SSH and openvpn:

http://ssh-ssl-proxy.svn.sourceforge.net/viewvc/ssh-ssl-proxy/tags/0.3/FAQ?view=markup

> Is there any other way to connect the tunnel in spite
> of the firewalls?

Since the firewalls allow SSH through, you can always run a PPP link 
over ssh...

Hope this helps

-- 
Karl E. Jorgensen
[EMAIL PROTECTED]  http://www.jorgensen.org.uk/
[EMAIL PROTECTED] http://karl.jorgensen.com
 Today's fortune:
A girl's conscience doesn't really keep her from doing anything wrong--
it merely keeps her from enjoying it.

signature.asc
Description: Digital signature

Re: openvpn in spite of firewalls

2007-07-18 Thread Alex Samad

On Wed, Jul 18, 2007 at 10:57:10AM -0700, David Brodbeck wrote:
>
> On Jul 18, 2007, at 10:15 AM, PETER EASTHOPE wrote:
>
>> Folk,
>>
>> I've installed openvpn on two systems and tried some
>> configurations including Example 2 from the man page.
>> Seems that firewalls block successfully (sarcasm).
>> Nevertheless, http, ssh, ftp and a few other protocols
>> work.
>
> If you control the firewalls, the obvious answer would be to open the port 
> that OpenVPN is using.  But I assume you'd have done that already if that 
> was the case.
>
> Ideally, you could find a port the firewall doesn't block that you're not 
> using for other purposes.  For example, many firewalls allow HTTPS on TCP 
> port 443, so you could try that one.  UDP port 53 is another possibility; 
> it's usually left open for DNS purposes.

The rfc that details proxy's (if you trying to get through a corporate firewall 
and they have a proxy), is to allow port 563 through as well as 443 (https).  
563 is nntps - strangely a lot of proxies are by default configured to let this 
through.


>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED] a subject 
> of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>


signature.asc
Description: Digital signature

Re: openvpn in spite of firewalls

2007-07-18 Thread David Brodbeck



On Jul 18, 2007, at 10:15 AM, PETER EASTHOPE wrote:


Folk,

I've installed openvpn on two systems and tried some
configurations including Example 2 from the man page.
Seems that firewalls block successfully (sarcasm).
Nevertheless, http, ssh, ftp and a few other protocols
work.


If you control the firewalls, the obvious answer would be to open the  
port that OpenVPN is using.  But I assume you'd have done that  
already if that was the case.


Ideally, you could find a port the firewall doesn't block that you're  
not using for other purposes.  For example, many firewalls allow  
HTTPS on TCP port 443, so you could try that one.  UDP port 53 is  
another possibility; it's usually left open for DNS purposes.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

openvpn in spite of firewalls

2007-07-18 Thread PETER EASTHOPE

Folk,

I've installed openvpn on two systems and tried some 
configurations including Example 2 from the man page.
Seems that firewalls block successfully (sarcasm).  
Nevertheless, http, ssh, ftp and a few other protocols 
work.

Is there any chance of using one of the open ports for 
the tunnel between the two machines?  For example,
can the tunnel between 10.4.0.1 and 10.4.0.2 use port 
22 while ssh uses it for other connections?  

Can a proxy server solve this?  

Is there any other way to connect the tunnel in spite 
of the firewalls?

Thanks,  ... Peter E.




 http://carnot.pathology.ubc.ca/

Re: firewalls and installation stuff....

2006-10-21 Thread Chris Bannister

On Thu, Oct 19, 2006 at 09:38:32AM +, Michael Fothergill wrote:
> 
> What I would say is that there is never a precise one to one match between 
> what is in a manual and what you need to do to use a piece of software.

If you can't do it without the software you won't be able to with the
software.

Don't make the mistake of thinking that installing e.g. crafty, you will
then be able to play chess if you couldn't before. If you can play chess
you will still need to read the documentation (if any provided) to get
the most from the software. I read somewhere that man pages need to be
read at least three times before they start making sense. Unfortunately,
some never do :-( 

> If you want you can ask dumb questions about this and I will be patient 
> with you.  I have to do this with business people all the time.  Even 
> executives in large companies who should know better can't understand what 
> I am doing in some cases.

A dumb question asked the right way could sound like a smart-question.
If you are having trouble with something then undoubtedly someone else
has had the same problem. The archives and google help out there.

Nearly (all?) everybody on this list is a volunteer. You sometimes get
the wrong advice, but that is normally followed up with the correct
advice if you are lucky.

Start using the tools provided:

apt-cache search  (e.g. apt-cache search chess)
apt-cache show  (e.g. apt-cache show crafty)

dpkg -L  (shows files in an installed package) which is good
for picking up any README's, .html, or other maybe helpful files.

Keep reading debian-user :-)

-- 
Chris.
==
" ... the official version cannot be abandoned because the implication of
rejecting it is far too disturbing: that we are subject to a government
conspiracy of `X-Files' proportions and insidiousness."
Letter to the LA Times Magazine, September 18, 2005.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-19 Thread Michael Fothergill

From: "P. Johnson" <[EMAIL PROTECTED]>
To: debian-user@lists.debian.org
Subject: Re: firewalls and installation stuff
Date: Wed, 18 Oct 2006 18:12:58 -0700

Andrew Sackville-West wrote:

> On Wed, Oct 18, 2006 at 03:37:19PM -0700, P. Johnson wrote:
>> Andrew Sackville-West wrote:
>>
>> > On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West 
wrote:

>> >>
>> >> And don't take this personally, but as a piece of friendly
>> > [...]
>> >
>> >> http://catb.org/~esr/faqs/smart-questions.html
>> >>
>> >
>> > I hope that didn't come across as harsh as it now looks to me.
>>
>> It isn't, if you're not so hung up on what the URL looks like and 
instead

>> click it and look at the content.
>
> please clarify for me as I'm having trouble parsing this. Are you
> saying it isn't harsh and if one took the time to read the page, they
> would not be offended by having it suggested to them? If so, I agree
> with you :)

Yup, that's exactly what I was getting at.

I went on this site and read the content.  I have some comments about this.  
In my career I have mostly been a user of software but when I was a kid I 
did do some programming in Fortran.  The types of software Ihave used range 
from the following:

software for solving protein structure by X-ray crystallography;

this included film measurement and scanning, crystal structure refinement 
software, molecular replacement, X-ray detector software, electron density 
maps, molecular graphics software and so on.

I had to read a lot of documentation.

I then got a job doing molecular dynamics simulations of enzyme catalysed 
reactions.

More documentation here.

What I would say is that there is never a precise one to one match between 
what is in a manual and what you need to do to use a piece of software.

So I have some sympathy for what people have written on this page but not 
completely.

Sorry if I seem a bit thick skinned but there it is.

I am running a company that is developing technology to clean up CO2 from 
power stations.

If you want you can ask dumb questions about this and I will be patient with 
you.  I have to do this with business people all the time.  Even executives 
in large companies who should know better can't understand what I am doing 
in some cases.

Even then, I can't give them a full clear explanation because I have to 
persuade them to sign a confidentiality agreement with me before I can 
disclose what I am working on in any detail to avoid blowing the patent 
rights..

But I have managed to get confidentiality agreements with a power company 
and an engineering contractor that builds chemical plants and power 
stations.

Regards,

Michael Fothergill

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact 
[EMAIL PROTECTED]

_
Stay in touch with old friends and meet new ones with Windows Live Spaces 
http://clk.atdmt.com/MSN/go/msnnkwsp007001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-18 Thread P. Johnson

Andrew Sackville-West wrote:

> On Wed, Oct 18, 2006 at 03:37:19PM -0700, P. Johnson wrote:
>> Andrew Sackville-West wrote:
>> 
>> > On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
>> >> 
>> >> And don't take this personally, but as a piece of friendly
>> > [...]
>> > 
>> >> http://catb.org/~esr/faqs/smart-questions.html
>> >> 
>> > 
>> > I hope that didn't come across as harsh as it now looks to me.
>> 
>> It isn't, if you're not so hung up on what the URL looks like and instead
>> click it and look at the content.
> 
> please clarify for me as I'm having trouble parsing this. Are you
> saying it isn't harsh and if one took the time to read the page, they
> would not be offended by having it suggested to them? If so, I agree
> with you :)

Yup, that's exactly what I was getting at.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

On Wed, Oct 18, 2006 at 03:37:19PM -0700, P. Johnson wrote:
> Andrew Sackville-West wrote:
> 
> > On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
> >> 
> >> And don't take this personally, but as a piece of friendly
> > [...]
> > 
> >> http://catb.org/~esr/faqs/smart-questions.html
> >> 
> > 
> > I hope that didn't come across as harsh as it now looks to me.
> 
> It isn't, if you're not so hung up on what the URL looks like and instead
> click it and look at the content.

please clarify for me as I'm having trouble parsing this. Are you
saying it isn't harsh and if one took the time to read the page, they
would not be offended by having it suggested to them? If so, I agree
with you :)

A


signature.asc
Description: Digital signature

Re: firewalls and installation stuff....

2006-10-18 Thread Russell L. Harris

"Michael Fothergill" <[EMAIL PROTECTED]> writes:
> Would that have been enough to include and fire up some kind of
> firewall or do I need to install that separately?
>
> If so what firewall would you recommend and what aptitude command will
> fetch me it?
>
> How do I know that the firewall is on and working?

If you have an older machine which has been retired:

-> 200 MHz Pentium is ample
-> 64 Mbytes RAM
-> CD-ROM drive
-> 5 or 10 Gbyte hard drive is ample
-> a pair of ethernet cards

you can turn it into a splendid firewall/router with:

-> DHCP server
-> time server
-> PPPoE manager
-> dial-up manager
-> VPN manager
-> etc.

Best of all, you can have it running and configured -- complete -- in
less than a half-hour.

Download and burn to CD an ISO image for SmoothWall Express 2.0 from

www.smoothwall.org

SmoothWall Express 2.0 is GPL software; it is mature, stable, and has a
excellent reputation.  SmoothWall is one of the few (if not the only)
firewall/router packages which comes pre-configured, and thus is usable
by individuals who do not have the time or interest to become
knowledgeable regarding the ins and outs of firewall design and
configuration.

RLH

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-18 Thread P. Johnson

Michael Fothergill wrote:

> I also have a broadband connection and the 15 CD set of official Sarge
> stuff.

Overkill.  If you have a broadband connection, for the sake of your time
(wasted by downloading more data than you have to and burning CDs you won't
need) the Debian mirrors (bandwidth) and the environment (wasted CDs), you
probably should have read more closely on the Debian CD image download site
at http://www.debian.org/CD/ .  The very first link on that page is a 120
MB minimal bootable CD, and says "Are you sure you really need the full
CDs? You can just get the basic installation system - it will download the
rest of the distribution if and when needed during the installation."

> I installed the base system plus XWindows plus Gnome etc.

Minor nitpick:  It's the X Window System or X, but not XWindows.  That
implies it has anything to do with Windows, the desktop environment trying
to be an operating system.

> Would that have been enough to include and fire up some kind of firewall
> or do I need to install that separately?

Not needed.  People use Debian to create firewalls.  Just don't install any
software that you don't need and you'll be OK.  aptitude visualizes this
well.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-18 Thread P. Johnson

Andrew Sackville-West wrote:

> On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
>> 
>> And don't take this personally, but as a piece of friendly
> [...]
> 
>> http://catb.org/~esr/faqs/smart-questions.html
>> 
> 
> I hope that didn't come across as harsh as it now looks to me.

It isn't, if you're not so hung up on what the URL looks like and instead
click it and look at the content.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-18 Thread Sven Arvidsson

On Wed, 2006-10-18 at 12:21 +, Michael Fothergill wrote:
> Would that have been enough to include and fire up some kind of firewall or 
> do I need to install that separately?
> 
> If so what firewall would you recommend and what aptitude command will fetch 
> me it?
> 
> How do I know that the firewall is on and working?

Other have already recommended shorewall, but there are other tools you
can try. For example firestarter is a complete package for managing a
firewall, and GUI based.

> Also if I want to probe the horizontal and vertical refresh rate of the 
> monitor I am using more precisely using Linux (e.g. superprobe?), how do I 
> do it?
> 
> Also I assume that if I go into the config box in Gnome then I should be 
> able to run the Xwindows config again somehow and then put in the precise 
> monitor refresh information into Xwindows and then have the monitor work as 
> effectively as possible.
> 
> Suggestions on the best strategy here are appreciated.  The video card is an 
> SiS 630/730 according to Fedora.  Putting in SiS as the card manufacturer 
> type seemed to work well.
> 
> So far I chose the "simple" option and put a generic 15 inch CRT display in 
> form my monitor.  This has actually worked OK but I want to refine it and 
> give Debian the fair deal when it comes to running my hardware.

You can re-run the configuration for X and manually input the correct
refresh rate. The configuration can be run inside X from a terminal, but
you need to restart X for the changes to take effect.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22



signature.asc
Description: This is a digitally signed message part

Re: firewalls and installation stuff....

On Wed, Oct 18, 2006 at 04:26:41PM +, Michael Fothergill wrote:
> 
> 
> 
> >From: Andrew Sackville-West <[EMAIL PROTECTED]>
> >To: debian-user@lists.debian.org
> >Subject: Re: firewalls and installation stuff
> >Date: Wed, 18 Oct 2006 08:43:05 -0700
> >
> >On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
> >>
> >> And don't take this personally, but as a piece of friendly
> >[...]
> >
> >> http://catb.org/~esr/faqs/smart-questions.html
> >>
> >
> >I hope that didn't come across as harsh as it now looks to me.
> >
> >A
> 
> It's OK.  In the case of the reconfiguring of Xwindows I thought you 
> couild do that from the configuration editor in Gnome now I have 
> installed it so I thought I was asking a slightly different question 
> than before.  I now realise I would just use the same command you 
> recommended before.

there is a seperation between Gnome and X. Its all about layers
(onions have layers!). Gnome is sort of the icing on the cake that is
X sitting on the plate that is linux. That is not to say that Gnome
couldn't incorporate a configuration mechanism that would allow
reconfiguration of X because it certainly could. 

> 
> I found the specs for my monitor on Google.  I will go away and think of 
> some more interesting questions to post on the site.

please don't go away, and realise that its not whether questions are
"interesting" or not, but whether they are either well researched,
informed questions or stabs in the dark. I am certainly one to make
too many stabs in the dark and would hope to help others to help
themselves somewhat. I'm glad you found your monitor specs, that will
make life much easier...

anyway, I apologise for coming off wrong there. 

A

signature.asc
Description: Digital signature

Re: firewalls and installation stuff....

2006-10-18 Thread Michael Fothergill

From: Andrew Sackville-West <[EMAIL PROTECTED]>
To: debian-user@lists.debian.org
Subject: Re: firewalls and installation stuff
Date: Wed, 18 Oct 2006 08:43:05 -0700

On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
>
> And don't take this personally, but as a piece of friendly
[...]

> http://catb.org/~esr/faqs/smart-questions.html
>

I hope that didn't come across as harsh as it now looks to me.

A

It's OK.  In the case of the reconfiguring of Xwindows I thought you couild 
do that from the configuration editor in Gnome now I have installed it so I 
thought I was asking a slightly different question than before.  I now 
realise I would just use the same command you recommended before.

I found the specs for my monitor on Google.  I will go away and think of 
some more interesting questions to post on the site.

Regards

mikef

<< signature.asc >>

_
The new Windows Live Toolbar helps you guard against viruses 
http://toolbar.live.com/?mkt=en-gb

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

2006-10-18 Thread Nyizsnyik Ferenc

On Wed, 2006-10-18 at 12:21 +, Michael Fothergill wrote:
> Dear Debian folks,
> 

> [...]

> The broadband connection and my browser work fine.
> 
> Would that have been enough to include and fire up some kind of firewall or 
> do I need to install that separately?
> 
> If so what firewall would you recommend and what aptitude command will fetch 
> me it?
> 

arno-iptables-firewall is a very simple one, it's in testing (I have it
installed on Sarge).

> How do I know that the firewall is on and working?
> 

Visit this site:
https://www.grc.com/x/ne.dll?bh0bkyd2
You can check your ports and some other security stuff there.

> [...]

> 
-- 
Szia:
Nyizsa.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: firewalls and installation stuff....

On Wed, Oct 18, 2006 at 08:08:33AM -0700, Andrew Sackville-West wrote:
> 
> And don't take this personally, but as a piece of friendly
[...]

> http://catb.org/~esr/faqs/smart-questions.html
> 

I hope that didn't come across as harsh as it now looks to me.

A


signature.asc
Description: Digital signature

Re: firewalls and installation stuff....