Opening ports in my firewall

I would like to know how to open ports in my firewall at home. I am running
Fedora Core2 with NAT. When I use the setup command, and firewall settings,
I am given some obvious choices, but not all. Suppose I have an application
that uses port 3000, 7025, 7026, 7080, etc. How do I tell my system how to
open them?

Thanks for your help

Bruce

new.artcraftcos.com wrote:
> I would like to know how to open ports in my firewall at home. I am running
> Fedora Core2 with NAT. When I use the setup command, and firewall settings,
> I am given some obvious choices, but not all. Suppose I have an application
> that uses port 3000, 7025, 7026, 7080, etc. How do I tell my system how to
> open them?
>

I am not sure what you want to do. Maybe you are also confused about
what you want?

Is your application a server ( ie: remote computers connect to your
server on specific ports ) or a client ( your application connects to
remote servers ) ?

Basically I suggest you take a look at "man iptables".
Then there are some good "graphical" tools that can help such as
fwbuilder ( which you can get via yum if you add AtRpms in you yum.conf)

new.artcraftcos.com wrote:
> I would like to know how to open ports in my firewall at home. I am
> running Fedora Core2 with NAT. When I use the setup command, and
> firewall settings, I am given some obvious choices, but not all.
> Suppose I have an application that uses port 3000, 7025, 7026, 7080,
> etc. How do I tell my system how to open them?
>
> Thanks for your help
>
> Bruce
>
>

You should also research a little network security theory, especially if
you use high speed internet. So you dont leave your system open for
somebody to play with.

(usernames, passwords, RFC 1918 addresses...)

Matthew Shelton <crash700@drexel.edu> wrote in
news:WwxPc.62724$4h7.9451721@twister.nyc.rr.com:

>> I would like to know how to open ports in my firewall at home. I am
>> running Fedora Core2 with NAT. When I use the setup command, and
>> firewall settings, I am given some obvious choices, but not all.
>> Suppose I have an application that uses port 3000, 7025, 7026, 7080,
>> etc. How do I tell my system how to open them?
>
> You should also research a little network security theory, especially if
> you use high speed internet. So you dont leave your system open for
> somebody to play with.

I fall into this camp. I have a LinkSys firewall with all ports shutdown
and set to timeout instead of reject. All except SSH on port 22. How
exposed am I? I see failed login attempts in /var/log/messages almost
daily. Should I be doing more to secure my box (RH9)? I really like being
able to ssh back home from work so I'd rather leave the ssh port open.

Thanks.

--
- Mark ->
--

On 2 Aug 2004 20:48:45 GMT, Mark A. Odell, <odellmark@hotmail.com> wrote:

> I fall into this camp. I have a LinkSys firewall with all ports
> shutdown and set to timeout instead of reject. All except SSH
> on port 22. How exposed am I? I see failed login attempts in
> /var/log/messages almost daily. Should I be doing more to secure
> my box (RH9)? I really like being able to ssh back home from work
> so I'd rather leave the ssh port open.

While you can't ever have perfect security without yanking out the
modem/wireless/usb/whatever, it doesn't hurt to use additional defensive
measures, i.e. "defense in depth".

1) Do your *VALID* ssh connects come in from all over the internet,
or just from a limited number of domains or IP address ranges? If
possible, limit where you accept ssh connections from by IP address or
domain name, or rDNS. Note; rDNS is spoof-able if someone really wants
to do it. These rules may be implemented at the hardware firewall
and/or iptables and/or hosts.allow.

2) This may be a bit more painfull, but consider accepting connections
only with DSA keys, and not allowing manual password logins.
Brute-forcing a DSA key is a helluva lot more difficult than a password.

--
Walter Dnes; my email address is *ALMOST* like wzaltdnes@waltdnes.org
Delete the "z" to get my real address. If that gets blocked, follow
the instructions at the end of the 550 message.

"Walter Dnes (delete the 'z' to get my real address)"
<wzaltdnes@waltdnes.org> wrote in news:2n85pgFu26blU1@uni-berlin.de:

