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