Mailing List Archive

Dave S wrote:
> Since I am rebuilding my system, I have decided to tighten my firewall,
>
> Instead of allowing processes to send to any port I have specifically
> defined the ports my system can send to. All has gone well except FTP
> (emerging something !)
>
> Active FTP is a no go, I don't like the idea of perminantly opening an
> incoming port
>
> Passive FTP is OK but I have to open all outgoing ports >1023 since it
> uses random high ports
>
> I am no expert on networking, but is this a security risk, 1024 - 65535
> seems a lot of ports to open up (Still better than 0-65535! I guess)
>
> Any comments greatly appreciated :-) as I am trying to learn ...
>
> Cheers
> Dave
>
> --
> gentoo-user@gentoo.org mailing list
>

First thing:
You don't need to close any ports if there are no services listening to
these ports. So, if you don't have any running service (like a webserver)
you don't need to have a firewall at all. A port on which no application is
listening is closed anyway, whether there is a firewall or not.
This is also the case, if your box doesn't need to route between LAN and
internet.

As for FTP:
Active FTP means, your client connects from an arbitrary high port to the
server on port 21, after this the server opens a connection from an
arbitrary high port to port 20 on your machine (opened by your client). Your
client will close port 20 if it's done with exchanging data.

With passive FTP your client does both connections: One from an arbitrary
high port on your box to port 21 on the server and one from a high port on
your box to a high port on the server which was opened by the serverprocess.

In both cases the local ports are closed the moment your client is closed.

You should restrict access from the internet to your box, of course. This
can be done in two ways: Configure your serverprocesses correct so they
don't bind to the internet-interface (usually ppp0), or at least don't allow
hosts from the internet to them (with /etc/hosts.allow and /etc/hosts.deny).
If that can't be done, you can use a packetfilter (which is often called a
firewall, but isn't) like iptables, to restrict inbound traffic.

Long story short:
There's nothing harmful in letting your box connect from any port to any
port, as long as the client software doesn't have any security holes which
could be used by a malicious server. But then it's equal which port is used
on your box, they'd be equally harmful.

So if you don't run any serverprocesses - don't worry about firewalls, you
don't need them.

Greetings,
Felix

Ps. Small hint, if you're using cups: Set up cupsd to listen only on
127.0.0.1 by adding the line
Listen 127.0.0.1:631
to your /etc/cups/cupsd.conf, this would deny access to your printers from
the internet more efficient than any packetfilter could do, as it binds cups
to the local machine only, ignoring all external traffic.

>
> First thing:
> You don't need to close any ports if there are no services listening
> to these ports. So, if you don't have any running service (like a
> webserver) you don't need to have a firewall at all. A port on which
> no application is listening is closed anyway, whether there is a
> firewall or not.
> This is also the case, if your box doesn't need to route between LAN
> and internet.
>
OK Im with you so far ... I guess I was being a little paranoid ...
However my machine is dual boot with win 2000. My firewall is a netgear
ADSL router/firewall so acts for Linux & 2K - not knowing what windows
does (does anyone ;-) ) I erred on the side of paranoia of blocking all
incomming ports & only allowing attatchment to certain outgoing ports !

> As for FTP:
> Active FTP means, your client connects from an arbitrary high port to
> the server on port 21, after this the server opens a connection from
> an arbitrary high port to port 20 on your machine (opened by your
> client). Your client will close port 20 if it's done with exchanging
> data.
>
> With passive FTP your client does both connections: One from an
> arbitrary high port on your box to port 21 on the server and one from
> a high port on your box to a high port on the server which was opened
> by the serverprocess.
>
> In both cases the local ports are closed the moment your client is
> closed.
>
So the passive FTP purely gets around a server having to 'dial up' a
host ? Getting round IPtables blocks etc ....

> You should restrict access from the internet to your box, of course.
> This can be done in two ways: Configure your serverprocesses correct
> so they don't bind to the internet-interface (usually ppp0), or at
> least don't allow hosts from the internet to them (with
> /etc/hosts.allow and /etc/hosts.deny).

/etc/hosts.allow or deny is new territory for me, I will have a look at
them.

> If that can't be done, you can use a packetfilter (which is often
> called a firewall, but isn't) like iptables, to restrict inbound traffic.

>
> Long story short:
> There's nothing harmful in letting your box connect from any port to
> any port, as long as the client software doesn't have any security
> holes which could be used by a malicious server. But then it's equal
> which port is used on your box, they'd be equally harmful.

I hadn't thought of it in that way ...

>
> So if you don't run any serverprocesses - don't worry about firewalls,
> you don't need them.
>
> Greetings,
> Felix
>
> Ps. Small hint, if you're using cups: Set up cupsd to listen only on
> 127.0.0.1 by adding the line
> Listen 127.0.0.1:631
> to your /etc/cups/cupsd.conf, this would deny access to your printers
> from the internet more efficient than any packetfilter could do, as it
> binds cups to the local machine only, ignoring all external traffic.

Thanks for the tip.

Cheers
Dave


--
gentoo-user@gentoo.org mailing list

