On 7/5/06, Alexander Skwar <[EMAIL PROTECTED]> wrote:
Trenton Adams wrote:
> I would move ssh to a very high port number of your choice. Most ssh
> port scanners do not bother checking anything other than port 22, as
> it is too time consuming. I have not had any weird hits on my ssh
> port in years. It was hammered daily, even with attempted logins and
> such, with it running on port 22. Now, pretty much nothing. Why not
> use something like 65350 or some random high port like that?
ACK. Good idea. One more thing though: I'd not use a "strange" port
like 65350, but rather a port, which might be legitimately open.
Suppose you've got a web server and DON'T use ssl. In this case,
https (443) would be available. Or if you don't have a usenet server,
you could use 119.
Reason: It's "normal" that such ports are open. If I were a
script kiddie, I wouldn't bother looking at normally open
ports. But if there's something strange like 65350, I *would*
look.
I completely agree with Alexander. On my young (and stupid) days I
would scan computers around my network for vulnerabilities, and open
ports where known services run were only targeted by specific attacks.
Trying to run (for example) a brute-force scan outside of 22, 23, 21
and other known ports were considered just waste of time. But as the
OP stated that this guy would target his machine only, you can safely
assume it won't be a non-assisted method.
Few years later, as a lab administrator, I've learn that you may block
whatever you want, but you gotta keep in mind that a server is there
for serve. Those services are the targets of attacks, and thus,
they're the real concerns. It doesn't matter how hard you implement a
firewall if you left a SQL Inject hole in your web server, you must be
more careful with what you OFFER than possible backdoors, I say that
because nowadays most servers run behind router firewalls blocking
traffic that is strange to the server, and those who don't have this
usually implement some way to write rules about traffic (iptables for
instance).
So, keep an eye open for security on your services software (ssh,
apache, dbs, etc).
> And yes, you probably shouldn't be asking these questions if you have
> an important linux computer on the internet. Because if it is
> important, you should know what you are doing before you put it on the
> internet.
>
> If on the other hand, you're just getting to know linux, and the
> computer is not all that important, then you should be asking these
> questions.
Yes, he *CERTAINLY* should be asking those questions - but he
shouldn't have a server on the internet. Reason: It might be
so, that the system is less secure than it ought to be and thus
might be already part of a botnet or somesuch. And if it were
part of a botnet, it might be used to attack other systems or
to simply relay spams.
Because of that, I find it somewhat irresponsible or at the
very least questionable, when users with not so much knowledge
operate servers. And it doesn't matter if all, if the system
is important to the OP - it matters only, if it might be used
to do things, which the OP doesn't want.
Again, I agree. But not only Servers, Desktops and any machine
connected to the internet should have security, and people running
this machines should have knowledge, but that is simply not the case,
specially with people running windows (wich is 90% of the personal
computers connected). All this computer power can be used (and has
been) for botnets, hacker attacks, etc.
Adaptative firewalls, service blocks, traffic control, every single
way to try and stop this is encouraged and good. I think the OP is a
step ahead by simply asking this questions.
My tips:
1) Block everything that you do not need (least open ports, least risk).
2) Check what you have open for specific security holes. Keep logs,
check them often, index them, make reports so you don't need to scroll
every single line (try Cacti, it is awesome).
3) Think as a cracker, if you would try to break your server, what would you do?
--
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------
--
gentoo-user@gentoo.org mailing list
