{OT} CUPS alternative?
 

I'm trying to print from my remote server to my local printer. It's
working great via CUPS, but I've been warned that this is not a good
idea and that I should be using Net::Printer instead. Net::Printer
docs say:

Net::Printer, by itself, does not speak to printers running the CUPS
protocol. In order to provide support for legacy clients, most modern
CUPS distributions include the cups-lpd mini-server which can be set
up to run out of either inetd or xinetd depending on preference. You
will need to set up this functionality in order to use Net::Printer
with a CUPS server.

I thought CUPS was *the* way to print on Linux. Is there another
solution that would work better with Net::Printer?

- Grant
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

On Saturday 02 February 2008, Grant wrote:
> I thought CUPS was *the* way to print on Linux. *Is there another
> solution that would work better with Net::Printer?

CUPS is the latest in a long string of different print systems, all
trying to solve this infernally difficult problem called putting dots
on the right place on a bit of paper. And all systems seem to fail at
it.

Admittedly, CUPS is better than most and to my mind best suited to
modern printing needs. What amuses me is what kind of project would
recommend you not use CUPS, and what is their reasoning?

--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

> > I thought CUPS was *the* way to print on Linux. Is there another
> > solution that would work better with Net::Printer?
>
> CUPS is the latest in a long string of different print systems, all
> trying to solve this infernally difficult problem called putting dots
> on the right place on a bit of paper. And all systems seem to fail at
> it.
>
> Admittedly, CUPS is better than most and to my mind best suited to
> modern printing needs. What amuses me is what kind of project would
> recommend you not use CUPS, and what is their reasoning?

What they've suggested is that using lpr on the remote system and
opening port 631 to the world is a bad idea and that it's much better
to use Net::Printer. Would you agree?

Net::Printer doesn't work with CUPS directly so I thought maybe I
should be using something else. I'd rather not set up inetd or xinetd
if I can avoid it.

- Grant
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

On Saturday 02 February 2008, Grant wrote:
> > > I thought CUPS was *the* way to print on Linux. Is there
> > > another solution that would work better with Net::Printer?
> >
> > CUPS is the latest in a long string of different print systems,
> > all trying to solve this infernally difficult problem called
> > putting dots on the right place on a bit of paper. And all
> > systems seem to fail at it.
> >
> > Admittedly, CUPS is better than most and to my mind best suited
> > to modern printing needs. What amuses me is what kind of project
> > would recommend you not use CUPS, and what is their reasoning?
>
> What they've suggested is that using lpr on the remote system and
> opening port 631 to the world is a bad idea and that it's much
> better to use Net::Printer. Would you agree?

I don't know Net::Printer, but if it prints over the network - as the
name implies - it has to use a port. So you have to open that port.
That's how TCP/IP works. No way around it.

Certainly, the organisation you are working in is behind a firewall
that allows pretty little from the outside to the inside. (If not so,
their network administrator or external consultant or or or should be
beaten over his head until he can spell "Bruce Schneier".) So you are
*not* opening port 631 to the world.

You are certainly opening it to your organisation. I have messed up my
CUPS configuration right now and can't look it up for sure but I
remember CUPS being able to listen only to certain hosts (IP
addresses) other than localhost. If if this is not so, you can still
set up a firewall on the client box (the one that is supposed to do
the printing) that allows only your server to connect to port 631 on
it.

If someone then argues about source IP spoofing, just let him. If
someone in your organisation is able to do it, make him your network
admin. ;-)

Uwe

--
Informal Linux Group Namibia:
http://www.linux.org.na/
SysEx (Pty) Ltd.:
http://www.SysEx.com.na/
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