Dave S wrote:
>
>>
>> First thing:
>> You don't need to close any ports if there are no services listening
>> to these ports. So, if you don't have any running service (like a
>> webserver) you don't need to have a firewall at all. A port on which
>> no application is listening is closed anyway, whether there is a
>> firewall or not.
>> This is also the case, if your box doesn't need to route between LAN
>> and internet.
>>
> OK Im with you so far ... I guess I was being a little paranoid ...
> However my machine is dual boot with win 2000. My firewall is a netgear
> ADSL router/firewall so acts for Linux & 2K - not knowing what windows
> does (does anyone ;-) ) I erred on the side of paranoia of blocking all
> incomming ports & only allowing attatchment to certain outgoing ports !
>
>> As for FTP:
>> Active FTP means, your client connects from an arbitrary high port to
>> the server on port 21, after this the server opens a connection from
>> an arbitrary high port to port 20 on your machine (opened by your
>> client). Your client will close port 20 if it's done with exchanging
>> data.
>>
>> With passive FTP your client does both connections: One from an
>> arbitrary high port on your box to port 21 on the server and one from
>> a high port on your box to a high port on the server which was opened
>> by the serverprocess.
>>
>> In both cases the local ports are closed the moment your client is
>> closed.
>>
> So the passive FTP purely gets around a server having to 'dial up' a
> host ? Getting round IPtables blocks etc ....


I think you are indeed a bit paranoid, insofar as you are so concerned
about preventing (unauthorized) access, that you are forgetting that the
entire point of programs such as an FTP client is in fact to access the
server it's connecting to.

If the FTP client *didn't* "get round" iptables/blocks/etc, you wouldn't
have a very successful FTP/telnet/irc/im/what-have-you session.

The thing that you want to concern yourself with is not that every
session is blocked, because that would include authorized sessions such
as you connecting to your network to do an FTP transfer, or even you
connecting to an external FTP server to upload or download files. What
is important is that *unauthorized* sessions are blocked-- such as when
you connect to IRC or a website, someone does not automatically upload
some malicious files to your PC.

And while a firewall/packet filter certainly protects you from random
unauthorized access-- port scanners and the like-- it won't help much if
you are connected to a service (FTP/IRC/IM), because the listening ports
have to be open to create the authorized session.

But most client programs are aware of this vulnerability and allow you
to create settings to prevent most or all of such attacks (for instance,
you can set most IM clients that I know of to only accept file transfers
from people on your buddy list, and most IRC clients have to be
explicitly set to auto-accept file transfers. Mozilla and most other
non-IE web browsers won't auto-install dialers or evil crap like
CoolWebSearch).

So it's not like the firewall is the be-all and end-all of network
security. The client programs must also be configured for security, and
the user must still keep an eye on things.

Think of it like a locked front door. Sometimes you want to open the
door to visitors. However, you don't want some third party taking
advantage of that to muscle past both you and your visitor to get the
drop on you. The solution is not to always keep the door locked (how
would you get your newspaper, or that package you ordered?), but instead
to be cautious (know your trusted networks), and to keep a bat nearby in
case of trouble (use properly configured clients, and install scanners
like chrootkit to check your system periodically).

Paranoia can be useful, but only if you use your heightened sensitivity
to find out what the dangers really are, and what tools are available to
effectively protect yourself. Otherwise, it's just a big emotional
stumbling block that probably puts you in more danger than if you were
completely ignorant (when you're very emotional, you can't pay careful
attention to your circumstances, and that's the most important thing to
do in an unsafe situation, which the global Internet network definitely is).

Holly

--
gentoo-user@gentoo.org mailing list

Dave S wrote:
>
>>
>> First thing:
>> You don't need to close any ports if there are no services listening
>> to these ports. So, if you don't have any running service (like a
>> webserver) you don't need to have a firewall at all. A port on which
>> no application is listening is closed anyway, whether there is a
>> firewall or not.
>> This is also the case, if your box doesn't need to route between LAN
>> and internet.
>>
> OK Im with you so far ... I guess I was being a little paranoid ...
> However my machine is dual boot with win 2000. My firewall is a netgear
> ADSL router/firewall so acts for Linux & 2K - not knowing what windows
> does (does anyone ;-) ) I erred on the side of paranoia of blocking all
> incomming ports & only allowing attatchment to certain outgoing ports !
It's a good idea to block incomming traffic. And now that you told me about
your network topology I can be a bit more specific.
You're right, the router can not tell between Windows and Linux, so it's a
bad idea to block outgoing connections, since Linux would suffer from that.

And come to think of it: If I'd program spyware, it'd connect to a
privileged port (80, http), so no router could distinguish between a user
browsing a website and a trojan connecting to its master... ;-)

If you're concerned about what Windows does on the net, I'd recommend
installing a personal firewall (Kerio 2.1.5) on Windows simply to restrain
installed programs. But explaining this is beyond my the scope of this
email. I'd say you should read some security-concerned newsgroups, they have
the best tips for such cases.
>
>> As for FTP:
>> Active FTP means, your client connects from an arbitrary high port to
>> the server on port 21, after this the server opens a connection from
>> an arbitrary high port to port 20 on your machine (opened by your
>> client). Your client will close port 20 if it's done with exchanging
>> data.
>>
>> With passive FTP your client does both connections: One from an
>> arbitrary high port on your box to port 21 on the server and one from
>> a high port on your box to a high port on the server which was opened
>> by the serverprocess.
>>
>> In both cases the local ports are closed the moment your client is
>> closed.
>>
> So the passive FTP purely gets around a server having to 'dial up' a
> host ? Getting round IPtables blocks etc ....
A "normal" (passive) FTP gets around the problem with NAT-routers: The
connection *back* from the server to the client, which is used for
filetransfer with active FTP, wouldn't pass the router.
The iptables-stuff related to active or passive FTP is complicated enough to
keep me from even thinking about setting up a local FTP on my box at home.