> On 2 Aug 2004 20:48:45 GMT, Mark A. Odell, <odellmark@hotmail.com>
> wrote:
>
>> I fall into this camp. I have a LinkSys firewall with all ports
>> shutdown and set to timeout instead of reject. All except SSH
>> on port 22. How exposed am I? I see failed login attempts in
>> /var/log/messages almost daily. Should I be doing more to secure
>> my box (RH9)? I really like being able to ssh back home from work
>> so I'd rather leave the ssh port open.
>
> While you can't ever have perfect security without yanking out the
> modem/wireless/usb/whatever, it doesn't hurt to use additional defensive
> measures, i.e. "defense in depth".

Agreed. So limiting open ports to just ssh is a step in the right
direction?

> 1) Do your *VALID* ssh connects come in from all over the internet,
> or just from a limited number of domains or IP address ranges? If
> possible, limit where you accept ssh connections from by IP address or
> domain name, or rDNS. Note; rDNS is spoof-able if someone really wants
> to do it. These rules may be implemented at the hardware firewall
> and/or iptables and/or hosts.allow.

Good question. My valid ssh connects are limited to a couple of domains so
I'll limit the acceptable domains to just those I know I use. I'll have to
read up on hosts.allow and how it pertains to incoming ssh.

> 2) This may be a bit more painfull, but consider accepting
> connections
> only with DSA keys, and not allowing manual password logins.
> Brute-forcing a DSA key is a helluva lot more difficult than a password.

I think that's doable if I understand it. Are the DSA keys generated via
ssh-keygen?

Thanks very much for the reply.

--
- Mark ->
--

"Walter Dnes (delete the 'z' to get my real address)" <wzaltdnes@waltdnes.org> writes:

> 2) This may be a bit more painfull, but consider accepting connections
> only with DSA keys, and not allowing manual password logins.
> Brute-forcing a DSA key is a helluva lot more difficult than a password.

Walter, sorry to butt in here but,I've wondered about password method
for a while and your post started to get to the crux of it.

Can you spell the above method out a little. I guess you mean the
method where you exchange id_dsa.pub keys and keep them an
authorized_keys file right? But how is this limiting done?

But that would assume you always know in advance what machine you will
be sshing in from (or at least a group of possible machines). So that
would be pretty much the same as using /etc/hosts.allow it seems.

In a situation where one may ssh in from machines unknowable in
advance, is there really any other technique than password?

Maybe this is where folks use the vpn stuff or does one have to know
the incoming machine in advance for that too?

If one uses a good password wouldn't a dictionary attack take a very
long time? And with ssh only allowing 3 login attempts at a time, you
could be talking wks of effort. Or is there some other way with ssh
password auth that is a quicker crack.

Also, is it possible to limit incoming ssh to a particualr username?
And that user ends up in a chroot jail or something. Needing yet
another password (root's) to do damage.

In message <Xns953A592BD5C82CopyrightMarkOdell@130.133.1.4> , Mark A.
Odell <odellmark@hotmail.com> writes
>"Walter Dnes (delete the 'z' to get my real address)"
><wzaltdnes@waltdnes.org> wrote in news:2n85pgFu26blU1@uni-berlin.de:
>
>> On 2 Aug 2004 20:48:45 GMT, Mark A. Odell, <odellmark@hotmail.com>
>> wrote:
>>
>>> I fall into this camp. I have a LinkSys firewall with all ports
>>> shutdown and set to timeout instead of reject. All except SSH
>>> on port 22. How exposed am I? I see failed login attempts in
>>> /var/log/messages almost daily. Should I be doing more to secure
>>> my box (RH9)? I really like being able to ssh back home from work
>>> so I'd rather leave the ssh port open.
>>
>> While you can't ever have perfect security without yanking out the
>> modem/wireless/usb/whatever, it doesn't hurt to use additional defensive
>> measures, i.e. "defense in depth".
>
>Agreed. So limiting open ports to just ssh is a step in the right
>direction?

Yes, certainly. While OpenSSH has had a few bugs in recent years, I
believe none of them were remote exploits, i.e. someone has to get into
a valid account first. If ssh is locked down, this should not be
possible.

>
>Good question. My valid ssh connects are limited to a couple of domains so
>I'll limit the acceptable domains to just those I know I use. I'll have to
>read up on hosts.allow and how it pertains to incoming ssh.

If you're allowing access to ssh only using iptables, as I would assume,
you can also use iptables to limit the hosts allowed to connect. But use
hosts.allow/deny as well. Finally, you can limit the users allowed to
connect, in the sshd config file. Never allow root, and this has a
separate config option.
>
>> 2) This may be a bit more painfull, but consider accepting
>> connections
>> only with DSA keys, and not allowing manual password logins.
>> Brute-forcing a DSA key is a helluva lot more difficult than a password.
>
>I think that's doable if I understand it. Are the DSA keys generated via
>ssh-keygen?
>
Yes.
--
Joe