> > > > I thought CUPS was *the* way to print on Linux. Is there
> > > > another solution that would work better with Net::Printer?
> > >
> > > CUPS is the latest in a long string of different print systems,
> > > all trying to solve this infernally difficult problem called
> > > putting dots on the right place on a bit of paper. And all
> > > systems seem to fail at it.
> > >
> > > Admittedly, CUPS is better than most and to my mind best suited
> > > to modern printing needs. What amuses me is what kind of project
> > > would recommend you not use CUPS, and what is their reasoning?
> >
> > What they've suggested is that using lpr on the remote system and
> > opening port 631 to the world is a bad idea and that it's much
> > better to use Net::Printer. Would you agree?
>
> I don't know Net::Printer, but if it prints over the network - as the
> name implies - it has to use a port. So you have to open that port.
> That's how TCP/IP works. No way around it.
>
> Certainly, the organisation you are working in is behind a firewall
> that allows pretty little from the outside to the inside. (If not so,
> their network administrator or external consultant or or or should be
> beaten over his head until he can spell "Bruce Schneier".) So you are
> *not* opening port 631 to the world.
>
> You are certainly opening it to your organisation. I have messed up my
> CUPS configuration right now and can't look it up for sure but I
> remember CUPS being able to listen only to certain hosts (IP
> addresses) other than localhost. If if this is not so, you can still
> set up a firewall on the client box (the one that is supposed to do
> the printing) that allows only your server to connect to port 631 on
> it.
>
> If someone then argues about source IP spoofing, just let him. If
> someone in your organisation is able to do it, make him your network
> admin. ;-)

You're right, access to the printer can be given only to certain
hosts. So simply using 'lpr file.pdf' on the remote machine doesn't
strike you as a bad idea?

- Grant
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

Grant <emailgrant <at> gmail.com> writes:

> > If someone then argues about source IP spoofing, just let him. If
> > someone in your organisation is able to do it, make him your network
> > admin.

> You're right, access to the printer can be given only to certain
> hosts. So simply using 'lpr file.pdf' on the remote machine doesn't
> strike you as a bad idea?


Might this be an opportunity to use 'port-knocking' ?

http://www.linuxjournal.com/article/6811

just a thought, never really tried this before.


James

--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

On Saturday 02 February 2008, Grant wrote:
> You're right, access to the printer can be given only to certain
> hosts. *So simply using 'lpr file.pdf' on the remote machine doesn't
> strike you as a bad idea?

Lets look at this from the perspective of what is really going on.

You have a process on one machine that opens a high numbered port to
knock on a low numbered port on another machine and conduct a TCP/IP
session. Data moves up and down blah blah blah. The process on the
first machine just happens to be lpr, and the port on your machine just
happens to be 631.

Here's another scenario:

You have a process on one machine (which just happens to be Firefox)
that opens a high numbered port to knock on a low numbered port (which
just happens to be port 80) on another machine and conduct a TCP/IP
session with the process listening on port 80 which just happens to be
Apache. Data moves up and down blah blah blah.

How are these two things different in any fundamental way? They are not.
Gladly setting up say Apache and also being hesitant about setting up a
print server is totally inconsistent (and yet you would be amazed at
the amount of clueless knuckleheads out there advising exactly this
attitude).

The only reason I would not do that remote printing setup is if I knew
of specific weaknesses/exploits in lpr and CUPS. But I don't.

--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

On Saturday 02 February 2008, James wrote:
> Grant <emailgrant <at> gmail.com> writes:
> > > If someone then argues about source IP spoofing, just let him. If
> > > someone in your organisation is able to do it, make him your
> > > network admin.
> >
> > You're right, access to the printer can be given only to certain
> > hosts. So simply using 'lpr file.pdf' on the remote machine
> > doesn't strike you as a bad idea?
>
> Might this be an opportunity to use 'port-knocking' ?
>
> http://www.linuxjournal.com/article/6811
>
> just a thought, never really tried this before.

port-knocking is the biggest load of fud (Microsoft products apart) I
have heard about in ages. The term snake-oil comes to mind, as
does "security by obscurity and obfuscation" which we all know is no
security at all.

I don't care if the originating process knocks on the well known port
with gold plated gloves hand braided from the finest Unobtainium by
seductive alluring Puerto Rican virgins, the receiving machine still
has to open another port short thereafter. This is not a magic port and
is not wrapped in Star Trek's finest stealth cloak, it's a port that
does TCP/IP stuff.

If the end process listening on the newly opened port is in any way
weak - and this is the only possible reason anyone would ever try the
port knocking workaround - it's just as weak when it's listening on an
obfuscated port number. If it's open, I can find it. If it's weak, I
can get in. Then it's game over, go home, I win.

I've yet to hear positive things about port knocking from someone who
actually implemented it fully. In truth it's just a major pain in the
arse that makes the admin's life miserable and gives the boss a warm
fuzzy feeling based on hot air.

End of rant.


--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