[snip]

Greetings,
Felix

On Sunday 19 September 2004 08:44, Dave S wrote:
> > First thing:
> > You don't need to close any ports if there are no services listening
> > to these ports. So, if you don't have any running service (like a
> > webserver) you don't need to have a firewall at all. A port on which
> > no application is listening is closed anyway, whether there is a
> > firewall or not.
> > This is also the case, if your box doesn't need to route between LAN
> > and internet.
>
> OK Im with you so far ... I guess I was being a little paranoid ...
> However my machine is dual boot with win 2000. My firewall is a netgear
> ADSL router/firewall so acts for Linux & 2K - not knowing what windows
> does (does anyone ;-) ) I erred on the side of paranoia of blocking all
> incomming ports & only allowing attatchment to certain outgoing ports !
>
<SNIP>
If I understand your concenrns... I have used portsentry for a long, long
time because I have found it to be more proficient at guarding my system than
any firewall I have tried so far. It is also a bit easier to config, I
believe.

HTH...
--
..."Yogi" CH
Namasté Yoga Studio
"If music be the food of love, why can't rabbits sing?"


--
gentoo-user@gentoo.org mailing list

Thanks for all your input guys,

I appreciate what you are saying about blocking calls to ports - I was
not trying to block them all, just the ones I had no intention of using.
However I see now that just ensuring that the services are not active
would have the same result. And even if they are active as long as they
are up to date & setup correctly there is still no problem.

Is there a command which will tell me which ports are being listened to
and by what process so I can detect any unwanted telnet demons !

Anyway thank you for putting me straight, building my 2nd PC & adding it
to the LAN - sharing files via NFS is my next project .... I am sure you
will be hearing from me :-)

Cheers
Dave


--
gentoo-user@gentoo.org mailing list

On Sun, 2004-09-19 at 23:23, Dave S wrote:
> Thanks for all your input guys,
>
> I appreciate what you are saying about blocking calls to ports - I was
> not trying to block them all, just the ones I had no intention of using.
> However I see now that just ensuring that the services are not active
> would have the same result. And even if they are active as long as they
> are up to date & setup correctly there is still no problem.
>
> Is there a command which will tell me which ports are being listened to
> and by what process so I can detect any unwanted telnet demons !
>
You may have a look at the tool lsof
lsof -i -n -P
will print all listening ports on you machine.

Netstat would be another option


--
gentoo-user@gentoo.org mailing list

On Sun, 19 Sep 2004, Felix Tiede wrote:

>
>
> First thing:
> You don't need to close any ports if there are no services listening to
> these ports. So, if you don't have any running service (like a webserver)
> you don't need to have a firewall at all. A port on which no application is
> listening is closed anyway, whether there is a firewall or not.
> This is also the case, if your box doesn't need to route between LAN and
> internet.
>

Hi,

Maybe I'm very wrong. I think, that users can open ports above 1024. It
can be a sec-hole, doesn't it?
If I'm wrong, please correct me, thanks.

Cheers,
Tamas Sarga Sarga Tamas
Software Developer Szoftver fejleszto
Member of the Mozilla Quality Assurance Mozilla Quality Assurance tag
OpenOffice.org translator OpenOffice.org fordito

A day is 24 hours long. Egy nap 24 órából áll.
A box of beer contains 24 bottles. Egy tálcán 24 üveg sör van.
I don't believe in suddenness. Nem hiszek a véletlenekben.

--
gentoo-user@gentoo.org mailing list

Tamas Sarga wrote:
> On Sun, 19 Sep 2004, Felix Tiede wrote:
>
>
>>
>>First thing:
>>You don't need to close any ports if there are no services listening to
>>these ports. So, if you don't have any running service (like a webserver)
>>you don't need to have a firewall at all. A port on which no application is
>>listening is closed anyway, whether there is a firewall or not.
>>This is also the case, if your box doesn't need to route between LAN and
>>internet.
>>
>
>
> Hi,
>
> Maybe I'm very wrong. I think, that users can open ports above 1024. It
> can be a sec-hole, doesn't it?
> If I'm wrong, please correct me, thanks.
>
Users *can* open ports above 1024, which is why they're called
"unprivileged". But to open a port means to start a server which listens to
this port. User applications open such ports to be able to receive answers
on their requests, which is why it is necessary for users to be able to open
ports >1024.

An attacker could install a trojan which could, if only run as user, open
only ports >1024. This trojan would then wait for a request to answer. That
would be a sec hole, yes, but by only executing "trusted" programs, you'd be
pretty safe. A packet filter could help you with just one thing: It could
examine if you're or the program you're running is allowed to do so, where
the communication is directed, and if it's really sophisticated, analyze the
traffic and decide if it's caused by a malicious program on your system.

Long story short: "Closing ports >1024" sounds in my ears like "forbid any
traffic from and to unprivileged local ports", which would render the
network useless. If it means to "forbid any traffic to unprivileged local
ports which I did not request", it is a useful configuration. But the OP did
not make very clear what he meant and it's difficult to guess...

Greetings,
Felix

