Securing archlinux scripts and help

jlvsimoes · 2003-03-05 06:43:02

Is it possible for someone ( the developers ) to include some kind off prebuilt firewall
On the arch and maybe some things like having syslog have logs " defaulted " on vc12
And some other things that I do not now remember
Hum … lets see is someone planning to do a " script " were a user can choose
" I am paranoid"
" I am not so paranoid "
"I m quite safe no security for me "
I realize that building something like this can be hard
But a paranoid mode using the most safe settings that people can think off , a not so paranoid mode just to be safe I think can be a most welcome feature
And I say this for one reason only a can think on one or two things to secure my system
But I do not now every thing or do I have the time to " read " research about it
And yes. I m officially in the most possible paranoid mode as I can be regarding my knowledge
Ps: BluPhoenyx as you may bean guessing by now I have been hacked the hard way

bodgy · 2003-03-05 07:28:50

I have said 'no' because to me there are more than enough security 'scripts' already available - like MonMotha's for instance - or firewall programs - like Firestarter.

I have always 'rolled my own' though...

Blaasvis · 2003-03-05 10:24:00

well i don't need it at all, i roll out my own maybe a package with a firewall script would be nice but if you only use it as desktop with a hardware route between internet and lan (like me) it would not be usefull too include it one base install .

jlvsimoes · 2003-03-05 14:13:59

Like you guys I to relayed on the " I m just a desktop user " no need for that
But …… surprises can happen and yes a firewall is minimal for most people.
Some other things can be changed, used to make AL and other Linux systems more secure
Maybe a group off user can take in to there ands building a package " script how to read me something " that can cover some security aspects and as I posted e do not now everything and a guess that no one can remember every thing and use every methods to make is system more " secure " my vote is still yes

Rouslan · 2003-03-05 22:24:30

I guess "no," because people in Arch are already experienced and know what's going on. Personally, I set up an iptables firewall for myslef without any troubles. I guess that experienced people won't even allow some script they never saw to control their security and they want direct access to conf files.

BluPhoenyx · 2003-03-05 23:04:08

I can't disagree that security is an important issue. I suspect that I might disagree with another persons methods in implementing the security I should use, even though I can still modify or even eliminate the setup. Security is such a volatile topic with large variety of opinions that it might be difficult to get a consensus on what is a minimum requirement.