In message <m3llgwbccz.fsf@newsguy.com>, Harry Putnam
<reader@newsguy.com> writes
>"Walter Dnes (delete the 'z' to get my real address)"
><wzaltdnes@waltdnes.org> writes:
>
>> 2) This may be a bit more painfull, but consider accepting connections
>> only with DSA keys, and not allowing manual password logins.
>> Brute-forcing a DSA key is a helluva lot more difficult than a password.
>
>Walter, sorry to butt in here but,I've wondered about password method
>for a while and your post started to get to the crux of it.
>
>Can you spell the above method out a little. I guess you mean the
>method where you exchange id_dsa.pub keys and keep them an
>authorized_keys file right? But how is this limiting done?
>
>But that would assume you always know in advance what machine you will
>be sshing in from (or at least a group of possible machines). So that
>would be pretty much the same as using /etc/hosts.allow it seems.
>
>In a situation where one may ssh in from machines unknowable in
>advance, is there really any other technique than password?

You carry a floppy/CD/usb device. puTTY (for Windows machines) will use
a shared key activated by a passphrase, which can be long. So you need
both the private key and its decrypting passphrase to connect, and no
amount of guessing will help without that private key. If you lose the
disc, then disable the public key and make another pair before someone
works out the passphrase.
>
>Also, is it possible to limit incoming ssh to a particualr username?
>And that user ends up in a chroot jail or something. Needing yet
>another password (root's) to do damage.

I haven't done the chroot bit, but you can certainly limit to particular
users. You can then specify the shell available after login, so with a
bit of research on shell design, you can limit a login in any way you
can imagine.
--
Joe

Joe <joe@jretrading.com> writes:

]In message <m3llgwbccz.fsf@newsguy.com>, Harry Putnam
]<reader@newsguy.com> writes
]>"Walter Dnes (delete the 'z' to get my real address)"
]><wzaltdnes@waltdnes.org> writes:
]>
]>> 2) This may be a bit more painfull, but consider accepting connections
]>> only with DSA keys, and not allowing manual password logins.
]>> Brute-forcing a DSA key is a helluva lot more difficult than a password.

Depends on the attack scenario. Getting the key off of the remote machine
may be much easier than either. Ie, brute force is rarely the most
dangerous attack scenario.


]>
]>Walter, sorry to butt in here but,I've wondered about password method
]>for a while and your post started to get to the crux of it.
]>
]>Can you spell the above method out a little. I guess you mean the
]>method where you exchange id_dsa.pub keys and keep them an
]>authorized_keys file right? But how is this limiting done?

What limiting. Only those systems whose public key you have can
sign on.


]>
]>But that would assume you always know in advance what machine you will
]>be sshing in from (or at least a group of possible machines). So that
]>would be pretty much the same as using /etc/hosts.allow it seems.

Yes, but more secure.

]>
]>In a situation where one may ssh in from machines unknowable in
]>advance, is there really any other technique than password?

NO.

]You carry a floppy/CD/usb device. puTTY (for Windows machines) will use
]a shared key activated by a passphrase, which can be long. So you need
]both the private key and its decrypting passphrase to connect, and no
]amount of guessing will help without that private key. If you lose the
]disc, then disable the public key and make another pair before someone
]works out the passphrase.

And that remote system on which you run putty say can also read your keys.
]>
]>Also, is it possible to limit incoming ssh to a particualr username?
]>And that user ends up in a chroot jail or something. Needing yet
]>another password (root's) to do damage.

In chroot environment you typically cannot do anything. It is pretty
useless unless you want the person to only do very veryspecific tasks.


]I haven't done the chroot bit, but you can certainly limit to particular
]users. You can then specify the shell available after login, so with a
]bit of research on shell design, you can limit a login in any way you
]can imagine.
]--
]Joe