Well in a few words. Cutting of ports over 1024 may make your system
instable. Many UNIX services have IPC's with sockets [a bit rare these
days though]. So beware with what you are doing. Furthermore, many
services listening to some standard ports lets say ssh [port 22]
forward incoming connections to ports other than 22 [>1024]at the
localhost. Also you should bear in mind that a port that having no
service running behind, Will not answer to any request. So let's say
that you having nithing bind behind port 10666 then sending a SYN
packet there will have no effect. Cutting ports has meaning only to
protect your local's machine interfaces running just for local
intranet from the outside net.

For more information concerning programming in nix env with C and
sockets, you should try your local library branch the book _/UNIX
NETWORK PROGRAMMING -Sockets Networking API/_ by the great master
_*R.W. STEVENS*_ [R.I.P. Master].
Some inet info about inet programming
http://www.ecst.csuchico.edu/~beej/guide/net/
check this to if you are intrested
http://www.softlab.ece.ntua.gr/facilities/documentation/unix/sockets.html
I insist R.W. Stevens' book is a Masterpiece...


--
-
Undergraduate Student of CEID

**Warning gmail may affect your mailing privacy**
If you like to mail me private please use:
korkakak *at* ceid *dot* upatras *dot* gr and my public key from
http://students.ceid.upatras.gr/~korkakak/mykey

--
gentoo-user@gentoo.org mailing list

Felix Tiede wrote:
> Dave S wrote:
>
>> Since I am rebuilding my system, I have decided to tighten my firewall,
>>
>> Instead of allowing processes to send to any port I have specifically
>> defined the ports my system can send to. All has gone well except FTP
>> (emerging something !)
>>
>> Active FTP is a no go, I don't like the idea of perminantly opening an
>> incoming port
>>
>> Passive FTP is OK but I have to open all outgoing ports >1023 since it
>> uses random high ports

surely one of the iptables kernel modules would help you here...

> First thing:
> You don't need to close any ports if there are no services listening to
> these ports. So, if you don't have any running service (like a
> webserver) you don't need to have a firewall at all.

umm, that's quite a dangerous statement... If the box is on the
internet, it certainly _does_ need a firewall, regardless of whether
there are running services or not. There are many exploits that don't
care about the service on the other end, the simplest being a Denial of
Service.

> A port on which no
> application is listening is closed anyway, whether there is a firewall
> or not.

A port on which no application is listening is handled by the
appropriate daemon - usually xinetd. And a firewall makes a BIG
difference. There is a difference between closed (iptables: rejected)
and "stealthed" (iptables: dropped). In fact, you should stealth
everything incoming by default (iptables: default policy drop).
Outgoing is up to your local IT policy.

> This is also the case, if your box doesn't need to route between LAN and
> internet.

Never ever rely on the fact that you're in a "trusted" network to be
your security. As has happened here before, laptops are taken outside
(to home dialups), infected with viruses, and then brought back into our
network. These viruses could potentially be packet sniffers which
broadcast all our plain text passwords to hackers around the world who
can then break in and take over.

[snip]
> You should restrict access from the internet to your box, of course.
> This can be done in two ways: Configure your serverprocesses correct so
> they don't bind to the internet-interface (usually ppp0), or at least
> don't allow hosts from the internet to them (with /etc/hosts.allow and
> /etc/hosts.deny).

the hosts allow and deny files are _not_ security methods, and shouldn't
be relied on to be so.

> If that can't be done, you can use a packetfilter (which is often called
> a firewall, but isn't) like iptables,
> to restrict inbound traffic.

iptables is not a firewall? From http://www.netfilter.org/:

What can I do with netfilter/iptables?
* build internet firewalls based on stateless and stateful packet
filtering

> Long story short:
[snip]
> So if you don't run any serverprocesses - don't worry about firewalls,
> you don't need them.

I couldn't disagree more. I believe that every linux distribution
should come with a simple deny all policy by default. (They should also
include a reasonable tool for configuring it!)

You shouldn't even let outsiders know that your box is there - ie even
drop pings. For a good test, once you have your firewall up, go to
grc.com and navigate (a few clicks) to Shields Up.

HTH,
--
Iain

--
gentoo-user@gentoo.org mailing list

On 21 Sep 2004, at 21:17, Iain Buchanan wrote (in part):
> Felix Tiede wrote:
>> First thing:
>> You don't need to close any ports if there are no services listening
>> to these ports. So, if you don't have any running service (like a
>> webserver) you don't need to have a firewall at all.
>
> umm, that's quite a dangerous statement... If the box is on the
> internet, it certainly _does_ need a firewall, regardless of whether
> there are running services or not. There are many exploits that don't
> care about the service on the other end, the simplest being a Denial
> of Service.

And, if you're on the receiving end of a (d)DoS attack, a firewall
won't help you anyway because your downstream is flooded, or because a
public service (e.g. httpd) is being flooded with requests.


>> A port on which no application is listening is closed anyway, whether
>> there is a firewall or not.
>
> A port on which no application is listening is handled by the
> appropriate daemon - usually xinetd.

Wrong. xinetd only listens on ports that it's been configured to listen
on.


>> This is also the case, if your box doesn't need to route between LAN
>> and internet.
>
> Never ever rely on the fact that you're in a "trusted" network to be
> your security. As has happened here before, laptops are taken outside
> (to home dialups), infected with viruses, and then brought back into
> our network. These viruses could potentially be packet sniffers which
> broadcast all our plain text passwords to hackers around the world who
> can then break in and take over.

If you're transmitting passwords in plain text, you're doing something
wrong anyway.


> I couldn't disagree more. I believe that every linux distribution
> should come with a simple deny all policy by default. (They should
> also include a reasonable tool for configuring it!)

