Jump to content

In need of real help with pop3


Albus
 Share

Recommended Posts

for the firewall, you might wanna try firestarter or guarddog for now. arnos firewall is a good script as is ipkungfu.

 

basically linux is linux. the same functions and rules apply. what you did in debian is done in mdk and done the same way.

 

when you select paranoid in mdk for example, it comments everything out of /etc/securetty this means no one can login directly as root. you have to su up. very secure, but it can be quite difficult to work with. thats only one example of one setting. of course paranoid affects many other settings. as do the other levels. this is why i recomend "normal" and then tweak it yourself. dont run any services you dont need. and try to comment out /etc/securetty. those you can do yourself, with out affecting your pop3 server. any servers or services like http or pop3, i'd run in a chroot jail/sandbox. this way they are confined to that area only. if a hacker gets in, he only has access to just that area.

Link to comment
Share on other sites

  • Replies 33
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Right, I understand that much. Here's my delima. When running debian, these are the only services running at boot:

 

syslogd

klogd

statd

svscan

mysqld

popa3d (standalone pop3 daemon)

postfix

sshd

atd

cron

apache

 

inetd has been neutered with K20's so it doesn't start period. With this in mind, there are obviously some grave differences between that and how mandrake works. For one, I cannot find a standlone pop3 daemon for it that I can jail. Neither will it compile Darren Butler's daemontools and tinydns (I really don't like bind....). Without inetd, a lot of other things don't start either, and that was by design when I assembled my debian server. Fewer holes. This is the kind of scenario I want to build using Mandrake, except for the addition on the display manager and font server stuff, as well as the few other things x/kde needs. I do like the new kernel features of not being able to login as root etc. Debian didn't have that. Or at least, by default it didn't.

 

Here's a quandry for you. If I choose to install Mandrake using the "Absolute Minimum" option, and then use RPM to add what I need, one by one, I'd have a system similar in many regards to the debian one. However, RPM usage eludes me (boy is THAT backwards from the norm...). Without rpmdrake, how do I tell rpm to install a package from the cd-rom (Yes, I know to mount it first...) and will it still includes dependant packages automatically?

Link to comment
Share on other sites

forget the cdrom and get plf sources and other sources. see easyurpmi (yes this is a web site i am refering to).

 

you would use urpmi from the command line. its kinda like apt.

 

urpmi <packagename> to install a package

 

urpme <packagename> to remove a package.

 

you can add cooker stuff, but just keep in mind, its experimental and liable to break your system. but with cooker, your likely to stay bleeding edge.

 

 

you can get mdk to be just like debian, your just going to have to take the time to learn the subtle differences.

 

 

i'd suggest reading the mandrake documentation section. mandrakesoft.com you can probably skip over most and skim over some other parts, but there may be some parts you may want to slow down on.

 

also check out the linux administrators guide.

Link to comment
Share on other sites

the same docs apply. http://www.mandrakelinux.com/en/fdoc.php3

 

enjoy :D :beer:

Link to comment
Share on other sites

linux system administrators guide http://www.tldp.org/LDP/sag/html/

Link to comment
Share on other sites

none. you can do that with any editor. just comment out /etc/securetty. to do this by hand all you need is an editor and an understanding of chmod.

Link to comment
Share on other sites

Yeah, that part I got. I just commented out all the entries in securetty to keep root from logging in anywhere, even locally, but I'd still like to control who can run the su command in addition to that, as well as apply a similar principle to other proggies, like cpp, x, and so on. Let me state what my approach would be and see if it jibes...

 

1) Create some new groups like susers (for su support), cusers (for compiler support), and so on.

 

2) Adjust the ownerships and privileges for the individual proggies such that only members of those groups can use them. For example, only those in the group susers can use the su tool.

 

3) Add members to the new groups, as a secondary group, so that thier initial dedicated group remains untouched.

 

Is this about right?

Link to comment
Share on other sites

if you take out, in the bash profile, the su and make it an absolute path, that also helps.

 

as to the proposal, try it. just know the GID's like for wheel and the GID for a regular user.

Link to comment
Share on other sites

/etc/... isnt a group, but a directory. a group is soft linked to various directories. much like java. the java plugin is typicaly in the /usr/... directory. this is not part of the home directory. when set on paranoid, the home user cant even veiw things outside of the home directory. typicaly the permissions for /usr/... are drwxr-xr-x (where d is directory). where a user GID might be 500 and grant you access to veiw files, just not write access. compare your user account GID to say X. X should be, or have similar group priveledges as root. X is a group, and account, you just dont log into it.

Link to comment
Share on other sites

Your system seems different from mine. I have a file named "/etc/group" which has all the user gruops listed in it. That's what I was talking about.

 

While I understand what you just said, and know that it occurs, I do not know how to make it happen on my own. For instance, on my mahcine, right now any user could "cd" to, and "ls" the contents of any directory on the system. I have no clue how to change that without accidentally destroying it. Some services require certain levels of access and figuring out who they are and what levels are required is beyond me at this point.

 

Let me make this simple by stating one task at a time, and see if sombody can tell me how to do it step by step. (Googling for answers just doesn't help)

 

Task 1: Adjust the system so that, by default, newly added users cannot run "su", "cpp", and "make".

 

I'll glean other restrictions from the answer to this. Please, if anybody has the answer, don't hesitate to jump in. Don't let linux_learner go this alone. He's helped tremendously already.

Link to comment
Share on other sites

the linux system admin guide would be good for you to read.

 

i do have /etc/group. it just contains the settings for each group.

 

i think your making this harder than it is.

 

as long as you make backups and note the permissions as they were before any changes are made, you can always fix it.

Link to comment
Share on other sites

I'm dense. I need examples. Reading alone doesn't work for me. :(

 

Let's say I have five users on my system and I want to keep them all from using "su" except the one called "drew" what do I do?

 

I'm sorry if I'm sounding like a broken record at this point, but the admin guide isn't written for people like me.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...