Of course, this being Linux, user support is often encouraged. If a user wishes to contribute such a script they have a number of options. It can be an unofficial (maybe? I don't maintain these) package. Small scripts can be posted here for people to use (perhaps in the network section). Even better might be a small html page with whatever support the user feels necessary.

There is one simple option for those who don't understand firewalls. You can use the program Firestarter. I think there is a version in the packages. It actually has two real modes of operation. The GUI system can make and run the firewall but you can also run the final firewall.sh script yourself. The resulting scripts are pretty decent and there are quite a few options for items such as NAT and filtering an server support. If nothing else, it's an interesting method to learn more about using iptables.

jlvsimoes · 2003-03-05 23:30:26

I guess "no," because people in Arch are already experienced and know what's going on. Personally, I set up an iptables firewall for myslef without any troubles. I guess that experienced people won't even allow some script they never saw to control their security and they want direct access to conf files.
_________________
Rouslan

But there are people who are not experienced
I consider myself a complete newbie
Picture this … AL works very well and pacman is the coolest thing managing packages
So is only natural that Al starts been used by all kind off users experienced or not
The firth thing I did was to disable tcp listening on xfree s startx and aft her the recent update to X I needed to reset the option again, lets see … second I created the
suauth rule set to prevent people to gain Su except the user I need to be Su capable
created porttime rules configured aide , set a firewall and some other things
But there are more things security related and lets be honest no one knows every thing
It's obvious that 2 minds think better than 1
And ok I get the picture every man for them self's
Here is a good starting point for not so experienced user
http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/
http://en.tldp.org/LDP/solrhe/Securing- … cured.html
http://www.lids.org/ --------> I will try to implement this on my system, does anybody use it?

BluPhoenyx · 2003-03-06 01:13:14

Yeah, it really looks like everyone for themselves here but it really shouldn't be that way. One problem, as you yourself mentioned, not everyone knows everything regarding security. Another is system complexity and yet another is actual security requirements for a specific system.

The biggest advantage to anyone concerned with security on their systems is acquiring the proper knowledge to implement it to meet their needs. This doesn't mean going around and turning off options because you think they are a problem, although if it makes you feel more secure then that in itself is something. It means taking some time to learn and understand what security vulnerabilities are, which ones are (or may be) possible with your particular setup and what options are available to control them. As well as setup, you need to consider options for the maintenance and surveillance of the system and any particular security issues it may have.

As you research, you will begin to understand that there is not a simple answer to this complex issue. If Arch Linux were to attempt to 'fix' this as some other distro's have we would be doing a disservice to the users. Some would think their system to be safe which cannot possibly be guaranteed and others would think the distro is lousy since it attempts to offer lousy security options. At best, we can offer the most useful packages and expect the user to 'help themselves'.

Of course this is simply my opinion. Other developers may have better ideas on this.

jlvsimoes · 2003-03-06 01:39:51

Sure thing. Maybe a security tip here and then: P
By the way I m making a lids kernel package and a lids user end package
This is not easy but I guess I can do it " hope"

jlvsimoes · 2003-03-07 03:45:01

lids kernel is build the user end is killing me
http://www.c2i2.com/~dentonj/system-hardening
cool reading

BluPhoenyx · 2003-03-08 08:57:22

jlvsimoes wrote:

.....
And yes. I m officially in the most possible paranoid mode as I can be regarding my knowledge
Ps: BluPhoenyx as you may bean guessing by now I have been hacked the hard way

Sorry to hear about the hack. Somehow I missed the mention of it when I first read the thread. You didn't mention how they hacked your system and whether any damage was done. I only ask because I think your request is a valid one. I don't know if it's something which can be fixed with a simple script (at least not properly.) If nothing else, perhaps we can provide a little more info on this area or maybe some urls. I suspect this will require Arch user input due to the huge variety of network connections available.

sarah31 · 2003-03-08 11:16:25

i have a firewall script on my site i use it on my router box it is quite good but unfortunately my explanantion for setting it up is incomplete.

jlvsimoes · 2003-03-10 01:26:23

if you can point me out some nice reading i will read it
sarah31 thak you but firewall only is futile

I do not now e some day I rune lastlog and " exim " logged from a pts using a ip that I did not know it was a ip from another isp according to R.I.P.E .I m not fully aware on the method the guy used but I m pretty sure that I was root kited I have not allot of info about the hack. I clean up my hard drive reinstalled. And started taking security measurements
I'm plain out off ideas so far I can only say this no one can log anymore.
If someone manage to brute force my root password " it takes time and I chance all passwords at a regular basis " they have to log as my default user so they have to brut force that one to. If some other user lets say "mail" manages to su this will apen

# Kick and ban users that are UID 0 but are NOT root!
if [ `id -u` = "0" -a `echo $USER` != "root" ]; then
#Lock the user out
passwd -l $USER

# Save as much info as possible
date >> /root/SHIT
echo "" >> /root/SHIT
ps auxww >> /root/SHIT
echo "" >> /root/SHIT
w >> /root/SHIT
# Let EVERYONE know
wall << EOF
*********************************************

$USER has gained ROOT access!!

*********************************************

EOF
# Let the luzer know
echo -e "annYou are _NOT_ root!!nna"

# Kill the processes they are running
Skill -9 -u $USER

# Shutdown the interface
adsl-stop
# This should be redundant
logout
exit
fi

# Attempt to catch those that su
alias su="su -"

I did a long consuming time chmod 000 some stuff: P and a lot off chattr +I
I now run aide on a regular base and its not on default place the db is not on the hard drive. locate and find are not allowed got myself a backup off /bin /etc
No services running got everything logged.
Using patched kernel using http://www.openwall.com/ did not liked lids and mi head still hurts from attending to make the user end pkg got the iptables that is decent and some other stuff, dam security is a full time job

ps : Only my ego got broken: P javascript:emoticon(':oops:')
" [mail@routty mail]$ su
Access to su to that account DENIED.
You are not authorized to su root"

BluPhoenyx · 2003-03-10 22:49:48

In case you don't know, 'exim' is an email transfer agent. If you're not using it you should uninstall it (I did) or at least make sure the daemon isn't running. While you're doing this, you might as well check the other daemons you have running. IMHO, if you don't need it then remove it if possible.

BTW, did you verify the hosts.deny and hosts.allow files to restrict access?

You can do a simple test of the firewall or verify ports at the following url. It should give you some idea what ports are open. Note that I have never tried this site with an adsl connection.
https://grc.com/x/ne.dll?bh0bkyd2

sarah31 · 2003-03-10 23:16:50

or just use nmap/nmapfe to determine which ports are open.

and i say again the iptable script on my website is damn good so if you are safe and hidden underneath the fire wall the firewal adds that extra security of being invisible. its a big and involved script.

you were talking iptables so there you are a great big iptables script ready to go.

BluPhoenyx · 2003-03-10 23:59:50

sarah31 wrote:

or just use nmap/nmapfe to determine which ports are open.

It may seem like overkill but I would consider using both local and external scan.

bodgy · 2003-03-11 08:22:18

General rule of thumb for security - If you dont know what it is (or you dont use it) - disable it. If it doesnt adversly affect your install - then you didnt need it.

Thanks Sarah for the firewall script - I will go through this when I have some time - it sure looks like it beats my simple "roll my own"

jlvsimoes · 2003-03-11 23:25:53

No ports just 80 do not now to close it and leave apache running
All services are closed minus http do not now how to make it invisible
cat /etc/hosts.deny
#
# /etc/hosts.deny
#

ALL: ALL: DENY spawn (/usr/bin/logger "%d[%p]: %c tried to get in.")

# End of file

I'm going to see that script Sara31
By the away take a look at the one im using
At http://routty.dhis.org/firewall and if its down
http://jlvsimoes.home.sapo.pt/rc.firewall

BluPhoenyx · 2003-03-12 23:00:53

While this is a little more than light reading, here's a couple of links for those who want more info and the chance to branch out and learn even more. I ran across a copy of the FAQ in my archives which reminded me of this thread.

http://www.sans.org/resources/idfaq/
This url is to a FAQ with a variety of info on system security.

http://www.treachery.net/articles_papers
This url has links to some interesting papers on IDS. In particular, it has a paper on 'snort installation and basic usage'. Inside this paper are a couple of other links for securing Linux systems which might be useful (I haven't verified this though.)

jlvsimoes · 2003-03-13 19:47:04

thank you im going to be away for couple off years reading the pdf

bodgy · 2003-03-14 04:08:58

Instead of DENY (which will respond that the port is Closed) would it not be better to use DROP - which will drop incoming packets and hence give you a 'stealth' system ?

jlvsimoes · 2003-03-14 23:21:35

Hum ... that's /etc/hosts.deny I don't really think that I can drop in there
But I may be wrong: P thank you

BluPhoenyx · 2003-03-16 06:43:01

No, that's DENY request which should signal access is denied whereas DROP simply sends the request to the bit-bucket. Basically, DROP doesn't even validate the IP address so the other system will not know if it's a valid address. This is, of course a simple answer.

Gyroplast · 2003-05-13 12:24:47

Instead of an utterly useless, host-based packet filtering mechanism, it's just fine as it is right now. After a normal Arch-Installation, there simply aren't any services running. Presto, remotely _absolutely_ secure, by default. Even better than OpenBSD, which at least has OSSH open remotedly by default.

Instead of wasting your time with remote nmap scans (or even worse, this GRC crap), you should just use the available local tools. netstat, fuser, ps. Nothing can give you better answers about running services than the system they're running on, right? Right. Unless you're already rootkitted of course, but that's a different story. And if you start installing software after the base system installation, you know what you're adding, and you need it to be available, so filtering is pointless. Just bind stuff like the MTA to 127. only, and you're nice and safe.

The use of a packet filter on a single host is pretty close to nil, as the TCP stack and some kernel options do all the hard work for you already. rp_filter to eliminate source routing, SYN-cookies, SYN-requests to non-running services are correctly handled with an RST, etc. etc. What else could one want. Iptables and friends are really only needed to correctly configure forwarding and redirection of all kinds, and that is rarely needed on single hosts. Transparent redirection to locally bound proxies would be such a case, for example.

BTW, DROP is stupid. It breaks the Internet.
You do NOT want to believe this "stealth" hype, read up on TCP/IP to find out why this is utter bullshit. Hint: "No, you can NOT connect to this port" is non-negotiable. REJECT with --reject-with tcp-reset does the trick in a TCP-conform fashion, but it's superfluid since that's exactly what your machine is already doing without iptables.

Greets,
Dennis

netkrash · 2003-05-13 14:42:29

I choose NO because every system is diferent and every user has his own needs.

Ex. Some users will use samba, some others ftp and web, etc, etc, etc..

Developers can't set up a general firewall script by default of instalation because it will reduce the productivity of too much end users.

Or this forum will be full of questions like: hey i want to setup ftp and everything works fine but i can't connect to it!

Or: why i can't ping my fresh archlinux install?

BUT yes, it would be NICE to have a dialog script to setup a firewall by users who knows what they are doing.

If a user don't know what a firewall is then hi/she don't need it (most of the time).

A nice security feature would be to use a secured kernel. Not the fresh vanilla kernel from kernel.org i mean that kernel patched with security patches (to prevent some root kit modules among other things).

There a lot of security issues and arch is focused to be easy to handle and keep up to date with lastest stable and optimized packages. Anyway we should think about security as an important goal and make archlinux a perfect distro to desktop users and to be a powerful, fast and secure server.

greets,

Arch Linux

#1 2003-03-05 06:43:02

Securing archlinux scripts and help

#2 2003-03-05 07:28:50

Re: Securing archlinux scripts and help

#3 2003-03-05 10:24:00

Re: Securing archlinux scripts and help

#4 2003-03-05 14:13:59

Re: Securing archlinux scripts and help

#5 2003-03-05 22:24:30

Re: Securing archlinux scripts and help

#6 2003-03-05 23:04:08

Re: Securing archlinux scripts and help

#7 2003-03-05 23:30:26

Re: Securing archlinux scripts and help

#8 2003-03-06 01:13:14

Re: Securing archlinux scripts and help

#9 2003-03-06 01:39:51

Re: Securing archlinux scripts and help

#10 2003-03-07 03:45:01

Re: Securing archlinux scripts and help

#11 2003-03-08 08:57:22

Re: Securing archlinux scripts and help

#12 2003-03-08 11:16:25

Re: Securing archlinux scripts and help

#13 2003-03-10 01:26:23

Re: Securing archlinux scripts and help

#14 2003-03-10 22:49:48

Re: Securing archlinux scripts and help

#15 2003-03-10 23:16:50

Re: Securing archlinux scripts and help

#16 2003-03-10 23:59:50

Re: Securing archlinux scripts and help

#17 2003-03-11 08:22:18

Re: Securing archlinux scripts and help

#18 2003-03-11 23:25:53

Re: Securing archlinux scripts and help

#19 2003-03-12 23:00:53

Re: Securing archlinux scripts and help

#20 2003-03-13 19:47:04

Re: Securing archlinux scripts and help

#21 2003-03-14 04:08:58

Re: Securing archlinux scripts and help

#22 2003-03-14 23:21:35

Re: Securing archlinux scripts and help

#23 2003-03-16 06:43:01

Re: Securing archlinux scripts and help

#24 2003-05-13 12:24:47

Re: Securing archlinux scripts and help

#25 2003-05-13 14:42:29

Re: Securing archlinux scripts and help

Board footer