That'd break more things than it'd fix.


> You shouldn't even let outsiders know that your box is there - ie even
> drop pings.

Why? This behaviour is considered incorrect by RFC standards.


> For a good test, once you have your firewall up, go to grc.com and
> navigate (a few clicks) to Shields Up.

Shields Up is considered a source of hysteria. For more information, see

http://grcsucks.com/shieldsup.html

Andrew Farmer wrote:
> On 21 Sep 2004, at 21:17, Iain Buchanan wrote (in part):
>
>> Felix Tiede wrote:

> And, if you're on the receiving end of a (d)DoS attack, a firewall won't
> help you anyway because your downstream is flooded, or because a public
> service (e.g. httpd) is being flooded with requests.

Surely there are other attacks before the service stage that would be
stopped by a firewall?

>>> A port on which no application is listening is closed anyway, whether
>>> there is a firewall or not.
>>
>> A port on which no application is listening is handled by the
>> appropriate daemon - usually xinetd.
>
> Wrong. xinetd only listens on ports that it's been configured to listen on.

My mistake then. So who actually handles the attempt to connect and
responds with the connection refused, the kernel?

>>> This is also the case, if your box doesn't need to route between LAN
>>> and internet.
>>
>> Never ever rely on the fact that you're in a "trusted" network to be
>> your security. As has happened here before, laptops are taken outside
>> (to home dialups), infected with viruses, and then brought back into
>> our network. These viruses could potentially be packet sniffers which
>> broadcast all our plain text passwords to hackers around the world who
>> can then break in and take over.
>
> If you're transmitting passwords in plain text, you're doing something
> wrong anyway.

Including ftp, windows file sharing (not that I personally use it),
email, etc? Relying on individuals to use safe practices is not a
security measure. If you're responsible for the network, then you
should expect that people will do The Wrong Thing(TM).

>> I couldn't disagree more. I believe that every linux distribution
>> should come with a simple deny all policy by default. (They should
>> also include a reasonable tool for configuring it!)
>
> That'd break more things than it'd fix.