> > > > If someone then argues about source IP spoofing, just let him. If
> > > > someone in your organisation is able to do it, make him your
> > > > network admin.
> > >
> > > You're right, access to the printer can be given only to certain
> > > hosts. So simply using 'lpr file.pdf' on the remote machine
> > > doesn't strike you as a bad idea?
> >
> > Might this be an opportunity to use 'port-knocking' ?
> >
> > http://www.linuxjournal.com/article/6811
> >
> > just a thought, never really tried this before.
>
> port-knocking is the biggest load of fud (Microsoft products apart) I
> have heard about in ages. The term snake-oil comes to mind, as
> does "security by obscurity and obfuscation" which we all know is no
> security at all.
>
> I don't care if the originating process knocks on the well known port
> with gold plated gloves hand braided from the finest Unobtainium by
> seductive alluring Puerto Rican virgins, the receiving machine still
> has to open another port short thereafter. This is not a magic port and
> is not wrapped in Star Trek's finest stealth cloak, it's a port that
> does TCP/IP stuff.
>
> If the end process listening on the newly opened port is in any way
> weak - and this is the only possible reason anyone would ever try the
> port knocking workaround - it's just as weak when it's listening on an
> obfuscated port number. If it's open, I can find it. If it's weak, I
> can get in. Then it's game over, go home, I win.
>
> I've yet to hear positive things about port knocking from someone who
> actually implemented it fully. In truth it's just a major pain in the
> arse that makes the admin's life miserable and gives the boss a warm
> fuzzy feeling based on hot air.
>
> End of rant.

Well thank you for that. I had planned on setting up port knocking
for ssh and cups but I guess I'm just as well off leaving them
listening on 22 and 631?

As for printing from lpr to cups across the internet, I should be
encrypting that data shouldn't I? Nothing too sensitive but it sounds
like a good thing to do. It looks like cups can use ssl but I don't
see any mention of it in man lpr.

- Grant
--
gentoo-user@lists.gentoo.org mailing list

{OT} CUPS alternative?
 

On Saturday 2 February 2008, Alan McKinnon wrote:

> port-knocking is the biggest load of fud (Microsoft products apart) I
> have heard about in ages. The term snake-oil comes to mind, as
> does "security by obscurity and obfuscation" which we all know is no
> security at all.

Uhm. Security by obscurity is not good because it hides something *that
is known for sure to be there*. Port knocking, on the other hand, makes
a computer appear as if nothing is there. No open ports.
A computer with all ports closed which uses portknocking and a computer
with just all ports closed cannot be told apart from remote, either by
portscanning or whatever mean. What the attacker sees is just "no open
ports". It could, of course, imagine that port knocking might be in use,
but even in that case, he would have to discover the knock sequence.
With a knock sequence long enough (say, 8 ports), the likeliness of such
a discovery is really low (1/65535^8 in this case). And, even if he
succeeds, he just opens a port (as if there was no portknocking), and
still has to violate whatever security measure is in place for the
service (eg, ssh authentication).

> I don't care if the originating process knocks on the well known port
> with gold plated gloves hand braided from the finest Unobtainium by
> seductive alluring Puerto Rican virgins, the receiving machine still
> has to open another port short thereafter. This is not a magic port
> and is not wrapped in Star Trek's finest stealth cloak, it's a port
> that does TCP/IP stuff.
>
> If the end process listening on the newly opened port is in any way
> weak - and this is the only possible reason anyone would ever try the
> port knocking workaround - it's just as weak when it's listening on an
> obfuscated port number.

This is not true, for at least two reasons:

- the port stays open only for the duration of the connection, not all
the time;

- at least with some implementations, the port is opened *only to the IP
address of the user who did the knock*, not to the whole world.

> If it's open, I can find it. If it's weak, I can get in. Then it's game
> over, go home, I win.

See above.

> I've yet to hear positive things about port knocking from someone who
> actually implemented it fully. In truth it's just a major pain in the
> arse that makes the admin's life miserable and gives the boss a warm
> fuzzy feeling based on hot air.

I don't know about large setups, where it might be very possible that
port knocking becomes a major PITA as you say. But I have setup and used
port knocking for remote ssh access lots of time in the past, and never
had a problem. This is just my little experience, of course.
--
gentoo-user@lists.gentoo.org mailing list