Wellllll, I'm not convinced that a default no-firewall installation is
good either. If you make it obvious (redhat's "firstboot", gentoo's
howto's, etc) then it won't be so bad. Gentoo is a bit of an exception
though, cause you can choose just about every single tool that you install.

>> You shouldn't even let outsiders know that your box is there - ie even
>> drop pings.
>
> Why? This behaviour is considered incorrect by RFC standards.

however, if you make it harder for the kiddies to find you, its harder
for them to hack you. I know there are other ways of finding hosts that
are alive, but how many people use ping as the primary test for a host?

>> For a good test, once you have your firewall up, go to grc.com and
>> navigate (a few clicks) to Shields Up.
>
> Shields Up is considered a source of hysteria. For more information, see
>
> http://grcsucks.com/shieldsup.html

I don't totally agree with everything they say. However I do agree that
"A FALSE sense of security is worse than being unsure." I'm happy to
suggest
http://whacker9.hackerwhacker.com.nyud.net:8090/main.php
https://secure1.securityspace.com/sspace/index.html or
http://www.vulnerabilities.org/ instead then.

It seems as though you don't agree with the necessity for a firewall either?

I still don't believe that locking down every service and trusing the
fact that no program is going to open any port, or no config file change
is a good security measure. A firewall will do that for you, and in
addition you can put rules on who can access what ports, at what times,
and at what throughput. As well as many more things.

I'm not an expert though...
--
Iain

"On a normal ascii line, the only safe condition to detect is a 'BREAK'
- everything else having been assigned functions by Gnu EMACS."
(By Tarl Neustaedter)

--
gentoo-user@gentoo.org mailing list

Iain Buchanan wrote:
[snip]
>>>> A port on which no application is listening is closed anyway,
>>>> whether there is a firewall or not.
>>>
>>>
>>> A port on which no application is listening is handled by the
>>> appropriate daemon - usually xinetd.
>>
>>
>> Wrong. xinetd only listens on ports that it's been configured to
>> listen on.
>
>
> My mistake then. So who actually handles the attempt to connect and
> responds with the connection refused, the kernel?
Yes. All connections are first handled by the kernel, then passed to the
packet filter and then to a service. If there is no service, the kernel
responds with "TCP-RST", so he says to the sender: "Nothing there to connect
to. Go away." A packet filter can send the same answer pretending there is
no firewall, but as the kernel would do so in case there is no service
listening to the addressed port the packet filter is unnecessary.
>
>>>> This is also the case, if your box doesn't need to route between LAN
>>>> and internet.
>>>
>>>
>>> Never ever rely on the fact that you're in a "trusted" network to be
>>> your security. As has happened here before, laptops are taken
>>> outside (to home dialups), infected with viruses, and then brought
>>> back into our network. These viruses could potentially be packet
>>> sniffers which broadcast all our plain text passwords to hackers
>>> around the world who can then break in and take over.
>>
>>
>> If you're transmitting passwords in plain text, you're doing something
>> wrong anyway.
>
>
> Including ftp, windows file sharing (not that I personally use it),
> email, etc? Relying on individuals to use safe practices is not a
> security measure. If you're responsible for the network, then you
> should expect that people will do The Wrong Thing(TM).
Which doesn't mean that you as the network administrator can not do your
best to keep them from doing so. Use SSL connections whenever you can,
switch to digest as authentication for password protected directories and so
on. And keep these laptops on their own physical subnet, which would protect
all your unsafe client boxes from viruses brought with them...
>
>>> I couldn't disagree more. I believe that every linux distribution
>>> should come with a simple deny all policy by default. (They should
>>> also include a reasonable tool for configuring it!)
>>
>>
>> That'd break more things than it'd fix.
>
>
> Wellllll, I'm not convinced that a default no-firewall installation is
> good either. If you make it obvious (redhat's "firstboot", gentoo's
> howto's, etc) then it won't be so bad. Gentoo is a bit of an exception
> though, cause you can choose just about every single tool that you install.
I think, there is a little misunderstanding here. A packet filter with a
deny all policy can mean two things: 1. "Deny every packet regardless of its
origin and destination (port)" and 2. "Deny every packet comming from
outside of this box regardless of its origin and destination (port)".
The former would in deed break things, since many programs rely on being
able to send and receive packets to and from the localhost (127.0.0.1). If
the latter is meant, yes, this would be a good default since it would cause
the administrator to think of which communication he should enable then of
which to disable. But then if there's no service listening to one of the
external interfaces there is no need for a packet filter since the kernel
would take care of communication.
>
>>> You shouldn't even let outsiders know that your box is there - ie
>>> even drop pings.
>>
>>
>> Why? This behaviour is considered incorrect by RFC standards.
>
>
> however, if you make it harder for the kiddies to find you, its harder
> for them to hack you. I know there are other ways of finding hosts that
> are alive, but how many people use ping as the primary test for a host?
Not responding to pings doesn't hide you from kiddies. A simple traceroute
or tracepath to your IP would show them that it is possible to reach the
last router prior to your endpoint and that this router doesn't respond
"destination unreachable". So the attacker would know that you _are_ there
but simply not responding to his pings. Also responding with "destination
unreachable" to pings from your own box marks you as false hide-out, since
it is clear that you are there and responding to network traffic. All it
costs are ten seconds of thinking or a better tool at the kiddie.
So there's nothing harmful in following the RFCs.
>
>>> For a good test, once you have your firewall up, go to grc.com and
>>> navigate (a few clicks) to Shields Up.
>>
>>
>> Shields Up is considered a source of hysteria. For more information, see
>>
>> http://grcsucks.com/shieldsup.html
>
>
> I don't totally agree with everything they say. However I do agree that
> "A FALSE sense of security is worse than being unsure." I'm happy to
> suggest
> http://whacker9.hackerwhacker.com.nyud.net:8090/main.php
> https://secure1.securityspace.com/sspace/index.html or
> http://www.vulnerabilities.org/ instead then.
>
> It seems as though you don't agree with the necessity for a firewall
> either?
I'd say, there _are_ occasions when you need one, but connecting a single
linux-only box to the internet with proper service configuration and without
a packet filter is better than using a lousy service config and rely on a
packet filter.
>
> I still don't believe that locking down every service and trusing the
> fact that no program is going to open any port, or no config file change
> is a good security measure. A firewall will do that for you, and in
> addition you can put rules on who can access what ports, at what times,
> and at what throughput. As well as many more things.
This is only true, if the firewall resides on a separate box than the
services. If I got access to a shell on the box through one of the open
services, I have also the possibility to change firewall rules. If you don't
rely on your box's config, you can not rely on its built-in firewall. That's
why a good service configuration is more helpful than having a good packet
filter configuration. And it can be much simpler to deactivate external
listening for services than to do a good packet filter configuration.

Greetings,
Felix

Iain Buchanan wrote:
> Felix Tiede wrote:
>
>>Dave S wrote:
>>
>>
>>>Since I am rebuilding my system, I have decided to tighten my firewall,
>>>
>>>Instead of allowing processes to send to any port I have specifically
>>>defined the ports my system can send to. All has gone well except FTP
>>>(emerging something !)
>>>
>>>Active FTP is a no go, I don't like the idea of perminantly opening an
>>>incoming port
>>>
>>>Passive FTP is OK but I have to open all outgoing ports >1023 since it
>>>uses random high ports
>
>
> surely one of the iptables kernel modules would help you here...
>
>
>>First thing:
>>You don't need to close any ports if there are no services listening to
>>these ports. So, if you don't have any running service (like a
>>webserver) you don't need to have a firewall at all.
>
>
> umm, that's quite a dangerous statement... If the box is on the
> internet, it certainly _does_ need a firewall, regardless of whether
> there are running services or not. There are many exploits that don't
> care about the service on the other end, the simplest being a Denial of
> Service.

No, that's plain wrong. The problem with exploits is, that they
abuse some running daemon (often called service). So, to make
exploits unable to work, we must find a way to stop the abuse of
the service. The way a packet filter works, is that it makes the
service not accessible.

HOWEVER, the same can be achieved by stopping that service. Now,
since the service is (thanks to the filter) not accessible anyhow,
it's no problem to shutdown the service completely. After the
service has been shut down, a filter is no more neccessary, since
the kernel can send out "no one's here" (TCP RST) by itself.

>>A port on which no
>>application is listening is closed anyway, whether there is a firewall
>>or not.

Yes, exactly.

> A port on which no application is listening is handled by the
> appropriate daemon - usually xinetd.

Nope.

> And a firewall makes a BIG
> difference. There is a difference between closed (iptables: rejected)
> and "stealthed" (iptables: dropped).

That's right, there's a difference: CLOSED exist and makes sense, whereas
"stealthed" is marketing bullshit made up to confuse users.

> In fact, you should stealth
> everything incoming by default (iptables: default policy drop).
> Outgoing is up to your local IT policy.

No, you should not. It makes much more sense, to reject than
to drop. With drop, IP stacks send more requests, because the
sending IP stack does not know that there's noone listening
on that adress. With REJECT, the IP stack knows and can stop
right away.

>>If that can't be done, you can use a packetfilter (which is often called
>>a firewall, but isn't) like iptables,
>> to restrict inbound traffic.
>
> iptables is not a firewall? From http://www.netfilter.org/:

No, iptables is not a firewall. It is a packet filter. A firewall
is a method.

>>Long story short:
>
> [snip]
>
>>So if you don't run any serverprocesses - don't worry about firewalls,
>>you don't need them.
>
>
> I couldn't disagree more.

Fine, but you're wrong. As he said, if no server processes are running,
and thus there's nothing to connect to, a packetfilter makes the system
more attackable.

> I believe that every linux distribution
> should come with a simple deny all policy by default.

Not needed.

> You shouldn't even let outsiders know that your box is there - ie even
> drop pings. For a good test, once you have your firewall up, go to
> grc.com and navigate (a few clicks) to Shields Up.

GRC sucks. There's nothing bad if your system responds to pings. In
fact, it's good if it does, as there's no such thing as "stealth
mode". If you're online, the router right in front of you (operated
by your ISP) will say so. Always. That cannot be influenced by the
client.

Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--
gentoo-user@gentoo.org mailing list

Iain Buchanan wrote:
> Andrew Farmer wrote:
>>On 21 Sep 2004, at 21:17, Iain Buchanan wrote (in part):
>>>Felix Tiede wrote:

>>If you're transmitting passwords in plain text, you're doing something
>>wrong anyway.
>
> Including ftp, windows file sharing (not that I personally use it),
> email, etc? Relying on individuals to use safe practices is not a
> security measure. If you're responsible for the network, then you
> should expect that people will do The Wrong Thing(TM).

Well, yes, including FTP and all that. FTP over SSL, SMTP/IMAP/POP3
over SSL exist and are usable. This makes the password not readable
over the wire.

>>>I couldn't disagree more. I believe that every linux distribution
>>>should come with a simple deny all policy by default. (They should
>>>also include a reasonable tool for configuring it!)
>>
>>That'd break more things than it'd fix.
>
> Wellllll, I'm not convinced that a default no-firewall installation is
> good either.

Why not? If there's nothing running (or only service are running that
the user wants), then a packet filter only adds complexity and makes the
amount of code that runs larger. Thus, a filter LOWERS the total system
security.

>>>You shouldn't even let outsiders know that your box is there - ie even
>>>drop pings.
>>
>>Why? This behaviour is considered incorrect by RFC standards.
>
> however, if you make it harder for the kiddies to find you, its harder
> for them to hack you.

That's right, however not answering to pings doesn't make it harder
for the kiddies.

> I know there are other ways of finding hosts that
> are alive, but how many people use ping as the primary test for a host?

That's rhight, but yet another however: Script Kiddies use "scripts",
and thus rely on "good" tools.

> It seems as though you don't agree with the necessity for a firewall either?

I for sure don't.

> I still don't believe that locking down every service and trusing the
> fact that no program is going to open any port, or no config file change
> is a good security measure.

Why not? If you're only running programs that you trust, there's no
reason for doubt. If you run programs you don't trust, you always
risk that this untrusted program makes use of some local exploit to
gain root and drop the filter rules.



Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--
gentoo-user@gentoo.org mailing list

[People] wrote [stuff]!

well, looks like I'm outnumbered on the firewall / packet filter issue.
The reason I push my POV is probably because of the innumerous
hardware firewalls (on adsl modems etc) and linux howto's on how to make
your box "invisible". Its all I thought anyone was doing. To be honest
the no-firewall but no-services running is a new one to me. Live n
learn! I don't think I'm going to ditch my firewall just yet though!!

--
Iain

This message was brought to you by Linux, the free unix.
Windows without the X is like making love without a partner.
Sex, Drugs & Linux Rules
win-nt from the people who invented edlin
apples have meant trouble since eden
Linux, the way to get rid of boot viruses
(By mwikholm@at8.abo.fi, MaDsen Wikholm)

--
gentoo-user@gentoo.org mailing list

Iain Buchanan wrote:
> [People] wrote [stuff]!
>
> well, looks like I'm outnumbered on the firewall / packet filter issue.
> The reason I push my POV is probably because of the innumerous
> hardware firewalls (on adsl modems etc) and linux howto's on how to make
> your box "invisible". Its all I thought anyone was doing. To be honest
> the no-firewall but no-services running is a new one to me. Live n
> learn! I don't think I'm going to ditch my firewall just yet though!!

You know, if it makes you feel better, by all means, keep your
filter. It's just, that with a properly setup system, it MOST
of the time is not necessary. However, to be fair, with "advanced"
setups (like with rate limits, access only from some certain
source net etc.pp.) a filter DOES make sense. But most of the
time, those packet filters are setup in a all or nothign way,
and that's, well, ...

You're also right, that everybody's suggesting to use a firewall.
Often for that stealth nonesense.

> --

Could you please add a space after that signature delimiter?
This allows compliant software, to drop the signature when
a reply is to be written.

Alexander Skwar
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--
gentoo-user@gentoo.org mailing list

Iain Buchanan wrote:

> [People] wrote [stuff]!
>
> well, looks like I'm outnumbered on the firewall / packet filter issue.
> The reason I push my POV is probably because of the innumerous hardware
> firewalls (on adsl modems etc) and linux howto's on how to make your box
> "invisible". Its all I thought anyone was doing. To be honest the
> no-firewall but no-services running is a new one to me. Live n learn! I
> don't think I'm going to ditch my firewall just yet though!!

A good (and stolen) anaolgy for a security model is that is should be
percieved like an onion.

Every layer of security should be another layer on top of each other..
whether it be a firewall, less services, kernel parameter tuning, no
root over SSH, secure tunnels, (probably most important) educated users
etc.. etc...

All work together to ensure that the box is as secure as possible..

The more of these you aim for the better that your box will stand up to
attack.

(on a side note - that reminds me of something I need to do, lol)


>
> --
> Iain
>
> This message was brought to you by Linux, the free unix.
> Windows without the X is like making love without a partner.
> Sex, Drugs & Linux Rules
> win-nt from the people who invented edlin
> apples have meant trouble since eden
> Linux, the way to get rid of boot viruses
> (By mwikholm@at8.abo.fi, MaDsen Wikholm)
>
> --
> gentoo-user@gentoo.org mailing list
>


--
(___) Joel Merrick
(o o) www.joelmerrick.com
/-------\ / www.connectedup.co.uk
/ | ||O
* ||,---|| GO ON LARRY SON!!
~~ ~~

--
gentoo-user@gentoo.org mailing list

Quoting Joel Merrick <joel@joelmerrick.com>:

> (on a side note - that reminds me of something I need to do, lol)

It also reminds ME of something YOU have to do!

Get on it Mr Merrick!

MB

--
- - - - - - - - - - - - -
.~.
/ v \ Mark Brier
/( _ )\ mark@brier.me.uk
^ ^
- - - - - - - - - - - - -


--
gentoo-user@gentoo.org mailing list

Quoting Joel Merrick <joel@joelmerrick.com>:

> (on a side note - that reminds me of something I need to do, lol)

It also reminds ME of something YOU have to do!

Get on it Mr Merrick!

MB

--
- - - - - - - - - - - - -
.~.
/ v \ Mark Brier
/( _ )\ mark@brier.me.uk
^ ^
- - - - - - - - - - - - -


--
gentoo-user@gentoo.org mailing list

Alexander W. Skwar wrote:

> You know, if it makes you feel better, by all means, keep your
> filter. It's just, that with a properly setup system, it MOST
> of the time is not necessary. However, to be fair, with "advanced"

with a firewall you can other neat things, such as rate limiting packets
- from certain net blocks - for a certain time - for a certain duration
- to certain ports - from certain ports - etc...

I've also blocked all access to port ssh (22) unless it's from my cable
company. Everyone I know has RoadRunner, the bussiness connection is RR,
my home is RR, all my friends are RR. Everyone else is blocked. Why? I
don't want some guy in China hitting my boxes testing my passwords. If
it's some guy in the RR network, it's easier to track down. It's also
less exposure. Less is Best! The only person that should even be
*attempting* to ssh into my systems is... me.

Firewall's/packet filters help a lot in limiting your exposure. Most
boxes that require you to have *some* remote connection - will run a
service. Some badly designed local daemons may listen on all interfaces.
Sometimes we humans make mistakes. The apache server you started to test
a website or php app - it doesn't have a password - you forgot. A packet
filter can help limit that exposure. Instead of several million
potential bots and web spiders hitting that apache server, you can limit
it just to your and your office internet neighborhood - much easier to
digest and perform damage control.

Firewalls/Packet Filters also can give you insight into who is
"knocking" at your door. With out one, you won't know if that jerk from
irc tried to find an unlocked port. What you do with that information is
up to you, and whether you care is another story. However, the
information is there and could prove useful - one day.

--
gentoo-user@gentoo.org mailing list

Billy wrote:
> Alexander W. Skwar wrote:
>
>
>>You know, if it makes you feel better, by all means, keep your
>>filter. It's just, that with a properly setup system, it MOST
>>of the time is not necessary. However, to be fair, with "advanced"
>
>
> with a firewall you can other neat things, such as rate limiting packets
> - from certain net blocks - for a certain time - for a certain duration
> - to certain ports - from certain ports - etc...

Yes, I quite agree. Let's "requote" the sentence you snipped:

| However, to be fair, with "advanced"
| setups (like with rate limits, access only from some certain
| source net etc.pp.) a filter DOES make sense.

Everything you said is true, but compared to the much more typical
"all or nothing" setup, that's a quite advanced setup you're
describing, don't you agree? :) If it helps you, then everything
is cool, as far as I'm concerned. It's nothing for me, but it does
not have to be.

Alexander Skwar
--
This fortune does not require Microsoft Windows.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


--
gentoo-user@gentoo.org mailing list

Alexander Skwar wrote:

> Everything you said is true, but compared to the much more typical
> "all or nothing" setup, that's a quite advanced setup you're

I just don't understand how any computer that is connected to millions
of other computers could possible *not* want to limit their exposure.

People make mistakes. Computers are vulnerable. Limit your exposure by
utilizing some type of packet filtering. That's all I was trying to get
across.

--
gentoo-user@gentoo.org mailing list